Shifting yourself to space

April 28, 2011

Dwelling into ZwSetSystemInformation

Filed under: Uncategorized — shift32 @ 4:34 pm
Tags: , , ,

As things got a bit out of control with my simple driver, I have decided to debug and see what’s going on really inside ZwSetSystemInformation.
Perplexed by the windows architecture (so far I was used to good old Linux 2.6.x ), I’ve plugged windbg
into a session an


kd> uf nt!ZwSetSystemInformation
nt!ZwSetSystemInformation:
804fe534 b8f0000000      mov     eax,0F0h
804fe539 8d542404        lea     edx,[esp+4]
804fe53d 9c              pushfd
804fe53e 6a08            push    8
804fe540 e80ce10300      call    nt!KiSystemService (8053c651)
804fe545 c20c00          ret     0Ch
kd> x nt!ZwSetSystemInformation
804fe534 nt!ZwSetSystemInformation = <no type information>

As I’ve read beforehand, ZwSetSystemInformation is an undocumented and “stealthy” function to load drivers, so I wasn’t looking for anything special
as the “examine” command doesn’t give anything at all, I’ve kept looking a bit more – I thought about checking out where the function is defined in the official sources – aka – Microsoft
or the WDK but it seems that undocumented is indeed undocumented, the best I could find was basically the original definition I had


NSTATUS (_stdcall *ZwSetSystemInformation)(	IN DWORD functionCode,
											IN OUT PVOID driverName,
											IN LONG driverNameLength );

and nothing more than.
Well, I guess that it’s enough for a start, I’ve a set a bp in ZwSetSystemInformation and kept hoping for good.

kd> bp nt!ZwSetSystemInformation
kd> bl
 0 e 804fe534     0001 (0001) nt!ZwSetSystemInformation

Once I’ve hit it, I’ve disassembled the call and wasn’t too surprised to see that it was calling to nt!KiSystemService

nt!ZwSetSystemInformation:
804fe534 b8f0000000      mov     eax,0F0h
804fe539 8d542404        lea     edx,[esp+4]
804fe53d 9c              pushfd
804fe53e 6a08            push    8
804fe540 e80ce10300      call    nt!KiSystemService (8053c651)
804fe545 c20c00          ret     0Ch

The interesting arguments here are

804fe534 b8f0000000      mov     eax,0F0h
804fe539 8d542404        lea     edx,[esp+4]
804fe53d 9c              pushfd
804fe53e 6a08            push    8

I don’t know enough to understand what each one of them means, but it’s worth a shot investigating deeper in order to understand

Trying to figure what is the address which gets into edx didn’t give much results beside archaic thoughts


kd> dw 81dc4068 
81dc4068  0006 0070 0000 0000 4070 81dc 4070 81dc
81dc4078  4078 81dc 4078 81dc 6000 f4ca 2000 f4ca
81dc4088  d000 7ffd 0000 0000 5b10 f4ca 0200 0000
81dc4098  0a00 0800 409c 81dc 409c 81dc 40a4 81dc
81dc40a8  40a4 81dc 2da0 8201 0000 0000 076e 0000
81dc40b8  0000 0000 0000 0000 0000 0000 40d8 81dc
81dc40c8  0000 0000 8db8 8054 5c6b 0001 0008 0400
81dc40d8  bbf8 81f2 bbf8 81f2 4068 81dc 3a60 f72a
kd> db 81dc4068 
81dc4068  06 00 70 00 00 00 00 00-70 40 dc 81 70 40 dc 81  ..p.....p@..p@..
81dc4078  78 40 dc 81 78 40 dc 81-00 60 ca f4 00 20 ca f4  x@..x@...`... ..
81dc4088  00 d0 fd 7f 00 00 00 00-10 5b ca f4 00 02 00 00  .........[......
81dc4098  00 0a 00 08 9c 40 dc 81-9c 40 dc 81 a4 40 dc 81  .....@...@...@..
81dc40a8  a4 40 dc 81 a0 2d 01 82-00 00 00 00 6e 07 00 00  .@...-......n...
81dc40b8  00 00 00 00 00 00 00 00-00 00 00 00 d8 40 dc 81  .............@..
81dc40c8  00 00 00 00 b8 8d 54 80-6b 5c 01 00 08 00 00 04  ......T.k\......
81dc40d8  f8 bb f2 81 f8 bb f2 81-68 40 dc 81 60 3a 2a f7  ........h@..`:*.
kd> 
81dc4068  06 00 70 00 00 00 00 00-70 40 dc 81 70 40 dc 81  ..p.....p@..p@..
81dc4078  78 40 dc 81 78 40 dc 81-00 60 ca f4 00 20 ca f4  x@..x@...`... ..
81dc4088  00 d0 fd 7f 00 00 00 00-10 5b ca f4 00 02 00 00  .........[......
81dc4098  00 0a 00 08 9c 40 dc 81-9c 40 dc 81 a4 40 dc 81  .....@...@...@..
81dc40a8  a4 40 dc 81 a0 2d 01 82-00 00 00 00 6e 07 00 00  .@...-......n...
81dc40b8  00 00 00 00 00 00 00 00-00 00 00 00 d8 40 dc 81  .............@..
81dc40c8  00 00 00 00 b8 8d 54 80-6b 5c 01 00 08 00 00 04  ......T.k\......
81dc40d8  f8 bb f2 81 f8 bb f2 81-68 40 dc 81 60 3a 2a f7  ........h@..`:*.
kd> u 81dc4068 
81dc4068 06              push    es
81dc4069 007000          add     byte ptr [eax],dh
81dc406c 0000            add     byte ptr [eax],al
81dc406e 0000            add     byte ptr [eax],al
81dc4070 7040            jo      81dc40b2
81dc4072 dc817040dc81    fadd    qword ptr [ecx-7E23BF90h]
81dc4078 7840            js      81dc40ba
81dc407a dc817840dc81    fadd    qword ptr [ecx-7E23BF88h]
kd>

So I kept on debugging .. to be continued for now….

Advertisements

Short tips: Debugging a vm with a named pipe

Filed under: Uncategorized — shift32 @ 12:59 pm
Tags: , ,

I recently started writing drivers with windows, so far I’ve only written one and you can see the results down below, however I tried loading the driver in a non-traditional way using the undocumented ZwSetSystemInformation

For some unknown reason, the driver halts the system and I get an exception of an invalid instruction
However this is not the case of this post

In order to debug things correctly, I’m using VirtualBox winxp-sp2 as a guest machine to run my code and my host machine runs a windbg session
VirtualBox’s support in com ports sucks and I didn’t make it at configurating a com port for my debugging session so I decided to use named pipes

In order to do so, go to the Settings -> Serial Ports – >
Check the “Enable serial port” and create “Host Pipe”

It is quite crucial that you’ll name your pipe as \\.\pipe\ since if not you’ll get an error while running the vm

Once you’ve created a named pipe, run

kdsrv.exe -t npipe:pipe=\\.\pipe\<pipe_name> in your guest machine

within the host machine go to File -> Kernel Debug ->
and choose “Port” within the COM box write your named pipe name, Check “Pipe” and you’re done.
You can also check “Reconnect” too, it saves a few things

Once you load up the os in debug mode (bcdedit etc) be sure to hit ctrl+break to halt the system and get control
It’s also noted to use the symbol server that ms offers in order not to fuck symbols up (it’s quite a nightmare setting things up imho)

enjoy.

April 17, 2011

The case of video.exe

Filed under: Uncategorized — shift32 @ 5:46 pm
Tags: , , ,

The case of video.exe

Just another day without much work and I wanted to do some fun reversing. I fetched some malware from malc0de.com database and started investigating.

The malware is packed, and from the begining it has a few annoying anti-debugging stuff, however IDA knows how to deal with them and with a little bit of editting in olly
everything can be overrun

loc_49C8F4:                            ; CODE XREF: start+9A7B6_j
.data:0049C8F4                 jmp     loc_49C8FD
.data:0049C8F4 ; END OF FUNCTION CHUNK FOR start
.data:0049C8F4 ; ---------------------------------------------------------------------------
.data:0049C8F9                 db 22h, 9Eh, 8Dh
.data:0049C8FC ; ---------------------------------------------------------------------------
.data:0049C8FC                 sahf
.data:0049C8FD ; START OF FUNCTION CHUNK FOR start
.data:0049C8FD

Notice the db 22h, 9eh and 8dh which resolve to

simple assembly obfuscation

Olly gets a little bit crazy when hitting the single step button, these anti-debuggin tricks appear all along the way

I’m writing this documentation while still disassembling the malware and so far I’ve ran into several xor-loop decryption
It seems that the crucial parts of this malware are encrypted with a simple xorl-loop encryption method, which is quite easy to spot

simple xor decryption loop of a code chunk

EAX seems to hold the address that will be decrypted, EBP holds the relative address and makes it a true virtual address
DL/EDX seems to hold the decryption key (70h) and ECX as always has the len

The malware continues it’s journey and allocate space at 0x00BEE00, without any known reasons (for now ? : )

It seems that every decryption method is quite similar to the other, only they’re written over and over
DST address is always in either EAX or EDX (depending on the size word,dword,byte, etc),
KEY is always in either EAX or DL which seems to be 0 most times
LEN is always in ECX

after these arguments are pushed onto the stack they’re moved into the registers and a simple mov-xor-dec-jnz loop begins

Next there’s an interesting PE header deobfuscation method, the method is very long and I still haven’t fully understood how it works
but the main thing it does is copy an obfuscated PE header from ESI to EDI using AL as the register holding the chars and DL as the state machine
The method consists of MANY JNB/JNZ and ADD/ADC’s with DL which makes it even harder to understand what’s going on and why

Once the DOS stub header is reconstructed, the basic PE header is copied along with the section names, size, and virtual addresses of the real executable
They’re all located from 0x00EB000.
There’s an interesting side note here to say, if you’ve been disassembling the binary with me, you’d notice that EB0000 plays an important role here, it is chunk we’ve allocated
somewhile ago with VirtualAlloc in 0x49C436

I didn’t follow all of it, I just ran through it managed to copy all the DOS header and the PE header,
once we return – the packer starts fixing regular jmps (E8,E9) and JMP DWORD (25FF), the loop itself is quite easy
it starts from the DOS stub looking for these bytes, if they exist, it just changes their values

fix jmps

Afterwards another PE header is parsed and copied, this time it’s a DLL type PE header, all the sections are copied into the executable and the original PE header is freed with VirtualFree (00BEE0000)

This is probably the end of part I in this series, I hope to continue and reverse this malware and actually see what it is doing

Blog at WordPress.com.