Go Back

Steam's anti-debugging code

I bought a few more steam games on friday (F.E.A.R. 3, DeusEx, Brinck, Fall out series, Duke Nukem) and ran into the annoying crash-at-breakpoint again. This time, however, I decided to put some time into it to try and find why this is happening.

After a lot of googling I ran into this blog post:

While it does not specifically mention Steam, it does explain why WinDBG (and other debuggers like OllyDBG and C.E.) crash the game when a break point is triggered. Windows simply does not tell WinDBG about the break point and as such it crashes the game (as the game can't handle it either).

So I spend several hours figuring out ways to circumvent the "ThreadHideFromDebugger" flag.

At first I tried to undo the "ThreadHideFromDebugger" flag, but apparently once you've set this flag, it stays on  (there's no way to turn it off on a thread). I then tried to access the ETHREAD structure which gets modified by "NtSetInformationThread" but apparently you can't get access to the ETHREAD structure from User Space (at least not in any way that I could find).

So the only way to get rid of the "ThreadHideFromDebugger" flag is by not letting the application set the flag. There's two ways to do this, stop it in user mode or in kernel mode. Kernel mode is nice, but it really isn't funny to BSOD your system a lot while developing the driver. Also the whole 'need it to be signed' part for x64 sucks. But this is still a valid option which I might look into.

But I decided to write a user mode DLL which you can inject into Steam. Once it's injected, you simply have to start the game you want to debug from within steam and the DLL does all the work for you. It hooks 3 functions, CreateProcessA/W and NtSetInformationThread, the NtSetInformationThread hook is responsible for actually disabling the "ThreadHideFromDebugger" flag. The CreateProcess hooks are used to hook any game launched by Steam.

There's 1 big *read this*, do *not* start VAC-games (and probably also PunkBuster games) with this DLL loaded into Steam! It will most likely get you banned. Also a small disclaimer, only use this to cheat in single player games. Cheating in online-games is wrong mkay! ;)

You can download it here.

Posted by: Da_Teach on Sunday, August 7, 2011  •  Comments (230)  •  Full story  •  C# Hack Cheat Engine WinDBG Anti-Debugger

Metro 2033

While I was letting the L4 Eve Online bot do its business, I was playing a nice game of Metro 2033. I have to say its a very nice story line and the atmosphere in the game is great.

But damn I hated running out of ammo!

So for you guys out there that hate that too, change the function at 0x74C7C3 into nop's and you wont run out of ammo anymore :D

Perhaps this weekend I'll make a proper trainer, although chances are I'll be too busy playing with the L4 Eve Online bot :)

Posted by: Da_Teach on Thursday, August 12, 2010  •  Comments (47)  •  Full story  •  Metro 2033 Hack Cheat Engine

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 #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

Trine Part #1

Another game I picked up during the holiday sales at Steam was Trine, its a very simple platform game but mildly entertaining and it doesn't take a huge amount of time to complete. I actually finished it yesterday without cheating, but this blog wouldn't be about hacking if I didn't want to hack it ;)

Booted up my VMware image, because this game also had the Steam debugger protection. Started up CheatEngine and went to work. Unlike Defense Grid, the values for health and power where easily found. Put some memory break points on them and quickly found that "Unlimited Power" can be attained by nop'ing the instruction at 682F53h (7 bytes) and "Unlimted Health" can be attained by nop'ing the instruction at 691BB2h (6 bytes).

However Unlimited Health gives a nice side effect. It will actually make the enemies nearly invincible as well. I say nearly because some attacks (like dropping a box on an enemy, or using the fire arrow from the thief ) will still kill the enemy instantly.

Tomorrow I'll start disassembling the game (have to dump the executable again, as its packed by what looks like the same packer used by Defense Grid) and figure a way around this "feature" :) It looks like some code will have to be injected into the game to allow damage to the enemies but not to the played-characters.

Fun fun fun :)

Posted by: Da_Teach on Monday, January 11, 2010  •  Comments (10)  •  Full story  •  Trine Cheat Engine

Defense Grid: The Awakening Part #1

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.

Posted by: Da_Teach on Friday, January 1, 2010  •  Comments (48)  •  Full story  •  Syser IDA Pro Cheat Engine Defense Grid