PDA

View Full Version : Malware obfuscation - how to rebuild imports?


klaymen
January 31st, 2008, 09:05
Hi all,

I just recently started with reverse engineering some malware, using Ollydbg and Ida Pro, and encountered the following problem:

After the malware decompressed itself in memory, as an additional step for obfuscation, it builds its own table for API calls into a data segment, which looks like that (this is only an excerpt):

Code:

...
0040FE38 7C80B828 kernel32.VirtualQueryEx
0040FE3C 7C809AA2 kernel32.VirtualAllocEx
0040FE40 7C801A5D kernel32.VirtualProtectEx
0040FE44 7C80994E kernel32.GetCurrentProcessId
0040FE48 7C80CC67 kernel32.SetThreadPriority
...


In the code segment, API calls are then made like this:
Code:

MOV DWORD PTR SS:[EBP-14],EBX
PUSH DWORD PTR DS:[EAX+3C]
PUSH EAX
PUSH DWORD PTR DS:[40FB30]
CALL DWORD PTR DS:[40FE40] ; kernel32.VirtualProtectEx
MOV EAX,DWORD PTR DS:[40FC1C]


Ollydbg itself seems to be able to resolve the VirtualProtectEx call.

I'd like also to be able to analyze it in IDa Pro though. So I used the Ollydump plugin and loaded the resulting file into IDA Pro, but only get

Code:

mov [ebp+var_14], ebx
push dword ptr [eax+3Ch]
push eax
push ds:dword_40FB30
call ds:dword_40FE40


In the data segment, I see
Code:

....:0040FE40 dword_40FE40 dd 7C801A5Dh ; DATA XREF: ...

But obviously it can't make the reference to the system call.

I also tried "Rebuild import table", "Method 1: search JMP[API]|CALL[API]", which looked like the thing I needed, but this doesn't work either. Actually, the import table is always empty, just the data stored at dword_40FE40 is modified (to 22EB6). I think my problem is an additional step of indirection that I'd need.

Does anybody know what could be done in this situation to make life easier?

Thanks in advance, Andy

naides
January 31st, 2008, 09:21
Hi Andy:
Perhaps ImpRec may help?
It will create its own import table and append it to the dumped file. IDA then LIKELY will recognize the imports and disassemble the system and api calls correctly. Keep in mind that the resulting executable is not a carbon copy of the unpacked dump, but certainly could make your life easier in IDA analysis.

klaymen
January 31st, 2008, 11:42
Hi Naides,
Thanks a lot, that worked very well :-) It could not resolve all of the calls, but nearly all, so it was no big problem fixing the rest manually.