Hiya friends,
I’m debugging some ring0 code on Win 7 x86_64 using WinDbg. This code?accesses memory that I wish to set a hardware breakpoint on so I may get notified whenever this location gets written to/read from.
The problem is that my hardware breakpoints are being disabled by the code running in ring0. Basically, this code is saving the contents of the dr7 register off, clearing it, accessing the memory that I’m watching (the memory I set the hardware breakpoint on), and finally is restoring the dr7 register after access. Thus, my hardware breakpoint is never hit! This means I never figure out where the memory was being manipulated from.
Suffice it to say that software breakpoints are not an acceptable alternative. Additionally, I’ve also tried mucking around with the general-detect bit in dr7 and installed my own debugger trap handler to understand if someone’s screwing with my hardware breakpoints. However, this code is quite smart and handles this attempt nicely (restores the old hooks before accessing any of the debug registers so the processor never causes an interrupt to?my debugger/trap handler).
I think I need to be running at a lower level than ring0 to deal with this piece of code. The only way of doing such a thing is by using a hypervisor, right? Are there any hypervisors/VMMs that support debugging the guest OS to accomplish what I’m trying to do (e.g. monitor register accesses)? Is there some ninja-like thing in WinDbg that can idle the guest when a specific register is altered?
Cheers,
~ ddebug
you are correct that the hypervisor can help you in debugging this problem.
since access to dr7 will cause a vmexit, you can see when/where it is
being cleared in your handler. there is no magical windbg functionality to
give you such info.
if you want to debug it old-school style, you will need to determine the
mechanism in which it is clearing dr7. for example, is it done in a tight
loop? is it done via a periodic timer/DPC? is it done in a workitem /
system thread at random times? once you’ve reverse engineered that piece,
you can patch out the code.
also, can you share this driver?
On Fri, Mar 21, 2014 at 11:42 AM, Developer Debug wrote:
> Hiya friends,
>
> I’m debugging some ring0 code on Win 7 x86_64 using WinDbg. This
> code accesses memory that I wish to set a hardware breakpoint on so I may
> get notified whenever this location gets written to/read from.
>
> The problem is that my hardware breakpoints are being disabled by the code
> running in ring0. Basically, this code is saving the contents of the dr7
> register off, clearing it, accessing the memory that I’m watching (the
> memory I set the hardware breakpoint on), and finally is restoring the dr7
> register after access. Thus, my hardware breakpoint is never hit! This
> means I never figure out where the memory was being manipulated from.
>
> Suffice it to say that software breakpoints are not an acceptable
> alternative. Additionally, I’ve also tried mucking around with the
> general-detect bit in dr7 and installed my own debugger trap handler to
> understand if someone’s screwing with my hardware breakpoints. However,
> this code is quite smart and handles this attempt nicely (restores the old
> hooks before accessing any of the debug registers so the processor never
> causes an interrupt to my debugger/trap handler).
>
> I think I need to be running at a lower level than ring0 to deal with this
> piece of code. The only way of doing such a thing is by using a hypervisor,
> right? Are there any hypervisors/VMMs that support debugging the guest OS
> to accomplish what I’m trying to do (e.g. monitor register accesses)? Is
> there some ninja-like thing in WinDbg that can idle the guest when a
> specific register is altered?
>
> Cheers,
> ~ ddebug
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
I suggest looking into VirtualBox. It has a debugger console that will
allow you to breakpoint at the machine level, rather than be dependent on
the kernel module that is implementing the debugger server that windbg
talks to.
On Mar 26, 2014 9:34 PM, “Bruce Dang” wrote:
> you are correct that the hypervisor can help you in debugging this
> problem. since access to dr7 will cause a vmexit, you can see when/where
> it is being cleared in your handler. there is no magical windbg
> functionality to give you such info.
>
> if you want to debug it old-school style, you will need to determine the
> mechanism in which it is clearing dr7. for example, is it done in a tight
> loop? is it done via a periodic timer/DPC? is it done in a workitem /
> system thread at random times? once you’ve reverse engineered that piece,
> you can patch out the code.
>
> also, can you share this driver?
>
>
> On Fri, Mar 21, 2014 at 11:42 AM, Developer Debug wrote:
>
>> Hiya friends,
>>
>> I’m debugging some ring0 code on Win 7 x86_64 using WinDbg. This
>> code accesses memory that I wish to set a hardware breakpoint on so I may
>> get notified whenever this location gets written to/read from.
>>
>> The problem is that my hardware breakpoints are being disabled by the
>> code running in ring0. Basically, this code is saving the contents of the
>> dr7 register off, clearing it, accessing the memory that I’m watching (the
>> memory I set the hardware breakpoint on), and finally is restoring the dr7
>> register after access. Thus, my hardware breakpoint is never hit! This
>> means I never figure out where the memory was being manipulated from.
>>
>> Suffice it to say that software breakpoints are not an acceptable
>> alternative. Additionally, I’ve also tried mucking around with the
>> general-detect bit in dr7 and installed my own debugger trap handler to
>> understand if someone’s screwing with my hardware breakpoints. However,
>> this code is quite smart and handles this attempt nicely (restores the old
>> hooks before accessing any of the debug registers so the processor never
>> causes an interrupt to my debugger/trap handler).
>>
>> I think I need to be running at a lower level than ring0 to deal with
>> this piece of code. The only way of doing such a thing is by using a
>> hypervisor, right? Are there any hypervisors/VMMs that support debugging
>> the guest OS to accomplish what I’m trying to do (e.g. monitor register
>> accesses)? Is there some ninja-like thing in WinDbg that can idle the guest
>> when a specific register is altered?
>>
>> Cheers,
>> ~ ddebug
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> — WINDBG is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer