OpenRCE: Blog

Using CreatePipe to detect and thwart Emulating Sandboxes and AV emulators

Fri, 08 May 2009 21:23:00 -0500

While analyzing a Tdss-packed sample, I stumbled across an interesting use of the CreatePipe API function for Anti-Emulation purposes. The idea is very simple: detecting and thwarting Emulating Sandboxes without valid implementation of the pipe subsystem.

How does it work? Well, the very first thing the malware did was to create an unnamed pipe using the CreatePipe function:

.text:004014CA    push    0
.text:004014CC    push    0
.text:004014CE    lea     eax, [ebp-18h]
.text:004014D1    push    eax
.text:004014D2    lea     eax, [ebp-14h]
.text:004014D5    push    eax
.text:004014D6    call    ds:CreatePipe
.text:004014D6

Now that the pipe has been created, the malware will proceed in writing to it:

.text:004013F1    push    0               ; [0x12fe78] = 0x00000000
.text:004013F3    lea     eax, [ebp-1Ch]
.text:004013F6    push    eax             ; [0x12fe74] = 0x0012FFA0
.text:004013F7    push    0Ch             ; [0x12fe70] = 0x0000000C
.text:004013F9    lea     eax, [ebp-10h]
.text:004013FC    push    eax             ; [0x12fe6c] = 0x0012FFAC
.text:004013FD    push    dword ptr [ebp-18h] ; [0x12fe68] = 0x00012000
.text:00401400    call    ds:WriteFile    ; WriteFile
.text:00401400

If we look closely, we see that the malware wrote 0xC bytes to the pipe:

WriteBuffer:
.stack:0012FFAC   dd 0FC7E251Eh [WriteBuffer + 0x0]
.stack:0012FFB0   dd 0A6B546CBh [WriteBuffer + 0x4]
.stack:0012FFB4   dd 401599h      [WriteBuffer + 0x8]
.stack:0012FFB8   dd 4015A0h      [WriteBuffer + 0xC]

Now comes the interesting part: after some junk operations, the malware will read again from the pipe, and will store the read data at offset +4 from the beginning of the buffer that was initially written to the pipe:

.text:00401509    push    0               ; [0x12fe78] = 0x00000000
.text:0040150B    lea     eax, [ebp-1Ch]
.text:0040150E    push    eax             ; [0x12fe74] = 0x0012FFA0
.text:0040150F    push    19h             ; [0x12fe70] = 0x00000019
.text:00401511    lea     eax, [ebp-0Ch]
.text:00401514    push    eax             ; [0x12fe6c] = 0x0012FFB0
.text:00401515    push    dword ptr [ebp-14h] ; [0x12fe68] = 0x00011000
.text:00401518    call    ds:ReadFile     ; ReadFile

The outcome of this write-read combination from the pipe is rather obvious: part of the content of WriteBuffer gets shifted of 4 bytes, overwriting the initial content.

Why does the malware does these kinds of operations? Well, we discover it very quickly: after another bunch of useless instructions, the malware uses the offset stored at WriteBuffer + 0xC to continue the execution:

.text:00401487 call dword ptr [ebp-4] ; [0x12FFB8] WriteBuffer + 0xC

and, if we focus on the called address, we see that it is exactly one of the locations that gets overwritten by the shifted content. In fact:

[WriteBuffer + 0xC]:
.stack:0012FFB8 dd 4015A0h --> .stack:0012FFB8 dd 401599h

So the calls destination address has been changed from 0x4015A0 to 0x401599. If we quickly inspect the two locations, we immediately notice that the overwritten offset points to garbage:

.text:004015A0   jl      short near ptr loc_40152E+5
.text:004015A2   inc     edx
.text:004015A3   int     3               ; Trap to Debugger
.text:004015A4   mov     ch, 9Dh
.text:004015A6   inc     edx
.text:004015A7   int     3               ; Trap to Debugger
.text:004015A8   adc     [edi+536FCC42h], esp
.text:004015AE   pop     edi
.text:004015AF   pusha
.text:004015B0   dec     ebp
.text:004015B1   rcl     dword ptr [ebp+5E895EA6h], 0BAh
.text:004015B8   outsd
.text:004015B9   xchg    eax, ebx
.text:004015BA   mov     al, ss:0ACAE1BF0h
.text:004015C0   ...

while the overwriting one points to the valid code that will allow us to continue the execution:

.text:00401599 xor edx, edi
.text:0040159B jmp loc_401057

The description above can be visually explained by the following diagram:

It is obvious how such a trick can cause problems even to Emulating Sandboxes that do feature extensive re-implementation of Windows APIs. In fact, unless you have a solid implementation of the pipe subsystem in an Emulating Sandbox, this code cannot be emulated, as the original wrong offset wont be overwritten and the execution would break right after the call.

It is also interesting to note that using Pipes is somewhat more effective than using other equivalent mechanisms (for example, the same trick could be used with files). The main reason for this is that implementation of pipe-related functions is not usually a priority for emulator developers, and such implementation may even be neglected given the huge amount of other APIs that need implementation.

VbPython 1.2a

Mon, 06 Oct 2008 22:31:00 -0500

After quite a while, VbPython has just been updated to version 1.2a. This new release does not offer much new, beside being much more stable and supporting latest IDA Python. In detail, the new version fixes the following bugs:

an endless loop when trying to undefining stuff
several crashes due to unchecked incoming parameters

and will run on IDA Python > 0.9.55, which at some point started requiring to have the idaapi module explicitly loaded (thanks to loopss7 for reporting!).
For anyone interested, script can be fetched from OpenRCE.

Again on Visual Basic

Fri, 18 Jan 2008 14:03:00 -0600

For IDAPython users, I have created a complete python script that handles Visual Basic written programs. Features are:

original code from Reginald Wongs IDC script, translated to python
my previous script for handling DllFunctionCall
type analysis helper: provides function prototypes for known visual basic functions. Although the list of this functions is pretty limited at this moment, it is very easy to add your own
no return helper: marks specific functions as "non-returning", to improve ida analysis. Again, so far the list of non returning functions is limited, but its easy to add your own

Download is, as usual, available from my repository, and will soon be committed to openrce-snippets. Again as usual, comments and feedback are welcome.

Enjoy :)

PS: In order to use this script you need the latest IDAPython (0.9.55 and up), due to use of *aflags functions.

Experimenting with IDA 5.2s scriptable debugger

Sat, 01 Dec 2007 20:27:00 -0600

Recently, IDA 5.2 has been released, bearing as usual a lot of cool features and bugfixes. One of the most interesting additions was the so-called scriptable debugger. Today, I had a bit of free time, and decided to experiment with that.

In a very limited time, I coded a simple API monitor to spy over file-write operations on executable files (for example done by some malware). For the curious ones, I have uploaded the script to my repository: the code is just an experiment and is not all that useful - but it shows anyway how easy it is to use the new IDC commands.

Interesting primer on Virtualization from VMware

Mon, 19 Nov 2007 11:28:00 -0600

A couple of days ago, VMware released an interesting primer on virtualization, that gives a good introduction on a topic that is kinda "foggy" for most non-deeply-technical people. In the paper is given a nice overview of virtualization techniques for intel x86 architecture, along with an high level survey of the state of virtualization technology.

Definetely a recommended reading for anyone willing to know more about virtualization, but not only... Fetch it here.