Cheat Engine Forum Index Cheat Engine
The Official Site of Cheat Engine
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


Use DBVM debugging

 
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine Source -> DBVM
View previous topic :: View next topic  
Author Message
nb81
Cheater
Reputation: 0

Joined: 08 Jun 2013
Posts: 31

PostPosted: Sun Jul 07, 2019 4:40 pm    Post subject: Use DBVM debugging Reply with quote

hi,

Is it possible to make CE use whatever 'DBVM Find out what accesses this address' uses to debug and set BPs? Whenever I want to set a breakpoint, CE prompts me to attach it's debugger (which is not an option as the game I'm trying to get into detects debugging). I have kernel-debugging ticked, DBVM loaded, global kernel debug ticked, override existing breakpoints unticked.

I donít know what kind of protection it is as it shuts down the game as soon as I attach the debugger (with like 2-3s delay). Is there any usermode API that could detect the attaching of CE kernel mode debugger?

thanks
Back to top
View user's profile Send private message
Dark Byte
Site Admin
Reputation: 367

Joined: 09 May 2003
Posts: 21661
Location: The netherlands

PostPosted: Sun Jul 07, 2019 11:04 pm    Post subject: Reply with quote

perhaps the window caption
And there is this one bug in kerneldebug

_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Back to top
View user's profile Send private message MSN Messenger
nb81
Cheater
Reputation: 0

Joined: 08 Jun 2013
Posts: 31

PostPosted: Mon Jul 08, 2019 12:45 am    Post subject: Reply with quote

I doubt it would be the window caption as I'm able to R/W the game's memory just fine (even though this is without handles but kernelmode debugging shouldn't open a handle either, right?). The game closes only if I attach the debugger (open the process with debugger attached, trying to place a BP or using the default 'find out what accesses...' feature). Can they counter the kernel debugger with NtSetContextThread (setting debug registers)?

I'm not sure what the kernel debugger does on initialization but it gets caught right after attaching :s. Also may I ask what's the bug that you mentioned?

edit: Oh, by kernel-mode debugger bug you mean the Dr7 flag being set to some value? That might be it ...
Back to top
View user's profile Send private message
Dark Byte
Site Admin
Reputation: 367

Joined: 09 May 2003
Posts: 21661
Location: The netherlands

PostPosted: Mon Jul 08, 2019 1:47 am    Post subject: Reply with quote

Are you using the default driver or the newer one i posted a few days ago?
the old one would make a wrong read of dr1 if it has set it's own debug register
but there could be more bugs.

The dbvm find what.. routines work by storing the state inside DBVM and let ce poll the buffer, so the guest os is never interrupted, but i guess i could make it trigger an interrupt.
also those functions don't set breakpoint, they just mark pages as unreadable so single step implementation will likely still require normal kerneldebug

_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Back to top
View user's profile Send private message MSN Messenger
nb81
Cheater
Reputation: 0

Joined: 08 Jun 2013
Posts: 31

PostPosted: Mon Jul 08, 2019 2:29 am    Post subject: Reply with quote

I'm using master HEAD compiled. Could you push the fix to GitHub?
Also, I think it's still a problem that the value of Dr7 isn't hidden (0xF0401).
Back to top
View user's profile Send private message
Dark Byte
Site Admin
Reputation: 367

Joined: 09 May 2003
Posts: 21661
Location: The netherlands

PostPosted: Mon Jul 08, 2019 2:52 am    Post subject: Reply with quote

that's likely due to some debugcode that crept in the released version

i've commited the latest changes to GitHub , but I haven't really tested this with kernelmode debug yet (focused more on dbvm at the moment)

_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Back to top
View user's profile Send private message MSN Messenger
nb81
Cheater
Reputation: 0

Joined: 08 Jun 2013
Posts: 31

PostPosted: Tue Jul 09, 2019 5:08 am    Post subject: Reply with quote

with the correct dr7 value in your last commit it doesn't crash anymore (they probably had some hardcoded check against CE or invalid Dr7 bits), however after attaching the debugger, the game slows down insanely (~400fps to 30-40fps) and I'm not able to catch any debug event (setting a breakpoint won't trigger, find out what writes functions don't work either, except for the DBVM one). I think they might be checking DR states and mess with threads but I have no idea what causes this kind of behavior (game slowing down and outputs no debug events).

Also note that, this is probably a specific (usermode, they don't load any driver at any time) protection against CE's kernel debug approach as other games can be debugged just fine using the same setup.
Back to top
View user's profile Send private message
Dark Byte
Site Admin
Reputation: 367

Joined: 09 May 2003
Posts: 21661
Location: The netherlands

PostPosted: Tue Jul 09, 2019 6:14 am    Post subject: Reply with quote

If the target uses up all 4 debug registers for itself then globaldebug won't be able to pick a free debug register.

And if it's constantly accessing debug registers it will slow down
E.g. A loop accessing debug registers and wait till that loop is done. If the loop normally would take 1 second, it would take 1000 seconds (since instead of 1 instruction it will go through the whole int1 handler code for every debug register accessed)

_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Back to top
View user's profile Send private message MSN Messenger
nb81
Cheater
Reputation: 0

Joined: 08 Jun 2013
Posts: 31

PostPosted: Wed Jul 10, 2019 4:15 am    Post subject: Reply with quote

Well, as you may have guessed, I tried hooking ntoskrnl.NtSetContextThread to see if any DRs are getting set but couldn't catch anything from the game (catched my own calls from a test app tho). Does NtGetContextThread counts as access? They might be looping that or using a different way to set DRs (?) or the CONTEXT structure has to be adjusted manually when the call came from a x86 app.

edit: found out they use heaven's gate to do inlined long-mode switching and invoke syscalls but that shouldn't get around an ntoskrnl.NtXXX hook, should it?
Back to top
View user's profile Send private message
Dark Byte
Site Admin
Reputation: 367

Joined: 09 May 2003
Posts: 21661
Location: The netherlands

PostPosted: Thu Jul 11, 2019 12:05 am    Post subject: This post has 1 review(s) Reply with quote

Perhaps they use an exception handler.

E.g have a loop constantly read the address 0 which triggers a memory access violation.
The exception handler then gets a context, which includes debug registers. In there it can modify that context and if it returns it as handled windows will set the specific context. I don't think it will use NtSetContextThread in that case (could be the Ps version as it's the local process, or even just directly manipulation of the trapframe of the pagefault interrupt handler)

Also, capturing the debug registers and prevent it from setting likely isn't a proper way to go about this, because if they do what I think they do they actually USE the debugregisters.

example:
dr0 is set to an execute BP at 00400500
dr1 is set to an execute BP at 00400504
dr2 is set to an access BP at 00400600
dr3 is set to an access BP at 00400604

then have an exception handler that does:
on DR0 cause change RIP to 00601230
on DR1 cause change RIP to 00614560
on DR2 cause change RIP to 00812340
on DR3 cause increase RAX with 1

So whenever a program wants to execute the function at 00601230 it executes 00400500 instead
for 00614560 it executes 00400504
for 00812340 it reads out 00400600

and some important functions return a value decreased by 1 and then they access 00400604 to fix the return value

--
So basically removing or changing any DR would cause a crash

_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Back to top
View user's profile Send private message MSN Messenger
nb81
Cheater
Reputation: 0

Joined: 08 Jun 2013
Posts: 31

PostPosted: Fri Jul 12, 2019 1:21 am    Post subject: Reply with quote

You might be right, however this sounds like something that'd impact performance by a lot for an anti-debug technique in a game. Anyways, the method you described seems very interesting and I haven't really seen it being used anywhere. Do you have any PoC code of this somewhere?

I had some time to debug and trace the callstack of NtSetThreadContext from x86 apps, seems like it's not even directed towards ntoskrnl.NtSetThreadContext but somewhere else. I'll try hooking some underlying function somewhere deeper and see if that gets called.
Back to top
View user's profile Send private message
Dark Byte
Site Admin
Reputation: 367

Joined: 09 May 2003
Posts: 21661
Location: The netherlands

PostPosted: Fri Jul 12, 2019 4:28 am    Post subject: Reply with quote

It's slightly faster than a change reg on BP using a hardware breakpoint in CE(Since it doesn't have to wait for CE to take up and handle the event), so getting to 60 times a second should be fine without noticing any speed decrease

I don't have that code readily available atm(Used it in a anti-debug piece of code but too heavily embedded to show), but look into addvectoredexceptionhandler, and then in the exceptionhandler check which breakpoint is responsible and change the context accordingly and return handled

_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Back to top
View user's profile Send private message MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> Cheat Engine Source -> DBVM All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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 cannot download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group

CE Wiki   IRC (#CEF)   Twitter
Third party websites