When you are analysing a malware it is common thing that you have to defeat some layers of obfuscation and anti-debugging. I have decided to describe one part of analyzing interesting sample from past.

Unpacking
A lot of malware samples are encrypted so the first step is find the decrypted part of program. It is possible that there are some anti-debugging tricks. So running in the debugger will cause a crash.

I discovered that there are two types of debugging traps:

• LOCK exception
• jump to end process call

The lock exception jump is surrounded by PUSHAD/POPAD instructions, so it could be NOPed whole block or just the JNE instruction.

 

 

 

 

The second type of trap is jump to end process call but it is not direct jump that could be easily recognized. So tracing is needed to find conditional jump at 00401FB which leads to the end of the procedure and then to another call which points on the EndProcess.

After passing all these traps it is a good idea to watch out memory allocations and writing. After a while I spotted a writing on 00930000 and that was  lucky so at the end of the writing loop I could dump the decrypted part of the malware.

 

 

 

 

 

 

 

 

 

Fun begins
Now it is a time for loading the dump into a debugger and start again. There is an unpacking loop which writes the program code to the stack. There is also lot of procedure calls those are not important for us and two traps which points to the EndProcess.

The important calls lead to these APIs kernel32.OpenProcess, kernel32.VirtualAllocEx, ntdll.NtWriteVirtualMemory and finally kernel32.CreateRemoteThread. These calls suggesting process injection.

This malware injects two system process explorer.exe and System core process. Each of these injections has different purpose.

explorer – downloads and drops another malware from malware sites
System core process – checks if the malware downloader is running; if not it starts it again

Debugging the system processes is not a good idea because the system would freeze very soon. So it is a good idea to redirect the code injection to another non-system processes e.g. notepad, mspaint, etc. It is not hard because the malware opens the process by kernel32.OpenProcess API function. So the only thing  to do is modify the process id variable on stack with the non-system one.

The injected code is started by kernel32.CreateRemoteThread. If the breakpoint is set on this API call then the entry point of new thread is set on stack too.

Attaching new instance of OllyDbg to a chosen non-system process is necessary before calling  the kernel32.CreateRemoteThread API. By setting a breakpoint on a start address of a new thread the real fun begin 🙂