Memory Dump Analysis

One of the things I'm seeing, or should I say, have been seeing for a while, is a move away from the purist approach to forensics, in that actual practitioners are moving away from the thinking that the process starts by shutting off power to the system. I've corresponded with folks using the FSP, and other similar toolkits, be they homebrew, or the WFT.

Besides collecting volatile data, one of the things that's talked about is imaging memory, or collecting a memory dump. For the most part, this has been talked about, but when I've asked the question (as I did at HTCIA2004), "what would you do with it?", most people respond with a blank stare. Then someone way, way in the back (or it sounds like they're way, way in the back...) says, "run strings on it." Okay, that's fine...but what then? How do you associate anything that you find in memory with the case you're working on?

Well, as a start, Mariusz Burdac, over at seccure.net, has released a white paper entitled, "Digital forensics of the physical memory". Now, some of the grammar may throw you off a bit, but keep in mind that this is a start in the right direction. The table of contents of the paper are pretty impressive, addressing some of the issues faced in performing analysis of memory dumps. Over all, I think that the paper is a really good contribution, and a definite step in the right direction. The collection and analysis of information (re: evidence) from live systems is going to become even more important as time goes on.

However, one thing that really threw me was the fact that the author started the paper off by using the FU Rootkit and SQL Slammer worm as examples to justify performing memory dump analysis. The issue I have with this is that the author then goes into analyzing memory from Linux systems...the FU Rootkit and SQL Slammer worm affect Windows systems. The author makes no mention of Windows systems other than to say that the analysis of memory dumps "can be done".

In order to collect the contents of physical memory from a Windows system, you should look into the Forensic Acquisition Utilities from George Garner. The web site includes examples of how to use dd.exe to obtain an image of PhysicalMemory.

One needs to keep in mind, however, that while the system is running, pages are swapped out of memory and into the pagefile (ie, pagefile.sys). Therefore, if you were able to identify the area of memory used by a process, it would be a fragment of the total amount of memory (RAM + pagefile) used by the process. If you're interested in a particular process, I'd recommend using pmdump, instead.

MS does have some documentation regarding using debugger tools to analyze memory dumps. According to MS documentation:

A complete memory dump file contains the entire contents of physical memory when the Stop error occurred. The file size is equal to the amount of physical memory installed plus 1 MB. When a Stop error occurs, the operating system saves a complete memory dump file to a file named systemroot\Memory.dmp and creates a small memory dump file in the systemroot\Minidump folder.

So, maybe that gets us on our way a bit. This is used to analyze Stop errors, but perhaps it can also be used to analyze memory dumps, as well.

It looks like more research is required, as well as some testing. As I'm digging into this, I'd appreciate hearing from folks with regards to what they did, what worked, what didn't work, etc.