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




And from the log:






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

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

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~


edit
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

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
7c90d05e

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

4100ca
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

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


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

I have nothing against perverts, do not worry.

@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?

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 )

mb wrk ?

@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?