Saturday, December 10, 2011

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.

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.