ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on March 02, 2010, 09:04:44 AM

Title: Encryption
Post by: Josh @ Dreamland on March 02, 2010, 09:04:44 AM
Despite what I'd like to believe (and maybe even what I'd like you to believe), making something in C++ doesn't mean it can't have its resources modified or even stolen. ENIGMA (being C++) makes sure that code isn't such a resource. No one can decompile your game. However, we do have a problem.

Because ENIGMA will be a regular system, unoptimized output executables will have the same basic format. Furthermore, because it is open source, an encryption algorithm is even more futile than it was in Game Maker. I can't just hide a seed and expect everyone to give up before finding it.

Now, in R3, rooms were stored as an array in the source code. This means that it would take a good amount of skill to modify them, but it's still feasible. Someone with a decent knowledge of how GCC handles such could probably make a tool to do it. If ENIGMA were to inherit GM's better disassemblers, we could possibly face problems with such (the hope is that since no one can get all of it, no one will write a tool to get some of it).

Fortunately, as long as you let GCC optimize your code, it should be too irregular to be removable by an automated tool. (Even if it was removed, it couldn't be decompiled other than manually, don't worry.) However, I'm not sure about unoptimized code. It would be far too much work to decompile it back to EDL (especially with the C++ goodness that gets thrown in), but it may be possible to remove entire events and replace them (making games easy to mod or cheat).

What's more, unified sprite and sound encryption is worthless. Pidgin doesn't encrypt passwords it stores for users because the developers understand that in an open source project--and for that matter, in any other project--doing so accomplishes nothing. So ENIGMA can not have a unified encryption system to protect non-code resources.

Personally I don't see this as a problem. However, I know one of the reasons people are in awe of the idea of C++ is that they think it will protect such resources. I can't think of a decent game whose resources aren't an open book (there are many Windows resource extractors. Not to mention, you Valve fans, think Garry's Mod). But, I can think of a way to fix this.

R4, as some of you are aware, will allow you to define C++ functions for use in your game. This is a great way to do with DLLs (but do note that external_define has been done for months). I could allow the implementation of a function called resource_encrypt (and one called resource_decrypt) to allow users to define their own algorithms. This would be done with the hopes that such an algorithm would not be in a uniform position in the executable every time. :eng99: If it was, it'd be as simple as writing a tool to look for like bits of code and extract the new stuff. Though they could still not decompile your code (and I am talking about the algorithm), they could call the decryption algorithm themselves, right where it sits, on whatever resources they extracted. Frankly, I think our better bet is to not waste time on encryption.

To protect room tampering, ENIGMA could hard code their creations in a large function (which would be optimized hopefully to un-uniform gobbledy... but it could still be replaced by a determined expert).

The function could be implemented conditionally; only executing if it has been defined by the user. This is just an idea I'm putting out, thoughts welcome. Especially from assembly people.

TL;DR: Paranoia resulting from the idea of really talented people wasting their time hacking games. Mods are inevitable, resource extraction is hard to stop, decompilation highly unlikely (as in, no one will waste their time on a huge game, and automation is impossible).
Title: Re: Encryption
Post by: retep998 on March 02, 2010, 12:11:17 PM
All I care about is my speedy c++ code.
I couldn't care less if someone tries to modify or decompile or rip my game.
You can never stop them completely.
Just work on getting Enigma to work, and let the userbase create it's own protection.
Title: Re: Encryption
Post by: Rusky on March 02, 2010, 01:30:40 PM
Umm... You can't prevent it; why bother? Go for extensibility and ease of use rather than false security.
Title: Re: Encryption
Post by: Grundoko on March 02, 2010, 02:16:55 PM
Performance over False Protection
Title: Re: Encryption
Post by: luiscubal on March 02, 2010, 02:40:04 PM
Even if you can't prevent it, C++ already provides decent protection.
I mean, Game Maker games were decompiled because they were ridiculously badly protected. I mean, COMMENTS in decompiled code!!?

Let's look at the facts:
1. Compiled games have no comments
2. A significant portion of the names used in ENIGMA will be gone, namely local variables.
3. The code formatting is gone forever

So indeed, the *code* is protected. And if huge-scale proprietary games have their resources unprotected(technically, they're impossible to protect), why bother to protect them in ENIGMA?
Also, if the infringer is in the USA, you can always use DMCA to prevent decompilation.
Title: Re: Encryption
Post by: RetroX on March 02, 2010, 04:58:47 PM
I don't care about encryption; I'll probably make all of my games open-source, anyways.
Title: Re: Encryption
Post by: IsmAvatar on March 02, 2010, 05:25:10 PM
While an automated encryption system would be infeasible for the reasons mentioned above, a user-interaction encryption is still relatively feasible. For example, any password-based encryption system, a user-provided seed, or an encryption based on a user-provided input (such as xor'ing 2 files).
Whatever the case, I think most of us could care less about encryption - we'd more readily implement our own if we needed it.
Title: Re: Encryption
Post by: Josh @ Dreamland on March 02, 2010, 07:04:56 PM
I'm afraid to reread my topic considering the replies are exactly what I was trying to convey. ;_;

Really, my biggest fear is room tampering.
Title: Re: Encryption
Post by: Micah on March 02, 2010, 07:09:29 PM
most of us could care less about encryption
I think that most of us couldn't care less. If we could care less, we would care at least some.
Title: Re: Encryption
Post by: RetroX on March 02, 2010, 08:44:22 PM
most of us could care less about encryption
I think that most of us couldn't care less. If we could care less, we would care at least some.
I think that your statement seems to be in reverse. :P
Title: Re: Encryption
Post by: freezway on March 02, 2010, 09:03:02 PM
I'll just open source my games anyway, i dont want slow(er) and not decompilable. Just out of curiosity, how is R4 coming?
Title: Re: Encryption
Post by: Josh @ Dreamland on March 02, 2010, 10:12:23 PM
Sometimes one bites off more than one can chew. Like including windows.h. It introduced a few concepts I saw in Boost but was afraid of. So those have been implemented. Other than that, it's going pretty swell. :P

Anyway, it's nice to see that those who hang around these boards are more down-to-earth.
Title: Re: Encryption
Post by: The 11th plague of Egypt on March 04, 2010, 10:17:56 AM
Com'on people, it's good to see someone design for securety. However, cheating is only harmuful in multiplayer games,
and I don't see any WoW coming out of GM coders any time soon. But, if you really care, you can just implement some
server-side checks, right?
Title: Re: Encryption
Post by: Rusky on March 04, 2010, 10:40:31 AM
Designing for security your own security is one thing; designing for everyone else's is something else.
Title: Re: Encryption
Post by: Micah on March 04, 2010, 05:58:42 PM
But, if you really care, you can just implement some server-side checks, right?
This is really the only non-stupid thing to do even when you have super-fancy-compiled-encrypted code.
Title: Re: Encryption
Post by: Josh @ Dreamland on March 04, 2010, 06:07:50 PM
Hmmmm... ENIGMA would be great for server side code if the graphics system could be disabled as easily as I intend...
Code to implement the framework for a set of simple checks could be integrated into the parser or something, but I'm not making any promises until I have a plan for such. Doesn't help that I hate coding online things.
Title: Re: Encryption
Post by: Rusky on March 04, 2010, 07:16:08 PM
That makes no sense. It's input validation- the parser has no clue what to check for. What would be useful is a library of helper functions like inRange (more complicated than that but you get the idea).
Title: Re: Encryption
Post by: Josh @ Dreamland on March 04, 2010, 07:20:40 PM
I could have worded that better. - fix'd

I meant that it could do such things as find locations where given variables are modified. The conditions of the set could then be relayed to the server-side module. That could of course be spoofed, but it'd be a step.

I think a more comprehensive idea would be to have submit the locations of certain key objects along with any changes; the server would allow a small tolerance accounted for by lag. No one likes missing a shot because the server and client disagree on a location.

So, a function could be defined for call when a certain variable is set or action is performed requesting a double check on locations and allowing the server to double check the math.

Frankly, I'm not sure how convenient such an idea would be, hence my not promoting it or "making any promises."
Title: Re: Encryption
Post by: Rusky on March 05, 2010, 10:43:28 AM
Basically, that'd be adding dependent typing (http://en.wikipedia.org/wiki/Dependent_type) to EDL.
Title: Re: Encryption
Post by: Josh @ Dreamland on March 05, 2010, 03:26:50 PM
The only way that could have anything to do with typing is if I made a class that did the checks on operator=, which wasn't what I was suggesting.
Title: Re: Encryption
Post by: serprex on March 05, 2010, 06:39:35 PM
It's funny when people think they're introducing some advanced concept, and so they include a wiki link
It's also funny when people forget the magic of hashing
Title: Re: Encryption
Post by: Rusky on March 05, 2010, 11:05:15 PM
It would be static analysis attaching constraints to certain values. You'd basically be extending their types. For example, the type of a variable in a certain context would be "int between 3 and 5," rather than just "int". I posted the wiki link to prevent this exact situation, serp. Not to look super-smart.
Title: Re: Encryption
Post by: Josh @ Dreamland on March 05, 2010, 11:08:46 PM
That's a tad more specific than what I was describing. It'd also require a lot of template instantiations.
Title: Re: Encryption
Post by: Micah on March 06, 2010, 01:23:59 PM
The only way that could have anything to do with typing is if I made a class that did the checks on operator=, which wasn't what I was suggesting.
Really? You honestly think that operator= is the only time types are checked?

Arguments to functions have types, you know...

Also, serp, he posted a wiki link so that if Josh wanted to implement this, he'd pattern it after stuff that works, not badly reinvent it.
Title: Re: Encryption
Post by: Josh @ Dreamland on March 06, 2010, 02:01:54 PM
I don't see why you're distinguishing operator= from any other member function. Operator= (and the implied other assignment operators) would just be the only good reason to use a type for this, as it would prevent me having to parse in a new block of code myself.
Title: Re: Encryption
Post by: Rusky on March 06, 2010, 02:34:02 PM
That's a tad more specific than what I was describing. It'd also require a lot of template instantiations.
What you described is a form of dependent typing, and it wouldn't require any template instantiations if the parser did it, which would be the right way (templates would generate multiple copies of functions that use the system).

You also said:
The only way that could have anything to do with typing is if I made a class that did the checks on operator=, which wasn't what I was suggesting.
miky was correcting this misunderstanding. It would have to do with types in the way I explained, not by checking in operator=.

The word "type" in "dependent type" does not have to do with C++'s type system. It would be an extension to that type system that does not exist in C++, even if it eventually got implemented using C++ semantics. If you added some kind of constraint checking to help with server-side code, that would be dependent typing.