carter jones

Halo Hacking

This blog post will demonstrate how to go about reverse engineering structures and functions of interest in a binary. Once this has been accomplished, I will show how to modify the program at runtime to alter the program flow in our favor.

overview

For our example, we will be using Microsoft's Halo for the PC, using build number 01.00.00.0564. Because this is a first person shooter, classic examples of functions of interest would be the ammo counter, health counter, etc. If we are able to modify those functions' functionality, we would be able to gain unlimited ammo, health, and more.

finding the target instruction

Using a program like Cheat Engine, we can find the functions of interest. The basic process involves searching the program's memory for a value, such as the current ammunition count, then changing the target value (in our case by using up some ammo), searching for the new value out of the current set of previous matching addresses, and so on. Eventually, this process can be used to narrow down where the value is currently stored.

Once we have the target value's address, we can modify it for the current session all we want it, but it will possibly change the next time the program is run. So what we need to do is find out what value writes to the target value's address. We would attach a debugger and set a break on write breakpoint. Cheat engine provides this functionality, as well as WinDbg.

Using Cheat Engine, I have found that for this instantiation, the amount of ammo is stored at address 0x401001F4. Using WinDbg, we can verify this:

0:013> d 0x401001f4
401001f4  3b 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  :...............
40100204  00 00 00 00 ff ff ff ff-a9 2b 00 00 00 00 00 00  .........+......
40100214  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
40100224  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
40100234  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
40100244  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
40100254  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
40100264  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................

I currently have 58 in my ammo counter and according we can see the same value in WinDbg (0x3a in hex = 58 in decimal). To see what instruction writes to this address, I'll set a breakpoint on 0x401001f4 and fire the weapon to decrease the ammo count:

0:014> ba w 1 0x401001f4 "r;g"

The "r;g" tells the debugger to print out the registers and then go (continue) each time the breakpoint is hit. When the breakpoint is hit, WinDbg prints out the following line:

004c269a 7f0c            jg      halo+0xc26a8 (004c26a8)                 [br=1]

This is the line that follows the instruction that wrote to our target value. To provide a little context, we look a few bytes back and see the instruction that writes to our target address:

0:004> u 004c269a-4
halo+0xc2696:
004c2696 66894608        mov     word ptr [esi+8],ax
004c269a 7f0c            jg      halo+0xc26a8 (004c26a8)

If we set a breakpoint on that address so it will stop before it is hit, then we can examine what esi's value is. We expect esi to be 0x401001f4-8 (0x401001ec), and we expect ax to be the current ammo count.

0:004> bp 004c2696 "r"
0:004> g
eax=40100037 ebx=00000000 ecx=4078e354 edx=4078d78c esi=401001ec edi=400fff3c
eip=004c2696 esp=0018d998 ebp=4078e3e0 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
halo+0xc2696:
004c2696 66894608        mov     word ptr [esi+8],ax      ds:002b:401001f4=0038

Sure enough, esi's value is 0x401001ec as expected and the lower byte of eax is 0x37, which is our current ammo count. At this point, we have successfully found the instruction that modifies the ammo count of the player.

modifying the target process

We can use a memory analysis framework like nouzuru to patch the program at runtime:

For values like ammo, grenades, and flashlight power, we can stop decrementing their value by simply overriding the modifying instruction with nop instructions (the "no operation" instruction). However, for values such as invisibility or shields, simply noping out instructions won't suffice.

In the case of invisibility, we want to be able to enable invisibility at all times, so simply nullifying the invisibility decrementer won't do the trick. In the case of shields, if we nullify the shield decrementer, then other characters like Elites, who also have shields, will never have their shields decremented. That would end up in an endless firefight, because we have enabled unlimited ammo.

Therefore, I reverse engineered the Master Chief structure so that these values could be set at specific values. To keep the values at a certain setting, I used a value freezing routine:

This routine gets the player object's current base address, calculates the invisibility and shield offsets, and sets them to the desired values. Then, it sleeps for a pre-determined amount of time and repeats. This allows the player's shields to be set high enough for no damage to be done.

master chief structure

For reference, the results of my reverse engineering efforts revealed the following important members of the Master Chief data structure:

0x000: float XAxisPosition;   // The X axis of the character's in-game position.
0x004: float YAxisPosition;   // The Y axis of the character's in-game position.
0x008: float ZAxisPosition;   // The Z axis of the character's in-game position.
0x00c: float XAxisVelocity;   // The velocity the player is traveling along the X axis.
0x010: float YAxisVelocity;   // The velocity the player is traveling along the Y axis.
0x014: float ZAxisVelocity;   // The velocity the player is traveling along the Z axis.
0x01c: float DirectionFacing; // The direction that the player is facing.
0x088: float Shields;         // The amount of shields the player has.
0x1a8: byte  Invisibility;    // A byte indicating the state of invisibility for the player. 0x51 indicates that the player is currently invisible. 0x41 indicates that the player is currently visible.
0x2c2: byte  GrenadeFrags;    // The number of frag grenades that the player currently has.
0x2c3: byte  GrenadePlasmas;  // The number of plasma grenades that the player currently has.

To find the base address of the Master Chief, we need to find the base address of the current level. To find the base level, look at the two bytes at the static address 0x4000000b. These can be used to identify which level the player is on. With this information, we can calculate the base address of the player using the following level offset dictionary:

Using these offsets, we simply read them depending on which level the player is on and add 0x5C to get the Master Chief's base structure address:

demo

try it yourself

If you would like to try out my Halo trainer, feel free to clone it from github at https://github.com/carterjones/halo-trainer.

git clone https://github.com/carterjones/halo-trainer.git

If you would just like the precompiled binaries, you can download them from here.

If you would like to mess around with nouzuru, the platform I wrote for making memory analysis/modification/debugging software, feel free to check it out at https://github.com/carterjones/nouzuru. Or to get started right away, just issue this command:

git clone https://github.com/carterjones/nouzuru.git

Enjoy!