Cheat Engine

[Bliebla]

Over the past 2 years a lot of topics have been devoted to this subject, but none of the solutions seem to work for me.

When debugging Steam games (MW3, single player in this case) the game always seems to crash the moment you attach the debugger.

Usually the solution is to use the DBVM or VEH debugger, but this does not seem to work for me.

I am using Windows 7, 64 bit on an Intel Q9570 quad core. I have tried all 3 available debuggers in Cheat Engine with almost all possible option combinations and it seems to crash iw5sp.exe every time.

Any help would be greatly appreciated.

[Dark Byte]

Get the cracked version of the game, not only will debugging be easier, the game will most likely run smoother as well.

anyhow, to see why it crashes, go to memoryview->threadlist and expand the threads.
If the DRx values are not set to 0, that means the game makes use of the breakpoints, and if you replace them with your own, those breakpoints never get hit, and thus crash the game.

You can prevent that crash by going to settings->debugger options and disable "override existing breakpoints when setting breakpoints", of course, if the thread that accesses it also has those breakpoints set, you won't find anything.
To increase the odds attach the veh debugger to the game(using the processlist, NOT by setting a breakpoint), and watch mv->view->debug events
Play the game a little and see which breakpoints have been hit and which threads it occurs the most.
Then in the threadlist select all threads, except the one that triggers the breakpoint almost every second, and then rightclick and choose the option to clear the debug registers
With some luck you will have a few seconds before the game crashes, allowing you to find the code that accesses the variable

[Apache81]

Hi Dark Byte !!!
I'm trying to hack the FalloutNV latest Steam version and I'm experiencing the crash as well.

Here's what I'm doing: I'm using veh debugger because windows debugger crashes more frequently.
With veh I'm able to attach a debugger to the variable with the value I want to track, to start searching for the pointer (find what write the memory).
But when I attach the debugger to the memory that contains the possible pointer (find what access the memory) the game crashes.

I did as you suggested but it doesn't seem to work. I also checked the DRx values of any single thread (there are a lot...) and they are all 0.

To be honest I've not tried to use the kernelmode debugger.

Any other suggestion?

[goat69]

[Apache81]

Well... a really unexpected answer....

Thanks

[Xblade Of Heaven]

[Dark Byte]

Go to settings, debug settings, and uncheck the option that says override existing breakpoints
See if it then still crashes

[Apache81]

override existing breakpoints is already unchecked... I'll try the DBVM and kernel mode

[Apache81]

just to make you know: using DBVM gives me blue screen

[dcx2]

I think I figured out how to debug Steam games. For ref I am Win7 x64 home premium.

First, I think you need DBVM. I shut down all apps except CE_x64 (might not have to do *all* apps but I couldn't be bothered to figure out which ones can stay open). Then go to Help -> About and click on the DBVM thing. Hopefully it won't BSOD (it did when I had some stuff open, which is why I closed everything).

If that works (mine said DBVM version 7), then the next step is to start Steam.

The next step is to beat Steam's anti-debugging code. According to a page on "The Hacker Within" regarding "Steam anti-debugging code" (the forum won't let me post url's, so just google the quotes), you can install that app at the end of his post. This app will let you inject a user-mode dll into Steam that hooks a couple functions that will hide the debugger. Make sure you do NOT go online or you will get VAC banned, if you go to play any online games after hacking then shut down and restart Steam or you will still get VAC banned.

Once you've injected the dll into Steam, then you must use Steam to launch your game (can't double click the icon, must go through Steam so that you use Steam's CreateProcess, which is hooked by the dll). Assuming you have DBVM working, this should let you attach the debugger to Steam games successfully. I am personally using this on Borderlands Steam version right now.

[Apache81]

Well.... very interesting solution.
I need to try.

However I'm a very lazy guy so I hope that DB will improve the next version of CE by introducing this as a function !!!

Anyway... just a think: I got also Divinity II on Steam (the summer sale made VERY BIG damages....) and I hacked it with no problems attacching the VEH Debugger.
Maybe the problems occurr only for the games that have online feature because they uses the Steam online library and VAC system.... dunno....

[Alice0725]

I've googled a blog, It's about steam anti-anti-debug! I'v tested ,not work with sleeping dogs, as it have some custom code. But, maybe work with other games.

-------------------------------------
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 VAdelphi-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.

[Dark Byte]

That doesn't really explain why kernelmode and veh cause a crash (unless it crashes because of the drx override)

Anyhow, 6.2 has a signed driver, and in lua I exposed routines to get the EThread of a thread. I'm sure someone can use that for something

[gir489]

I'm trying to do what dark byte said to do on the latest cracked version of sleeping dogs, but as soon as I clear the debug registers on the thread that's consuming all the breakpoints, the game crashes instantly.

[Dark Byte]

Try exception breakpoints

Alternatively, patch all the codes that rely on hw bp's and emulate their behaviour. While the debugger is attached the debug events window will show the internal breakpoints