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:
http://nsylvain.blogspot.com/2007/08/threadhidefromdebugger-but-why.html

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 07, 2011  •  Comments (37)  •  Full story  •  C# Hack Cheat Engine WinDBG Anti-Debugger

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 03, 2010  •  Comments (5)  •  Full story  •  Pointers Codecave Cheat Engine Mass Effect Anti-Debugger

Anti-debugger protection

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.

Posted by: Da_Teach on Friday, January 01, 2010  •  Comments (0)  •  Full story  •  Syser WinDBG Anti-Debugger