5

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.

Scylla_output

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

PEBear_output

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

ImmunityDBG_output

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.

  • could you give the sha256 hash of the file? – ubnix Oct 23 '17 at 7:20
  • 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
  • Is it possible malware using anti-debugging methods? – de6f Oct 23 '17 at 16:18
5

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).

  • 1
    Thanks. Even though my problem was IAT I will upvote for detailed answer. – rustam Shirinov Oct 27 '17 at 19:18
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.