How to defend against hardware breakpoints-debugging registers

1. Preface

When I entered the ollydbg door, I was full of questions about various breakpoints in ollydbg. I used to understand the differences between normal breakpoints, memory breakpoints, and hardware breakpoints, why are they sometimes unable to mix them? What are their principles? after learning the articles of their predecessors, they finally understood something. I hope this article will help you with the principle and usage of hardware breakpoints.

2. Text
--------------------------------------------------
I. Principle of hardware breakpoint

In registers, there are some registers for debugging. People call them debugging registers, which have a total of eight names respectively from the Dr0-Dr7. Therefore, we also call the debugging register drx.

For the four Debug Registers of the Dr0-Dr3, their role is to store the interrupt address, for example: 401000
For DR4 and DR5 registers, we generally do not use them and keep them.
For dr6, the two registers of dr7 are used to record the properties of the address you disconnected in the Dr0-Dr3, for example, whether the 401000 is read or written by hardware or executed; whether it is a byte, a pair of words, or a pair of words.

Okay. you may understand something here.

1. Why is there only four hardware breakpoints in OD?
2. Why are there byte, word, and DWORD in the hardware breakpoint?
3. Why are there read, write, and execution points for the hardware breakpoint?

Ii. Differences between F4, F8, F7, and F2

In the help of ollydbug, I only mentioned how to use F7 and F8, and did not explain their implementation principles.

Now let's do an experiment.

Experiment 1 (Principles of F4)

1. Find a program, load the OD, and construct an endless loop.

Like this:

00400154> 90 NOP // EP stops here
00400155 90 NOP
00400156 90 NOP
00400157 90 NOP
00400158 ^ EB fa JMP short day 2 International. <moduleentrypoint> // construct an endless loop
0040015a 61 popad
0040015b 94 xchg eax, ESP

2. Press F4 on the line 0040015a. The program runs continuously due to the endless loop.

3. In the debugger window, right-click to view the debugging register.

The result is displayed in drx:

Dr0 0040015a // address
DR1 00000000
DR2 00000000
Dr3 00000000
Dr6 ffff0ff0 // breakpoint attribute
Dr7 00000401

Experiment 2 (F8 Principles)

1. Find a program, load OD, and construct an endless loop of sub-programs.

Just like this

00400154 T> E8 0100d03f call 4010015a // EP, stop here
00400159 90 NOP
0040015a 90 NOP
0040015b 90 NOP
0040015c 90 NOP // The F2 breakpoint here
0040015d C3 retn // return

2. Press F8. Due to int3 breakpoint, the program is interrupted at 0040015c.

3. In the debugger window, right-click to view the debugging register.

The result is displayed in drx:

Dr0 00400159 // return address of call
DR1 00000000
DR2 00000000
Dr3 00000000
Dr6 ffff4ff1 // breakpoint attribute
Dr7 00000401


Experiment 3 (F7 Principles)

1. Find a program and load the OD

2. Double-click the t sign in the window of the debugger to change TF from 0 to 1.

3. Run F9

The result program is disconnected from the following line.

Experiment 4 (Principles of F2)

1. Use notepad of 98 to load OD and construct an endless loop.

004010cc n> 90 NOP // EP, which is quite here
004010cd 90 NOP
004010ce ^ eb fc jmp short notepad. <moduleentrypoint> // endless loop
004010d0 90 NOP // press F2 here, normal breakpoint
004010d1 90 NOP

2. Press F9 and the program runs continuously due to an endless loop.

3. Use lordpe (do not use ollydump) to dump the program.

4. Reload OD

Let's see what it looks like.

004010cc D> $90 NOP
004010cd. 90 NOP
004010ce. ^ eb fc jmp short dumped. <moduleentrypoint>
004010d0 CC int3 // CC is changed here
004010d1 90 NOP

--------------------------------------------------

3. Summary

From experiment 1 and Experiment 2, we can clearly see that F4 directly puts the address of this row into drx, and F8 puts the address of the next row into drx, they all use debugging registers. From the third part of the experiment, we know that for F7, it is likely to use the method of setting TF to one, that is, when we press F7, OD sets TF to one. For F2, the first byte is changed to CC. Although it is not shown to me, it is a CC. When we press F2, OD is not running yet, just record this representation. When it runs, it modifies all the marked bytes, even though the original code is displayed. Of course, when it is paused, it is modified again.

In the above experiment, the F7 principle is just speculation. There is no good way to prove that it is using TF. Next I will continue to guess the principle of memory breakpoint.

1. Record the configured memory breakpoint address

2. Modify its attributes on the memory page of this address

If it is a memory write breakpoint, change it to RE (readable, executable)
If it is a memory access breakpoint, change it to no access (inaccessible)

3. As long as you access this page, an exception will occur, and the OD will determine whether it is consistent with the recorded breakpoint, so as to determine whether it is interrupted.

--------------------------------------------------
4. Subsequent remarks

Pipeline is a good suggestion. If any brother knows how to do this, I hope I can tell you. Of course, you are welcome to discuss it with me.

The following section describes how to use anti-hardbreakpoint.

If the reposted document is complete, thank you for reading it.