Several friends asked for my advice on a particular technique seen in some recent malware samples, which is similar in nature to the Nanomites feature of the Armadillo copy protection. There are three parts to this technique:
- When creating the malware binary, replace control transfer (call and jmp) instructions with privileged instructions.
- At run-time, install an exception handler.
- Catch the exceptions thrown by the privileged instructions, perform the intended control transfers, and resume execution.
A concrete example follows.
UPX0:004081F7 in eax, dx UPX0:004081F8 dw 4EE0h
When the process attempts to execute this instruction, an exception is generated. The exception handler checks to see that the faulting instruction is "in eax, dx", then reads the word following the instruction, and generates a call to location 0x405000 + 0x4EE0. In other words, call instructions within the module are replaced by:
in eax, dx dw call_destination - 0x405000
As malware analysts, we would like to deobfuscate the binary by replacing these privileged sequences with the original call instructions, both for our own sake as well as the ability to use the Hex-Rays decompiler (which otherwise balks at the use of privileged instructions). However, the particular implementation within this sample poses a slight conundrum. The sequence "in eax, dx / dw XXXXh" is three bytes long, whereas the original "call 409EE0h" is five bytes. Therefore, we cannot merely rewrite the original instruction atop the privileged one without overwriting subsequent instructions.
A second idea is to use detouring, another staple technique in reverse engineering. We could find or create some unused space within the binary, patch a jmp from the privileged instruction to that new location, recreate the original instruction at that location, and then patch a jmp back to the location after the privileged instruction. However, this idea is flawed for the same reason: a long jmp instruction is five bytes long, so we would also alter subsequent instructions.
Bill Gates questionably said "I choose a lazy person to do a hard job, because a lazy person will find an easy way to do it." After some thought, I recalled a bit of x86 processor arcana that can help us fit our detours into the three-byte spaces provided by the obfuscator: the address-size prefix, 0x67. Quoth the Intel manuals: "Address calculations are first truncated to the effective address size of the current mode, as overridden by any address-size prefix. The result is then zero-extended to the full address width." I.e., when operating in 32-bit mode, if we prefix an instruction that references an address with 0x67, the address will be truncated to 16-bits.
To be specific, consider the following:
UPX1:00410320 EB 00 jmp near ptr unk_410322 ; jump to 0x00410320 + 2(length of jmp instruction) + 0x00
When we place an address-size prefix on this instruction, we get:
UPX1:00410320 db 67h UPX1:00410320 67 EB 00 jmp near ptr unk_323 ; jump to (0x00410320 + 3(length of jmp instruction) + 0x00) & 0xFFFF
To use this trick for deobfuscation, we must first create a segment at address 0x0 of length 0xFFFF.
Recalling our motivating example:
UPX0:004081F7 in eax, dx ; obfuscated call 0x405000 + 0x4EE0 UPX0:004081F8 dw 4EE0h
Let us overwrite these bytes with 67 EB FD:
UPX0:004081F7 db 67h UPX0:004081F7 jmp short loc_81F7
This is the first half of our detour. Now, at location 81F7h, let's replicate the original control transfer instruction and add a jmp back to the location after the obfuscated sequence:
ROLFMSRE:000081F7 loc_81F7: ROLFMSRE:000081F7 call sub_409EE0 ROLFMSRE:000081FC jmp loc_4081FA
And now we have accomplished our goal. Once we have replaced the obfuscated control transfers, we human analysts can read the listing more easily, and Hex-Rays no longer has trouble decompiling the code.