OllyDbg Fake ImageName Bug

I have recently found a weird behavior in OllyDbg, which can further be used as an anti-debugging / anti-attaching trick. The problem occurs when enumerating the running processes if the "Select a process to attach" dialog box is opened.

The psapi "EnumProcesses" function is called to get the list of process identifiers (PIDs). For each PID, the psapi "EnumProcessModules" and "GetModuleFileNameExA" functions are called to extract the image base and full name of the main executable.

As i have shown in previous posts, the values in  PEB.LoaderData can easily be manipulated. In this case i will manipulate only the full name of the main executable to be of an existing but malformed file. Surprisingly, OllyDbg trusts the new file name and starts to extract essential information from it. Information extracted includes MZ signature, optional header values, section table data, etc.

The interesting thing about the forged executable is that it is rejected by the OS loader but still used by OllyDbg.

To create a one-file demo for this bug, i had to embed the malformed executable into the original one as a binary resource.

 

As you can see in the image below, the number of sections is set to 0xFFFF (malformed executable).

 

The demo can be found here.  The virustotal report can be found here.

N.B. This has been tested on OllyDbg v1.10 only.

Update:
Another demo, that crashes OllyDbg upon debugging or attaching, has been created. You can find it here.

Update:
The source code for the demos above can be found here.

You can follow me on Twitter @waleedassar 

Debuggers Anti-Attaching Techniques - Part 6

In this post i will discuss a simple anti-attaching trick, which i forgot to document in previous posts. This trick is so simple that all it requires is erasing the PE header of the main executable at Run-time.

Erasing the PE header works as an effective anti-attaching technique as it prevents the system from creating new threads, a critical step of attaching to active processes since a successful call to the "RtlCreateUserThread" function is required for the "DebugActiveProcess" function call to succeed. See Debuggers Anti-Attaching Techniques - Part 1.

This trick is implemented with only few lines of C code. See the image below.

Trying to attach to this process, you will get the following message box.

This trick does not necessarily require erasing the whole PE header. Erasing the MZ signature is enough.

This trick works under Windows 7 and not under Windows XP due to a dramatic change introduced in later version of Windows in the way threads are created. In windows 7, the kernel has to extract the value of SizeOfStackReserve and SizeOfStackCommit from the PE header of the target process image, unlike  XP which extracts those values from the PE header of the process that is creating the thread.

So, erasing the PE header as shown above, we can cause the "RtlImageNtHeader" function called from the "RtlCreateUserStack" function to fail returning 0xC000007B which is quivaluent to
ERROR_BAD_EXE_FORMAT.

 
The source code of the example above can be found here.

N.B. This has only been tested on Windows 7.
N.B. This can also be used as an anti-dumping trick.

You can follow me on Twitter @waleedassar 

DetachMe, A New OllyDbg Plugin

One of the new interesting features of OllyDbg v2.0 is the "Detach" functionality, which enables you to detach debuggees from OllyDbg at anytime and let them run freely outside control of OllyDbg.

Unfortunately, OllyDbg v1.10, the widely used version, lacks this features. Pedram Amini has created a nice plugin to fill this gap, but it does not satisfy my needs, though.

Pedram's plugin only works on debuggees in the running mode. It does not work on debuggees in the suspended mode. In addition, debugees will crash if software breakpoints are left.

This pushed me to create a new OllyDbg v1.10 plugin, in which i tried to create a similar functionality to the one in version 2.0.

Features introduced in my plugin:
1) Disabling user's software and hardware breakpoints without affecting the corresponding .udd files.
2) Detaching debuggees in the suspended mode.

The plugin can be found here.

N.B. Several enhancements are continuously being released  for this plugin in the near future.

You can follow me on Twitter @waleedassar 

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