4

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.

Improve this question
6
  • could you give the sha256 hash of the file?
    – ubnix
    Oct 23, 2017 at 7:20
  • 9ed85a6de31604eb431cdd7632cad0e5be54af10a16cc6ca0b886d1f92bb91b8
    – rustam Shirinov
    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.
    – rustam Shirinov
    Oct 23, 2017 at 13:17
  • Is it possible malware using anti-debugging methods?
    – Kerim Can Kalıpcıoğlu
    Oct 23, 2017 at 16:18

2 Answers 2

Reset to default
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).

Improve this answer
1
  • 1
    Thanks. Even though my problem was IAT I will upvote for detailed answer.
    – rustam Shirinov
    Oct 27, 2017 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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