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:

  • Set a password to it (like a password-protected ZIP), then provide the password when the program needs it
  • Encrypt the archive with Crypto++ or similar
  • 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.

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

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

    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?

    链接地址: http://www.djcxy.com/p/50260.html

    上一篇: Mysql存储过程列类型参考

    下一篇: 用C ++加密档案的方法