8

I'm writing a game that will have a lot of information (configuration, some content, etc) inside of some xml documents, as well as resource files. This will make it easier for myself and others to edit the program without having to edit the actual C++ files, and without having to recompile.

However, as the program is starting to grow there is an increase of files in the same directory as the program. So I thought of putting them inside a file archive (since they are mostly text, it goes great with compression).

My question is this: Will it be easier to compress all the files and:

  1. Set a password to it (like a password-protected ZIP), then provide the password when the program needs it
  2. Encrypt the archive with Crypto++ or similar
  3. Modify the file header slightly as a "makeshift" encryption, and fix the file's headers while the file is loaded

I think numbers 1 and 2 are similar, but I couldn't find any information on whether zlib could handle password-protected archives.

Also note that I don't want the files inside the archive to be "extracted" into the folder while the program is using it. It should only be in the system's memory.

moinudin
  • 134,091
  • 45
  • 190
  • 216
Derek Maciel
  • 1,275
  • 2
  • 12
  • 19

3 Answers3

3

I think you misunderstands the possibilities brought up by encryption.

As long as the program is executed on an untrusted host, it's impossible to guarantee anything.

At most, you can make it difficult (encryption, code obfuscation), or extremely difficult (self-modifying code, debug/hooks detection), for someone to reverse engineer the code, but you cannot prevent cracking. And with Internet, it'll be available for all as soon as it's cracked by a single individual.

The same goes, truly, for preventing an individual to tamper with the configuration. Whatever the method (CRC, Hash --> by the way encryption is not meant to prevent tampering) it is still possible to reverse engineer it given sufficient time and means (and motivation).

The only way to guarantee an untampered with configuration would be to store it somewhere YOU control (a server), sign it (Asymmetric) and have the program checks the signature. But it would not, even then, prevent someone from coming with a patch that let's your program run with a user-supplied (unsigned) configuration file...

And you know the worst of it ? People will probably prefer the cracked version because freed from the burden of all those "security" measures it'll run faster...

Note: yes it is illegal, but let's be pragmatic...

Note: regarding motivation, the more clever you are with protecting the program, the more attractive it is to hackers --> it's like a brain teaser to them!

So how do you provide a secured service ?

  • You need to trust the person who executes the program
  • You need to trust the person who stores the configuration

It can only be done if you offer a thin client and executes everything on a server you trust... and even then you'll have trouble making sure that no-one finds doors in your server that you didn't thought about.

In your shoes, I'd simply make sure to detect light tampering with the configuration (treat it as hostile and make sure to validate the data before running anything). After all file corruption is equally likely, and if a corrupted configuration file meant a ruined client's machine, there would be hell to pay :)

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722
  • Even though you didn't answer my question, it does give me a lot to think about, and you pointed out things that I would have overlooked myself. But you're right. In my game I have an "optional file" called debug. If present, there will be debug information inside, for example: disabling the patching service, allowing you to play without patching. Or, another example: allowing the game to read from a folder of files rather than an archive, if the archive is not present. This is great for creating content quickly, but I wouldn't want someone to use it. So I'm going to keep it server-sided. – Derek Maciel Jan 27 '11 at 16:20
1

If I had to choose among your three options, I'd go for Crypto++, as it fits in nicely with C++ iostreams.

But: you are

  • serializing your data to XML
  • compressing it
  • encrypting it

all in memory, and back again. I'd really reconsider this choice. Why not use eg. SQLite to store all your data in a file-based database (SQLite doesn't require any external database process)?

Encryption can be added through various extensions (SEE or SQLCipher). It's safe, quick, and completely transparent.

You don't get compression, but then again, by using SQLite instead of XML, this won't be an issue anyway (or so I think).

Daniel Gehriger
  • 7,339
  • 2
  • 34
  • 55
  • I considered a database but since there are many different types of files (not just xml configuration), I don't think it would make sense to store a .png, for example, into a database. Also, if I needed to edit many or a single file, I could just: unpack the file, edit it, and repack. A database, I think, would be a bit more complicated. – Derek Maciel Jan 26 '11 at 22:47
1

Set a password to it (like a password-protected ZIP), then provide the password when the program needs it

Firstly, you can't do this unless you are going to ask a user for the password. If that encryption key is stored in the code, don't bet on a determined reverse engineer from finding it and decrypting the archive.

The one big rule is: you cannot store encryption keys in your software, because if you do, what is the point of using encryption? I can find your key.

Now, onto other points. zlib does not support encryption and as they point out, PKZip is rather broken anyway. I suspect if you were so inclined to find one, you'd probably find a zip/compression library capable of handling encryption. (ZipArchive I believe handles Zip+AES but you need to pay for that).

But I second Daniel's answer that's just displayed on my screen. Why? Encryption/compression isn't going to give you any benefit unless the user presents some form of token (password, smartcard etc) not present in your compiled binary or related files. Similarly, if you're not using up masses of disk space, why compress?

  • I've never used SQLite before, so if you disagree please mention so, but when I came up with the archive idea it was because I could organize similar files into their own archive (bgm, system, map1, map2) which would make updates simple because all the updating program has to do is delete the existing file and replace it with a newer version. With SQLite, both the overall organization of all the files and the updating process would be more chaotic. – Derek Maciel Jan 26 '11 at 23:18
  • "you cannot store encryption keys in your software, because if you do, what is the point of using encryption? ". Asymetrical encryption offers tamper protection: the archive can be readable with the (public) decryption keys, but not writeable. – MSalters Jan 27 '11 at 09:45
  • @MSalters true, but then said data must remain fixed or re-supplied from the original vendor, i.e. the holder of the private encryption key. You can't prevent the user from reading that archive, which I *think* (OP tell me if I'm wrong, I can always delete this) the OP means. –  Jan 27 '11 at 15:42
  • Similarly, there is nothing stopping you the attacker replacing said public key in the binary. Not easy, but doable. Of course, at that level of reverse engineering they may be able to circumvent whatever protected feature it is anyway. The point here is, encryption as a method will not stop determined reverse engineers. Ever. –  Jan 27 '11 at 15:44