Author Topic: Automod-app - the lost tutorial  (Read 437 times)

0 Members and 1 Guest are viewing this topic.


  • Heckler
  • *****
  • Posts: 1522
    • View Profile
    • Facebook
Automod-app - the lost tutorial
« on: January 29, 2007, 04:58:07 pm »
Lost and reveived:

Code: [Select]
Newcomers to gamemod-apping often try to nop out, or modify any instructions that 'look' cool; and instantly crash their target program; causing all their nicely set up DMA addresses to forever dissappear.  At this stage- they may not know how to find static pointers to the DMA addresses, it can be extremely frustrating and painful to recover the enormous amount of lost ground.

Here are a few general rules about x86 and dissembly- most of which can be applied to game mod-apping to improve your cheat/trainer making progress; and help prevent you from crashing the program/game.


An instruction assigning to the destination Register:


1)  Often, the ECX register is passed implicitly to functions as a pointer to a current (C++) object (eg. the this pointer).
In this case- it's a very bad idea to nop the instructions out- or change them in any way; because the following code can try to dereference the (invalid) address value in ECX.  Doing so will usually raise and exception because the program is trying to access memory pointed to a 'wild' or 'stray' pointer, that is not valid (Exception code: STATUS_ACCESS_VIOLATION).

2)  ECX is also used to keep track of the current index in a repetition.  As such- you can easy modify it in the initialisation stage of a loop; causing the loop body to be executed a number of times not originally intended (has interesting results sometimes).

EAX Generally stores a function's return value.  By modifying this value- all kinds of interesting things can happen.  It is generally safe to change the value in EAX (near the end of a function)- provided this value isn't stored as a pointer and later dereferenced by the client code.  If the value being stored in EAX right before the function returns is less than 0x1000 (on a windows machine); it is safe to assume a constant value (not a pointer to some memory) and change be freely changed.

ESP   Never modify instructions that assign to this register!  It is the stack pointer and changing it will almost certainly crash your game/program!

EBP   Don't modify instructions that assign to this register unless you know what you are doing!  EBP usually keeps track of a very important structure called the stack frame/activation record- which is essential to the correct operation of most functions; changing the instructions that cause side effects to value in register will cause disaster.

(Even if the function does not use the standard stack frame- this call is usually nested inside another; and you will inevitable corrupt it somewhere in the call chain- causing the program to crash).

ESI  Instructions assigning to these registers, ESI (Extended Source Index) and EDI (Extended Destination Index) are bad choices for modifying.  They generally contain pointers to data- which are later dereferenced.  Noping out/modifying these instructions will most likely raise an exception (STATUS_ACCESS_VIOLATION) and crash the target program.

EAX, EBX, ECX, EDX (Truly* General Purpose Registers)
These registers- (particularly EBX & EDX) are often used to store intermediate values in (integer-based) calculations.  It is usually fine to modify them; and recognising when this is the case is infact and fine skill inherent to making good quality cheats.

Remember- if EAX is assigned towards the very end of the function- it is often an indication of the return value (and can generally be changed without worrying about crashes- provided it contain a value < 0x1000).  ECX can also be used in the ways discussed above; so care must be taken when changing the corresponding instruction.

Floating Point Unit

Instructions that act on floating point data are different to regular (integer) ones.  In order to do something anything with floating point values- the data first need to be pushed onto a special stack called the FPU stack.  FPU instructions take an index into this stack; and use it to perform the specified operation; before poping it off the special stack and back into the original variable.

It is a bad idea to modify ANY of the floating point push/pop instructions- because this corrupts the stack- and causes instructions to be performed on semi-random operands.

DO NOT modify any of the floating point push instructions- eg. FLD, FSTP, ANY instructions beginning with FLD, etc.

DO NOT modify any of the floating point pop instructions- eg. FSTP.

The key to making high quality cheats (eg, Superjump & walk on air) often come about by carefully changing floating point instructions that calculate something:

Common examples are FADD, FSUB, FMUL & FDIV.

*Remember divide operations- such as IDIV, DIV FDIV can not have an argument of 0 as the divisor!  This will raise an exception in the program- and can eventually crash it.

Static/Global Pointers

Static/Global Pointers often keep track of some value that must be known through the entire program- across all sections.  Hence changing the assignment to this value will change the value retreived in all parts program.  This allows for some interesting things to happen when doing so.


All this said- these are just conventions that most compilers seem to follow.  There is nothing stopping compiler developers from changing these conventions; hence rendering this whole article unworthy- but this is rather drastic and highly unlikely.

Source: Subsky, former topic on TKC forum
« Last Edit: August 04, 2011, 01:39:23 am by M. O. »
Watch out where the huskies go, and don't you eat that yellow snow...