Just a little heads up on beginning the analysis of the drivers of this malware..
To start with, the zip file blabberer attached - it contains 2 zip files as mentioned, but the file named 'wincom32' should actually be renamed 'wincom32.zip'. Then you can unzip it with the supplied password to get the 2 drivers.
There is various infos about wincom32 around, I found that the service entry in the registry defines it as a Start Type 2 driver, a regular Win32 Service that is loaded by the Service Control Manager (SCM).
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wincom32
"start" = "2"
This means we can start the drivers manually with any old SCM loader and trace it in Softice. I used DriverMonitor in the Softice Tools directory. You could also use the OSR driver loader, or Greg Hoglunds instdrv, or your own or whatever..
Recall how a driver is loaded through ntoskrnl!IopLoadDriver and the sequence:
Code:
push dword ptr [ebp-0x0090] // PUNICODE_STRING RegistryPath
push edi // PDRIVER_OBJECT pDriverObject
call [edi+0x2C] // DriverEntry
We can set a breakpoint on Call [edi+0x2C] in order to trace directly into the rootkit driver INIT routine. A combination of IDA + symbols + some digging will find this address for you. Or do it dynamically by tracing back into ntoskrnl from your own driver INIT..
In XPsp2 this ntoskrnl address is 0x805A69D0.
With Softice and this breakpoint we've now got a way to trace the driver.. Now let's take a look at the IDA disassembly for ROOTY.SYS (the file named ROOTDEV.SYS is similar):
Code:
INIT:0001D300 public start
INIT:0001D300 start proc near
INIT:0001D300
INIT:0001D300 arg_0 = dword ptr 4
INIT:0001D300
INIT:0001D300 mov edx, [esp+arg_0] PDRIVER_OBJECT
INIT:0001D304 mov edx, [edx+0Ch] DRIVER_OBJECT.DriverStart
INIT:0001D307 add edx, 0DB00h
INIT:0001D30D mov eax, 0DF95h
INIT:0001D312 pusha
INIT:0001D313 mov ecx, 45Ch
INIT:0001D318 mov esi, edx
INIT:0001D31A mov edi, esi
INIT:0001D31C
INIT:0001D31C loc_1D31C: ; CODE XREF: start+29j
INIT:0001D31C lodsd
INIT:0001D31D sub eax, 24738268h
INIT:0001D322 stosd
INIT:0001D323 sub ecx, 4
INIT:0001D326 cmp ecx, 0
INIT:0001D329 jge short loc_1D31C
INIT:0001D32B popa
INIT:0001D32C add edx, 8
INIT:0001D32F jmp edx
INIT:0001D32F start endp
Hmmm, looks awfully like a decryption routine doesn't it?
You can see that the first thing it does is get DRIVER_OBJECT.DriverStart from the stack parameters. This is the MZ header of the PE file. Then it adds the offset 0DB00h, which would be the start of the encrypted block.
OK, so if the Base Offset of the file is 00010000h, then 0001DB00h must be...
Wait a minute, this is outside of what IDA disassembled, what the heck?
Well, from live tracing I already know that this offset is in the .reloc section.. ooh, that's different
Take a look at the code characteristics of the PE file, .reloc section is defined as C0000060 (writable, executable, non-discardable). Normal .reloc characteristics would define the opposite of these - 42000040).
OK, so we need to reanalyze the file in IDA, this time select the checkbox Manual Load from the IDA dialog box and when it asks you choose Yes to loading the .reloc section.
Now we can create a little IDC script, adapted straight from the IDA site example, to mimic the simple decryption:
Code:
// Decrypt rooty.sys (Wincom32)
// decrypt_rooty.idc
// decrypt(0x1DB00, 0x45C, 0x24738268);
#include <idc.idc>
static decrypt( from, size, key ) {
auto i, x; // define the variables
for ( i=0; i < size; i=i+4 ) {
x = Dword(from); // fetch the dword
x = (x - key); // decrypt it
PatchDword(from,x); // put it back
from = from + 4; // next dword
}
}
Load the IDC script and hit Shift-F2 to execute it with the proper command and parameters:
decrypt(0x1DB00, 0x45C, 0x24738268);
Scroll down to offset 0x1DB08 (the first 2 dwords of the encrypted bytes are zeroed out) and tell IDA to Convert to instruction (C) from the toolbar or menu. Viola, the code is decrypted.
The various offsets are relative to ebp and don't make much sense unless you're also live tracing in Softice, but it's a start. The driver uses MmGetSystemRoutineAddress to do much of its work, I haven't traced much of it yet though.
For interest/comparison you might want to look at Nicolas Brulez blog
Kernel Driver Backdooring
http://www.websense.com/securitylabs/blog/blog.php?BlogID=124
Cheers,
Kayaker
Oh yah. Him! 
