Virus total & PEiD detects that the malware is packed with UPack.
Loading the malware in IDA Pro we can see that it’s import table is almost empty. This is another indicator of a packed binary. LoadLibraryA and GetProcAddress are typically used to rebuild the malware’s import table in the unpacking routine.
Usually for unpacking a technique that I would use is to break at GetProcAddress. Typically after the import table is rebuilt the unpacking routine will then jump to the OEP of the binary.
Soon after the last GetProcAddress was called, a jmp instruction was executed. We reached the OEP of the malware as seen below.
Next, we would begin dumping out the debugged process using ollydump plugin in ollydbg. However, when we tried to execute the binary… the application would crash! I could only think of 2 reasons why the dumped binary is behaving in this manner.
Corrupted PE Header
In our case here it is the later… We could fire up the ImpREC tool to fix the IAT as seen below and we would find ourselves with a healthy running malware.
Virustotal and PEID both suggests that the malware is packed using FSG.
For this malware, I did not see any tail jump signature. However after analyzing the sections in the binary, I observed a global variable that is being referenced in the code.
So i put a breakpoint @00409010 which is the address that the eip jumps to. Press Ctrl-A to reanalyze the code in ollydbg.
Now dump out the memory and you will get the unpacked version. If you were to analyze the disassembled code, you will realise that LoadLibraryA is being called to fix the IAT of the unpack malware. Once the libraries are fixed, the malware should jump to the unpacked code. Tracing it from LoadLibraryA is an alternate way to reach the jump instruction to 0x401090.