Suggestion for AGS 3.5 or 4.0: Encryption

[abstauber]

I've just read this thread about ags, scummvm and so on. The main reason for not going opensource with the engine was, that it will ruin the business modell of the commercial devs.

But has this idea been discussed before: How about encryption ?
You could generate a key for your game and if you want it on Scumm VM, share the key so the engine can decode it.
And if you want it safe, just spread a compiled version with the key built in.

So the secret ingredient wouldn't be whole source code anymore.
Could this work?

[Gilbert]

In fact, in pre-AGS era (i.e. AC), room files could be password protected so other people couldn't load it up with RoomMake. It's just not very useful (at that time, also I think that implementation was very basic) so this feature wasn't brought up to RoomEdit.

Still, I doubt the usefulness of adding encryption to AGS games though. An engine (be it AGS or ScummVM or whatever) being able to run an encrypted AGS game when the key is given means that the files are open for people to investigate already. Also, I think in recent versions of AGS, the compiled games won't contain information like the original scripting sources any more, so at least that will provide some minimal protections.

[abstauber]

Maybe I should point it out a little more.

1st case: a developer who doesn't care if their files get decoded
They share their generated key, so the engine can decode the game.

It still won't be an easy task, to build a decryption tool.

2nd case: commercial developers, who have to avoid that their files getting decoded
They don't share a key, use the typical compile process (engine + build-in key) but loose the benefit from platform independency. So the key isn't public and built into an exe and therefore safe. Or might it still be possible to extract a key from there on?

So the point is, you know, how the Engine decodes the files and runs the game, but it doesn't help you because you don't have the key.

The only other possibility for commerical devs, wanting ScummVM AND their secret kept, would be some key server stuff and that's definately not very popular.

[Pumaman]

The key would have to be built into the EXE in order for the game to be able to decode the files when you ran it

That's why it's basically impossible to encrypt or password-protect the game resources, since the password/key to decrypt them has to be stored in there too.

You could argue that it would provide a layer of obscurity since a hacker would have to find out where the key was located before they could use it to decrypt stuff -- but if the engine source code was open source then it would be easy for people to see how the game engine retrieved the key in order to do the decryption.

[abstauber]

Good point

So the only options would be "wine" or a nice guy who's porting the engine.
But not all nice guys have this amazing endurance, that you have (is AC/AGS already 10 years old?)... thus would wine be an option?

[Gilbert]

I have a little thinking about it, maybe we can put it this way (but it will complicate stuff):

As the main concern seems to be more like developers don't want the data of their games got hacked and studied, rather than preventing completely people to run their games, I think each room can be encrypted with its own key, if a room change is triggered where the destination is an encryption room, a proper key must be provided for the room to be properly loaded and decrypted. This can be done by introducing a new optional parameter as the key to room-changing functions like Character.ChangeRoom() and dialog script new-room command, etc.

Points to note:
1. The first room loaded in a game should not be encrypted. This way you don't need to complicate things like the need to run the engine with a key. If you want protection, just make the first room to prompt the user for a key and then proceed. This has a benefit that if people hack your game by say forcing the game to start in another room, the game won't start if that room is encrypted.
2. You can have different keys for different rooms, so hackers who are able to decode some of the rooms may not be able to decode others without further hacking. Of course, it is the developers' own bussiness to keep track of the keys, but if you don't want too much troubles you can use only one key also.
3. In this way you can even make games that are freely playable in some section but require some codes to play the remaining part (like those stupid shareware ideas).
4. Of course the keys could be traced, but it would be slightly harder than using just one single key when the game starts.

Of course, nothing can stand against real hackers, but that is something we know already.

[Misj']

First of, I don't really care that I can't play AGS games on my PalmPDA. Sure it would be nice, and I can understand why people want it, but personally I just don't care.

That being said...The only way to have proper and decent protection of the game's content in commercial games is if Chris were to provide two distinct (mostly unrelated) compilers that would allow for an open- and a closed-standard AGS format. That way the closed games can never be decompiled based on the knowledge gained from the open games. But I personally would really consider that more fuzz than it's worth. Particularly since the current compiler does the job really well, and why fix something that just isn't broken?

Of course if someone were to write an open-compiler-plug-in (that is updated together with AGS itself), that would allow people to choose between open and closed games...that's a whole different story. But I don't see it happen (because it would require Chris to open up AGS completely (with the exception of the compiler itself, or course)).

[RickJ]

It seems to me the simplest way to do something like this is to have two different output formats, one that is documented and one that is not.  There would then be one version of the runtime for each output format, the only difference being in the algorithm that reads resource info from the game file.    Except for this super secret algorithm both runtimes would be exactly the same.  The open format version runtime could be open sourced without compromising the closed version, which would be as secure (or insecure) as it is now.   

I am also curious about how the runtime porting process might be made easier.

[abstauber]

Not to mention that offering tools that break copy protections isn't that easy anymore. So even if those tools would exist, the majority won't have a chance to optain it. Well at least you won't find it on Download.com or brothersoft

[SSH]

Or CJ could just add support for the PhoneHomeCheckLicence("licenceserver.agscommercialgames.com") function 

[abstauber]

Or CJ could just add support for the PhoneHomeCheckLicence("licenceserver.agscommercialgames.com") function 

lol, or he convinces Steve Jobs to add AGS to the iTunes DRM family 

Now as I'm writing this - ags on the iphone...just... wow *drools*

[subspark]

I've mentioned this encryption idea before in a previous thread, but again, no one turned an eye.
Shame Chris has no help in designing this engine. I think the project managment side of the software could be taken much much further.
If I can remember what that old thread was from earlier this year I'll dig it up for you guys. I basically threw the idea at everybody that we could, in the editor, encrypt our files to a custom format with whatever file extension we choose.

Heres an image from that post: (The Ideal Project Tree)


An 'internal' project tree encrypted into a user defined/custom file format is the best solution I can imagine.
Sparx.

EDIT: I wasn't specifically referencing to using this type of encryption to allow an open source AGS. I just saw the title of this thread and posted accordingly.

[DoorKnobHandle]

I don't think any of this is in ANY relation to what it would bring us as AGS users. If you want your game to be that secure, go ahead and write your own engine. After all, AGS is a freeware tool and 98% of the games made with it are freeware, too. And for these games, it just doesn't make much sense to defend them like a fortress. Also, both music and all the art including the fonts can ALWAYS be ripped anyways, so the only thing this would prevent is that somebody took a look at your project itself or the code. And even if it's all encrypted and hidden away, a good hacker will always be able to gain access and publish a tool that helps others, it's like anti-virus software, it improves security but isn't totally secure at the same time. Adding such protection, in fact, may work counter-effectively, meaning it will actually motivate hackers to try it after all (much like alcohol laws in the US, where it's forbidden to drink under 21 and still minors get more and much worse drunk than where the age limit is 16 or 18).

Of course, if there were no other more important things to add to or improve in AGS, I would fully support dealing with this, but I'm afraid there are and all the ideas so far sound like they would take a huge amount of time and, as I said in the beginning, that does not stand in any relation to the use.

Was there even one instance where somebody's game was actually hacked? I never heard of anything like this and so I have to say I believe what the people suggesting this are doing here is satisfying some kind of technical fetish rather than actually thinking of and trying to help the end user.

No offense intended, please, I'm just trying to argument against this, please don't feel attacked. If enough people support this or anyone can supply me a good reason why it in fact does make good sense (enough to even come close to justifying the cost it takes to implement it all) then I'll be a supporter, too.

[Khris]

Completely seconded.

The only use for an encryption I can see is to hide the video files.

[SSH]

I know that the portals that sell Dave Gilbert's AGS games use SoftwarePassport to put a secure wrapper around AGS. This encrypts the whole executable and lets users play for an hour only. After that they have to pay to get a key that unlocks the game again and lets them play for longer. However, this software is expensive so Dave doesn't use it for downloads on his own site.

[Snarky]

I think Dave is moving away from the AGS engine, though (he lists an engine programmer as part of the team for his Mystery Playfirst game, due to be announced this week). That makes sense. For instance, he might want to be able to port his games to multiple platforms, stream them over the web, and embed stronger and more configurable security. However, I doubt that the application environment will ever be as powerful and streamlined as AGS.

I think the decompilation/ripping argument is a load of nonsense, personally, but if it really is a concern of some game developers (even if it's an irrational concern) then I guess we shouldn't spook those guys.

[Dave Gilbert]

To be fair, the decision to not use AGS for the Playfirst project wasn't mine.  All Playfirst game have to be written in the Playfirst SDK, so I had to hire an engineer to make an adventure game framework within that SDK.  The portability of the system is a major point in its favor, but I'd rather be using AGS. 

[Misj']

I don't think any of this is in ANY relation to what it would bring us as AGS users. If you want your game to be that secure, go ahead and write your own engine.

This made me laugh - I thought the correct sentence should be: if you want your game to be open, go ahead and write your own engine (since Chris wrote his own engine, and apparently he is concerned with the security of the games)

No offense intended

What he said

[Shane 'ProgZmax' Stevens]

There are plenty of third-party encryption tools out there that work just fine, so if you are making a commercial game and are worried about it, it's worth investing in one of them.  AGS doesn't really need built-in encryption for a very important reason:

once it is broken CJ would have to go through the process of redesigning it to make it secure once again.

This process would repeat over and over and each time there was a breach all AGS games compiled with that version would be like open books, whereas there are companies that provide encryption tools specifically and update them regularly.  Game engines rarely, if ever, employ any kind of detailed encryption for this reason and leave it up to the developer to protect their game.

[RickJ]

I don't think any of this is in ANY relation to what it would bring us as AGS users.

Go back and read the initial post.  Abstauber suggested that perhaps some form of encryption of the game files would satisfy the need/desire to maintain some degree of protection against people ripping resources from AGS games.   In the thread he references, that was the main reason  to not  open up runtime so that it would be possible for third parties to port it to other platforms.   What it would bring us AGS users is the potential to deploy our games on platforms other than windows.  Personally, iI suspect there are other, perhaps more complicated,  reasons for not opening up the runtime.

I agree that all this has nothing to do with DRMing (or whatever name you would like to use) of commercial games.