Trainer (games): Difference between revisions
No edit summary |
|||
Line 7: | Line 7: | ||
Modern trainers also come as separately downloadable programs; instead of modifying the game's programming directly, values stored in memory are changed. |
Modern trainers also come as separately downloadable programs; instead of modifying the game's programming directly, values stored in memory are changed. |
||
With [[Object-oriented_programming|object-oriented programming]] the memory [[Object_(computer science)|objects]] are often stored dynamically on the [[Heap_(programming)|heap]] but modern [[Operating_system|operating systems]] use [[Address_space_layout_randomization|heap and stack randomization]]. 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|reverse engineering]] methods like [[Hooking|API hooking]] of [[Malloc|malloc()]] and [[Free_(programming)|free()]] |
With [[Object-oriented_programming|object-oriented programming]] the memory [[Object_(computer science)|objects]] are often stored dynamically on the [[Heap_(programming)|heap]] but modern [[Operating_system|operating systems]] use [[Address_space_layout_randomization|heap and stack randomization]]. 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|reverse engineering]] methods like [[Hooking|API hooking]] of [[Malloc|malloc()]] and [[Free_(programming)|free()]], [[Code_injection|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. |
||
==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 spys 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 an 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|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 adaption 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 [[FOSS|free and open-source (FOSS)]] universal game trainer "ugtrain" shows this method completely legal with [[FOSS]] games as examples. |
|||
==See also== |
==See also== |
Revision as of 16:35, 28 January 2014
Game trainers are programs made to modify behavior of a computer game, usually 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. It simply manipulates 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 he/she wished to cheat. Then the code would proceed to the actual game. In the cracker group release lists and intros, trained games were marked with one or more plus signs after them, one for each option in the trainer, for example: "the Mega Krew presents: Ms. Astro Chicken++". Modern trainers append their titles with a single + and a number, as many have several functions. The number used represents the number of modifications the trainer has available, e.g. 'infinite cash' or 'instant research'. For example: "Final Fantasy VII - Ultima Edition +50 Trainer", Brutal Legend +10 Trainer etc.
Modern trainers also come as separately downloadable programs; instead of modifying the game's programming directly, values stored in memory are changed.
With object-oriented programming the memory objects are often stored dynamically on the heap but modern operating systems use heap and stack randomization. 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.
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 spys 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 an 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 adaption 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.