Trainer (games)

Game trainers are programs made to modify memory of a computer game thereby modifying its behavior using addresses and values, in order to allow cheating. It can "freeze" a memory address disallowing the game from lowering or changing the information stored at that memory address (e.g. health meter, ammo counter, etc.) or manipulate the data at the memory addresses specified to suit the needs of the person cheating at the game.

History

In the 1980s and 1990s, trainers were generally integrated straight into the actual game by cracking groups. When the game was first started, the trainer loaded first, asking the player if they wished to cheat and which cheats would like to be enabled. Then the code would proceed to the actual game. These embedded trainers came with intros about the groups releasing the game and the trainer often used to showcase the skills of the cracking group demo coding skills, some of these groups focus entirely on their Demoscene today In the cracker group release lists and intros, trained games were marked with one or more plus signs after them, one for each option or cheat in the trainer, for example: "the Mega Krew presents: Ms. Astro Chicken++". Modern trainers append their titles with a single + or writing "plus" and a number, as many have several functions. The number used represents the number of modifications the trainer has available, e.g. 'infinite health' or 'one hit kills'. Another difference is the inclusion of game version or digital download source of game. For example: "Hitman: Absolution Steam +11 Trainer", "F.E.A.R 3 v 1.3 PLUS 9 Trainer" etc.

Modern trainers also come as separately downloaded programs. Instead of modifying the game's programming directly, they modify values stored in memory. In fact, this has become so common that trainers today, by definition, only modify memory; modification to the game's executable is frowned upon and such programs are not considered true trainers but patches instead.

With object-oriented programming the memory objects are often stored dynamically on the heap but modern operating systems use address space layout randomization (ASLR). Therefore, the only way to modify such memory in a reproducible manner is to get information from inside the game process. This requires reverse engineering methods like API hooking of malloc() and free(), code injection or searching for static access pointers. The trainer gets active when the object has been allocated and deactivates itself again when the object is freed.

Modern operating systems also come with position-independent executables (PIE) for security. Together with ASLR, the binaries are loaded to a different virtual memory address each code execution. This makes the reliable modification of static memory values more complex. The load address has to be determined and subtracted from a found memory address to obtain a static memory offset. This offset is often exactly the address of the static variable within the PIE binary. E.g. the Linux tool scanmem supports PIE this way. For the configured memory offset the game trainer determines the load address as well and adds it back during run-time. The same method can be used for dynamic libraries as well.

Static access pointers vs. API hooking

Searching and following access pointers reverse to pointers on static memory can be cumbersome. It doesn't provide the size of the object and if there are multiple objects of the same class, these often can't be handled correctly as there can be e.g. vectors or lists in between on the heap. But the advantage is that this method can be used to attach to an already running process if it works. The DMA (Dynamic Memory Allocation) support in Cheat Engine is an example for that.

API hooking works completely differently: A preloader loads a library into the game process while starting it. The library spies on dynamic memory allocations and discovery starts with recording them all. With static memory search in parallel it is possible to match the found value address to a unique memory allocation. The idea is to close the game process directly after the value is found and the object still exists. Then, the last matching memory allocation is the correct one. So matching it reverse is the method of choice. The object size as well as the value offset inside it are discovered and the jump-back code address in the game binary can be determined by backtracing. Often a constructor is found and with that it is possible keep track of all memory objects it allocates. The library in the game process and the game trainer need to communicate with each other through inter-process communication (IPC). The disadvantage is: This can be detected as malware. But it is possible to find more values within objects by dumping and comparing them. Also adaptation to other game and compiler versions becomes simple as all it takes is to look for a library function call with known parameter (the object size) in the disassembly. E.g. the free and open-source (FOSS) universal game trainer "ugtrain" shows this method completely legal with FOSS games as examples.

Automated tools used in trainer making

In the past, trainers were often coded in assembly language or any of the high level language available at the time. Today, trainers can also be made with automated trainer making tools that just require basic information about cheats such as address and injection code, the program then compiles the trainer using pre-defined values and settings requiring no programming skill from the end-user. The most popular trainer making tool used today is Cheat Engine which supports wide variety of injection types and pointers, other tools that were used in past but are no longer as applicable are Trainer Maker Kit, Game Trainer Studio and Trainer Creation Kit etc. Some of the advanced techniques that Cheat Engine trainers supports include code injection, code shifting and the flexibility and versatility provided by its Lua scripting which has phased out other trainer making tools which lacked the support for some of these features.