Obtain this sample from a cool malware researcher. Debug rootkit by IDA + Windbg.
PEID & PE Detector fail to find packer but clearly the DriverEntry is full of crap:
Debugging the packer for a while, function 0xA974B931 (base address 0xA974A000) leads to unpacking routine:
Lots, lots of functions are designed to decrypt data/code in .data section. SMC is everywhere for sure.
E.g one of the numerous decryption function:
Also anti-IDA trick can be found:
As a packer, it should call some memory allocation function like ExAllocatePool for releasing unpacked code / image. However, IAT in packed code does not include ExAllocatePool.
Packer must dynamically load ExAllocatePool via three methods:
- MmGetSystemRoutineAddress. UNICODE_STRING is supposed to be found.
- Looping nt’s export table and calculate the function address. Nt base address should be found somewhere.
- idk but there must exist third method.
After a while, method #2 is noticed:
Addresses of ExAllocatePool and ExFreePool are inferred and stored in the .data section.
This is part of loop in the rootkit (loop 256 times, call RtlCompressBuffer & RtlGetCompressionWorkSpaceSize). It strongly indicated part of unpacked code is compressed and decompressed somewhere. (http://www.literatecode.com/wzip).
Focusing on ExAllocatePool function: once a pool is created, watch this pool in the hex view until the pool is freed. (IDA memory breakpoint for kernel driver makes me anxious - it does not work stably).
Finally I found 0xA9753AA5 function is the key function. It builds a new image in the kernel memory pool. After that, the rootkit module is fully unloaded and windbg can’t found the module drv anymore.
The image size is 0x10000. Dump the memory image(of course IAT and relocation needs to be fixed.) and we get something lovely.
Some cool stuff (Unfortunately I don’t have time thorougly analyze the unpacked rootkit):
My friend told me he used windbg script. Cool!
Forensic tool in this scenario should be welcomed.
E.g Intel VT/EPT debugging kernel pages.