I begin by setting a breakpoint at 0x402038 which was contained a dynamic call.
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.
No comments:
Post a Comment