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, 200915 yr by R3lly

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.

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, 200915 yr by R3lly

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.

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

Works like a charm, thx