This page has been robot translated, sorry for typos if any. Original content here.

Writing trainers for games (games trainer)


We all once, for a long time or recently, played games - board, sports, and with the introduction of computing technology and computer into our lives. Because of their age, habits, or simply the desire to relax and cheer up after a hard day's work.

It would seem that the game gives unlimited opportunities for self-realization: as a racer, pilot, killer or even god. But the person is so arranged - having reached a certain height, he still wants something more and therefore finds a new goal or new opportunities.

It is clear that when creating games, developers are primarily guided, if not by their own taste, then by the taste of the project manager, sometimes by statistics. But sometimes you want the slowdown effects of the Matrix to be transferred to the game Indiana Jones, and not the most agile hero of the gaming industry - Hitman killer, learned to run along the walls. For these purposes, and trainers are created.


Trainer (Eng. Trainer) - a program designed to change the behavior of the game, usually working directly with the computer's RAM.

In the 1980s and 1990s, coaches were usually built in by hackers right into the game code. When starting, the coach was first launched with the dialog “Do you want to use cheats?”, Then the game code was executed. In the name of the trainer, addition signs (+) were used, one for each option of the trainer. For example, the "Hacker Group represents: Doom +++" - three options, for example, immortality, infinite ammunition and teleportation.

Modern same coaches, usually run as a separate program, before the game, and in their names use one addition sign with the number of options after it, for example, "Doom Trainer +15". In addition, modern coaches work with the operational memory of the game, rather than its executable file, since making changes to the executable file is complicated by copy protection systems.


To create trainers, memory dumpers, debuggers and disassemblers are used. The easiest way to create a trainer is to search for a value in memory that matches the desired game parameter. Then change it and look in the resulting list again. After several iterations, a small list of addresses is likely to remain, the values ​​for which you can try to change. There are many utilities such as: ArtMoney, Cheat'o'Matic - automating the process of finding and changing values.

In some cases, the desired game value is constantly changing its position in memory. In this case, you can try to find a pointer to it with a slight offset, if the game value is in any data structure. If the pointer changes its position in memory, then you can search for a pointer to this pointer, etc. You can also put a stop point on the appeal to the game value and analyze the code that reads or modifies them.

To summarize, so what is DMA? DMA (Dynamic Memory Allocation) is a dynamic memory allocation. Simply put, DMA games, as opposed to non-DMA games, store the values ​​they use to addresses in memory, which change after each game launch. All games under DOS do not use DMA, while most games under Win32 use it.


In this article I will look at the principles of writing trainers for DMA and non-DMA games. In RuNet, there is very little information on this topic, already existing examples of code, the writing of trainers are often not tested in practice, and therefore they can simply confuse newbies. All we need is the Delphi programming language and the TSearch debugger.
  1. Not DMA games:

Run TSearch. Clicking on the Open Process, we select the process of interest from the list. Next, using the search, we search, we filter out and then we determine the address of the value of interest. As an example, I will consider the game GTA - Vice City. The interest meter is time.

As you can see, the code is at a minimum; I did not use checks for the existence of a program window. Since I don’t see the point of folding the application, it will be much more practical to use any joyner and glue the game file and trainer together.

 Form1: TForm1;
 WindowName: integer;
 ProcessId: integer;
 ThreadId: integer;
 HandleWindow: Integer;
 write: cardinal;

 buf: dword;
 WindowTitle = 'GTA: Vice City'; 
 Address = $ 0097F266; 
 NumberOfBytes = 4; 


 {$ R * .dfm}

 procedure s1ow_mode; 
 WindowName: = FindWindow (nil, WindowTitle); 
 ThreadId: = GetWindowThreadProcessId (WindowName, @ ProcessId);
 HandleWindow: = OpenProcess (PROCESS_ALL_ACCESS, False, ProcessId);
 buf: = $ 3E90;
 WriteProcessMemory (HandleWindow, ptr (address), @buf, 4, write);

 procedure nos1_mode; 
 WindowName: = FindWindow (nil, WindowTitle); 
 ThreadId: = GetWindowThreadProcessId (WindowName, @ ProcessId);
 HandleWindow: = OpenProcess (PROCESS_ALL_ACCESS, False, ProcessId);
 buf: = $ 3F80;
 WriteProcessMemory (HandleWindow, ptr (address), @buf, 4, write);

 procedure TForm1.Timer1Timer (Sender: TObject);
 if (GetAsyncKeyState (VK_LBUTTON) <> 0) then 
 if (GetAsyncKeyState (VK_RBUTTON) <> 0) then

If the game has an official high score table or the game is networked and not all calculations go on the server side, then the existence of coaches is ruining the game. In this case, it is necessary to build a protection against trainers system, since copy protection systems do not cope with this task. To do this, the most important game parameters are encrypted and decrypted for a short time before use, or an encrypted copy is created with which the original parameter is constantly compared. To bypass such protections, one cannot do without disassembling the program.