A forum for reverse engineering, OS internals and malware analysis 

Discussion on reverse-engineering and debugging.
 #10917  by _Lynn
 Mon Jan 09, 2012 7:45 am
judging by my analysis of kiuserexceptiondispatcher under wow64 you can of course set the debug registers, however they do not fire. Here is an example -

SetThreadContext() on a thread with Dr0 to some instruction, then set Dr7 to 1 for locale detect and leave the other flags 0 because it would be an instruction fetch. (dosent matter, same issue with read/write)

now the thread is moving along and decides it will call NtContinue, before the call it sets Dr0 to a different address.

after the thread begins execution at EIP specified in the CONTEXT struct we passed to NtContinue it hits instruction fetch Dr0 specified to NtContinue but does NOT raise an exception, instead it will raise exception on what we originally set with SetThreadContext.

I saw this today when analyzing some user-mode malware that was using debug registers to hold data, I wasn't sure if it was normal but after confirming it through several tests in my own program it seems this is the case.

So question is, is this intended? or this just wow64? :D

thanks
 #10927  by lorddoskias
 Mon Jan 09, 2012 4:58 pm
I'm just thinking aloud here - but PatchGuard as a security measure tinkers with the hardware debug register - could it be that its integrity checking routine is firing up and messing with you?
 #10943  by everdox
 Tue Jan 10, 2012 10:36 am
i think you are forgetting the context_debug_registers flag which is first field in a wow64 context struct. The thing about that is, the calling code to NtContinue can mingle with the debug registers all it wants but if that flag isn't set, nothing will come of it. so it may look like something is going on, when it really isn't.

either that or the individual to write that piece of malware isn't all too informed ;p

you can tell this easily because in the wow64 subsystem NtContinue wont step into kernel unless that flag is set ;)