This my personal blog where I share my learnings and hope to contribute to the community.

Sunday, February 12, 2017

Analysis of Rovnix Dropper 2/5 - Unpacking

In the previous post, I documented how I begin with the analysis of the Rovnix dropper and I concluded with the guess that I am dealing with a packed binary. In this post I showed how I unpacked the sample.

I begin by setting a breakpoint at 0x402038 which was contained a dynamic call.

From Ollydbg, I observed the address 0x3AEE590 is located in the heap and the access rights was set to RWX. At this point, the sample is unpacked yeah \o/.

After I dumped out the 'unpacked' heap memory segment and fixed the IAT. I import the 'unpacked' memory segment into IDA Pro. I noticed no strings pointing the URL that I obtained from FakeNet and no APIs were imported for accessing the internet. I guessed the sample is not unpack completely. :(

I tried to let the execution of the sample continue hoping to see the RWE memory segments created by the unpacker codes but I end up with BSOD.
I tried to hook the VirtualAlloc and HeapAlloc APIs to catch the sample dumping the unpacked binary.

Both options failed :( I guess I can only TRY HARDER!

At this point I knew, there was no short cut. I try to figure out what are the code in the heap memory segment doing. Then I noticed this:

Both the .text and .rdata sections of the binary(SUPERRAM) were set to RWE. The original memory access to these two sections were R_E not RWE. Now I understand how my hook attempts failed. The unpack was making using of SELF Modifying code. Next I set a hook at VirtualProtect and run the binary again. I noticed how the .text and rdata sections were changed from R_E to RWE.

Now, I went back to IDA Pro to look at the CFG of the heap memory segments there was no import function of VirtualProtect. WHY ? This was due to a 'trick' used by the author of the binary. It used an indirect call access to VirtualProtect API via a function table that was pre-populated with function addresses.

Finally, I located an indirect call that goes to the unpacked code!

Finally after fixing the IATs and executing a few functions to decode the strings, I could now dump the unpacked binary. I can now see the URL being accessed and the APIs used to access Internet.

YES finally the binary is unpacked! \o/

Next, I will cover some of the anti analysis techniques used by the sample.