 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
chASM
Newbie cheater
![]() Reputation: 0
Joined: 23 Jun 2011
Posts: 17
|
 Posted: Wed Dec 14, 2011 11:41 pm Post subject: Saints Row The Third + start in debugger lollygagging. |
 |
|
I needed something to test a plugin I coded for CE. So, I picked Saints Row the Third, which I had just purchased for a nice price.
After the necessary 'installation' of a crack (don't want to screw up my Steam account, even if it is improbable), I think its a Skidrow one, I noticed that when the game is launched in a debugger (open process in CE, start it in OllyDbg, etc), it bombs out in a rather 'cute' manner.
I decided to track this down, since the error message (the second one actually, the first 'bomb' was quickly found) it throws DURING the replay of the intro movie uses an 'error code' that isn't actually and error code but an exception one MUST raise (yeah, MS, that's how it's done.. idiots) if you want to assign a NAME to a THREAD. In short, you want an actual string name for your thread, you must raise a specific exception (literally a call to the 'kernel32.RaiseException' (which under Win7 calls KERNELBASE.RaiseException) function) to do so.
Binkw32.dll seems to do just this, but only if a debugger is present.
The first detonation in the debugger happens within "saintsrowthethird-dx11.exe" (note, this is only tested on that specific executable) however.
In OllyDbg, locate the following bit of code (0xD2C253 on my version):
| Code: |
00D2C253 |. 8D85 BCFDFFFF LEA EAX,DWORD PTR SS:[EBP-244]
00D2C259 |. 8945 08 MOV DWORD PTR SS:[EBP+8],EAX
00D2C25C |. 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8]
00D2C25F |. CC INT3
00D2C260 |. 64:8F05 00000000 POP DWORD PTR FS:[0]
00D2C267 |. 83C4 08 ADD ESP,8
00D2C26A |. 5E POP ESI
00D2C26B |. 8BE5 MOV ESP,EBP
00D2C26D |. 5D POP EBP
|
To the 'trained' eye, it is instantly obvious what tosses the game. Note the INT3 call in there, that's a software break point, in the middle of a routine. This, apparently throws a debugger into convulsions. Simply replace the INT3 with a NOP (change the 0xCC to 0x90) and that's the first one out of the way. The game will now actually start all the way to the intro movie.
The second error (the thread naming one, which isn't an error, most (debugger alike) software processes it as an exception anyway), is in Binkw32.dll, located at 0x10000000 on my version of the game.
Below is the code that raises the exception (eg, tries to set a thread name), note the debugger check.
| Code: |
1002704E 68 00100410 PUSH binkw32.10041000 ; ASCII "IsDebuggerPresent"
10027053 68 14100410 PUSH binkw32.10041014 ; ASCII "KERNEL32"
10027058 FF15 B0100310 CALL NEAR DWORD PTR DS:[<&KERNEL32.Ge> ; kernel32.GetModuleHandleA
1002705E 50 PUSH EAX
1002705F FF15 A8100310 CALL NEAR DWORD PTR DS:[<&KERNEL32.Ge> ; kernel32.GetProcAddress
10027065 A3 10000410 MOV DWORD PTR DS:[10040010],EAX
1002706A 85C0 TEST EAX,EAX
1002706C 75 10 JNE SHORT binkw32.1002707E
1002706E C705 10000410 01000000 MOV DWORD PTR DS:[10040010],1
10027078 5F POP EDI
10027079 5E POP ESI
1002707A 8BE5 MOV ESP,EBP
1002707C 5D POP EBP
1002707D C3 RETN
|
At 0x1002706C is a JNE (jump if not equal) or JNZ (jump if not zero), depending on debugger used. Simply change that to a JE (jump if equal) to kill that 'error' message (so, change the 0x75 to 0x74) and be able to start the game entirely.
BIG NOTE: This still does NOT allow one to use the debugger to set breakpoints (which is what CE does to find out what values/memory addresses/etc are accessed or written to), the game will bomb out without even the slightest hint of an error. This is a game internal memory integrity management system at work. I've found and circumvented it (with much help of the above explanation, since I run x64 and kernel mode hacking is as thus useless) but that one comes in a bit of a harder package, it is not easy to locate which code is doing it, or is it? Give it a shot, never hurts to f**k around a bit to learn/become better at things.
Here's a simplistic auto-assembler script to disable the 'debugger protection' and the thread naming.
| Code: |
// Find offending code areas
aobscan(breaker,89 45 08 8b 45 08 CC 64 8F)
aobscan(binker,85 c0 75 10 c7 05 * * * * 01 00 00 00)
// Replace 0xCC with 0x90
breaker+6:
db 90
// Replace 0x75 with 0x74
binker+2:
db 74
|
If you open the exe with open process in CE, execute the above script right after it loads into CE but before you run the game from the memory viewer.
Oh, the game will throw at least one or two other exceptions that can simply be continued with shift-F9 in OllyDbg, I think CE swallowed them just fine.
Perhaps someone will have a use for such basic issues (one a 'protection' of sorts, the break point in the middle of code, the other a debugging feature but ignored entirely by OllyDbg and CE due to it being a RaiseException) and how to fix em the simple way.
Personally, I just thought it was 'funny' that something as simplistic as a break point in the middle of code can throw off two 'major' debuggers as well as the same two debuggers not detecting a specific error code being sent to RaiseException which so happens not to be an error, both debuggers allow it to throw the exception as an exception, instead of just continuing, as the very call to RaiseException specifies upon execution.
Understandable omission though, It seems that the knowledge of the ability to assign a name to a thread is as obscure as the method of doing so.
Also, doing this seems to change something in the game. For one, the game runs in a window, automatically if a debugger is attached. It is entirely possible that there are debugger options in the game somewhere that can be activated with a key-press or something. I honestly haven't bothered to try this at all as I had a different goal (the disabling of the memory integrity management code).
On a side-note, another game that tends to throw a lot of these thread-naming exceptions is Batman Arkham City, even with xlive memory integrity management circumvented. Here too it is based upon a VERY infrequent (and almost random locations in memory) check by some bits of code. either xlive or internal to the game, I didn't spent a lot of time investigating this one.
I suspect we are going to see a lot of these memory integrity management systems in the coming years, and with that I mean _different_ ones, each one more sophisticated than the previous. Considering how aggressive some of these systems are (I am looking in the general direction of Activision/Blizzard here) for anti-cheat purposes, specifically for multiplayer of course, but why turn that off during single player? It is easier to just have it run exactly like the multiplayer, but with just a single player present, and as thus, the anti-cheat code will come along with that. Going to be interesting to see how far they are willing to go in order to prevent cheating based sales/subscription disasters (and with that, make many people's lives very difficult in order to create cheats, yet challenge others to reverse-engineer the s**t out of it in order to break it. I belong in the latter category (it is almost what I do for a living, sort of) while most people on this forum fit in the former category, others in the middle.).
Regards,
chASM
PS: This is some strong stuff, man.. look at the SIZE of this post..
|
|
| Back to top |
|
 |
bartekdvd
How do I cheat?
![]() Reputation: 0
Joined: 01 Jan 2012
Posts: 4
|
| Posted: Sun Jan 01, 2012 12:21 pm Post subject: Saints Row The Third anti-debugger protection off |
|
|
Hey,
Your post really help me to disable anti-debugger protection in saints row 3 (SKIDROW ver). However changeing only int3 (d2c25f) instruction to 0x90 and JNE to JE in binkw32.dll doesn't resolve the problem and game always turning off(?) (using your auto-assembler script too) when I was trying to attach debugger to the saintsrowthethird_dx11 process. So I decided to open sr3 exec in ollydbg and I discovered that NOPing instructions at these addresses:
| Code: | ffd3ff
ffd4bf
d2c1ec
ffd072
ffd51d
ffcf12
ffd33f
ffd39d
ffcfc2
be5cd9
e87697
eab5a2
(binkw32)
10002446
10002502
100025D8 |
gave me the possibility to debug the sr3 process in game successfully. What is more when I changed int3 to NOP at d2c25f address, in CE "find what writes to this address" and "find what access to this address" functions fails showing nothing. Concluding, it is not indicated(?) or necessary to nop this int3 instruction in CE. Without doing this debugger works just fine and i am able to "find what access and what writes to this address", but in ollydbg before intro movies, when int3 is not replaced by nop, game throws an exception and stops.
Sorry for my bad English.
Edit;
Download cheat table from this post.
In game(only for dx10/11):
1. Open process and load table.
2. Click on Advanced Options.
3. Replace all with code that does nothing.
4. Now you can attach debugger to the current process.
| Description: |
| disable anti-debugger protection saints row the third |
|
Download |
| Filename: |
saintsrowthethird_dx11.CT |
| Filesize: |
11.23 KB |
| Downloaded: |
1589 Time(s) |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
