Encrypted Archives

Started by G_G, March 14, 2011, 08:35:09 am

Previous topic - Next topic

Blizzard

If we use a fixed size key and can compile force it into the DLL to reserve us zero-bytes across the DLL that we will literally fill up during compilation... we will still make it easy for hackers because they can just compare 2 DLLs, find the differences and extract the keys for both. ._. Any ideas on how we could handle this? The problem here is that we need to hide the public key of the encrypted data. :/
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

is there any way we can get the dll to 'Generate' the key instead of holding it internally and passing it along? I know it not as simple as putting a few function in because compilation will tempt to condense those function down to their result.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

We should inform ourselves properly about obfuscation. I just took a quick look around the Internet and one of the methods to do this is to generate the key based on function calls, "dead blocks" and other stuff. Check this quick slide presentation out: http://logic.pdmi.ras.ru/~yura/en/stuttgart-talk.pdf You should also check out the links given at the end of the presentation. We will most likely have to add just one key into the DLL and hope nobody cracks it. :/ There has to be a good way to hide the key.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

September 18, 2011, 05:42:13 pm #23 Last Edit: September 18, 2011, 05:59:01 pm by Ryex
Ok, I just had an idea. In my head it seems to make it near impossible for someone to obtain the data from the files with out reverse engineering ARC to get the source code.

first things first:
only the game exe should be able to encrypt and decrypt data.
when ARCed generates an encrypted archive it takes a user string generates a numerical sequence and uses that sequence in a process call to the ARC exe.

so ie
Game.exe -e list|of|files|to|encrypt 1754932017649


there is no reverse of this to get the un-encrypted files only the load_data function tied into the ruby scripts can access the decryption function

2)
the encryption key is never stored anywhere in it's full form.

3)
to get the key we call a sequence of functions that when called in a specified sequence generate a key. the sequence passed to the encrypter tells it the sequence to call these functions in to get the key.

4)
the function used in the decryption process are never publicly available in the dll so linking to it will NOT give you access to call these functions. the functions will only be called internally when a file is recognized to be encrypted

5)
now we store this sequence somewhere. while this sequence IS easily obtained like the DEADCAFE key in RGSS was with it alone it is impossible to obtain the real keys for the decryption with out reveres engineering the set of functions that are called to make the key. this IS possible but only for a significantly motivated and extremely knowledgeable individual. we can the task harder for them and thus less worth it by using a code obfuscator to make following these function calls in the byte code (thus finding the byte code that needs to be reverse engineered) more difficult.

I'm not sure if that made sense to you guys but in short this method obfuscates the key quite significantly form the public AND allows uses to have unique encryption keys


EDIT:

this system is only secure if all encrypted files are combined into an archive of some sort or the scripts file made so it can't be replaced. other wise a fresh script file containing instructions to load and dump the encrypted files in non encrypted form could be encrypted with the sequence which would be easy to find and replace the existing scripts file with their freshly encrypted one so as to "inject unsafe code" like a virus. once the code is in there the encryption key doesn't matter.

this is a major flaw. perhaps you guys can take parts of this idea or build on it to remove this flaw.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

ForeverZer0

I use {smartassembly} for .NET projects, and it has a setting for a dynamic proxy. The proxy is created dynamically at run-time, and all external and public calls are made through it. It supposedly prevents any type of post-build modification, because it screws up the proxy, rendering it useless.  I don't really know how this achieved, nor if we could implement such a thing in ARC, but it may be another avenue to look at.
I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

I was thinking to obfuscate a hardcoded key the same way Ryex already described, to generate it through a series of function calls. In fact I was thinking of a seriously long key (like 128 characters) where we spread the functions across classes to make things every more difficult. We can mess even with the decryption by using a function pointer and passing it across some classes before we actually call it. This is nasty to reverse engineer and we should be able to deflect the simplest attacks to keep out 99% of the hackers. I think we shouldn't implement the encryption function in the DLL at all. ARC::Data.dump is fine, but without the encryption.

The scripts will be in some sort of archive (other files won't), but we have to figure out a way how to disallow simple replacement. I see no other way than generating some sort of hash or fingerprint. But then again we have to problem where to put that one and we are back at square one where we would have to modify the DLL. :/ The only way I can think of is that we generate a file with a special key that is generated together by using all files included in the project and the DLL won't load a scripts file if it was replaced because it couldn't have been generated with the same files. Even if the hacker replaces the key file, he won't be able to load the scripts as the key file will not work with the other files (because it regenerates that hash key using the data files so they key won't match again).
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

oh, so it would require a key file that contained a hash created from all the files that were encrypted together so that if a file was replaced the resulting fingerprint of the file together wouldn't match. This idea sounds like it could work, but it suddenly makes it hard for the creator to update individual files... unless of course the dll contains a way to modify the key file correctly so that file contents could be replaces if it was done from within the game engine.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

Not necessarily. The creator just has to make sure he ships all the changed files and the file with the new hash key. :)
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

G_G

Well maybe we should just have 1 single key then, like you said created globally across several functions and classes. I bet we could combine 20 sex terms for the key and no one would ever guess it. :V
In all seriousness though, if allowing people to have their own key is too difficult, one key would be fine, we just have to make it more secure and longer then DEADCAFE.

Blizzard

Let me explain: We need two different keys. One is the decryption key to protect the data. That one can will be generated through a series of functions, that's the DEADCAFE equivalent of RMXP's key. The other is a hash key to make sure nobody replaces the scripts with their own and accesses the decryption method from the outside. Basically a hacker would have to both find the DEADCAFE equivalent key, replicate the decryption algorithm or replicate the hashing algorithm to decrypt the resources.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

It sounds like a pretty solid idea. but can we do it? do we have the parts to rebuild him?
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

Who cares about how RMXP does it. We're probably going with RSA. We'll just obfuscate it a bit here and there by spreading it across functions and methods within other classes and we'll mess around with function pointers. It will not be impregnable, but it will keep out 99% of the hackers (not noobs).
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

nothing is impregnable, the point is just to make it too hard for anyone but a skilled and VERY motivated person to feels it's worth it and put forth the effort.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

Exactly. If somebody cracks it, at least we know somebody who wants to learn and is dedicated did it and not some smart-ass thief.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

I had a small idea. should we perhaps package two game exes with ARC? one debug exe that can only run from un-encrypted files and accepts the -debug command line argument. and one that doesn't accept arguments and can only run form encrypted archives with a proper hash key that was built with the archive? this might make it easier to make, and perhaps harder to crack.
I'm kinda sleep deprived at the moment so I might just be being stupid.
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

We can just compile 2 exes without the need for an additional argument. One is the debug, the other is the release one.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

G_G

I think ryex wants the -debug argument in case people want to run their game without being in debug mode.

Blizzard

Quote from: Ryex on September 27, 2011, 12:53:32 am
I had a small idea. should we perhaps package two game exes with ARC?
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

the difference would be that one of the exes counld only run unencrypted files and could accept a -debug argument.
the other exe would NOT accept the  -debug argument and would only run from encrypted archives
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

I just remembered something. Do you know what package signing is? I mean this would be pretty much what we're trying to do here. Maybe it would be wiser if checked out how others did it and see if we can learn something or gather interesting information.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.