Reversing Self-Modifying Malware

Question

recently i got my hands on one sample that self-modifies its .text section. So, I placed a breakpoint on .text section on write operation and then continued. I found out that it zeroes out the .text section and then writes the decrypted code to that section and then makes a call to the decrypted OEP. I used Scylla to correct the OEP and dump the .exe file.

When i get the imports it shows that the program only imports kernel32.dll.

This is the assembly of the dumped .exe file in the PEBear.

This is what I get when i try to open the dumped file in ImmunityDbg.

The imports i get are also very different from what Scylla gave me + The dumped program does not run it crashes right away. What am i doing wrong?

Thanks.

9ed85a6de31604eb431cdd7632cad0e5be54af10a16cc6ca0b886d1f92bb91b8 — rustam Shirinov, Oct 23 '17 at 10:31
ImmunityDbg is a fork of OllyDbg, both sometimes have difficult to recognize the code of the unpacked part. In Olly you can right click on these unrecognized code and click Analysis > Analyze Code. I'll suggest you to follow the steps Igor mentioned in this answer. You'll often have a hard time making an unpacked file executable, keep this in mind. — Megabeets, Oct 23 '17 at 10:43
Thanks for the advice, btw I forgot to mention everytime i go through the same procedure I get different hashes even though I m doing the same thing. — rustam Shirinov, Oct 23 '17 at 13:17
There is a call to IsDebuggerPresent but i already patched it. — rustam Shirinov, Oct 23 '17 at 17:46

score 5 · Answer 1 · answered Oct 27 '17 at 15:51

Start by placing a breakpoint on the entrypoint itself, which is probably not in the .text section at all, but in another section entirely. You will see that the program resolves its own imports dynamically, probably by searching within kernel32.dll for LoadLibrary and GetProcAddress.

By tracing through the top layer, you will also find when the decryption is complete and the transfer of control occurs to the decrypted code. If you dump the file at that moment, and then disassemble the result, you might be able to see the cause of the crash - it is likely to be anti-debugging mechanisms, of which there are too many possibilities to list here (but see http://pferrie.host22.com/papers/antidebug.pdf for a selection of commonly-used ones).

Thanks. Even though my problem was IAT I will upvote for detailed answer. — rustam Shirinov, Oct 27 '17 at 19:18

score 2 · Accepted Answer · answered Oct 27 '17 at 19:16

2

Thanks everyone who responded. The IAT was the problem. The OEP I found was the real OEP pointing to the unpacked code. But the dumped executable was not runnable because IAT was corrupt. After Fixing IAT in Scylla. It is now runnable.

answered Oct 27 '17 at 19:16

rustam Shirinov

395
1
3
16

Reversing Self-Modifying Malware

2 Answers2