Tutorial :Cheating in online games: Is it possible to prevent one Win32 process from inspecting/manipulating another's memory?


I play the online game World of Warcraft, which is plagued by automated bots that inspect the game's allocated memory in order to read game/player/world state information, which is used to mechanically play the game. They also sometimes write directly to the game's memory itself but the more sophisticated ones don't, as far as I know.

The game's vendor, Blizzard Entertainment, has a separate application called Warden that it is supposed to detect and disable hacks and cheats like that, but it doesn't catch everything.

Would it be possible to make a Windows application where you're the only one that can read the things you've read into memory?

Would that be pragmatic to implement on a large C++ application that runs on millions of machines?


Can't be done. The application is at the mercy of the OS when it comes to memory access. Whoever controls the OS controls access to memory. A user has full access to the whole machine, so they can always starts processes with privileges set to allow them to read from other processes' memory space.

This is assuming a 'regular' environment - today's hardware, with a multipurpose OS that allows several simultaneous programs to run, etc.

Think of it this way - even single-purpose machines where developers have full control over the hardware, with digital signing and all the tricks possible like the XBox or PlayStation can't manage to keep third-party code out. For a multi-purpose OS, it'd be 10 times harder.


If you want to achieve a real security, not only obscurity, this needs to be done at operating system level. This is a part of what is called Trusted Computing, something which was talked about a lot in the past years but no real progress was made (you can search for Microsoft Palladium for one example).

If you try to look at this a a cryptographic problem with a private and public keys, currently there is no way to hide a private key you use in your application from the hacker. Once the hacker finds your private key, he can use it to emulate your application - and all you can do is to make this somewhat harder.

Some partial solutions are possible in multiplayer games, where part of the game is run on servers. You can use the fact the hacker does not have an access to the server and therefore server can perform operations using its own private key which hacker is unable to get. This can help is some situations, but it far from being a general solution.


Warden is neither a separate application nor does it attempt to disable hacks in any way. The structure of it is basically equivalent to a trojan which pulls down (theoretically trusted) code from a known location and then runs it. This code than carries out various checks (the vast majority of which are hashing locations in memory to detect patches for things like bot event handlers) in order to mark an account as 'suspicious'. Blizzard then waits until they have a sufficient number of 'suspicious' accounts and executes a ban wave (there are some notable exceptions, which can result in instant-bans, but these are targetted at specific known hacks like Glider or D2JSP in Diablo II, not for general cheating).

My point in explaining this is twofold: First of all, you should know that Warden is very unsafe by design. You're giving someone the power to execute arbitrary x86 instructions on your machine, likely with full administrator access if you're using Windows. There exist private re-implementations of the Warden server code that are deployed on private emulated servers, and these can be malicious. I say this as someone who has written custom Warden modules. Secondly, and more relevant to the question as stated, Warden is not a prevention tool, it is a punishment tool and a major invasion of privacy. If you are a game developer looking to implement a similar system, I strongly advise against it, as it opens many cans of worms, and will still fail. Since it involves dynamically loading code there are many, many ways to screw it up, a lot of which will be hard to find in standard testing. Warden aside, Blizzard's only real effort to stop hacks from being made in WoW is their attempt to stop Lua plugins from doing anything close to botting (and even this chas been circumvented numerous times). And as others have said, it is fundamentally impossible to stop hacks, even with a system as dynamic as Warden. Even without touching the game's memory, packets and screen-reading are more than sufficient to make an advanced bot (look at mm.BOT and RedVex, or any of the oldschool AutoIt bots that work entirely on pixel detection).

The best way to stop bots, in a game or otherwise, is still to use a CAPTCHA of some kind. It doesn't have to be a distorted image, though. There are many ways to integrate human-or-AI tests into games that are at least somewhat transparent to legitimate users. If you make the system modular enough, you'll be able to make updates much faster than any publicly released hack will care to update their code.


And even if you could do that, there's the possibility of running the game in a virtual machine, and modifying the virtual RAM from the host. The guest will never know.


There exists a nice book about that topic:

Exploiting Online Games: Cheating Massively Distributed Systems (ISBN-10: 0132271915 or ISBN-13: 978-0132271912)

The problem is that there is not only the threat of other threads/applications but also from the kernel level. There are bots which work together with something like a root kit to hide from detection software.


As long as your code runs on the user's computer, the user will figure out a way to be intrusive. There's nothing that you can do to prevent that.


Yes you can do that, if you can afford to run only on Vista and later. See "Protected Processes" chapter in this article.


The game Runescape - a browser-based MMO - was fighting a (losing) battle against botters for the longest time. Their first attempt was a CAPTCHA that would have to be entered every few minutes while playing. Their second attempt was various graphical tests that would have to be passed by the player. Their last attempt was teleporting the player from what they are doing every once in a while, and forcing them to solve a puzzle.

Each of those worked for a small while, but eventually every one was cracked and was solvable by a machine.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »