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[0],[1],[2],[3] 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[0] (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.
June 5, 2008 at 12:41 am
When you speak of comparing the VMWare snapshots, do you mean that you are comparing .vmem files?
If so, you’re essentially comparing two full dumps of physical memory. A .vmem file contains a full linear dump of system memory; physical address x will correspond to file address x. Given this, it is not surprising that kernel memory can be found in the snapshot file!
There are tools that can parse such dumps; my favorite (probably since I’ve contributed a fair amount of code to it) is Volatility (https://www.volatilesystems.com/default/volatility); it can extract lots of information about open files, running processes, loaded kernel modules, etc. from memory dumps such as .vmem files.
It doesn’t currently have the capability to extract the SSDT; however, this would probably not be too difficult to implement, and having a volatile memory analysis framework available would allow you to reliably locate the SSDT within the VM snapshot (roughly, you would find the loaded kernel image, track down its KeServiceDescriptorTable export, and thus get the virtual address of the SSDT, which you could use directly within Volatility, as Virtual->Physical translation is handled for you).
There’s a whole field of digital forensics dedicated to examining such dumps of memory, called physical/volatile memory analysis or RAM forensics. Check out http://4tphi.net/fatkit/#links for a good list of papers/articles on the topic!
June 5, 2008 at 11:18 am
Hi.
Thank you very much for the links, seems like there are some nice articles.
Yes, I’m working on single vmem files.
If “physical address x will correspond to file address x” it’s relative easy to parse the file looking for various info, the hard part is to locate something else. The big problem of this kind of tools is that most of them are not able to find out hidden processes/modules, which is the interesting part of a static analysis. I tried Volatility (nice framework indeed), but it misses hidden processes/modules. I have to admit I’m far from being an expert in this field, but as far as I tried the only tool able to give out some good info is MemParser by Chris Betz.
I would like to know if there are some more tools able to discover hidden processes/modules, can you help me with some names?
Thanks in advance.
June 5, 2008 at 4:34 pm
Hidden processes and modules can be found within Volatility using “modscan” and “psscan”, which do not rely on processes/modules being in the various linked list structures, as they scan all of memory. The only disadvantages at the moment are that they’re a little slow (things are a *lot* faster in the next release, which will hopefully be out shortly), and it’s vulnerable to “chaff” — someone could put things that look like _EPROCESS structures into memory to throw off scanners.
Right now there’s no automatic correlation between the output of pslist and the output of psscan to detect discrepancies, however. Again, this would be easy to implement.
Memparser is cool, but last I saw only works on Win2k, and would be quite difficult to extend to XP and above, since it uses hardcoded offsets in the source code.
Andreas Schuster’s ptfinder is another great tool for finding hidden processes; however, its output should be the same as Volatility’s psscan. However, it has support for many more versions that Volatility at the moment.
Hope this helps!
Also, feel free to drop by #volatility on freenode if you want to learn more; most of the people doing open research in memory forensics hang out there.
June 9, 2008 at 10:35 am
Zairon,maybe this is of some interest to you?
http://nucia.unomaha.edu/tvidas/
June 9, 2008 at 10:20 pm
Thank you sowhat-x for pointing it out.
Seems like there are a lot of programs out there able to retrieve really good information from a generic snapshot, Volatility is one of them of course (Thanks Brendan).
June 16, 2009 at 2:59 pm
Keep your computer running like new.
Have you been searching for a great antispyware to keep your computer running like new? If so, you will be happy to know that there are some great options out there. I have tried many different types of antispyware only to find that the majority of them find the exact same types of bugs. The biggest difference that you will find between all the different types of antispyware offered is the price. Orbasoft Antispyware is an excellent choice that can be purchased at a lower price than many of the other options available. If you are interested in discovering the benefits offered from antispyware solution from Orbasoft visit http://www.orbasoft.com to learn more.