A game Trainer is a program that modifies the memory of a computer game, changing its behavior using addresses and values to allow cheating. It can “freeze” a memory address by prohibiting the game from reducing or changing the information stored at that memory address (e.g. health counter, ammo counter, etc.) or manipulate certain memory address data to meet the needs of the person who cheated the game.
In the 1980s and 1990s, most coaches were integrated directly into the actual game Traine r by breaking up groups. When the game first starts, the coach loads first and asks players if they want cheats and which cheats to activate. The code then leads to the actual game. This built-in trainer comes with an introductory session for the group playing the game, and the trainer is often used to demonstrate coding skills on a coding group demo. Some of these groups are now completely focused on their demo scene. In the Smash Squad release and introduction list, the game being trained is denoted by one or more plus signs, one for each option or cheat in the trainer, for example: “The Mega Krew Presents: Ms. Astro Chicken++”. Modern educators add their degrees with a simple + or “plus” spelling and number, as many have multiple functions. The number used indicates the number of modifications available to the trainer, e.g. “Infinite health” or “one hit kill”. Another difference is the inclusion of a version of the game or a digital source for downloading the game. For example: “Hitman: Absolution Steam +11 Trainer”, “F.E.A.R 3 v 1.3 PLUS 9 Trainer”, etc.
Advanced trainers are also available as a separately downloaded program. Instead of changing the game’s programming directly, they change the values stored in memory. In fact, it has become so common that today’s educators are, by definition, simply modifying memory; Changing the game’s executable file is unsatisfactory and such a program is not considered a real tutor, but a patch.
In object-oriented programming, memory objects are often stored dynamically on the heap, but modern operating systems use address space randomization (ASLR). Therefore, the only way to modify such a memory in a reproducible manner was to obtain information from the game. This requires reverse engineering methods such as malloc and free APIs, code injection, or static access pointers. The simulator is activated when the object is distributed and disabled again when the object is released.
Modern operating systems also have position-independent executables (PIE) for security reasons. Along with ASLR, binaries are loaded at a different virtual memory address each time the code is executed. This makes it difficult to change static memory values reliably. The boot address must be specified and removed from the found memory address to obtain a static memory offset. This offset is often the exact address of a static variable in a PIE binary. e.g. the Linux tool scanmem supports PIE this way. The game master also determines the boot address for the configured memory offset and adds it again at runtime. The same method can be used for dynamic libraries.
Finding and tracking access pointers versus static memory pointers can be cumbersome. It doesn’t give the object size and if there are multiple objects of the same class, they often can’t be processed correctly because there are for example vectors or lists in between in the stack. However, the advantage is that this method can be used to attach an already running process if successful. Cheat Engine DMA (Dynamic Memory Allocation) support is an example.
API attachments work very differently: Preloads load libraries during game start. The library spies on dynamic memory allocation and detection starts by recording everything. With parallel static memory search, it is possible to compare the address of the found value with the unique memory allocation. The idea is to close the game process right after the value is found and the object still exists. Then the last matching memory allocation is correct. So comparing the opposites is the method of choice. The size of the object, as well as the displacement of the value it contains, is detected, and the address of the rollback code in the game binary can be determined by tracking. Often constructors are found that allow tracking of all memory objects allocated by them. Game libraries and game teachers must communicate with each other using interprocess communication (IPC). The downsides are: It can be detected as malware. But it is possible to find more values in the object by discarding and comparing. Adaptation to other versions of the game and compiler is also easy, because when disassembling, you only need to search for library functions with certain parameters (object size). for example the free and open source Universal Game Tutor (FOSS) “ugtrain” demonstrates this method completely legally using the FOSS game example.
In the past, trainers were often coded in assembler or one of the high-level languages available at the time. Nowadays, trainers can also be created using automated trainer creation tools which only require basic cheat information like address and injection code, after which the program compiles trainers with predefined values and settings which does not require any programming knowledge from the end user. User. The most popular trainer creation tool in use today is Cheat Engine, which supports a wide variety of injection and pointer types. Other tools that have been used in the past but are no longer applicable are the Trainer Maker Kit, Game Trainer Studio and Trainer Creation Kit, etc. Several advanced techniques supported by the Cheat Engine trainer, including code injection, code switching, and the flexibility and versatility provided by Lua scripts , are gradually removing other trainer build tools that do not support some features this.