Protect my game from Memory editing
Members - Reputation: 104
Posted 10 July 2013 - 09:08 PM
Crossbones+ - Reputation: 7970
Posted 10 July 2013 - 10:48 PM
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.
The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.
- Pessimal Algorithms and Simplexity Analysis
Senior Moderators - Reputation: 9507
Posted 11 July 2013 - 04:46 AM
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...
Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]
Crossbones+ - Reputation: 1835
Posted 11 July 2013 - 11:22 AM
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.
Edited by Norman Barrows, 11 July 2013 - 11:27 AM.
Rockland Software Productions
"Building PC games since 1988"
Crossbones+ - Reputation: 2771
Posted 11 July 2013 - 08:37 PM
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.
There are ten kinds of people in this world: those who understand binary and those who don't.
Crossbones+ - Reputation: 16688
Posted 11 July 2013 - 09:27 PM
Consider they could be running your game in a special VM to have even more control over it, perhaps bypassing the operating system completely.
@Kyl3: This is not at all unusual. One of the most famous cheat tools can be ran as, basically, friendly rootkits on your own machine to keep the cheat tool from even showing up in the list of running processes and is, if ran in that mode, almost impossible to detect. This cheat tool is widespread and very popular. Not everyone runs it in that rootkit mode, but when they do, I don't think there's anything you can do about it.
Another cheat method is, for online games, setting up a network node (either physical or virtual) between the game client and server, and reading and modifying values in the packets on the fly. The very advanced ones remember the previous packets and built a virtual imitation of a surprising amount of the knowledge the server has to display things like player positions on the map, or the amount of health a certain boss has, or where, statistically, the best places for certain items are. This information is even crowdsourced and used to dump the stats of enemies and the probability chances of drops on wikis and things like that.
Don't lose too much sleep over it, and instead cater to those who pay you. If a paying customer wants to cheat, and it doesn't affect the other paying customers, let him! He might even have a good reason for doing so (his save file getting corrupted or something, so he's trying to return to where he was).
[Edit:] But one trick is to only use the sensitive memory locations for a mere fraction of a second, and then wipe them clean.
Another trick (in theory) might be to, if the player knows they are looking for value "230" because their health is that amount, always get and set that value with a bitshift or a ^= scramble with a magic value (XORing with a known value can be undone by XORing with the same value), so they can't Ctrl+F the values. This won't stop people, but it's a tiny trick to just make it slightly more annoying and require slightly more technical knowledge. It might hinder script kiddies with a memory editor until someone intelligent releases a custom-made tool for your game.
Edited by Servant of the Lord, 12 July 2013 - 11:58 AM.
It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God. [Need free cloud storage? I personally like DropBox]
Crossbones+ - Reputation: 1835
Posted 12 July 2013 - 04:34 PM
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.
Rockland Software Productions
"Building PC games since 1988"