how to make a trainer?

If you want a c or asm skelleton for a trainer, just pm me.

Trainers can be very simple, something like a timer (SetTimer) that checks your hotkey keystate (GetAsyncKeyState), and then writes to a memory address (WriteProcessMemory).

But before you can WriteProcessMemory you need to find the games Handle, using FindWindow, then GetWindowThreadProcessId, which lets you OpenProcess.


Also, if you don't want to do any codeing, You can download "Trainer-Maker-Kit" from here http://membres.lycos.fr/tsearch/. (authors website).

It simplifys it all, but can be restrictive.

[ArC]

Trainers can be very simple, something like a timer (SetTimer) that checks your hotkey keystate (GetAsyncKeyState), ...

Hm but this doesn't always work (e.g. Mafia: City of Lost Heaven: the input made is not detected by the trainer app).
In that case you can use DirectInput.
Another thing you should pay attention to is the problem of memory allocation. Mondern games are very complex so they use dynamically allocated memory (often called DMA - Dynamic Memory Allocation if i'm not mistaken) to store certain stuff. In that case it doesn't help to you look for a particular value in memory and to write to it directly. Instead you will have to use one of the following techniques:

1. Code Injection: You look for some code that modifies or reads the value you have found in memory. Then you put a jmp to your own code there (which can be situated in a cave for example) which writes the memory address to some freespace within the exe. Then your trainer program can read out this address and use it.
   However this method has some disadvantages:
   • The access rights for the section with the freespace which you use to store the memory address need to be modified so that write access is permitted (can be done with PE Editors or with VirtualProtectEx which is probably better); otherwise the game will crash with an access violation.
   • It can be a lot of work to port such a cheat to newer versions. First of all you will have to find the code which reads/writes from/to the memory address you want to hack, again. Then you have to find a new cave to put your injected code in and in same cases you also have to change the injected code to make it compatible with the new version.
   • The cheat can only be used if the code you're patching (and as such your injected code) has been executed at least once. Sometimes it happens that this code is executed after specific events only.
2. Find the base address: Certain values (health, money) are stored within structures or classes. Now it's possible to look for a "static" pointer which contains the base address to such a structure. Once you've found one you can read out that base address and "calculate" the address of the memory you want to modify.
   Anyways it can sometimes be difficult to find such a "static" pointer...
   But it's much easier to port those cheats to new versions as you only have to look for the address of the "static" pointer.

[Mkz]

Just a little correction about DMA.
DMA stands for Direct Memory Access, and is used when performing IO to a hard disk or a CD-ROM, for example. Without DMA, in PIO mode, the CPU is used a lot because it's reading the bytes from the IO ports of the device and writing them to the memory locations, or vice-versa. With DMA, or Ultra-DMA, data is read from the device and placed in memory directly (by the DMA controller), while the CPU is doing something else, or is idle.
DMA can also be used in a sound card for example. In that case, the sound card goes directly to memory to read the sound samples, the CPU doesn't have to be in the middle instead of doing something else.
The dynamically allocated memory you're talking about is a simple malloc(), or a VirtualAlloc call, which reserve a memory region in the heap and return a pointer to it.
Also, regarding item 2, "base address", I'd say that probably it's likely that a single pointer won't suffice. Due to the chaining of objects created at runtime, you may have a static location which points to a structure that can be in different locations. That structure, in turn, will contain one pointer for another structrure, and so on, until another structure some levels deeper will contain the actual lives and energy counters.
That said, this 2nd approach will also hardly work on a newer version. Both the initial base address, and the structure's offsets may change between versions.

[SiNTAX]

Originally Posted by ArC

.. you put a jmp to your own code there (which can be situated in a cave for example) which writes the memory address to some freespace within the exe.

If you inject your own DLL into the executable, then you don't need to find 'free space' in the exe to put your code.
As for..

Originally Posted by ArC

Mondern games are very complex so they use dynamically allocated memory

I think making trainers in the old days (e.g. Amiga), was way more difficult than it is now. Today code is always loaded at the same address, and all code is usually present from the start.
In the days of Yore.. you had to patch track loaders because each level used different code or was loaded to a different address. And ofcourse you had no breakpoint on write access capability to find that all important SUB #1 instruction :-)
But then.. it made it more fun to do..

[ArC]

Just a little correction about DMA.
DMA stands for Direct Memory Access, and is used when performing IO to a hard disk or a CD-ROM, for example. Without DMA, in PIO mode, the CPU is used a lot because it's reading the bytes from the IO ports of the device and writing them to the memory locations, or vice-versa. With DMA, or Ultra-DMA, data is read from the device and placed in memory directly (by the DMA controller), while the CPU is doing something else, or is idle.
DMA can also be used in a sound card for example. In that case, the sound card goes directly to memory to read the sound samples, the CPU doesn't have to be in the middle instead of doing something else.

Well yes this is the "real" DMA. But when you refer to DMA when speaking about trainers you don't mean that DMA but "Dynamic Memory Allocation".

Also, regarding item 2, "base address", I'd say that probably it's likely that a single pointer won't suffice. Due to the chaining of objects created at runtime, you may have a static location which points to a structure that can be in different locations. That structure, in turn, will contain one pointer for another structrure, and so on, until another structure some levels deeper will contain the actual lives and energy counters.

Well of course nested classes/strucutures are possible. But anyways in the end you will always find one basepointer that you can use, no matter how complex this nesting is. Once you've read the address of the first nested structure you can read the address of the sub-structure, aso...

That said, this 2nd approach will also hardly work on a newer version. Both the initial base address, and the structure's offsets may change between versions.

Well the address of the static pointer with the base address will certainly change in new versions unless the programmers only changed a few stuff. Anyways it's usually easier to find such a pointer in newer versions than to port the code injection.
However it should rarely happen that structure member offsets change. This can only happen if the programmers add members before the member you want to hack or if they modify the structure's member alignment.
And just to make it clear: With porting to newer versions I didn't mean to port cheats from 1.0 -> 2.0 (as this rarely works) or sth like this but from 1.0 -> 1.1.

If you inject your own DLL into the executable, then you don't need to find 'free space' in the exe to put your code.

Well you still need to inject some code to load the dll and to get the function address'.

I think making trainers in the old days (e.g. Amiga), was way more difficult than it is now. Today code is always loaded at the same address, and all code is usually present from the start.
In the days of Yore.. you had to patch track loaders because each level used different code or was loaded to a different address. And ofcourse you had no breakpoint on write access capability to find that all important SUB #1 instruction :-)
But then.. it made it more fun to do..

Hm don't know these times...

[Mkz]

I thought you were making a confusion, but you obviously know what you're talking about

[surferxyz]

Try this example in asm.

[LordGarfio]

I do remember that it was very easy using Game Tools 3.xx for MSDOS times.

In Windows times ReadProcessMeory, WriteProcessMemory...

Cheers.