It’s simple: Analyze the sample, find the key. Each key is an email address.
Password for any encrypted archives is ‘malware’.
This time we have 32bit Windows executable. Viewing the Section names and IAT, it looks it’s packed and only loading a single DLL (msvcrt.dll).
I used OllyDBG to debug the binary and see it’s functionality. In the beginning we see the following instructions.
The first CALL to such_evi.004024D1 at address 0x004024CE it’s a function that installs a SEH routine. We are not interested in it since an exception is never generated.
Continuing with the code we see controlfp(), __set_app_type() and __getmainargs() from msvcrt.dll which we are not interested in.
At address 0x0040252A, however there is a call to what seems to be the ModuleEntryPoint, let’s go there.
Here we see a static shellcode being pushed to the stack. It’s rather lengthy so I’ve omitted a big chunk of it.
Once the shellcode has been installed on the stack, execution is transfered to it via the CALL EAX instruction at the end.
I could of copied the shellcode to a separate file and do some static analysis but I’ve decided to keep this POST kind of short so let’s continue debugging.
Place a BreakPoint at 0x0040249B and hit RUN.
Let the unpacking begin. What we see in the below snippet is that 0x1df number of bytes are going to be XORed with static hex key 0x66.
The XORed bytes are the ones where execution will jump to after this ‘unpacking routine’. So, let’s manually loop through this loop a few times and than place
a BreakPoint at 0x0012FD9B. The reason why we are manually stepping through this piece of code before placing a BreakPoint is so the BreakPoint does not get overwritten
by the initial XOR loop. I know that the first address to be XORed is past where the BP would be placed,
however this is how I like stepping through these loops and ensuring everything runs as expected.
The other solution would be to place a Hardware BreakPoint on execute on the same address…
Here I’ve copied a snippet of the previous routine and the resulting instructions after the unpacking routine.
You see how the code has changed ? What used to be 0x07 at address 0x0012FDA0 is now 0x61, because 0x07 ^ 0x66 = 0x61.
The interesting part here is the jump at address 0x0012FD9B where we are currently.
The jump is going to transfer execution to 0x0012FDB0, however if you pay attention you will see that that address is in
the middle of the interpreted instructions and not at the start of another routine. This is a nice nifty anti-disassembly method.
You see how instruction IMUL at address 0x0012FDAC starts and ends at 0x0012FDB3 and it takes raw hex bytes “67:696E 73 68757300” ?
If execution is going to jump to 0x0012FDB0, this address starts at raw bytes “68757300”, which is a PUSH (0x68).
Since we are using a debugger and not static analysis we can jump step there without much to worry about. However if you are
using static analysis, make sure to start disassembly from those instructions so the real code gets interpreted properly.
As expected, the instruction jump took us to is a PUSH. Here is we have absolutely the same routine, except this time the key
is not a 1 byte 0x66 but the bytes being pushed to the stack at the beginning of the routine, 0x7375 0x72756173 and 0x61706F6E.
Remember those are little-endan, if we convert them to ASCII just for clarity we get the key “nopasaurus”.
Again the first XOR address is past the second JMP at 0x0012FDF3, which is 0x09 and it will be XORed with the first byte of
“nopasaurus” which is 0x6E… and so on. Let’s place a BreakPoint at 0x0012FDEE the same way as before.
Just as before, JMP is going to jump in the middle of an instruction. We know how to deal like that…
After we have transfered execution to address 0x0012FE24, we see the same XOR routine again. Well… almost the same :P
Now, we have XOR DWORD which means it will apply XOR to 4 bytes at a time with key 0x476C4F62.
Another thing I like to do is when seeing those XORing functions is to follow the address being XORed in the Olly’s DUMP window
and watch for any interesting strings… Let’s not asume that only execution instruction are being obfuscated but helpful resources as well.
Again manually go through the unpacking loop and then place a BreakPoint at 0x0012FE47 after the loop.
The unpacked routine decrypted the next XOR key, again this is applied byte by byte.
Also if we follow the data that’s being decrypted in the DUMP window in Olly, we can see that the string
“firstname.lastname@example.org” is revealed.
Since we have found the password, I will not go over the rest of the code. In a summary another XOR key “aaaaaand i’m spent” is applied on the
Stack data which decrypts, “BrokenByte” string. Than the binary looks for “FatalAppExitA” in kernel32.dll
which it uses to deliver the “BrokenByte” Exit pop-up message and Exits.