What are the best methods to protect my game against memory issues coming from other executables?

Anyone know some tips? My team did a pretty simple game, but it was however quite vulnerable to attack by hackers, and I wonder how I could detect changes primarily by WriteProcessMemory.

Thank you in advance.

You can't. If it's running on the player's computer, the player has full and unconditional control over your program's input, output, and internals. There is no way around that. You can make it harder for them by writing your code in strange, convoluted ways (increasing development and maintenance costs) but looking at how many popular games have actually evaded hacking, I'd say you're just wasting your time here. Consider they could be running your game in a special VM to have even more control over it, perhaps bypassing the operating system completely.

That said, if you look around the web you will find many game hacking communities. Perhaps you could infiltrate them to learn some of their techniques and see what you can do. I wouldn't recommend it, though, since that time could be better spent improving your game.

Rule of thumb:

- If it's a single player game: let the player do whatever he wants, it doesn't harm anyone and he'll be happy he can modify the game in interesting ways.

- If it's a multi-player game over the internet: use the so-called "dumb terminal" design where the game client does absolutely no logic and only displays stuff sent from the server and sents player input to the server, whereas the server (which cannot be memory-edited since it is on a remote, secure system) does all the checking, cheat detection, and so on.

The third situation, a bit more difficult, is a single-player game with leaderboards (like many flash games). I don't think a robust solution has ever been invented besides tying scores to individual accounts (deterring people from cheating because they are more exposed if they are caught and their score means less if it isn't on their account) but you could always try to study high scores and statistically decide whether a score is faked/hacked or is legitimate. Not sure how feasible that is, though.

As you have probably discovered, the majority of casual cheating is using memory debuggers - encompassing a variety of tools that use debug hooks to read and modify your process's local memory.

These cheats all rely on being able to find the address of the value (health, ammo, score, cash, etc.) they want to modify. You do this by reading the value in the game UI (say, I see I have have $120 in-game), and searching through the entire process address space for all integers with that value. Then you spend some money in-game, and search for the new value in the list you found previously. After two or three repetitions, you should have narrowed it down to a single address, and you can change it to your heart's content.

It should be immediately obvious that you (as the game developer) can screw with this process in a few ways:

• If the value in memory doesn't match the value displayed in-game, it's a lot harder to find. Don't store the actual value, instead add/xor a constant to it before writing it to memory.
• If the addresses don't stay constant between searches, it's hard to correlate the search results and find the exact variable. Move your variables around in memory, by allocating new storage and copying.
• Guard Pages to watch for connected memory debuggers were really popular a few years back, I don't know if they still are in use. They let you crash when you know you are being hacked.

Keep in mind, though, that none of this will stop a skilled and determined adversary. If you are lucky, it'll give bored teenagers pause for thought...

and a fourth scenario:

a single player game that gets cracked and the full version is posted on the web for free. been there, done that.

i'm in the business of selling key cd's, not games.

i use a combo of key CD DRM, encryption of the exe by a VM, and obfustication of the source code. so when they load up the game in a debugger, they see the implementation of a VM for an imaginary computer. that VM loads and runs a decryption program written in its own proprietary instruction set, which decrypts and runs the actual game exe. needless to say, they can still look at the exe in ram, thus the obfustication. I did a fair mount of research on the available methods. i'll post my findings in my developer's journal here.

basically, you need to identify what kind of tampering you need to prevent, this will determine the best "protection methods". "delay tactics" may be a more accurate term though, as any cracker with sufficient time, tools, skills, and DETERMINATION can crack any game. the key is to make it not worth their time. this depends on who they are and why they're trying to crack it. end users will attempt to cheat hack the game, and will attempt to make illegal copies to distribute their friends for free. pro-crackers will attempt to crack the game for bragging rights on the world wide web. the more popular the game, the greater the glory.

Spend several thousand dollars on crack evasion. This serves to further improve the notoriety of the cracker that breaks through your method the day after release.

Running a debugger on a VM, any basement dwelling mad scientist can and will break through all barriers presented to them. The higher you make the fence, the more kicks they get while digging under it.

If a paying customer wants to cheat, and it doesn't affect the other paying customers, let him!

in fact, help him/her. include an editor. just say something like "use of the built-in editor is technically considered cheating, and is not officially supported".

i plan to include the game editor, limb-based model and animation editors, and the play testing "cheats" in the release version of my current project.

as long as it doesn't hurt anyone (like you financially, or other users' game experience) its a feature, not a problem.