How to fight against memory editing cheat software?

Question

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

Answer 1

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.

---

EDIT:

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

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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