Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Methods for encrypting an archive in C++

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.

like image 282
Derek Maciel Avatar asked Jan 26 '11 22:01

Derek Maciel


2 Answers

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 :)

like image 153
Matthieu M. Avatar answered Oct 01 '22 02:10

Matthieu M.


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).

like image 42
Daniel Gehriger Avatar answered Oct 01 '22 01:10

Daniel Gehriger