Hello,

I was told that I might find more help here than at reverse-engineering.net

Where to begin:

Firstly, I do not have much experience in reversing malware. I have completed about 30 crackme's in my lifetime and have a fairly decent knowledge of windows internals (or so I thought).

Recently, I decided to attempt the disassembly of a random piece of malware downloaded from a website.

I first ran the program through PEiD. It detected it as packed with PECompact 2.xx, yet the program was not packed and could be disassembled with ease.

During execution, the malware loaded kernel32.dll and some choice functions. It then extracted a resource and wrote it to a file called "malware_filename.dat". It then called LoadLibrary on the .dat file.

When this was being disassembled with IDA Pro I received an access violation exception. Upon examination of the code I witnessed:
Code:



I didn't understand what I was seeing until I read an article about how packers can execute their code in the SEH. I tried to trace where the SEH was by looking for the TIB, but it pointed to some location in ntdll.dll which did not seem correct.

I did trace the code a couple times and notice that it is polymorphic in the sense that it seems to write to memory and then call it.

I can't seem to figure out how to dump a clean version of the dll.

UnPE2 and unpecompact both do not work on dlls.

Furthermore there are some interesting anti-debugging techniques used such as placing me in an infinite loop inside of ntdll_DbgUIRemoteBreakin.

The only reason I think it uses PEcompact2 is because you can physically see an ascii string "pecompact2" inside of it, which may have been placed there to trick me.

PEiD does not detect anything, IDA and Olly beg to differ.

Does anyone have any ideas? Has anyone seen anything similar before? Any tutorials to point me in the right direction?

If you would like the file, I could upload it. But I will only need help defeating the packer/polymorphic code.

Thanks,
-TCM

assuming you are using ollydbg you dont have to search tib teb and peb for seh handlers

view->seh chain will provide a neat over view of all the structured exception handlers that have been chained together

the top most one will be called first and the bottom most one will be called last before the application crashes if none of them handled the specific exception

you can use right click follow handler to follow and analyse the seh handler
after you follow you can set a breakpoint there
and use shift+f9 (pass exception to handler)

hope that helps

Some other possibilities:
It might be using Vectored Exception Handling instead of or in addition to Structured Exception Handling.
It might not have any custom SEH functions at that point in the execution because it purposely went down a "bad-guy" path because it detected your debugger.

Well. I managed to trace it to right before the point where I become jailed.

The DLL virtualalloc a space in memory at 0x00350000.
The DLL then points to it's text section and begins (in some weird way) decrypting a section and writing the result in the new memory region.
Eventually the DLL jumps into the new region.

When inside the new memory .text section it runs a very similar LoadLibraryA/GetProcAddress loop.




For some reason, it successfully loads kernel32.dll (or aquires the handle to it since it is already loaded). When it needs to load user32.dll it gets stuck in an infinite loop somewhere in ntdll.

Has anyone seen this before as a possible anti-debugging method?
I can F8 over the kernel32.dll load, but if I try over the user32.dll load I lose control of execution.


Here is what it should load from user32.dll eventually.

you mean you can f8 this line once

0035036A FF93 211E1701 CALL DWORD PTR DS:[EBX+1171E21] ; Call LoadLibraryA -> 7C801D77

and after f8 you land in this line
00350370 8945 FC MOV DWORD PTR SS:[EBP-4],EAX

but the second time you cannot f8 on this line ?

can you set a f2 break point on the
00350370 8945 FC MOV DWORD PTR SS:[EBP-4],EAX

and f9 it ?

i assume you are using a virtual machine or a safe environment
while doing this experiment
and not using your production machine with network access etc ??

no loadlibrary system call doesnt have any antidebug tricks
and user32.dll initialization code also doesnt have any antidebug tricks
as far as i know

Your assumptions are correct, and I have tried to bp/F9 the following line. Unfortunately, After I F8 the second LoadLibraryA (for user32.dll), I "lose control" of execution. Ollydbg's CPU utilization hits 90% and all it says is "running..." in the bottom corner. If I attempt to actualize the thread I always find it near NtContinue.





Yes. I'm running a Win XP SP2 box under VMware Server. It has network access to my other machine through an anonymous windows share for transferring files and thats it.



Btw, the "View SEH chain" worked perfectly. That is how I was able to get so far.


Update: It looks like the control is lost when syscall #06C is called (NtMapViewOfSection)

it is stopped on NtContinue

how are you determining this did you hit f12 pause the app and view the call stack ?

does it say NtContinue is in top of the stack ?

are there any other thread running besides the main

in thecall stack window you can view call stacks for every thread by rightclicking and checkmarking differnent threads that are running

if your main is stuck on NtContinue

NtContinue takes a CONTEXT Parameter whose member eip will point to where it will will land once system returns

find it in stack follow in dump and then follow the eip in disassembler from dump [esp+4] == (CONTEXT *) = 0x123456##; [123456##+0xb8] == pointer to eip
in c
typedef struct _CONTEXT
{
..
..
..
dword eip;
..
}CONTEXT *PCONTEXT;


PCONTEXT pcontfoo;
pcontfoo->eip

you should see where it will start executing

NtmapViewOfSection also doesnt have any antidebugtricks
but it holds LoaderLock a critical section and if the critical section locks wasnt released then it will simply be looping infinitely

but that should normally not happen unless in some special cases where you shouldnt be reaching this point without some earlier failure

you might have landed in a kind of intentional misleading code sequence may be thats supposed to make you go insane tracing that while you should never be in this place ?? red herrings ??

if it is a plain NtMapViewOfSection it should never loop infinitely

on a heavily loaded multithreaded apllication it may take a few clock ticks
more than normal becuse some other thread hasnt ceded control of the critical section but in a normal app it should never loop infinitely

The unpacking stub could have patched anti-debug code into the LoadLibrary function in USER32's memory space. Unlikely, but a possibility to consider.

yeah disavowed definately a possibility why unlikely ??
if he is tracing code that he should have never been tracing in the first place then every thing is a possibilty however remote

that why i added a qualifier system some kind of obtuse referance to indicate possible fiddling

Thanks for all of the responses. I'm not exactly sure of what happened but I can successfully trace over (F8) the call now. It appears that when the program attempted to load user32.dll, there were tons of other dlls loaded too including gdi32.dll and advapi32.dll. Also, when I F8 over the LoadLibraryA for user32.dll I get another warning from OllyDbg that the entry point of the module that I am working on is outside of the range (or whatever that generic "this file is packed" message is).


I managed to make a dump of the dll after it finished all of it's writing to the .text section. It actually went through a large loop where it XOR'd large sections of the code with '0x55' and then wrote calls to internal functions all over the .text section.

It hid ascii strings using a function that takes a hard-coded number and a encoded string and uses XOR to decode it. Pretty lame if you ask me.

Has anyone seen a type of packer or obfuscation like this?


Finally, does anyone know of website that lists explanations of the methods of packers so I could compare what I saw?

I would like to thank disavowed and blabberer for all of the help they have given me. I have learned a lot You guys are great.