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.

With Steam having those amazing sales, I picked up Defense Grid: The Awakening for something like 2-3 euro. I was bored, so sue me. I found that it was actually a pretty funny game for a few hours and then I figured, what the hell lets start hacking :D

Started up Cheat Engine and started searching for some values. Interestingly enough this game had some unexpected anti-cheat mechanisms in place.

Anyways, I went through the usual tricks, search for the credits as a integer, float, double, etc. Funny enough it seemed it was stored both as a float and a double. But changing those values did not do anything to the ingame credits.

That got me intrigued, apparently this game was either using memory-encryption or some other form of anti-cheat mechanisms. I then remembered that the first level starts off with 0 credits and a bit later in the level you got 200 credits to finish the mission. So I put Cheat Engine to work.

A minute or so later I had the starting-credits and I saw something strange. The value at this pointer never went down and in fact (by killing enemies) only went up, regardless of the amount of credits I spent.

This got me thinking, if this value does not go down, another value must be somewhere in memory that keeps track of what has been spent. So started a new mission,searched for the amount of credits spent on towers and found the value that keeps track of the amount of credits that have been spent.

Now having two values in memory it was time to find out what static addresses point to these values so I can create a trainer for the game. This is where things got funky. Normally I would use the pointer-scanner in Cheat Engine and it'll quickly tell you what base pointer points to the value. However that would be too easy wouldn't it ;)

With that not getting anywhere, I used Cheat Engine's "what changes this address" only to crash the game seconds later. I should have known because its a Steam game, it has anti-debugger protection. So I booted up my VMware image with Syser and repeated the whole process.

I found out that the code-address changing was at 8BB1FCh, the instruction in question as "movss dword ptr [ebx+10h], xmm0", great.

As I was interested in base address of the value, I booted up IDA Pro Disassembler which has to be the best disassembler on the market at this moment. Only to find out that there was yet another protection in place, the executable had been packed by a PE Packer.

For 2-3 euro, I didnt expect this many protections in place, but it sure made hacking this game so much more interesting. Anyways, check out part 2 which will be posted later to find out a way to get around a PE Packer. Its only one of the possible ways, but its probably the easiest way.

Lately I've seen an increased number of games use anti-debugger protection. This is mostly because a lot of them use the same copy protection. For example, it seems all the Steam games (at least the ones I have tried) have the same anti-debugger protection.

The effect seems to be roughly the same with the various protections. They all seem to crash the game after you place a breakpoint (either hardware or an int-3 breakpoint) inside it.

Now I have actually been too lazy to figure out exactly what's causing this issue. But I have some idea's which I'll have to play with in the future.

However there is an easy way around the issue. Use a kernel debugger that also supports debugging user-mode applications.

I've tried WinDBG, but its kernel debugger requires you to connect two pc's together with a serial cable. I got this working with VMware, however I got an error trying to attach to a user-mode application. It might still be possible with WinDBG, but I got bored trying to figure out why I was getting errors.

VMware also had an internal remote kernel debugger, however it doesn't support user-mode application debugging, at least not for Windows guest-os.

I also tried Syser and while it can do exactly what I want, I couldn't get it to work with my PC (Clean WinXP install with Syser, BSOD whenever Syser activated). Then I played around with it a bit more and found out that it works perfectly inside a VMware guest-os.

So to get around the anti-debugger protection (for now) I ended up using a WinXP guest-os inside a VMware machine with Syser installed. That said I do hope that Syser fixes support for the newer nvidia-graphics cards soon so I can debug without the use of VMware.