Preventing High Score Board Hacks

Preventing hackers from ruining high score boards seems to come up all the time on the Flash forums. I end up posting some of this over and over again so I figured I'd blog about it to avoid having to re-post it.

In short, there are four steps needed to hinder or possibly stop any casual or semi-casual hacking.
1) Use SSL to prevent hackers from manipulating the data being sent over the wire
2) Encrypt all important variables in memory to protect from memory hacks
3) Use a Flash obfuscator to prevent easy decompilation and patching of the code
4) Validate anything possible on the server (score vs. length of play, etc)

Step 1)
Many of the easiest high-score hacks involve simply packet sniffing the data sent from the Flash client to the server and re-submitting it back to the server with a modified score. Using SSL stops this dead as packet sniffing SSL traffic won't reveal anything useful to the hacker. Super cheap SSL certificates can be purchased from GoDaddy. If SSL is not an option, it's possible to use other security techniques to encrypt or ensure the integrity of the data stream. I've covered this process in detail here.

Step 2)
UPDATE: I've created the utility I suggest below. You can see the post on it here. Encypting the variables in memory seems odd but is a crucial technique to ensure that the memory hacks out there can't actually manipulate the game state directly. For instance, if you have an unencrypted score variable a memory tool would actually let the hacker find that value and update it to something else directly. Then when they submit their score, the game will send the new value as though it were correct. There is no easy way for the game to really know otherwise. Likewise, if you have stats or character abilities, all are easily hackable the same way.
The fix for this is to store the value encrypted. So while the game shows you have 3 lives left, in memory it looks totally different. There is no easy pattern for the hacker to use to find the number of lives. In practice, updating your score by 1 would work something like this:

var rawScore:Number = decrypt(score);
rawScore++;
score = encrypt(rawScore);

In practice, you would probably want to make it even cleaner with some sort of "decryptUpdateAndEncrypt" type methods, something full-service in a single call.

The other trick to this is that the encryption scheme needs to use a "rotating" key. Every time the game is played, the encrypted value in memory should be different. This prevents any clever hacker from determining the key and writing a little tool to duplicate the encryption scheme - thus breaking your protection. Since the key is internal only, you can simply use a random number and it should work fine. You will want to use a nice and fast encryption scheme as well. Something like TEA would be idea. A good JavaScript implementation can be found here. As mentioned above, I've created a version of this utility and posted it here.

Step 3)
This is a general hardening step. If you obfuscate your SWF file, it will be very hard for hackers to decompile it and determine what's going on under the covers. It's always a good practice if you are concerned about security, but try hard to never rely on this as your primary technique because it isn't prefect. While I haven't used SWF Encrypt, I know and respect the owner of Amayeta and have no doubt his product will be an excellent choice.

Step 4)
This is another general step and it's specific implementation depends on the game. Try and validate everything on the server if possible. For instance, if their game session started 2 minutes ago, there should be no way they can submit a very high score. Likewise, track the time of all score submissions, it's not possible to submit high scores with tiny intervals between them. Try and think about how long it takes to play a game and use that as a guide. Also, when you fail a score, don't tell them why. Just say the score submission failed. OR, don't even tell them it failed, just ignore it. This makes the hacker have to work to figure out what went wrong. Don't make it easy for them.

This post doesn't cover everything, it only covers the things many developers forget when trying to harden a game. Also keep in mind that there are lots of exploits in the games themselves. Tricks like slowing down the game timer (thus slowing down movement), exploiting bugs, etc. Make sure you have those covered as well.

Finally, this isn't a way to perfectly protect a game. It simply makes it much harder for a casual hacker. They will have to really work at it if they want to cheat and in practice, that is generally good enough. Have fun!