执行地址时引发异常，而无需直接对其进行修改

Question

I would like to raise an exception when code at a given address is executed, without making it visible in the code.

I know that using a hardware breakpoint is a possibility, but these would get removed if someone were to attach a debugger that uses them and I wouldn't have a way of detecting if they are missing and replacing them. What other options are there?

Speed is a concern, ie: I cannot do PAGE_GUARD single stepping; the user would lag to death.

I'm on Windows and using VC 2012 w/ C++.

Answer 1

If exception handling is too costly, the only other solution is to emulate the code as the CPU would do.

There are a few caveats, though:

• There are a lot of instructions and decoding and emulating them correctly is a big undertaking. Switching between emulation and execution will cost you extra CPU cycles.
• You won't be able to emulate everything and will have to execute a number of instructions (eg FPU/MMX/SSE instructions) in a "playground/sandbox" because of that.
• To handle system calls properly, you'll actually have to prepare the CPU state and execute them and then go back into the emulator. You'll probably have to generate code on the fly here.
• If the emulated code causes CPU exceptions and uses SEH to handle them (or throws and catches C++ exceptions as CPU exceptions, again via SEH), you are very likely to break the code as stack unwinding won't work on the foreign (emulator's) stack.
• Things will get tricky with multi-threaded code, especially so on multi-processor systems. You'll have to catch thread creation/destroying and create/destroy individual instances of the emulator and deal with memory sharing between the threads and deal with atomicity of emulated/executed instructions.
• Whatever I've forgotten to think of.
• Things may still work too slowly or not work at all.

Another, perhaps more practical, option would be to patch the executable at that address of interest, divert execution to your code (with the jmp instruction), do whatever you need there and then go back. You'll have to take care of all context preservation/restoration and also emulate the instructions damaged by the jmp instruction written on top of them. There are caveats here as well. Those overwritten instructions may be jumped to from elsewhere in the code. You'll have to either choose the address in such a way that there're no jumps into the middle of your jmp or you'll have to deal with them somehow (not sure how yet).