One debugging process and summary, debugging Summary

One debugging process and summary, debugging Summary

Today, I am tracking a program with od, and the result is falling into the trap. I think there should be more than OD. Most debuggers on the market are like this.

This program tracks the execution process all the way. It basically executes a piece of code first, then unlocks the next piece of code, encrypts the previous piece of code, jumps to the unwrapped code through jmp, and then repeats it.

The decryption is performed in the exception. It jumps to the exception by accessing an invalid address, and then conducts SMC in a call in the SEHandler. This call receives a buffer, used to store the parsed code.

After executing several pieces of code repeatedly, I am too lazy to decrypt the code again. So I broke the code at the buffer location and wanted to run it directly to the desired location, the strange thing is coming out. After ZwContinue () is decrypted, the memory access exception occurs again, so I jumped to the last SEHandler, because I have interviewed and run it directly in the debugger before, so I can restart the program or F9 cannot run. Check whether the buffer finds that the decrypted content is a problem. I compared the difference between the next two start times, that is, the first time the program was not disconnected, and the second time the program was disconnected, so my first reaction is that it may have anti-Soft Interrupt at some locations. If it detects the Soft Interrupt, it will solve the wrong data. So I placed a hardware breakpoint at the buffer location, I finally removed all the breakpoints and the program ran smoothly. After a long time, we also looked at the anti-detection hardware breakpoint, most of which involved drivers, so we just wanted to look at it. However, this program is not driven, so even if there is a hardware breakpoint, it must be completed under ring3, so we simply reverse the decryption algorithm, at last, I found that the breakpoint under me prevented a byte of decryption data from being written into the buffer. The principle is very simple, when int3 breakpoint occurs, the debugger changes a byte at the breakpoint to 0xCC, and the change in this Byte will not be visible to you, at this time, the program cannot write data into it, because once it is written in, this breakpoint will be discarded. So... I was played by the debugger.

Conclusion: in the future, when you execute a breakpoint where data is written, you can first access the breakpoint in the next memory.