Writing trainers for games (games trainer)

Intro:

All of us when, long ago or recently, we played games - desktop, sports, and with the introduction of computer technology into our lives and into computer games. Due to his age, habits, or just 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 rider, pilot, killer or even god. But man is so arranged - reaching 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, by the taste of the project manager, sometimes by statistics. But after all, sometimes you want the effects of moderation from the Matrix to get into the game Indiana Jones, and not the most agile hero of the game industry - hitman Hitman, learned to run around the walls. For this purpose, the trainers are created.

Theory:

Trainer (English 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 into the game code by hackers. At start, the trainer with the dialog box "Do you want to use cheats?" Was started first, the game code was continued. In the name of the coach used signs of addition (+), one for each option of the coach. For example, "The Hacker Group presents: Doom +++" - three options, for example, immortality, infinite ammunition and teleportation.

Modern 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 trainers work with the operating memory of the game, and not its executable file, because making changes to the executable file is complicated by copy protection systems.

Methods:

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

In some cases, the desired game value constantly changes its position in memory. In this case, you can try to find a pointer to it possibly with a small offset, if the game value is in any data structure. If the pointer changes the position in memory, you can search for a pointer to this pointer, etc. Also, you can put stopping points on calls to the game value and analyze the code that reads them or changes them.

Let's sum up - so what is it, DMA? DMA (Dynamic Memory Allocation) is a dynamic memory allocation. Simply put, DMA games, unlike non-DMA games, store their used values ​​at memory addresses that change after each game starts. All games under DOS - do not use DMA, while most games under Win32 use it.


Practice:

In this article I will consider the principles of writing trainers for DMA and non-DMA games. In runet very little information on this topic, the already available code samples, writing trainers are often not tested in practice, which means they can simply confuse newcomers. All we need is the Delphi programming language and the TSearch debugger.
  1. Not DMA games:

Start TSearch. Clicking Open Process, select the process that interests us. Further, 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 interested time is time.

As you can see, the code is at a minimum, I did not use the checks for the existence of the program window. Since the sense in folding-unfolding the application does not see, it will be much more practical to use any joeyer and to glue the game file and the trainer into one.

 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 table of records or the game is network and not all calculations are on the server side, then the existence of coaches ruins the game. In this case, you have to embed the system with protection from coaches, because copy protection systems can not cope with this task. For 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 circumvent such protections, you can not do without disassembling the program.