as we known,in OD the hardware breakpoint use the DR0-DR3.
my questions are
1. F8 and F4 are also use these debug registers,but they still work after i set 4 hardware breakpoints.how can OD do?
2. when i set a memory breakpoint,it appear in the DR0,but it is overlayed by another hardware breakpoint after i set the hardware breakpoint.fortunately the memory breakpoint still work. where is it?
3.at the memory map,we can set a memory breakpoint to a section with F2 or "right button" .what is the difference?
4.when i set a memory breakpoint to a section,how can OD do?i means whether the OD use the DRx debug registers or not.if no,how can OD do it?
thx

I think memory breakpoints are done with memory protection options (PAGE_NOACCESS, PAGE_GUARD and such) rather than hardware breakpoints. And I'm not sure if tracing with hw bp is done correctly - when I set all four hw bps, Olly starts breaking on every command.

Hi Lenus,

1. There are only four hardware breakpoints, so Olly has to use a standard 0CCh replacement. The 0CCh will be replaced by the original byte as soon as you press F8. Code a little procedure to check the return address and you will see if i'm right. Note that this a problem with checksums...

2. Olly has problems with the hardware breakpoints. For example, they are still there if you clear the debug registers!. This is partially a feature, cos you dont have to loose time adding them again, and a problem, cos a packer could use a hardware breakpoint as well. Restoring them could be done at ntdll.ZwContinue, but never before.

Let's do a little experiment: we set the 4 hardware breakpoints and now we set a memory breakpoint. It works fine. Then, this means that Olly has also used a PAGE_GUARD for the later one, however we have not been shown the exception. A debugger chooses when to report an exception (example: SICE controls most of the intel predefined interrupts but you only "see" int1 and int3).

3,4 are already answered in the post above.

Hope it helps

PS: you can debug Olly with Olly, set a breakpoint (a standard one) at WriteProcessMemory, ReadProcessMemory, WaitDebugEvent,... and observe what happens. Check the context changes when it calls Get/SetThreadContext.