First, I'm back from the MISTI "Cracking eFraud" conference. It was great to meet a lot of the folks there, both other presenters, as well as attendees.
I attended Brian Carrier's presentation entitled "Live Forensic Analysis". Brian was kind enough to sign my copy of his book for me. I also need to get a copy of Dan Farmer's book, as well.
While I enjoyed Brian's presentation, I have to say that there wasn't a great deal of "analysis" discussed. Yes, Brian covered tools and techniques, talked about rootkits...but analysis techniques weren't really discussed. However, I don't think that a one-hour presentation was really the venue for that sort of topic. I gave a presentation earlier in the morning on looking in the Registry for specific data, and went over by a few minutes...even though I felt that I was glossing over a lot of things.
Maybe the whole idea of presenting on "analysis" really needs to be a full-day presentation, with hands-on exercises, etc.
Anyway, I wanted to blog on memory dump analysis a bit more this morning. What I'm talking about here is using tools such as dd.exe to grab the contents of physical memory; i.e., RAM. As I blogged earlier, on Windows systems, if you want to grab an "image" of physical memory, you have to generate a crash dump, in which the system halts and the contents of physical memory are written to a file. However, most of the systems we would likely see aren't set up for this...so lots of folks, including LEOs, are using dd.exe to dump the contents of physical memory.
Once you have this file, what do/can you do with it? Well, the first and most obvious thing is to run strings.exe against the file or open it up in BinText. You might also run scripts against the file, looking for specific types of strings, such as email addresses, IP addresses, etc. Such things might be useful.
Another thing you might do is to break the dump down into 4K pages and generate hashes for those pages, and then parse through the file system, doing the same thing for the files. Matches would let you know if the pages were loaded in memory (credit for that one goes to Dan Farmer).
But what about parsing kernel structures? Microsoft has many of the available structures documented in MSDN, so we know what they look like. We know, for instance, that a particular structure is so many bytes long, based on the values in the structure, and we can parse these with computer code, either in C, or in scripting languages such as Perl (using unpack()). Knowing this, we only have one thing left that we need to know...the offsets. The image file itself starts at 0 (or 0x00000000)...we need someway of finding out where the Waldo structure begins in that file, before we can start parsing it.
So...what are your thoughts? Am I off base? Am I close? Do you have have any input at all on how to determine the offsets...other than "ask Microsoft"? Are there any developers out there who can comment on this?
(Prefix**Im no developer, but this is an interesting topic**)
ReplyDeleteLets assume you have a dd image of memory AND a harddrive dd image(s).
I would imagine that there might be a way to crossreference "dead" hd's ntoskrnl or ntdll (memory manager artifacts) to locations on a ddimage of memory.
I like Joanna's invisiblethings.org)tool, modGREPER-0.2 but thats on a live system....
Sal,
ReplyDeleteGood comment. I'd like to ask you to provide a little more info, though...either here or to me directly (keydet89 at yahoo dot com).
Basically, I think I can see what you're saying. Given the capture of memory via dd.exe (technically, it's not an "image"), one can go onto the image of the drive, find the files you mentioned, generate hashes of 4K blocks of those files, and then parse through memory in 4K blocks, comparing hashes.
What I would be most interested in finding is network connections and process listings, which are maintained in memory by the kernel...not written to disk in ntoskrnl or ntdll. We can find the structures for this info at the MS site...and if we know the offset in memory where it's located, we can parse it out.
Im working("thinking")from the following sources/tools:
ReplyDeleteJoanna's modgreper.02 and Windows rootkit interaction and memory use in general; w2k_internals program w2k_mem.exe,and the Windows SysInternals book to name a few.
Have you tried the w2k_mem.exe? Theres a good bit of command options that might help better map out memory structure.
Keydet,
ReplyDelete> break the dump down into 4K pages and
> generate hashes for those pages
How can you create the 4K parts? I mean how do you know where the borders are?
Varanusz
How can you create the 4K parts?
ReplyDeleteThat's not hard...just read in 4096 bytes at a time.
I mean how do you know where the borders are?
That's the hard part...that's why I'm asking all these questions about offsets. I've been digging and researching (possibly with the wrong search terms...), and not found the info. I've been asking, but not getting a lot of responses.