New OllyDbg Anti-Debug Trick

Actually, it is not just a trick. It is a buffer overflow in OllyDbg v1.10, which does not affect OllyDbg v2.0 since the compromised functionality seems to be dropped or subject to some enhancements. The story begins when i was trying to create the longest possible pathname for an Exe file to see if olly would crash upon loading that file. And olly really did.

Loading olly into another instance of olly did not help, and the child olly gracefully exited.

So, I quickly opened the minidump into windbg and then issued a ".ecxr" command to see the exception that caused my beloved olly to suffer.

The eip, as you can see above, is 0x0303906F, which belongs to dbghelp.dll version 6.11.1.404.

The faulty address has mov esp,ebp, which doesn't look like an instruction triggering exceptions. So, i took one step back and checked the preceding "call" instruction.

It was easy to notice it is the cookie checking procedure.  I easily figured out that olly crashed due to a an invalid cookie value.

I then reloaded olly into another instance of olly and searched for all references to the call instruction at 0x03039065, trying to find the procedure/stack frame whose cookie was compromised.

Three references were found.  Okay, easy to be tried one by one.

I placed a breakpoint on each reference and also instructions around it.

 

As you can see in the image above, push 57 was hit but instructions before it were not. Also, no references to push 57 were found. Weird, isn't it?

In the image above, if we follow the very first value on the stack, we find will ourselves in ollydbg.exe.

 

 Ollydbg.exe executes call dword ptr[ebp-0x1c] and then goes to push 57 at 0x03039000.

 Let's stop here for a while, dbghelp.dll does not export push 57 and olly is less likely to call a non-exported procedure.

Now, the only assumption i got is that variable at ebp-0x1c in ollydbg.exe was compromised so that only one byte was overwritten (An off-by-one).

Given that my assumption is true, has Microsoft intentionally placed the push 57 at 0xXXXXXX00 to handle such cases? Abit off-topic, i know.

Back to ollydbg.exe, i put a breakpoint on the prologue of our compromised procedure and at call dword ptr[ebp-0x1c] and started tracing over.

I think the two images above should confirm my assumptions.

I spent one hour to see what occurs in the compromised ollydbg procedure and summarized it into the following steps:

1) Addresses of some dbghelp.dll functions are retrieved and stored into stack variables. The one of interest is the address of the "SymGetModuleInfo" function stored into dword ptr[ebp-0x1c].

2) The "SymSetOptions", "SymInitialize" functions are called to start symbol loading.

3) The being-loaded Exe filename is split into parts, e.g. "C:\walied\xxx\walied\mostafaaaaaaaa.exe" would be split into "c:", "\walied\xxx\walied\", "mostafaaaaaaaa", and "exe", and each part is stored in a sufficiently wide buffer.

4) The "SymSetSearchPath" function is called.

5) The "CreateFileA" and "GetFileTime" functions are called.

6) The "FindDebugInfoFile" function is called.

After these 6 steps have been executed successfully, a loop is entered. In the loop, different paths are copied into a buffer at [ebp-0x128] (i think it is 0x10C bytes long). Given that ollydbg.exe resides in "c:\walied\ollydbg110\", paths are copied in following manner.

1) "c:\walied\ollydbg110\" + "symbols\sym\" + mostafaaaaaaaa + ".sym". If not found, jump to 2.

2) "c:\walied\ollydbg110\" + "sym\" + mostafaaaaaaaa + ".sym". If not found, jump to 3.

3) "c:\walied\ollydbg110\" + mostafaaaaaaaa+ ".sym". If not found, jump to 4.

4) "c:\walied\xxx\walied\" + "symbols\sym\" + mostafaaaaaaaa + ".sym". And so on.

Now it is easy to notice that [ebp-0x1C] was compromised at path no. 4.

Here is a screenshot of where exactly the buffer overflow occurs.

A question urgently arises here, that is, how can we practically use the aformentioned buffer overflow as an anti-debug trick?

Given the fact that olly tries to find the .sym file for every module, including the dynamically loaded one, we can ask the to-be-protected application to recursively create the longest valid pathname, then copy any .dll into the newest directory, and finally LoadLibrary the .dll.

A simple PoC has been created to reproduce this Buffer Overflow. 

Here is the source code.

Here is VT report.

You can follow me on Twitter @waleedassar 

Debuggers Anti-Attaching Techniques - Part 5

In this post, i will explain another anti-attaching trick. The trick is that if we manipulate the _PEB_LDR_DATA structure pointed to by PEB.LoaderData, we can cause functions like EnumProcessModules and GetModuleFileNameExA to fail.


Consequently, ollydbg would not be able to see the process in the "Select process to attach" dialog box.

You can play with this demo.

N.B. This trick can't be reliably used unless you carefully choose APIs in your application. Try to avoid APIs which read or write to the _PEB_LDR_DATA structure.

Update:
I have made a tiny plugin for OllyDbg v1.10. The plugin enables debugging those applications, which don't show in the "Select process to attach" dialog box. The plugin first checks the integrity of the target process's _PEB_LDR_DATA structure. If a manipulated structure is detected, a new typical one will be created.

The plugin can be downloaded from here and its source code from here.

Update:
Variants of this trick manipulate PEB.LoaderData so that an infinite loop occurs in OllyDbg or any other application which tries to use the "EnumProcessModules" function or the likes. See the image below.

The demo can be found here.

You can follow me on Twitter @waleedassar 

Debuggers Anti-Attaching Techniques - Part 4

In this post i will take you through an anti-attach trick i have recently come up with.

Given the two following facts, 1) For a debugger to attach itself to a process, the debugger has to create a remote thread in the process, 2) The OS loader calls TLS callbacks when a new thread is created in a process - we can design a TLS callback which increments a global variable. This global variable holds number of threads in the current process. If value in this variable exceeds a specific number, this means that a foreign thread has just been created and the process has to exit as such. We can alternatively ask the TLS callback routine to query the entrypoint of the thread it is running under and if the entrypoint is the address of the "DbgUiRemoteBreakin" function, we should kill the process.

This is a simple demonstrating example.

Abit more complicated example can be found here and its source code from here.

N.B. Both examples have been tested on XP SP3 only.

To make things harder, we would use dynamic TLS callbacks instead.

To implement a dynamic TLS callback, follow these 2 steps:
1) Create a TLS structure and then store its rva and size in the TLS data directory at runtime.
2) Set the "_LdrpImageHasTls" global variable in ntdll.dll to true.

Source code can be found here. It works on Win XPSP3 only. You can edit the source code to include other OSes.

N.B. This trick is still in progress and i am waiting for any feedback.

You can follow me on Twitter @waleedassar 

Debuggers Anti-Attaching Techniques - Part 3

In this post i will shed some light on another anti-attach trick. The point here is based on the fact that only one debugger is allowed to debug a specific process.

Implementing it is as easy as creating two executables (hereafter, i will refer to them as EXE1 and EXE2). EXE1 spawns and then debugs EXE2. So, any further attempt to debug EXE2 will fail.

A demonstrating example can be found here. This executable just spawns calc.exe and then acts as its debugger. If you try to attach ollydbg to calc.exe, you will get the following message box. See the image below.

N.B. Any attempt to close EXE1 will result in EXE2 being closed as such.

To circumvent it, all we have to do is detach EXE2 from its debugger (EXE1) by calling the "DebugActiveProcessStop" function in context of the debugging thread in EXE1. 

 I just created a small debugger (I refer to it as EXE3).

1) EXE3 debugs EXE1.
2) EXE3 patches the "WaitForDebugEvent" function in the debug loop of EXE1, inserting a jump to the "DebugActiveProcessStop" function.

The source code can be found here and the executable from here.

Update:
The detacher's source code has been updated. The new source code can be found here.

You can follow me on Twitter @waleedassar 

Debuggers Anti-Attaching Techniques - Part 2

In the previous post, i talked about the trick of patching the "DbgUiRemoteBreakin" and "DbgBreakPoint" functions and how to circumvent it.

In this post, i am going to analyze another trick. This time, the trick is patching the "NtContinue" function.

We already know the remote thread starts with executing the "DbgUiRemoteBreakin" function.

Trying to find how execution is transferred to the "DbgUiRemoteBreakin" function in the new thread, i found that it is the "NtContinue" function.

Hooking the "NtContinue" function, we can prevent ollydbg from attaching to processes.

Here you can find an demo (Tested with Windows XP SP2 and Windows 7).
 
This trick is bypassed in the same way as that one in Part 1 and can similarly be implemented in an ollydbg plugin.

Update:
I updated the demo in response to a comment. 

You can follow me on Twitter @waleedassar 

Debuggers Anti-Attaching Techniques - Part 1

It's been a while since i played with packing/unpacking tricks. So, i am going to choose some fancy tricks and try to explain them in detail.

The story begins when i was trying to analyze a security issue in an infamous application. I tried to attach ollydbg to the running process but the process immediately crashed. I quickly googled "anti-attach tricks" and found many useful links.

In the next few posts, i am going to explain those anti-attach tricks.

It would surely be better to understand how debuggers attach themselves to running processes in order to understand those tricks and perhaps innovate new ones.

The main idea behind attaching is that a debugger calls the "DebugActiveProcess" function which ends up with calling the "RtlCreateUserThread" function to create a new remote thread into the target process, with the "DbgUiRemoteBreakin" function as the new thread entry point.

Thread creation occurs in the "DbgUiIssueRemoteBreakin" function, which looks something like the highlighted line in the image below.

As far as i see, one way to prevent debuggers from attaching to a process is conducted by hooking the "DbgBreakUiRemoteBreakin" or "DbgBreakPoint" function.

  I will write a simple executable to demonstrate that. It overwrites the first six bytes of the "DbgUiRemoteBreakin" function with some instructions to jump to the "ExitProcess" function. Similarly, we can patch the "DbgBreakPoint" function.

Here you can download the source code for the example above.

Trying to attach to such a process, as you can see in the image below, results into terminating the process.

Bypassing this trick is pretty easy. Just load olly into another instance of olly, set a breakpoint on the "RtlCreateUserThread" function call, and finally modify its seventh paramter to point to any int3 in the target process address space. 

Once execution stops at int3 (in the debugged ollydbg), kill the current thread.

This way we can bypass this anti-attach trick whether the "DbgUiRemoteBreakin" or "DbgBreakPoint" function is patched in the target process address space.

This bypass trick seems to be impractical. So, i decided to write a simple ollydbg plugin for this situation. The plugin simply patches the "DbgUiIssueRemoteBreakin" function in ollydbg.exe to jump to the plugin code. The plugin code gets the process handle from the stack, allocates memory into this process, and finally writes a few instruction to the new memory.

Here you can download the plugin dll.

N.B. This write-up is based on analysis conducted on Windows XP SP3 and WOW64, windows 7.

N.B. The plugin is tested on windows XP SP3 and WOW64, Windows 7. 

You can follow me on Twitter @waleedassar