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

Writing trainers for games (games trainer)

Intro:

We all once, for a long time or recently, played games - board, sports, and with the introduction of computer technology 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 possibilities 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, the developers are primarily guided, if not by their taste, then by the taste of the project manager, sometimes by statistics. But sometimes you really want the slowdown effects of the Matrix, moved into 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, trainers are created.

Theory:

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.

Methods:

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 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.


Practice:

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 have often not been tested in practice, which means they can simply confuse newbies. All we need is the Delphi programming language and the TSearch debugger.
  1. Not DMA games:

We start TSearch. Clicking 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.

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

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

 implementation

 {$ R * .dfm}

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

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

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


Protection:
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 ruins 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.