OllyDbg v1.10 And Hardware Breakpoints

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 

OllyDbg Export Table Parsing Integer Overflow

While reading one of Peter Ferrie's wonderful papers, i came across an interesting OllyDbg bug. It is so interesting that i decided to analyze and write a proof of concept for it.

The bug is triggered when parsing the export table of debuggees. First, the NumberOfFunctions member of the IMAGE_EXPORT_DIRECTORY structure is extracted.

This value is then left shifted by two bits (multiplied by 0x4). So, if this value is 0x40000000, it will be truncated to zero. Finally, heap memory of this size is allocated.

Now, it is clear that an overflow will definitely occur when it comes to copying RVAs into the newly allocated memory since 0x40000000 bytes will be copied to memory of size Zero.

A POC can be found here.

You can follow me on Twitter @waleedassar