What is the best way to protect run-time memory from such software?

We just published an online game (written on AS3, Flash, published on a social network), and pretty much all of the players got max_int money just using a simple memory editor ("ArtMoney").

  • 16
    \$\begingroup\$ Simple: You don't. \$\endgroup\$
    – thedaian
    Feb 13, 2012 at 13:24
  • 3
    \$\begingroup\$ To expand on @thedaian, If it isn't an online game, who cares if the players cheat? \$\endgroup\$
    – DampeS8N
    Feb 13, 2012 at 13:55
  • 14
    \$\begingroup\$ You should have specified in your question that it's an online game, because that's a different problem than an offline game. I'm pretty sure this question is a duplicate, but long story short store sensitive data like money on your own server, and don't rely on the client to have the correct amount. \$\endgroup\$
    – jhocking
    Feb 13, 2012 at 14:33
  • \$\begingroup\$ Even online games like Diablo 2 have implemented advanced antimemory hacking mechanisms. They usually eventually are broken, but they can be effective for a period of time. An authoritative server doesn't solve all problems. Even for a single player game, making cheating too easy can reduce inapp purchases. Whether you feel in principle this is good or bad doesn't invalidate the question. \$\endgroup\$
    – AaronLS
    Nov 28, 2016 at 0:27

6 Answers 6


Simple ways to protect your game:

  • Duplicate your data: store some information twice and compare the copies. If they are different, something is going wrong. You don't have to do it per variable, you can also make CRC's on some big areas of memory (ex: on a struct that contains all player information).
  • Encrypt your data before its written to memory (and unencrypt after reading). A simple xor could be effective. This will make finding the addresses of some interesting variables a LOT harder.
  • Never declare sensitive data "static" (with a fixed memory address) but rather use pointers. If someone find the address of interesting variable, the address will change next time process is run, making it harder to create a trainer (but not impossible).

In some professional games (like GTA IV), the game is split in two parts:

  • One main process for rendering, input and processing game logic, which is unprotected (like most games).
  • Another process that keep sensitive data (ex: player health, money, weapons, ...). This process has several protections against cheating (memory regions are readonly, data is encryted and so on). It's not possible to modify these values directly by writing in them, but only by using a set of functions that the process provide. These functions are only available after you have been authenticated using a set of keys/challenges. I guess other sensitive stuff like load/save savegames is also done here.

I guess this has some costs. Every modification of game data require some interprocess communication and some other checks (instead of a single read/write to memory).

However, all protections can be defeated: someone could disassemble your game to figure out exactly where and how data is stored. Or even better, modify the .exe himself to directly remove the protections. Anyway, I think using what I described above will stop most cheaters.


If it's a Flash game, you can regularly send some game events to a server (eg: "+50 points at frame 41, lose one life at frame 1231"). Then analyze these events and some statistics (eg: total seconds the game was played, number of player actions (mouse moves, key presses)) and compare to the submitted score to see if it appears to be possible...


You can't stop memory editing cheats, so design your game so that such cheats won't matter. For an online game, sensitive data like money on your own server, and don't rely on the client to have the correct amount. That way it won't matter if players change the amount of money displayed on the client, because when the player purchases stuff the game checks the amount stored on the server.

  • 2
    \$\begingroup\$ Note that this also means that only the server can decide to give/receive money. \$\endgroup\$ Feb 13, 2012 at 16:37
  • 1
    \$\begingroup\$ Right. More generally, this means you mostly just send UI commands from the client ("the player just pressed Attack") and do everything else on the server. \$\endgroup\$
    – jhocking
    Feb 13, 2012 at 16:43
  • 1
    \$\begingroup\$ This can be very overwhelm to the server, but some famous game do it this way. e.g: Ragnarok Online. Try to search for eAthena in Google, it's how the game server is implemented. The client actually does nothing, just send commands to the server. \$\endgroup\$ Feb 14, 2012 at 2:23
  • 1
    \$\begingroup\$ Well you can usually achieve a balance where the client handles everything where cheating doesn't matter and the server handles everything where cheating does matter. So the client handles stuff like rendering graphical effects, and the server handles stuff like economic transactions. \$\endgroup\$
    – jhocking
    Feb 14, 2012 at 19:29

There are a lot of complex ways to go about blocking your process from being modified externally. Most of these dip into the realm of anti-reverse engineering solutions at their core. Such as anti-debugging, breakpoint detection, etc.

If this is a concern for you focus your efforts on automated solutions and not on the person performing the operation by hand. Tools have to find ways to identify what your information is in order for it to change it. By making runtime changes in how you organize and store your data you can make these tasks more difficult.

Few things you can do:

  • Mask string constants and use Encrypt/Decrypt functions to change masked strings to output strings. This quickly deters someone from walking through a string table. Localization can often times add this feature without any intentional effort to obfuscate strings.

  • Checksums. On all sorts of data to validate their integrity. This requires at least a two step process of the person changing the value and the checksum associated with it. Just don't store them in the same area so they are easily identified.

  • Encrypting data in memory (as previously mentioned) is a good way to avoid a person easily modifying your contents. They will first have to identify how the data is encrypted and then any relative pattern or key associated with it.

  • Hook the Windows API functions that are commonly used by trainers. Such as ReadProcessMemory and WriteProcessMemory. A simple hook can let you know when a trainer is using these on your process, and you can determine if you want them to occur or not. It's not the only way to modify the memory contents but it's the most common.

Once you begin going outside of simple things you really are moving into Anti-RE territory. Which also applies to anti-cheating, but becomes much more in depth. These techniques take time to implement carefully and may be overkill for your intended purposes.

  • Launch a child process and have the child process attach to the parent process as a debugger. This will stop additional debuggers from attaching to your process.

  • Keep sensitive data that doesn't need to be used frequently (not stuff used every frame) in guard pages. These are created through VirtualProtect() and will make the process throw an exception when the memory is accessed.

There's a lot more options you can explore, but I won't go into length here. Just lookup Anti-RE.


You run the software far away from the user like for example onlive does it.

Google "Cloud gaming" if you wan't more information about the technique.

  • 9
    \$\begingroup\$ never trust the client. \$\endgroup\$
    – lathomas64
    Feb 13, 2012 at 14:00

Also, you could use simple sanity checks. A player doesn't just randomly pick up a billion gold.

  • 8
    \$\begingroup\$ unless another player dropped a billion... \$\endgroup\$
    – Exilyth
    Feb 28, 2012 at 9:53

One very effective technique used by some roguelikes (DoomRL, Brogue) is to mask the actual variables. What this means is that instead of showing health as "2/10," show it as "20%."

Remember, most memory editors work well with specific value searching/filtering. If you don't know the specific value, you can still track it down (eg. search for changed/decreased values after the player health drops), albeit it takes much longer to do it that way.

I also suggest an anti-cheat backlash. For example, if you have a game where the player takes non-positive damage and their health didn't drop, you can easily and accurately check this and know that the player cheats. Do something interesting, like spawning some uber enemies around him :)


Not the answer you're looking for? Browse other questions tagged .