I have some code which makes use of the Structured Exception Handler in order to employ some anti-debugging voodoo. It executes a series of instructions and I need to get the correct input. I can see the instructions and can reverse the ones that work directly with my input, but there is some background work (which happens at [esi]) - that also plays a part in the challenge. If I could follow the instructions step by step, I could make some great progress.
As I was saying, there are sets of instructions which work on my input. Let's say I am at 0x402DC0. The problem is that once I get to 0xCC, the debugger alerts me of the BREAKPOINT_EXCEPTION (I choose to Step Over) and then, instead of taking me (nicely and slowly) to the address 0x402B5D, the debugger skips to 0x402F1E (this behaviour repeats itself with another 8 sets of instructions each with its own exception handler thingy). The instructions get executed though - I figured it out giving the program different inputs.
I assume the program creates exceptions then just makes the jumps using SEH. The anti-debugging thingy is the fact that it doesn't let me go step by step, I suppose.
The question: Can I somehow step into the function at 0x402B5D, then going step by step just like when I am debugging a simple program?
I have tried modifying EIP and then Stepping Into (also swallowing the exception), but this does not produce the desired result because the instruction at 0x402B6D will produce another exception - I access [esi] which is out of the memory map of the program.
Also, is there any way I could find the instructions which make up the Exception Handler (in my program)? Reading up on it (http://bytepointer.com/resources/pietrek_crash_course_depths_of_win32_seh.htm) gave me a basic understanding of the mechanics under the hood. I've also tried to follow the pointer in the SEH chain, but the kernel functions don't help much.
The registers (at least some of them) are clearly modified because the program goes on flawlessly (if I do not modify EIP). Can I find the function which modifies them?
0x402B5D
and maybe tell OllyDbg to pass on int3 exceptions? I think I did something like this a long time ago, only the actual bps triggered, but not int3 calls.