Stud_PE Internal File Name Buffer Overflow

I have found a vulnerability in Stud_PE, a tool used to inspect the PE header of executable files. Stud_PE does not check the length of the internal file name (referenced to by Export Table) prior to copying to a stack-based buffer.

A proof of concept can be found here.

Update: This has been fixed as of version 2.6.0.8.

You can follow me on Twitter @waleedassar 

Catch Debuggers With The Step Over Trap

Everyone who spent a short while playing with debuggers knows very well what Step into and Step over mean.

Step into is used to execute one instruction at a time, giving the chance to check registers, stack, etc, it is something called Single Stepping. Step over does the same job except when it comes to call or rep instructions, as Step over does not single step them, it simply jumps over but still executes them. How is that accomplished?

The answer is definitely software breakpoints. When you Step over a call instruction, OllyDbg or any other debugger places an int3 software breakpoint just after the call instruction. In other words, Step over is exactly the same as manually pressing F2 just after the call instruction and then pressing F9.

After we have seen how debuggers implement "Step over", how can we use this for our advantage?
We can easily use this fact as an anti-debug trick by inserting a small macro in the prologue of each function in our application. The macro should extract the return address from the stack and check the first byte pointed to by the return address. If it is 0xCC, it means that someone is trying to step over the protected function and it should escape execution as such.

Walied, Stop talking. Show me some damn code!

 

If we compile the code in the image above and load the resulting executable in OllyDbg, we will get something like this.

In OllyDbg, if we step over func1, func2, or func3, we will get this error message.

You can imagine how ridiculous it could be for a novice reverse engineer to debug your application as he or she is less likely to step into every single procedure in the application.
The demo mentioned above can be found here. You can also find its source code here.

An example demonstrating how Step over rep movsb can be used as anti-debug trick can be found here.

The interesting thing about rep instructions e.g. rep movsb is that reverse engineers usually step over them since rep movsb instructions often involve copying long strings or large chunks of data.

Everything mentioned in this post has been tested on OllyDbg v1.10, but as far as i know, it should work anywhere else.

You can follow me on Twitter @waleedassar 

Yet Another Anti-Debug Trick

I have recently come up with a new anti-debug trick, which can be useful only if the "Break on new thread" option is set in OllyDbg. The trick has been tried on OllyDbg v1.10 and Immunity Debugger v1.83 in Windows 7, Wow64. Actually, i am not sure if someone else has already found it.

In any affected debugger, if CREATE_THREAD_DEBUG_EVENT is received and the "Break on new thread" option is set, the debugger places an int3 software breakpoint on the lpStartAddress. There is a narrow time window between setting the int3 software breakpoint and recovering the original byte and this is what we are going to exploit.

N.B. The next few lines are only for demonstration. More complicated methods may evolve out of them.

Having two threads in an application, the first thread does almost nothing and the second one checks the first byte of the first thread's entrypoint, we can simply detect the debugger. See the image below.

The demo can be found here.  You can also find its source code here.

An XP-compatible demo can be found here. You can find its source code 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 

Anti-Dumping

I decided to write this post after i read a wonderful paper for Peter Ferrie. His paper includes several nice anti-dumping tricks. And i am now about to discuss one of them.

For those who are not familiar with the concept of "Anti-dumping", it is preventing debuggers from taking memory snapshots of debuggees after they have already been unpacked. In this post, i will show how to prevent OllyDump from dumping a debugee.

I quickly checked the source code of OllyDump and found out that:
1) The plugin extracts the PE information from the raw file by calling the "CreateFileA" and "ReadFile" functions. This can be defeated by calling the "CreateFile" function in our code with the "dwShareMode" parameter set to Zero, thus preventing OllyDump from opening the file and extracting PE info. See example 1.

2) When the user chooses to dump the process by clicking the "Dump" button, the plugin reads the PE info again, but this time from memory by calling the "ReadProcessMemory" function analogue and then checks for integrity. This can be defeated by destroying the PE header at runtime. See example 2.

 These two pitfalls could have been bypassed by calling the "CreateFileA" and "ReadFile" functions in the "_ODBG_Pluginmainloop" function and then caching the PE header.

To make things even harder, we can call the "UnmapViewOfFile" function to unmap the process main executable's image after we have copied it to a new memory block allocated by the "VirtualAlloc" function or the likes.


This can't be accomplished successfully until you :

1) Fix all absolute addresses e.g. push 0x00401122 because the whole image has been mapped at a new image base, that is, the address of the new memory block.

2) Change PEB.ImageBaseAddress to hold the new image base, otherwise application may access violate when executing code from the new memory block.

Our code will end up with something like the following:
1) Get the size of the main executable image and allocate memory with this size.
2) Copy the whole image to the newly allocated memory (new image).
3) Call the "UnmapViewOfFile" function to unmap the original image.
4) Jump to the newly allocated image and execute code.
5) Fix all absolute addresses in the new image and update PEB.ImageBaseAddress and LDR_MODULE.BaseAddress.
6) Continue execution normally.

Here you can find the source code of example 1, example 2, and example 3.

You can follow me on Twitter @waleedassar 

Another OllyDbg Anti-Debug Trick

It is similar to, but different from the one i disclosed in the previous post. The previous one occurs when OllyDbg tries to grab .sym files, but this one occurs when it tries to grab .udd files.

Similar to .sym files, .udd files are grabbed for all loaded modules, including dynamically loaded ones, which gives us the chance to use this buffer overflow as an anti-debug method.

To exploit this buffer overflow, all you have to do is create a .dll with length of 0x102 bytes and then LoadLibrary it.

N.B. ollydbg.exe must reside in a directory with length of 0x29 bytes or more, e.g. "D:\Documents and Settings\Administrator\Desktop\odbg110".


Demo:
http://ollytlscatch.googlecode.com/files/bug.exe

Source code:
https://docs.google.com/document/d/1Vi3UO6sglpoEYMPNdA8ZXKrc7oBmR-0Bd5v0rnFGfug/edit

Update:
Another less critical bug (buffer overflow) has been found in OllyDbg v1.10. It is triggered upon exit or manually choosing the "Update .udd file now" menu option. If you need its POC, just shoot me a mail.

You can follow me on Twitter @waleedassar