Some time ago I blogged about Vmware snapshots introducing a way to recognize hidden files by simply comparing two snapshots. I wanted to extend my research on the subject a little bit more, but I didn’t. I got the opportunity to put my hands on some snapshots again in these days. I haven’t anything on my mind, but I was surprised by some coincidences. Look at the information below:
80544bc0: 804fc624 00000000 0000011c 804fca98
80544bd0: bf995ba8 00000000 0000029a bf98f5f8
80544be0: 00000000 00000000 00000000 00000000
80544bf0: 00000000 00000000 00000000 00000000
00544BC0: 24C6 4F80 0000 0000 1C01 0000 98CA 4F80 $.O………..O.
00544BD0: A85B 99BF 0000 0000 9A02 0000 F8F5 98BF .[…………..
00544BE0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
00544BF0: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
First 4 lines are taken from Windbg while I was debugging an XP sp1 virtual machine running under Vmware; last 4 lines are taken from a saved Vmware snapshot (same os of course).
Do you see anything useful? These are KeServiceDescriptorTable,,, and they have of course the same bytes, but there’s something else. There’s a connection between the addresses on the first lines and the offsets on the second ones, just remove the first 2 digits from the address. Do you see it? Look here: 80544BC0/544BC0, 80544BD0/544BD0, 80544BE0/544BE0, 80544BF0/544BF0.
Seems like the kernel memory is stored inside the snapshot. It’s not totally true indeed, there’s only a part of the kernel memory stored inside a Vmware’s snapshot. All the KeServiceDescriptorTable entries are present btw.
SSDT is inside the snapshot I have and it’s complete; SSDT Shadow seems to be inside the snapshot too, but there’s no real connection between kernel memory/snapshot addresses and it’s not complete (it needs some more research btw).
Is it only a coincidence? I tried with some XP machines and the result is the same, it’s possible to obtain real information of SSDT. According to Kayaker’s test it should work on win2k (don’t remember the service pack he was using…).
With this new information it’s pretty easy to code a SSDT revealer. I gave it a try and here is a result:
You can use the program to display SSDT entries and to find out modified entries too by simply comparing an original snapshot with another one.
To retrieve information from a snapshot you have to provide the address of KeServiceDescriptorTable (something like 80544BC0, no “0x” prefix), and you have to select the OS of the virtual machine. After that you can:
1. save an untouched SSDT using the button labelled “Create untouched SSDT”
2. retrieve SSDT information from a snapshot by simply pushing the button labelled “Get snapshot SSDT”. Checking “Load untouched SSDT data” you can compare the original table (previously saved) with the one from the snapshot you’ll select. If a service has been changed you’ll read the word “YES” in the last column.
I took the name of the services from this table: http://metasploit.com/users/opcode/syscalls.html
I can’t test all the OS, if you find one or more errors drop me a mail.
Following this method it’s also possible to get the list of the running processes/modules, more about this later.
SSDT from snapshot