OllyDbg RaiseException Bug

In this post i will show you a bug in OllyDbg that can be used to detect its presence. The trick is so easy that all you have to do is call the "RaiseException" function with the "dwExceptionCode" parameter set to EXCEPTION_BREAKPOINT 0x80000003. The response depends on the OllyDbg version used. If it is v1.10, then the exception is going to be silently swallowed by the debugger and the registered exception handler is not called. In v2.01 (alpha 4), several message boxes pop up and the exception handler is not called either. Only v2.01 (beta 2) is immune to this bug.

The reason behind this bug is OllyDbg trying to read the x86 instruction pointed to by the "ExceptionAddress" field of the "EXCEPTION_RECORD" structure to ensure it is 0xCC or 0x03. In case of EXCEPTION_BREAKPOINT exceptions raised by explicitly calling the "RaiseException" function, the instructions at ExceptionAddress is definitely not 0xCC or 0x03.


You can find a demo here and its source code from here.

Any comments or ideas are very welcome.

You can follow me on Twitter @waleedassar

OllyDbg Section Name Crash

This is an old yet interesting bug in OllyDbg. This bug affects OllyDbg v1.10 even with the "OllyAdvanced v1.27" option set.

Here is a screenshot of the vulnerable code.

In brief, set the name of the code section to "%*s%*s%s" and the "SizeOfCode" field to zero.

A demo can be found here.

You can follow me on Twitter @waleedassar 

Collection Of OllyDbg Bugs And Exploits

I have created a new project on code.google.com to track the publicly disclosed bugs and exploits in OllyDbg v1.10 and later.

It can be reached at:
http://code.google.com/p/ollybugs
http://code.google.com/p/ollybugs/downloads/list

I will keep updating it as long as bugs and exploits are being disclosed.

Any comments or ideas are very welcome.

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 

An OllyDbg Bug Disables Software Breakpoints

I have found a new bug in OllyDbg v1.10. The bug is triggered when the BaseAddress value is changed in the LDR_MODULE structure for the main executable. Any subsequent DLL loading forces Olly to call the psapi "EnumProcessModules" function in order to update the module list, and since the psapi "EnumProcessModules" function traverses and reads from the LDR_MODULE linked list, the new (fake) base address will definitely be returned.

A simple application was written to test this bug. See the image below.

Here is how the source code above looks in olly.

If some breakpoints are set after the troublesome code and OllyDbg is left to run, an error message shows up once we step over the "LoadLibrary" function call and none of the breakpoints is hit.

The problem is that OllyDbg trusts the data retrieved from the psapi "EnumProcessModules" function call and tries to update data related to the main executable, including software breakpoints. At this point, all software breakpoints are deleted since OllyDbg thinks their addresses are no longer valid. Actually they are, but this is how it goes in OllyDbg v1.10.

N.B Software breakpoints outside the main executable e.g. in ntdll.dll are not affected by this bug.

Source code in the example shown above can be found here.

Update:
An executable demo can be found here.

You can follow me on Twitter @waleedassar