how to handle this super annoying anti trace trick
 

hi,

code like

dies when executed while singlestepping for obvious reasons
does anyone has an idea how to make it singlestep proof?

that should be fine when single stepping
and its not for 'obvious' reasons
it'll just morph the dword at esp-4
and eventually jump to the address
single stepping through it shouldn't do
anything different, theres nothing pushed
or popped in the snippet...

we write values below esp

any exception uses stack -> previously written values are overwritten -> crash

securom IAT protection?
and this will anoy you only with nointrusive tracer, but with r3 or r0 debugger there should be no problem. Trick why seh tracing fails is because KiDispatchException writes context and error code at esp and your data at esp-X is overwriten.

seems you are right deroko

i thought the cpu overwrites the stack in the same second the exception occurs
but the stack is overwritten later

do you know how exceptions are dispatched when a debugger is around?

till now i thought everything starts at KiUserExceptionDispatcher, but it seems its not the very first one that is informed by windows when a debugger was used

maybe the best solution is to write a small driver that hooks int1 and handles the exception stack-safe

hmmmhm

the exception is first sent to the debugger if there is one attached and in case it doesnt handle it, it is dispatched to the app.

I dont see why sending the exception to a debugger would overwrite the usermode stack of the debugged process :O

Well answer is very simple, we are using 2 rings -> when exception is generated some of IDT entries is called but at this moment we are switching to r0 stack and all data is writen there -> if there is attached debugger data is passed to it and no modification is performed on r3 stack, on other hand, when there is no debugger, context is saved at r3 stack + exception code and execution is transfered to KiUserExceptionDispatcher. Code above would be impossible to trace iwth debugger if it is executed in r0 or if there were no rings (eg. only one ring used).

my last question was, *where* windows decides to inform the debugger instead of giving control to the application's KiUserExceptionDispatcher

its done in the int handler itself or what?

then the only way to handle this is indeed an own driver (?)

simply use r3 debugger and everything will be fine. You may safely trace that code with olly or sice but not with nointrusive tracer, If you want full control from your loader, then yes, driver is good choice or oraculums.

And yes windows deceides in int handlers if exception is delivered to debugger or if there is no debugger then kiuserexception is called.