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?


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

2 Answers 2


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. Oct 27, 2017 at 19:18

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 and acknowledge you have read our privacy policy.

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