Results 1 to 11 of 11

Thread: 'Debugged application has modified the debugging registers', what does this mean?

  1. #1

    'Debugged application has modified the debugging registers', what does this mean?

    I am using olldbg 2.0.1h and loaded a dll into it, but during the loading it shows me that:

    Debugged application has modified the debugging registers. Maybe it called ZwContinue() or SetDebugContext(). The modifications are saved to the log.

    And from the log:

    77C1F2A1 Modified debug registers of main thread
    DR2: old 7C90D05E, new 00000000
    DR3: old 004100CA, new 00000000
    DR7: old 00002150, new 00000000

    So what does this mean and how to deal with it?

  2. #2
    Super Moderator
    Join Date
    Dec 2004
    Blog Entries
    i assume you understand the basics of hardware breakpoints ( the so called data breakpoints or write breakpoints)

    if you dont giyf (google is your friend)

    in short when you set a hardware breakpoint (limited to max 4 breakpoints in parallel in x86 )
    the system notes the offset where the breakpoints were set in the debug registers (dr0 to dr3) ( dr4 and dr5 are synonyms for dr6 and dr7) dr6 and dr7 are hold bitmasks that describe the breakpoints
    1) Read access to a specific address
    2) Write Access to a specific address
    3)execute access on a specific address

    when you have set a breakpoint it can be erased by a debugging application (anti debugging measure)
    how it does it is implementation specific but most likely an exception is raised
    and in the exception handler debug registers are wiped off in the context structure

    now in v2 ollydbg also uses hardware breakpoints internally for stepping if opted in

    and like it posted in the log the debuggee you are playing with has wiped off the debug registers
    and like it says some apis like ZwContinue ( ) on Exception handling or direct modification of DebugRegisters via SetDebugContext()
    might have been used

    how to deal with it single stepping as usual looking for setting up of exception handlers
    reading about windows internals waiting for the action deep inside system and bypassing the antidebug measure manually

    and mostly it is case specific no generic do this do that steps can be laid out
    Last edited by blabberer; January 30th, 2013 at 04:42.

  3. #3
    Thanks for the reply. According to your comment I can come up to a conclusion that "The debuggee has used(100% sure) some anti-debug techniques, so go follow the code as usual and bypass(or clean up) the anti-debug code first", is my understanding correct?

    But I tried many times and the breakpoints(hardware type and memory type) I set all worked, so what's the bad consequence if I leave the 'debug registers being modified' or 'the debug registers has been wiped off'?

    Thank you~

    use reply to thread and not reply with quote
    when replying quote parts of earlier reply only if it is essential to replying
    quoting the full previous reply makes it hard to read the post and increases the storage space for a thread
    Last edited by blabberer; January 30th, 2013 at 04:35.

  4. #4
    Super Moderator
    Join Date
    Dec 2004
    Blog Entries
    yes your understanding is pretty much right if there is an antidebug that screws the debug registers you need to eliminate it first

    i have not played a lot with ollydbg v2 so i cant say why the log is generated

    but the log is pretty clear for what it logged
    have you googled about debug registers or did you digest what i posted earlier ?

    there seems to be two hardware breakpoints one at

    which in xp sp3 is for ntdll.dll Zw/NtContinue ( i rememeber seeing and option in odbg2 where you can opt in to set permanent hwbp on this api and few others
    have you enabled it ?? look in options

    lkd> lm m ntdll
    start end module name
    7c900000 7c9b2000 ntdll (pdb symbols) f:\symbols\ntdll.pdb\6992F4DAF4B144068D78669D6CB5D2072\ntdll.pdb
    lkd> ln 7C90D05E
    (7c90d05e) ntdll!NtContinue | (7c90d06e) ntdll!NtCreateDebugObject
    Exact matches:
    ntdll!NtContinue = <no type information>
    ntdll!ZwContinue = <no type information>

    the other one is at your user space

    who set this breakpoint ? have you set it ? look here for clues to your problem

    DR2: old 7C90D05E, new 00000000
    DR3: old 004100CA, new 00000000
    DR7: old 00002150, new 00000000

    as mentioned earlier dr7 holds a bit mask

    lkd> !grep -i -e "binary" -c ".formats 2150"
    Binary: 00000000 00000000 00100001 01010000
    bit 4 and 6 are set so so dr2 and dr3 are locally enabled with bit 8 (will be reset by processor on task switch)

    DR7.GD (bit 13) is set so reading or writing to a debug registers triggers an int 1 (possible r0 hooks)

    and remember dont reply with quote use reply to thread
    if you want to quote quote parts with tags

  5. #5
    Get control in the place where the context is changed. This is a primitive antidebug.

    lkd> lm m
    Use KM dbg - it insanity

  6. #6
    Super Moderator
    Join Date
    Dec 2004
    Blog Entries
    Use KM dbg - it insanity
    then i must tell you i wrote a plugin to use lkd inside ollydbg v2 didn't you see it
    all you need is alt+f1 and lm m ntdll is inside ollydbg no KM dbg no vm no terabytes of hard disk no gigabytes of ram no core 2 duo
    just plain old p1/2 20 gb 512 mb sdr can run it

  7. #7
    I have nothing against perverts, do not worry.

  8. #8
    @blabberer it really took me some time to do some homework of what you replied. but now I met a problem:

    The process I debugged in olly created a thread to do some socket communicating, I stepped in this thread but cannot move on when met "GetQueuedCompletionStatus".
    Any idea about this?

  9. #9
    Super Moderator
    Join Date
    Dec 2004
    Blog Entries
    GetQueuedCompletionStatus blocks the thread that called it until some work is available
    so you need to understand what port it is waiting for and why

    one trick if the timeout value is INFINITE is it can be changed in memory to some few seconds so that the api returns back when timeout happens
    (obviously you wont get the data it is supposedly waiting for but careful single stepping can yield further code paths )

  10. #10
    mb wrk ?

  11. #11
    @blabberer What I want to do is to find out what way the code is going(after receiving the socket packet). I also tried 'run trace', but also stuck at 'GetQueuedCompletionStatus'. If I press f12 to pause and then press f9 to run again, the program could continue, but looks like I lost some trace. I just want to know what way the code is going, do you have some workarounds?

Similar Threads

  1. Problem debugging DirectX application
    By LOPAN in forum The Newbie Forum
    Replies: 4
    Last Post: March 1st, 2010, 19:16
  2. DirectX debugging: modified PIX shows callstacks
    By arc_ in forum Tools of Our Trade (TOT) Messageboard
    Replies: 7
    Last Post: June 16th, 2009, 19:17
  3. Replies: 3
    Last Post: December 4th, 2008, 01:57
  4. Debugged program unable to process exception
    By _InSaNe_ in forum Malware Analysis and Unpacking Forum
    Replies: 10
    Last Post: September 27th, 2007, 22:02
  5. multithread application debugging
    By crkzone in forum Advanced Reversing and Programming
    Replies: 3
    Last Post: November 7th, 2004, 17:32

Tags for this Thread


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts