Log in

View Full Version : Can't set a working Hardware breakpoint


Neitsa
September 18th, 2004, 11:44
Hello,

I'm currently coding a little debugger for my own knowledge, just to see how it works. I've successfully coded the Software breakpoint (BP) part, but I can't have a working Hardware BP working.

here's some code (coded with MASM) form the debugger loop:

Code:

.elseif DebugEvent.dwDebugEventCode==EXCEPTION_DEBUG_EVENT
.if DebugEvent.u.Exception.pExceptionRecord.ExceptionCode==EXCEPTION_BREAKPOINT
.if DebugEvent.u.Exception.dwFirstChance != 0 ;first time break (ntdll.DbgBreakpoint)
;BP address (inputed by user)
push BPADDR
pop Context.iDr0
;set DR7
push 401h
pop Context.iDr7
mov Context.ContextFlags,CONTEXT_DEBUG_REGISTERS
invoke SetThreadContext,ProcessInfo.hThread,addr Context

.else
;other breakpoints /Display message
invoke MessageBox,NULL,addr szBPHere, addr szCaption,MB_OK

.endif
//cut


Little explanation :

When the system BP (ntdll dbgBreakpoint) arise I set my Dr0 and Dr7 for my target.

Dr0 is a linear address
Dr7 is set to 401h

Quote:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1

bits of Dr7:

-0 : L0 => Local breakpoint with Dr0 [set to 1]
-10 : undocumented, set to 1 as intel manual stated
-16/17 : R/W0 => set to 00 for Execution only

- 18/19 : LEN0 => set to 00 for "1 byte length" as intel manuel stated

I think threre's no need to set other bits field, thus Dr7 should be:

10000000001b = 0x401


Now the strange things happens...it never breaks on my target program...

I was just wondering why. I've read the intel manual many times but maybe I've missed something (I'm not setting the Dr6 because I think there's no need to do it...)

I've extracted the Hardware BP part of my program in a fully working program. Attached is the program with source code in asm (with radasm project). There's also a little target that does nearly nothing... (just for testing purpose).

I've tried to set hardware BP on 0x401017 in my target.exe program but it never breaks...

Can someone help me ?

Thank you very much !

Regards, Neitsa.

[edit]
Finally solved, here's a working version :

nikolatesla20
September 18th, 2004, 14:52
DR7 should be set to 0x101

-nt20

Neitsa
September 18th, 2004, 21:22
Hello,

Thank you for your answer nikolatesla20.

I've set Dr7 to 0x101 (enabled "Local exact BP" but my debugger loop never catch the Hardware BP...

Does this part of the loop catch hardware BP has it catch software BP (AKA 0CCh opcode) ?

Code:

.elseif DebugEvent.dwDebugEventCode==EXCEPTION_DEBUG_EVENT
.if DebugEvent.u.Exception.pExceptionRecord.ExceptionCode==EXCEPTION_BREAKPOINT


The only BP I get is the ntdll DbgBreakPoint, no other BP...Maybe this isn't handling hardware BPs.

Damn, I can't see what's going wrong.

Thank you very much.

Regards, Neitsa.

doug
September 18th, 2004, 21:43
your software breakpoint raises
EXCEPTION_BREAKPOINT A breakpoint was encountered

while your hardware breakpoint raises:
EXCEPTION_SINGLE_STEP A trace trap or other single-instruction mechanism signaled that one instruction has been executed.

goggles99
September 19th, 2004, 03:21
wow Neitsa, this is very interesting code to me...
Can you post your updated version source here too (once you get it working properly)

Thanks a lot......

Neitsa
September 19th, 2004, 09:24
Hello,

Thank you Doug for your answer. Well, I've uploaded a new version of this mini-debugger which handles EXCEPTION_SINGLE_STEP and EXCEPTION_ACCESS_VIOLATION.

I've put also SuspendThread and ResumeThread to be sure that the CONTEXT is set in a proper way...

Same problem... The Hardware breakpoint never raise an exception, breakpoint or single single step for my hardware BP... (I just got the same BP in ntdll)

Damn, I don't understand what is wrong, and I haven't been able to find a source code (Asm or C++) of a debugger that handle hardware BP.

It makes me sad...

goggles99 : Be sure that I'll post this code if it could work ! With the above code source you can add the software BP handling which is more easy to do. Just add some WriteProcessMemory (writing an opcode 0CCh) at the desired location in your code, and don't forget to restore the original code. If you want more precision, just feel free to ask.

Regards, Neitsa.

doug
September 19th, 2004, 12:09
there is a working implementation here:

http://www.woodmann.com/forum/showthread.php?t=5035

download e32unpack.zip from there and check the function SetBreakPoint in e32unpackDlg.cpp.

kudos to bedrock for this, it's a nice piece of work.

nikolatesla20
September 19th, 2004, 20:28
Here is some code in which I at one time tested using Hardware breakpoints, this code works.

Change the address of the BPM to the address you want to use in your test target.



-nt20

Neitsa
September 19th, 2004, 22:18
Hello,

Thank you very much doug and nikolatesla20. I've read both source code carefully and they do nearly the same thing I've done (but they works ).

I think the problem is in my debugger loop, but I haven't find it yet. I'll watch both source carefully, and I'm sure I'll be able to make it works as I need.

Thank you for the help you provided.

Regards, Neitsa.

goggles99
September 23rd, 2004, 04:07
here is a masm example

"Examples on how to use the DrX registers on 9x, ME and NT/2k"

y0da.cjb.net <---look under "Code Snippets"

Good Luck... Let us know how it goes.

Neitsa
September 23rd, 2004, 11:55
Hello,

Well goggles99,

It works !!!

Even without seeing the source code from the yoda site, the solution was in the readme file... My mistake was I was trying to set the hardware BP too soon

here's a part of the readme:

Quote:

It's because at the time of the DEBUG_BREAK hasn't the main thread it's real context. NT sets the real context later via the NtContinue API. So a possible method to set a BPM directly at the EntryPoint...


I've done something different than yoda makes, but the final result is the same...

Damn I'm happy !!!

Thanx a lot goggles99

I've uploaded the working version of the debugger with hadware and software breakpoints handling at the top (with full source code in Asm)

Thank you very much.

Regards, Neitsa.