Friday, December 6, 2013

Memory image file formats

The bulk of this blog post came from the answer I gave to a question that one of my SANS FOR526 (Memory Forensics) students sent me about file formats and extension names.  Specifically, he wanted to get some information on the difference between files with a .vmem extension and the .raw files output by DumpIt, a great, free memory dumping utility.  I told him:
The .vmem extension is used by vmware to indicate that a file represents the contents of physical memory on a guest virtual machine.  You would get a filename of .vmem if you used the snapshot method of obtaining a memory capture from a VM.  Alternatively you can capture the .vmem by pausing the VM, but this is less ideal since network connections are broken and VMware tools provides notifications to software in the VM guest.  
In the case of a physical machine, dumpit will provide a filename with a .raw extension.  Presumably this is used to differentiate it from memory captures that include capture specific metadata in the file format (HBGary's .hpak format is one such example).  Another example of a memory capture with metadata might be an .E01 captured with winen.exe (provided by EnCase).  Your tools will work identically on a .raw and a .vmem file. 
Of course there are many other file formats where physical memory may be found.  One such format is the hibernation file.  I love using hibernation files in cases, especially when volume shadow copy is enabled on the machine.  Sometimes I have several historical memory images that I can perform differential analysis on.  This may help determine when a compromise occurred, particularly if anti-forensics techniques were employed to destroy timestamps on the disk.
A final memory image format that comes to mind is the crash dump.  While this requires that a machine be appropriately configured to create a dump, many are (especially servers).  The crash dump is particularly relevant to rootkit detection as the fateful BSOD is most common when loading new kernel mode software (many rootkits are implemented as device drivers).  There are several tools that can convert kernel memory dumps (.DMP files) into physical memory dumps (to be consumed by memory analysis tools).  But they aren't needed if all we want to do is run Bulk Extractor (BE).  Because the memory contents in .DMP files are not compressed, the data can still be accessed.  The additional metadata added to a .DMP file (debugging related) isn't a concern for a tool such as BE that ignores internal file structure.

My student went on to ask whether he could use Bulk Extractor on a .raw file acquired by DumpIt.  In FOR526, one of the things we teach is using Bulk Extractor to parse memory for artifacts such as email addresses, URLs, and facebook IDs (among others).  If you aren't using BE in your cases, you owe it to yourself to give it a try.  At the banner price of free, it's something we can all afford.  I told my student:
In a larger sense though bulk extractor can be used on any image file of any format that doesn't use compression (it won't natively handle EnCase .E01 compression for instance).  But otherwise, just point bulk extractor at the image file and go to town.  That's one of the things that makes BE so magical.  If you have an SD card or USB drive from a device that uses some unknown filesystem, BE can still do it's magic because it doesn't try to understand the filesystem at all.  Same goes for memory, it's just doing pattern matching, so the underlying container structure doesn't matter.
If this sort of thing is up your alley and you want more information, come take FOR526 at an upcoming event.  We introduce Windows memory forensics and cover it in sufficient depth to immediately apply memory analysis skills in your investigations.  Rather than focus purely on theory, we ensure that you walk away with skills to hit the ground running. 

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.