Go Back

Alien Breed: Impact

I recently bought Alien Breed: Impact from Steam, an Arcade Shooter (as they call it themselves) that gave me back 'old' feelings (they don't make that many games like it anymore). Anyways, I played it for a while but the controls of the game are horrid. I ended up getting annoyed by the controls. So the logical next step is to hack it ;)  By the way, if the controls where better, it would be a lot more fun to play.

However, Alien Breed uses the Unreal 3 Engine. Several other games use it too, like Mass Effect 2, which made me 'worry' a bit. The Unreal 3 Engine takes OO-programing to another level. As soon as I found some values (ammo/health) my suspicions where confirmed. Just like Mass Effect 2, Alien Breed uses 1 function to subtract nearly every value in the game.

Initially I wanted to give up, not that hacking it is impossible. It is just a lot of work and is it really worth it? I decided not to give up. And my decision will probably make me look into Mass Effect 2 again.

After putting a (memory-write) break-point on the ammo value, I saw that the instruction at 0x4BE228 is responsible for subtracting health, ammo, enemies health, cash, etc. Replacing the the "sub [ebx], eax" instruction with nothing (nop's) worked.  Ammo was frozen and I couldn't die. But it also made it creatures, windows, etc invincible.

The next step in the chain was to trace (using Syser) the function's return address (which was 0x4C5331), that was a dead-end too. All values used this same function. Instead of digging deeper, I decided to try and find something in the call-arguments of the subtract function (0x4BE180) that allowed me to identify the values it was subtracting from.

To do this I had to figure out a bit on how the subtract function worked. This wasn't easy, mainly because the function accepts a wide array of values it has to subtract from. Through tracing I found out that the first call within the function (call edx at 0x4BE1B5) retrieves the pointer to the value it is going to subtract from.

Looking at the first call that it does, we find out it bases this call on the value that is present at the first argument + 0x18 (it loads the first argument in esi @ 0x4BE183 and then loads a the pointer from [esi+0x18] into eax). It loads a byte from the pointer that it gets, and then uses that to call the function for the address to the value. For ammo, health, cash, that value is 1. The function that it calls when the value is 1 is 0x4BB610.

Inspecting this function gets us to the following conclusion, [[[first argument + 0x18] + 0] + 0x64] contains the offset of value compared to the class that is calling the subtract function. While checking out the memory address that [[first argument + 0x18] + 0] points to, I saw that [[[first argument + 0x18] + 0] + 4] points to a value identifier. For ammo this identifier is 32810 and for health its 5685.

With this info we can determine when to subtract the value, and when to keep the value the same. The problem however was that the function overwrites several things before it finally gets to the actual subtract instruction (at 0x4BE228). So the decision to subtract or not would have to be made at the start of the function. (perhaps its possible to get the  original esi value back, but I gave up looking for it)

This brought me back to the function that calls our subtract function, which was the 0x4C5331 function (or well, thats the return address). In this function we see that it gets the subtract function from a look up array (see 0x4C5322), using Cheat Engine we find that the subtract function-address is stored in 0x11C9438. I decided to make a detour function and write its address into 0x11C9438.

With the detour function in place, my first try was to not-execute the subtract function if it concerned ammo/health/etc. This quickly led to a crash. Apparently the subtract function does more then subtract. My next try was to get the pointer to the value, and increase it with the value being subtracted (as such, subtract would then have no effect). This quickly led to an issue, the value it subtracts from the main value (ok too many value's in one sentence) is also stored in an object.

It was getting late, and I was getting bored real quick with these objects in objects. So I decided to actually change the code depending on the main value. If the value is ammo/etc, I change the subtract instruction at 0x4BE228 to nop, if the value is something else, I change subtract the instruction at 0x4BE228 back to its normal value.

This worked!  So while probably not the most elegant method to success, it definitely works. I had to put in one additional check for Health. Because the Health identifier was the same for everyone (e.g. also enemies), I had to check if the health was player-health or enemy-health, I did this by checking the v-table of the calling-class (for the player its 0xF4FE60).

The end result is this +4 trainer.

Posted by: Da_Teach on Saturday, July 3, 2010  •  Comments (83)  •  Full story  •  C# Code Injection Pointers Syser Codecave Trainer Alien Breed: Impact

Mass Effect Part #1

As I said in the previous post, Mass Effect (like Trine) doesn't have a static pointer to the player object. There are a few ways around this problem and I'm going for the easiest solution.

First get the newest version of Cheat Engine, it has improved kernel debugger support (its not a full kernel debugger though, so you cant step through code) which will allow us to get passed the debugger protection in Mass Effect. Although the newest version should support 64Bit processors, I couldn't get it to work. So I used a clean WinXP install for this hack.

The next thing you do is enable kernel debugging (you can find it under Edit -> Settings -> Extra), I also enabled "Use Global Debug routines". Not entirely sure what it does but it seemed to increase stability a bit for me.

Once you setup Cheat Engine correctly its time to search for Health. Its a float, so make sure you search for a float and not 4 bytes. After you have identified the health address its time to use the kernel debugger routines.

Right click on the health address in your address list and press "Find out what writes to this address". This should return 1 instruction at 10D26F4Bh (fst dword ptr [edi]), its the only instruction (that I found) that lowers the players health. However nop'ing that instruction (e.g. make it do nothing) will result in enemies also becomming invincible. So we're not there yet.

Stop the code-finder and right click on the health address again and now select "Find out what accesses this address". This will return at least 1 function which will access the address using an instruction a bit like this "mov xmms0, [edi+48]". Using that instruction we can conclude that the health address is at 48h offset of the player object.

The reason that is interesting is because we need a way to change the instruction at 10D26F4Bh in such a way that it will decrease health for enemies but not for players.

If we remove 48h from the player address (and change the memory-type to 4 bytes) we will see that it contains 118D6968h. This is the player object's vtable, its a unique number for all objects of that type. In this case 118D6968h is the vtable for the player object and 118D3968h is the vtable for your team members.

With this information we can detour the instruction at 10D26F4Bh to use this information. There is one small problem though, the instruction is only 2 bytes and for a long-jump or call we need at least 5 bytes. To get around that problem I decided to use the code cave right after the call that holds the instruction that we want to change. That way we can use a short jump, which is also 2 bytes in size.

If you open up CheatEngine's memory view and go to address 10D26F4Bh you will see that a code-cave starts at address 10D26F57h.

I decided to write this code into the code-cave:
10D26F57 - cmp [edi-48], 118D6968
10D26F5E - je 10D26F4D
10D26F60 - cmp [edi-48], 118D3968
10D26F67 - je 10D26F4D
10D26F69 - fst dword ptr [edi]
10D26F6B - jmp 10D26F4D

Once you wrote the above code to the code-cave, then change the instruction at 10D26F4Bh to this:
jmp 10D26F57

And voilla your enemies are dieing but you and your team mates are invincible.

Tomorrow I'll write a trainer for Mass Effect which will also include some additional hacks like money, grenades, etc. But its late now and I need to go to bed :D

Posted by: Da_Teach on Wednesday, February 3, 2010  •  Comments (12)  •  Full story  •  Pointers Codecave Cheat Engine Mass Effect Anti-Debugger

Torchlight Part #2

And I thought I'd seen it all, but I was wrong :)  I have to admit I knew it was possible, but I never ever saw an executable change its base address each time it loads. That is, until I loaded up Torchlight.

While it was always on the 'standard' base address in my virtual pc (40000h), on my main pc it kept changing. Could it be a Windows 7 64-Bit thing?

Anyway, this means that all pointers have to be relative to the base address, not fixed. Its not a huge issue, whenever you find a pointer just subtract the base address from it and you have the relative pointer.

But back to the Torchlight and using a code cave. As I mentioned in part #1, I wanted to try something different. Instead of allocating memory for my code detour, I decided to use a code cave instead. Using the handy code cave finder in Cheat Engine, I found that at Torchlight.exe + 2D0h there's a code cave big enough to fit my injected code.

I decided to inject this code (I highlighted points of interest using bold-comment code):
2D0 - push eax // Start of new-health detour
2D1 - call 2f1 // Compare ESI to the Player / Pet Pointer
2D6 - cmp al,00 // Is it an enemy?
2D8 - je 2e5 // Yes, set the new health
2DA - fcom dword ptr [esi+00000394] // No, is the new value higher?
2E0 - fnstsw ax
2E2 - sahf
2E3 - jb 2ed // No, its lower
2E5 - fstp dword ptr [esi+00000394] // Set the new health value
2EB - jmp 2ef
2ED - fstp st(0)
2EF - pop eax
2F0 - ret // Return back to the normal flow (end of new health detour)
2F1 - mov eax,[Torchlight.exe+A2B6A4] // Load base pointer (start of player / pet compare)
2F6 - mov eax,[eax+1c] // Load actual player pointer
2F9 - cmp eax,esi // Compare player pointer to ESI
2FB - je 312 // Is it the player?
2FD - mov eax,[Torchlight.exe+A2B6A4] // Load base pointer
302 - mov eax,[eax+000002d4] // Load pet offset
308 - mov eax,[eax+2c] // Load pet pointer
30B - cmp eax,esi // Compare pet pointer to ESI
30D - je 312 // is it the pet?
30F - mov al,00 // Its an enemy
311 - ret // End of player / pet compare
312 - mov al,01 // Its player or pet
314 - ret // End of player / pet compare
315 - push eax // Start of new mana detour
316 - call 2f1
31B - cmp al,00
31D - je 32a
31F - fcom dword ptr [esi+000003b8]
325 - fnstsw ax
327 - sahf
328 - jb 332
32A - fstp dword ptr [esi+000003b8]
330 - jmp 334
332 - fstp st(0)
334 - pop eax
335 - ret // End of new mana detour

The above code shows 3 functions, the first function is the "new health" detour function. It checks it the health is set for an enemy or player (or pet). If its the player then it will check the new health, if its lower then it wont set the new health, if its higher it will set the new health.

That function is then copied to the "new mana" detour function (the last function).

The middle function is a small helper function (as I needed it for both new health/mana detours), it will compare the esi register with the player/pet pointers and return 1 (player/pet) or 0 (enemy).

I can write this injected code into Torchlight.exe + 2D0h, I can then detour the new health/mana instructions using a call to this injected code. And voila, you cant die, but when you level up you can get more health :)

I do have to say that my first code cave experience was a good one and I'll probably use them more. A nice thing is that almost all the injected code and detour code doesn't change because the code cave doesn't change its address.

In the trainer that I put online I added a few functions. Like change your experience, fame, pet experience, money, stat points and spell point. You can also freeze the enchantment difficulty of items. It'll basically let you enchant with almost no risk (there's still 2% risk).

You can download it here, enjoy.

Posted by: Da_Teach on Friday, January 22, 2010  •  Comments (13)  •  Full story  •  Code Injection Torchlight Codecave

Torchlight Part #1

Just like with Trine, the health of the player character is lowered / increased using the same function. This means if you make the player invulnerable, the enemies will also be invulnerable.

Now we could do the same as with Trine, allocate memory and then redirect the program flow to our injected memory. But I wanted to do something different, so for Torchlight I decided to use a code cave.

Basically this means that we look for a piece of unused memory that has already been allocated and use that to inject our code. Up until today I never used a code cave for this purpose, I have to be honest I never thought about using code caves for anything.

But it works, its "safe" (as safe as code injection can be). The only trick is to find a code cave big enough to fit the code that you want. Luckily Cheat Engine has a nice function which searches for code caves, including a desired size.

Torchlight had an additional fun factor which I never played with before, both health and mana are stored as floating points. Now this in itself isn't something new, but I never worked with floating point assembly instructions (at least not changed them).

The instruction for unlimited health was at 490649h (fstp dword ptr [esi+394]) and the two instructions for unlimited mana are at 490894h and 4908C3h (both fstp dword ptr [esi+3b8]).

All three instructions use fstp, the description for this function is "Copy ST(0) to m32fp and pop register stack". The last part causes an issue if you only nop the instruction. Not executing the instruction causes the register stack to stay the same which caused several other issues in the game (including gfx errors and crashes).

To get around this issue you have to execute a "fstp st(0)" whenever you do not execute the original instruction. This causes the register stack to pop into nothingness.

As with Trine, we have to figure out how to identify the player. With Torchlight its a bit easier then Trine. There's a pointer to the Player structure at [[E2B6A4h]+1Ch], so we can use this in our code redirection to check who's health (or mana) is getting lowered.

In part #2 I'll show some assembly code which can be used (in the code cave) to accomplish exactly that. I have some code lying around but I want to play with it a bit more before releasing it.

Posted by: Da_Teach on Tuesday, January 19, 2010  •  Comments (24)  •  Full story  •  Torchlight Codecave Cheat Engine