I'm working on a flash game that saves your progress locally. These saves can easily be hacked. My solution is to add an md5 hash of all the variables saved into the save file itself. When loading the save, the game would check if the hash is valid.

Is this a good soultion? Are there better solutions?

  • \$\begingroup\$ This might be a stupid question, but when you say they can easily be hacked, are you simply saving as a readable text file? Or as a proper binary file? \$\endgroup\$ – Ray Dey Feb 8 '11 at 23:02
  • 1
    \$\begingroup\$ Using Flash's standard local shared objects \$\endgroup\$ – Abdulla Feb 9 '11 at 2:35
  • \$\begingroup\$ I would suggest asking on security.stackexchange.com. Though it's not a typical IT type question, development security is squarely within scope. I'm sure you'll get some good answers, though you may need to phrase the question a bit differently. \$\endgroup\$ – AviD Feb 9 '11 at 8:41
  • 1
    \$\begingroup\$ @AviD: this is very game related, actually \$\endgroup\$ – o0'. Feb 15 '12 at 8:48
  • \$\begingroup\$ @Lohoris of course its game-related, but my point was this is looking for security expertise - though its related to gamedev, its not a gamedev-expertise question. \$\endgroup\$ – AviD Feb 15 '12 at 10:11

The way you have it described, somebody hacking a save file would just need to construct an MD5 hash of the save file values in order to bypass this measure. You need to add one thing in order for this to even really be worthwhile: a secret block of arbitrary data that's added to what you're hashing (both when creating the save and when validating it on restore). The mechanism won't be uncrackable or anything at that point, but it'll be resistant to medium-casual tampering. If you can avoid having the data block be easily extractable from your runtime files using a hex editor, that'll add another notch.

If you want people to actually not be able to hack your saves, you cannot perform local saves at all. You cannot trust the client because the client is in the hands of the enemy.

  • \$\begingroup\$ Something I'd like to add, you should try to incorporate something about the user's computer as part of the protection. That way users can't trade save files so easily. (perhaps incorporate the computer's name into the salt or something of this sort) \$\endgroup\$ – Michael Coleman Feb 9 '11 at 3:52
  • 3
    \$\begingroup\$ @Omnion: The risk of associating with the computer is that the user may lose all their save files when they get a new machine. Migrating data to a new computer is painful enough without that. Probably the ideal thing, if possible, is associating the save file with a server account. \$\endgroup\$ – chaos Feb 9 '11 at 6:58
  • 2
    \$\begingroup\$ Salt is not a secret chunk of data, while it is random it does not add authenticity, nor does it prevent tampering. Salt is only intended to "randomize" the hash output, such as to prevent e.g. Rainbow Table attacks. \$\endgroup\$ – AviD Feb 9 '11 at 8:43
  • 2
    \$\begingroup\$ "You cannot trust the client..." this part is very true. \$\endgroup\$ – AviD Feb 9 '11 at 8:44

If this is not an online tracked competitive type game:

Let em hack away man. You can spend way too much energy on things like this when people who will play the game, will just play the game. Those who want to hack it will never really want to play it, they just want to hack it.

If it is an online competitive type game:

All you have to do is store the hashes on a server some where with their login information. If the hash from their save file is not valid, then their game is not valid.. Start over, or revert, or whatever :)

This is fairly basic but there again, we are talking about games, not bank accounts and such.. And always remember.. hobbyist or professional gamer developer, there are Hundreds of people out there who are going to try and hack your games. Put in enough effort to try and preserve the enjoyment of the game for those who are going to play by the game's rules, and thats about it.

  • 1
    \$\begingroup\$ +1 for putting the security effort into context of benefit. \$\endgroup\$ – AviD Feb 9 '11 at 8:45
  • \$\begingroup\$ -1 for dismissing games so easily (why?!). Though the first part of the post is very true. \$\endgroup\$ – o0'. Feb 15 '12 at 12:53
  • \$\begingroup\$ @Lohoris I do not dismiss video games. I just think people should evaluate what they get out of spending time on security vs game development. \$\endgroup\$ – James Feb 15 '12 at 17:08

This is not a good solution, since all the values hashed are in the save file.

If the attacker twiddles something, they just have to recompute the hash and store that in the save file too...

Saving things locally without any online state tracking is fundamentally non-securable.

You need an element that is on the server such as HMACing with a key that only the server stores.

This will not guard against an active attack where the attacker impersonates or otherwise piggybacks a live session however.

I know people who delight in hacking Flash games btw.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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