Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

In my game I have data like items, enemies, tools, craft formulas, etc. I want store this information on disk securely. What algorithms I can use for free? I currently store my data using the JSON format.

I'd also like to encrypt the data I transmit for my multiplayer mode to keep it safe.

share|improve this question
This question is very broad - probably too broad. It's also confusing encryption for network communications and verifying the integrity of client disk files, which are separate tasks (and the latter is essentially impossible today). –  user744 Jun 13 '12 at 15:37
'Securely' and 'safe' are pretty obscure terms. Do you want to protect against accidental alteration, data loss, fire or theft? Check file integrity? Prevent unauthorized editing? Limit read access? Render it unreadable to anyone intercepting communication? Does this apply to everyone or just to clients, men in the middle, other players...? –  Marcks Thomas Jun 13 '12 at 15:53
add comment

4 Answers

up vote 2 down vote accepted

How do you store your data now? Presumably you have a bunch of setting files or even XML. Let's say your data looks like this:

<Character name="Jim-Bob the Peasant">
    <Item name="Shirt">
    <Item name="Belt">
    <Item name="Pants">
    <Item name="Shoes">

Before you go out and start encrypting your datafiles, I would strongly suggest you first establish an intermediate format like the one I gave you. Why? Because then you have a file that you can read and edit using any text editor. When you have an encrypted file, you can only access it using your game and any tools you write.

But on to the question at hand: how do you protect this data from tampering in a multiplayer game?

Remember the golden rule of multiplayer programming: Never trust the client. Clients lie, all the time.

So the first step would be to verify that the server's datafile is exactly the same as the client's datafile. An easy implementation would be to hash the file using MD5. If the hashes don't match, the client has tampered with his file.

You'll note that the datafile we have now is very high "noise-to-signal": a lot of the bytes aren't for data, but for human-readability. We can improve that by compressing the file until only the raw data is left, by making a binary format.

  • First, let's write a header for our custom format. Let's write the bytes "ITE" to show that this is a ".items" file.
  • Next, write the name of the character and end with a 0.
  • Then, write the properties of each item: name, protection, weight, speed.

Here's what it looks like in 010 editor:


You can see (with a bit of trouble) that every string ends with 0 and that for every item, we have a byte for protection, weight and speed.

Our datafile just went from 327 bytes (intermediate) to 58 bytes (binary)! But it came at a high price: it's now very hard to read what's going on and even harder to add new properties. But it gives us access to all kinds of neat tricks:

  • Encoding the data with a XOR-key, so only if you have the key will you be able to read the data.
  • Compressing the data further with run-length encoding, zlib or some other custom implementation.
  • Shuffling the bytes around.

However, each of these encryptions comes at a cost: you first have to decrypt the file in memory before you can use it. And that's fine for files that are 58 bytes, but if you have 5 MB files and you have 100 of them, that could become a problem.

P.S. Your English is fine. ;)

share|improve this answer
Thanks @knight666. Now I understand that my game doesn't needs powerful encryption. –  cristaloleg Jun 13 '12 at 14:52
-1, There are some really silly ideas in here, like how do you intend for the server to compare the hashes? Why all the talk about compression (and a very naive view of decompression) when the question is about authentication? Why even say MD5 anymore? –  user744 Jun 13 '12 at 15:25
knight666: since you can't trust the client, there is little point asking the client to make a hash and send it to the server to see if the file has been altered - if you can alter the data files, you can probably alter the executable to send the old hash. –  Kylotan Jun 13 '12 at 15:41
Your .items file is corrupt. The third byte ought to be 0x45. –  Marcks Thomas Jun 13 '12 at 15:43
@cristaloleg My sarcasm translator is giving me either "Thanks for the post, you helped me gather my thoughts!" or "Of course I know about binary files, you idiot." ... I think it may be broken. –  knight666 Jun 13 '12 at 20:34
show 2 more comments

If you're interested in cryptography, run over to Coursera and sign up for Dan Boneh's Cryptography class. It'll teach you all about the fundamentals, how to secure various forms of communication, etc.

Key take-away points:

  • do not invent your own algorithms
  • use an existing crypto library
  • use existing crypto techniques
share|improve this answer
I'm enrolled in this course. "do not invent your own algorithms" - so I have created this question =) –  cristaloleg Jun 13 '12 at 14:42
add comment

Possible duplicate of this question ?

First of all, you may try to serialize your data structure and save it in a binary format, probably also try to obfuscate it with some useless data. Now, the client must try to reverse engineer it.

Of course, that is not enough, and now it's time to encrypt this data. I believe that ANY cryptographic library would do, as you don't really need anything tailored to gamedev. You can test it and see if you should focus on size or speed. For example, in C++, you can use these libs:

  • stackoverflow.com/questions/2250650/encryption-of-objects-stored-to-disk-using-c-for-a-java-developer

  • cryptopp.com

You can use a (private) tool to convert the serialized data into a human-readable form, simplifying your work :)

share|improve this answer
No encryption suitable for real-world use is going to help you stop the user who saved the file from modifying it. At some point the computer encrypted it, which means that same user could've intercepted the key. On-disk encryption stops other users from editing the files. –  user744 Jun 13 '12 at 15:46
add comment

Like others have mentioned: You can't trust the client. All MMOs, Battlefield *, Diablo 2&3, etc, all store their characters online because there is no way to secure the client's files against malicious users.

Hackers, and the like, will always try to find the weakest point to make their modifications. In this system, I can already tell that the weakest point would be memory injection, and memory injection is easy stuff. Changing your gold, your XP, and other numeric values is trivial. There are only 3 ways to fight against memory injection that I know of.

  1. Use VAC or PunkBuster
  2. Don't trust anything the client says, ever, and store sensitive information on a server, and actually run the game on the server (like any MMO, BF*, and D2/3). If the server is running the game, the clients can only send commands like "attack this thing" or "move here". The server inputs these commands into the game, and the game hands out XP and money and all of that other good stuff.
  3. Put your game on a locked-down hardware device knowing that most users won't have access to your precious files, but those people who have unlocked their device will be the same group of people who are able and willing to hack your game.

Encrypting the client's files will only stop people from using a text editor, but so will simply compressing the data in a zip file. I would simply recommend that you store your data files in a binary file, maybe compress it or use a simple encryption algorithm to fend off casual tinkerers. It would still be harder to crack open that file than it would be to open up TSearch and give myself a million dollars.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.