Driver Rootkit Analysis

[R3lly]

Hello,

I'm trying to analyze a ring 0 driver which can completely lock my computer except one software, VM(Ware) player. In fact, this driver communicates with the Virtual Machine to allow access to a software installed in the VM. It can't run without this driver.

As it's a 32 bit driver, my goal is to recreate a program which would emulate the presence of this driver so I could use my VM on Seven. I'm focusing on the communication between the VM and the host machine.

As I'm a complete newbie, disassembling the driver with IDA didn't help me much. Many of the calls made by the driver are a part of the "locking host system" routine.

Then I made some analysis with Wireshack. From what I saw. the Virtual System sends a packet with 64 bytes of data to the host machine, which replies with a packet containing no data. Then the Virtual Machine sends 64 other bytes of data and this time, the host replies with a block of 64 bytes of data. Here's an example of data sent by the VM :

VM : 19:3b:93:40:6c:c5:28:93:bc:43:31:85:12:bc:28:5f:c7:15:e3:85:11:8a:58:52:86:79:6b:fb:3d:a2:33:c4:30:af:c4:d8:2a:87:e9:c5:95:43:6d:f8:7c:c9:88:98:89:11:62:2e:11:1e:64:2c:25:96:40:d9:09:5a:3a:ef

Host :

VM : 7a:ae:f4:81:d7:b8:c1:db:2c:d5:c9:48:ab:e8:a6:c9:37:6c:2c:aa:2f:bc:ab:68:71:33:d4:5e:cb:20:b1:10:eb:6f:41:fb:96:74:66:b8:77:27:30:dd:43:c0:52:22:ab:20:90:cd:0d:97:2d:11:10:45:60:c6:bd:cf:4b:c4

Host : 7f:4c:7c:91:41:91:86:89:3d:88:20:51:cb:4d:e9:8f:d9:f1:66:02:c3:f1:d3:ba:27:c6:d3:a1:8f:f4:f5:59:06:eb:19:19:7e:58:a7:4a:b6:ab:e8:5b:5e:82:a0:44:6e:9e:37:31:d5:86:31:d7:03:ab:98:55:08:5f:52:89

VM : aa:a4:92:7e:c7:37:b0:06:14:13:6f:3b:07:08:b6:c0:7b:26:d2:ba:a8:06:ab:9d:61:21:40:81:28:57:ae:11:a9:cb:3a:1b:ce:81:6c:59:cd:75:a6:75:e3:8d:6b:09:27:9d:65:77:53:01:d2:e3:4d:2e:7d:ec:18:ba:69:32

Host :

VM : c9:31:f5:bf:7c:4a:59:4e:84:85:97:f6:be:5c:38:56:8b:5f:1d:95:96:30:58:a7:96:6b:ff:24:de:d5:2c:c5:72:0b:bf:38:72:72:e3:24:2f:11:fb:50:dc:84:b1:b3:05:ac:97:94:4f:88:9b:de:78:fd:5d:f3:ac:2f:18:19

Host : cc:d3:7d:af:ea:63:1e:1c:95:d8:7e:ef:de:f9:77:10:65:c2:57:3d:7a:7d:20:75:c0:9e:f8:db:9a:01:68:8c:9f:8f:e7:da:9a:5e:22:d6:ee:9d:23:d6:c1:c6:43:d5:c0:12:30:68:97:99:87:18:6b:13:a5:60:19:bf:01:54

If at the second part of the communication, I send nothing, the VM will refuse me the access to the software. Same thing if I send 64 byte of random data.

So I suppose that the null.sys host driver generates the third block using the two first blocks of 64 bytes to authenticate.

So here's my problem : I have sincerely no idea of how the null.sys generates the third block.

If anyone can help me, It would be very appreciated. Thank you.

Regards

PS : Sorry for my lame english.

null.rar

Edited November 2, 2009 by R3lly

[Teddy Rogers]

Chances are that first packet, because your on a TCP/IP network is a broadcast for the MAC address if its not already been found and cached? But you should be able to confirm this by pinging the device and sniffing the packets...

Ted.

[R3lly]

Hello,

Actually my description wasn't very accurate. By "first", "second" and "third" packet, I meant packets sent by the VM when I enter my login/pass (which activates the rootkit). The discovery is made way before this moment.

Here's the wireshack capture I've made :

Thank you for your help,

Regards.

Edited November 3, 2009 by R3lly

[kao]

I have no idea what the first packet sent by VM does. Second packet is a challenge that driver encrypts and sends back. It uses 64 byte XOR key, which seems to be static (=always the same).

Take data sent by VM and xor them with a proper response, and you'll have the key.. For your example:

7a ^ 7f = 05
ae ^ 4c = E2
f4 ^ 7c = 88
81 ^ 91 = 10
d7 ^ 41 = 96
b8 ^ 91 = 29
...

So the key is 05:E2:88:10:96:29.... Once you have the key, you can generate your own response.

[R3lly]

Awesome ! I tried to make some Xor operations but only with the strings sent by the VM ! Thank you !

I'll try and keep you informed. Again thank you

[R3lly]

Works like a charm, thx