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.
