View Full Version : Abusing alignment code for anti-sandboxing purposes

Reversing It Out
February 20th, 2010, 08:17
Incidentally, I last week had a look at some MMORPG-related password stealer; although the malware was rather simple it still managed to contain a small trick that some may not be aware of. The trick that I am referring to is contained in the following code:

.text:00401248 mov edi, ds:GetProcAddress
.text:0040124E push eax ; hModule
.text:0040124F call edi ; GetProcAddress
.text:00401251 GetProcAddress(0x7c800000,"CreateToolhelp32Snapshot"
.text:00401251 sub eax, 3
.text:00401254 mov CreateToolhelp32Snapshot, eax
.text:0040127C mov eax, CreateToolhelp32Snapshot
.text:00401281 test eax, eax
.text:00401283 jz short loc_40128F
.text:00401285 push 0
.text:00401287 push 2
.text:00401289 call eax ; CreateToolhelp32Snapshot

At a first glance, everything looks relatively harmless, but if we look closer, we notice that there is something interesting; I am referring to the instruction at address 0x401251: why should someone want to retrieve the address of CreateToolhelp32Snapshot, then subtract three to the retrieved value and then call the resulting address?

We understand why if we have a look at kernel32.dll:

http://1.bp.blogspot.com/_Iq20R_ym4vY/S3_nItL5EoI/AAAAAAAAAHI/tqESO3SMik8/s400/AC2.png ("http://1.bp.blogspot.com/_Iq20R_ym4vY/S3_nItL5EoI/AAAAAAAAAHI/tqESO3SMik8/s1600-h/AC2.png")

It is clear that the purpose of the subtraction is to have EIP land in the alignment code just before the actual function, but why does the malware do this operation?

This is not an anti debugging trick, as the code will eventually fall through to the actual real address of the API function without disturbing possible breakpoints; instead, the mysterious instruction is there to prevent sandboxes from running the file successfully and thus determining its behavior.

In fact, depending on how the sandbox implements the concept of system dynamic link library, there may be several problems. For example, if the sandbox provides its own version of the system’s dlls, then there is no way to know where the sandbox would land when this retrieve-API-address-then-subtract-some trick is used... Most likely not where we would like to, thus jeopardizing the sandboxing process; other implementations and designs may be vulnerable in different ways.

Let’s see how a popular open source sandbox, the ida-x86 emu, behaves when dealing with this trick. Let’s assume that we have coded a very simple fake implementation for the function CreateToolhelp32Snapshot, like the one below:

http://3.bp.blogspot.com/_Iq20R_ym4vY/S3_sb4mmWrI/AAAAAAAAAIA/9xkVnAIMSRc/s400/i7.png ("http://3.bp.blogspot.com/_Iq20R_ym4vY/S3_sb4mmWrI/AAAAAAAAAIA/9xkVnAIMSRc/s1600-h/i7.png")

When the problematic address is called, the emulator will start doing various checks to see what kind of address is being called; at some point, this function will be called:

http://4.bp.blogspot.com/_Iq20R_ym4vY/S3_pZgsY5mI/AAAAAAAAAHg/fR-LUK4lgYg/s400/i4.png ("http://4.bp.blogspot.com/_Iq20R_ym4vY/S3_pZgsY5mI/AAAAAAAAAHg/fR-LUK4lgYg/s1600-h/i4.png")

This code is responsible for iterating through the list of available hooking functions, like our emu_CT32S above. If we look closer, we see that, in order to see if there is an available hooking function for the called address, the function matches the address associated to the hook with the address that the program is trying to call. Obviously, the function will never be able to match the address that we are trying to call (0x7c8647b4) and the address that is associated with the function (0x7c8647b7), thus bypassing completely our reimplementation of the function and smashing the stack:

http://1.bp.blogspot.com/_Iq20R_ym4vY/S3_p6sHprTI/AAAAAAAAAHo/iWoOLlHgSwM/s400/2010-02-11_20.44.34.png ("http://1.bp.blogspot.com/_Iq20R_ym4vY/S3_p6sHprTI/AAAAAAAAAHo/iWoOLlHgSwM/s1600-h/2010-02-11_20.44.34.png")

A trivial solution for this issue could simply modify the above function so that it will map to an API also a few bytes immediately preceding the real address:

http://3.bp.blogspot.com/_Iq20R_ym4vY/S3_rGrs_b8I/AAAAAAAAAHw/dkwjv2VADsw/s400/i5.png ("http://3.bp.blogspot.com/_Iq20R_ym4vY/S3_rGrs_b8I/AAAAAAAAAHw/dkwjv2VADsw/s1600-h/i5.png")

If we try to run the portion of code under analysis with this fixed version, we see that we are able to invoke properly our great API implementation:

http://1.bp.blogspot.com/_Iq20R_ym4vY/S3_rjpWtptI/AAAAAAAAAH4/ce6seGgA2m8/s400/2010-02-11_20.51.44.png ("http://1.bp.blogspot.com/_Iq20R_ym4vY/S3_rjpWtptI/AAAAAAAAAH4/ce6seGgA2m8/s1600-h/2010-02-11_20.51.44.png")


February 21st, 2010, 23:46
really simple method to bypass emulator.