Arcane
August 21st, 2008, 15:20
This little trick is very interesting, my first encounter with it was in a commercial protection, it left me wondering why a Push / Pop SS would implicit execute the next instruction without the Debugger knowing of it, i.e. raising a single-step exception, so I’ve decided to look into it and try to figure out why, and I believe I have found the explanation , but first let me show you how this technique can be used to detect debuggers relying on the Single Step flag for tracing.
If a debugger executes something like this:
PUSHFD -> push Efflags to Stack .
debuggers such as Olly is kind enough to “shadow” itself, And clean the result produced by this instruction and removing the trap flag from the EFflags pushed to stack.
But if it’s done like this:
Push ss
pop ss
pushfd
Olly will not remove the trap flag, which is very interesting and leaves it very vulnerable to trace detection. The Explanation seems to be pretty straight forward if you check out the Intel manuals and look up pop , you will find a passage similar to this :
A POP SS instruction inhibits all interrupts, including the NMI interrupt, until after
Execution of the next instruction. This action allows sequential execution of POP SS
And MOV ESP, EBP instructions without the danger of having an invalid stack during
An interrupt1. However, use of the LSS instruction is the preferred method of loading
the SS and ESP registers.
Well most of this can be boiled down to , if POP SS is executed , the CPU will prevent triggering of interrupts , as to avoid corruption of the stack. So why on earth is this affecting us when we are tracing using the single-step flag, well simply because when the Single-step flag is set , it triggers and interrupt in the CPU , but when a POP SS is executed it won’t trigger interrupts before it has executed the next instruction after it , and thus olly will never get a single-step exception for the PUSHFD and won’t know it has been executed , and thus wont clean out the trap-flag and leave us vulnerable to detection.
Circumventing this trick , is tricky since simply patching it out is easy , but if implementet correctly it can prevent tracing of your code very effectively and be a pain in the ass.
Comments and suggestions , are always welcome
If a debugger executes something like this:
PUSHFD -> push Efflags to Stack .
debuggers such as Olly is kind enough to “shadow” itself, And clean the result produced by this instruction and removing the trap flag from the EFflags pushed to stack.
But if it’s done like this:
Push ss
pop ss
pushfd
Olly will not remove the trap flag, which is very interesting and leaves it very vulnerable to trace detection. The Explanation seems to be pretty straight forward if you check out the Intel manuals and look up pop , you will find a passage similar to this :
A POP SS instruction inhibits all interrupts, including the NMI interrupt, until after
Execution of the next instruction. This action allows sequential execution of POP SS
And MOV ESP, EBP instructions without the danger of having an invalid stack during
An interrupt1. However, use of the LSS instruction is the preferred method of loading
the SS and ESP registers.
Well most of this can be boiled down to , if POP SS is executed , the CPU will prevent triggering of interrupts , as to avoid corruption of the stack. So why on earth is this affecting us when we are tracing using the single-step flag, well simply because when the Single-step flag is set , it triggers and interrupt in the CPU , but when a POP SS is executed it won’t trigger interrupts before it has executed the next instruction after it , and thus olly will never get a single-step exception for the PUSHFD and won’t know it has been executed , and thus wont clean out the trap-flag and leave us vulnerable to detection.
Circumventing this trick , is tricky since simply patching it out is easy , but if implementet correctly it can prevent tracing of your code very effectively and be a pain in the ass.
Comments and suggestions , are always welcome
