Perma's Gamehacking Blog

Anyone who has done any amount of reverse engineering for games is well aware of all sorts of modern anti-cheat tools in use today. There is an entire line-up of software designed specifically for the purpose of catching and identifying users who are employing third party programs to gain an advantage in the game.

Many authors of cheat programs work very hard finding ways of circumvention, including myself. I would like to share some of the theory behind a potential solution to the anti-cheat problem.

To begin, imagine for a moment the way a game might start loading itself into memory. You run the executable file, which in turn loads a number of dynamic link libraries into its memory space so that it can utilize their functions or classes. This is done, generally, using the standard LoadLibrary() call and can be easily tracked down within a disassembled executable file. As you may know, when a library is loaded it is allocated a certain amount of memory in the target process by the operating system, then mapped into that memory space so that it can be called and used by the program.

Consider how an anti-cheat program would have to work in order to correctly identify the memory in which it would need to search for any anomalies. In order to get an accurate base address for whatever memory location it was intending to scan, the program would need to call GetModuleHandle() if it was within the process's memory already, or some equivalent if it was searching externally. This is because of how process memory is handled in Windows, particularly in more recent versions in which the base address of any given module can be completely dynamic.

Taking this fact into consideration, one can surmise that if we could keep an unmodified version of the library we're attempting to change (for the purposes of game hacking) loaded in memory, the anti-cheat software would pick up that module instead and ignore our modified version. Of course, how do we load two different versions of the library at once and make sure that the game will use our version rather than the unmodified version? And how do we know that the anti-cheat tool won't just pick up both instances of the library?

The answer is straightforward enough. We can write a hook in the original executable file that copies the contents of the library we're modifying into some buffer after it's been loaded by the game. We can then unload the library (or close the handle on the library), and copy the contents from our buffer back into the exact memory location where the library had been mapped. This gives the game executable the impression that the library is loaded and in the correct position in memory, and preserves all of the respective calls and structures associated with those memory locations. We can then load another version of the library into memory with LoadLibrary(), leaving the handle open so that it can be accessed by the anti-cheat software. This will not affect the game, as the executable is already satisfied after loading the library the first time. We can keep this library loaded in memory so that each time the anti-cheat program scans for specific offsets (after calculating the base address of our dummy library), it is scanning the memory of the fake module and ignoring the real code where we are making our modifications.

The down side to this method is that it can be detrimental in terms of memory usage when a large quantity of libraries need to be simulated in this way; however, often times all of your modifications can be done while spoofing only a single module.