While playing with OllyDbg v1.10, i came across a weird behavior in OllyDbg v1.10, which was fixed in the latest version. The problem lies in the way OllyDbg sets hardware breakpoints.
At 0x4D8D70, there is an array of four structures of type, t_hardbpoint.
Each structure in this array holds information about each hardware breakpoint. Information includes hardware breakpoint address, type, and size. When you manually set a hardware breakpoint, this structure is filled, but the breakpoint is not immediately activated.
On the other hand, when an EXCEPTION_SINGLE_STEP or EXCEPTION_BREAKPOINT is received, information in the structures at 0x4D8D70 is copied to DR0 through DR3 overwriting old values in them, if there are any. The point here is that if you programmatically set a hardware breakpoint, single stepping will be enough to cause debug registers to be cleared.
N.B. IDA pro and OllyDbg v2.0 behave normally with this scenario.
An executable demonstrating how to use this strange behavior to detect OllyDbg v1.10 can be found here.
You can follow me on Twitter @waleedassar
At 0x4D8D70, there is an array of four structures of type, t_hardbpoint.
On the other hand, when an EXCEPTION_SINGLE_STEP or EXCEPTION_BREAKPOINT is received, information in the structures at 0x4D8D70 is copied to DR0 through DR3 overwriting old values in them, if there are any. The point here is that if you programmatically set a hardware breakpoint, single stepping will be enough to cause debug registers to be cleared.
N.B. IDA pro and OllyDbg v2.0 behave normally with this scenario.
An executable demonstrating how to use this strange behavior to detect OllyDbg v1.10 can be found here.
You can follow me on Twitter @waleedassar
No comments:
Post a Comment