Okay, so the other night I was working on some OO Perl code for parsing RAM dumps, and I decided to put together a table of important value/offset pairs for EPROCESS blocks for the different OSs. Andreas already has a good one started, but it stops at Win2003, then jumps to the Vista betas (also, the link for the EPROCESS for XPSP2 is wrong...go to the one for XP, and replace the "0" before ".html" with "2180"). I fired up a Win2003SP1 VMWare session, launched LiveKd, and dumped the EPROCESS structure. So filling out my table, I find a lot of differences in the structure, going from Win2003 to Win2003SP1...there weren't this many differences going from XP to XPSP2. Oddly enough, the offsets that remain constant throughout, from 2000 all the way to 2003SP1, are for the DirectoryTableBase (0x018), and the ThreadListHead Flink and Blink values (0x050 and 0x054, respectively).
Oh, yeah, one other thing...the Size value for the Dispatcher Header for Win2003SP1 changed, too...the new value is 0xle. I found this by opening up the .vmem file in UltraEdit and searching for the ImageFileName for the System process, which is "System" followed by 10 "\00"s. From there, I backed up 356 bytes (the ImageFileName is a 16 character string located at offset 0x164 within the EPROCESS structure), and as the 356th byte was aligned on a page, I checked the values. As Andreas pointed out, the Absolute and Inserted values are 0x00, but without more to go on, don't use these as part of your "magic number" when looking for EPROCESS structures in a memory dump.
Looking at my table, and looking at a draft paper I was reading, I figured that I could write a tool that would take a dd-style RAM dump or a .vmem file and figure out what OS it was. I mean, after all, now many times does someone tell you that their Windows box has a problem (or got p0wned) and when you ask which version of the OS they were running, you just get a blank stare? Yeah, that never happens to me, either. Anyway, I was looking at some of the "rules" mentioned in the paper, and I started organizing things in my mind...and then started implementing what I was thinking about in code. So, the end result is a pretty decent OS identification script that works for Win2000 through Win2003SP1. The script works, and I'll need to incorporate that functionality into the OO framework I'm putting together.
Here's a sample output from the script:
C:\Perl>ostest.pl g:\vmware\vmware2k3\winNetStandard-Snapshot2.vmem
ostest - parse dd-style RAM Dump to determine OS (v.0.1_20060906)
Ex: ostest
..
Idle check : 2K3SP1
..........................
System check : 2K3SP1
OS guess based on System and Idle checks:
2K3SP1
I incorporated checks for the Idle process, in addition to the System process. The dots printed to STDOUT indicate possible EPROCESS structures that need to be checked...they provide a visual status, nothing more.
If this is something you'd be interested in, please let me know, by comment or by email. I'm not sure if this is entirely useful, and if it isn't, I won't bother posting it with the other tools.
2 comments:
You definitely need to release this tool, being able to detect the OS of a memory image reliably is incredibly important. For starters we can get rid of all the separate ptfinder type tools and have a single script.
Will also help significantly with some firewire stuff we are releasing soon :)
Darren,
Thanks. I'm working on some improvements to the reliability of the script.
Post a Comment