3

I'm trying to reverse a malware sample with the following MD5: ef668a0cd0755c67930ece13d28a6bda.

Obvious, this is a packed malware. On a first look, it seems to bee some GUI Programm, but at some point(0x4013E6) it modifies itself and turns to completely another program(malicious one).

I'm preety sure that the OEP is at 0x401265. But the problem is - I can not dump the process at this point and it makes the analysis difficult, because I can analyze only in a debugger. I tried to use the OllyDump and it throws the Unable to read memory of debugged process(00400000..00408FFF) followed by Bad DOS Signature!!. I also tried the dump.py in ImmunityDBG but it did not helped.

I also tried to change memory acccess right on every section in Olly before I dumped the process. Unfortunately it was not possible to change it at all sections. Also, consider that this malware sample creates new sections while modifying itself, may be it causes the problem?

If you want to take a look on the malware sample by yourself than set a first hardware breakpoint at 0x40220F(it is where the unpacking stub starts). After that set another one at 0x401265(OEP in my opinion).

It would be great if you count give me a hint how could I dump the process or what am I doing not correctly.

Thank you in advance :-)

  • Did you try dumping with Volatility's procdump plugin? – mayahustle Jul 14 '15 at 13:37
  • I used to have good success with LordPE's process dumper – fileoffset Jul 15 '15 at 5:43
  • Yes I could dump the process with several other tools like procdump(volatilitiy's one and from Sysinternals). But I have another problem. I cannot repair the IAT. I tried to use ImportRec and volatility's impscan. And that is why I cannot see in IDA which functions are called. If I use MakeName in Python it just adds a comment. But I would like to somehow rename functions... Do you know how can I achieve that? – 0xDEADC0DE Jul 17 '15 at 16:05
2

Malware can be removing/manipulating its own PE Header.

void destroyPEHeaders(){
        DWORD OldProtect = 0;
        char *pBaseAddr = (char*)GetModuleHandle(NULL);
        VirtualProtect(pBaseAddr, 4096,
            PAGE_READWRITE, &OldProtect);
        srand(time(NULL));
        ZeroMemory(pBaseAddr, 4096);
        srand(time(NULL));
        for (int i = 0; i < 4096; i++){
            char *x = pBaseAddr;
            x += i;
            *x = rand() % 255;
        }
    }

Something like this normally blocks stuff like CreateRemoteThread calls, so maybe it does the same thing to dumps?

Maybe you should try rewriting the original PE?

  • Actually your assumption is right. The malware writes 120 Bytes of its header to zero before it starts a new instance of itself in a new process(it copies itself to Temp-Folder and executes from there). I tried to recover this 120 Bytes of header (in a debugger) before it starts a new process but it just causes an error! – 0xDEADC0DE Jul 17 '15 at 16:00

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.