msramdmp: McGrew Security RAM Dumper

Creating bootable USB drives for capturing the contents of memory


Hello CanSecWest 2008 Attendees! Check out this blog post for links to more information on this site on the topic of msramdmp.

Overview

A short while back, a paper was published by researchers at Princeton University, in which they talk about the process of recovering encryption keys out of memory after a cold boot. This was surprising to many people, as most just assume that, since RAM is volatile storage, it is erased when power is removed. This is an incorrect assumption.

When the idea of memory retaining state for a short time was first brought to my attention a little over a year ago, I ran a few experiments similar to this one, just to prove it to myself. The desktop machines I tried would hold state for anywhere between 5 and 10 seconds without power, whereas my laptop, with no battery or wall power, would maintain state for an amazing 10 minutes. I used a Linux bootable CD to get an image of memory from a Windows to data carve, and found some interesting things. The footprint for the Linux OS was huge, though, and this interfered with my ability to capture as much memory from the previously running operating system as possible.

The Princeton researchers applied this method to the recovery of encryption keys, with great results. They also cooked up a way to image the contents of RAM with a very small footprint, only overwriting a small amount of memory in the process. Unfortunately, at the time of writing this, their tool, ram2usb, hasn't been released. I decided that it wouldn't be hard to go ahead and implement one myself, based off their paper and youtube video posted above, so that I (and others) can go ahead and start having fun.

So, as a small side project, I've written "msramdmp", the McGrew Security RAM Dumper. Enjoy!

Download

  • msramdmp.tar.gz - The compiled com32 executable, ready for use with SysLinux. Also, the C source code is included, along with some things needed to compile and link it properly.

    This version fixes a bug where the first section of memory wasn't being dumped correctly. Redownload if you downloaded this before 2:00PM March 5th, 2008.

  • syslinux-3.61.tar.gz - This is the exact version of SysLinux that I'm using here. You'll need this to prepare a USB drive for capturing RAM, and to compile modifications to the msramdmp source.
  • msramdmp_cd.iso - This is a bootable CD version of msramdmp that I made with isolinux. Please read this blog posting for information on using this. You'll still need a drive hooked up that msramdmp can write to through BIOS interrupts.

Usage

This isn't the most user-friendly program out there. It's small, low-level, and your only real recourse, if it doesn't do exactly what you want it to do, is to hack at the code yourself. Or email me if you're in a real bind ;) . It's also very hard to test this for proper operation in a lot of different situations since I just don't have the hardware. If something does go wrong and you manage to figure out why, definitely let me know the situation.

msramdump is compiled into a standalone "com32" application that SysLinux executes. So, it's tiny. To get this up and going on a USB drive, you're going to have to prepare it properly. I'll give a demo on how to do this in Linux, but the concepts should apply to wherever you want to do it.

For this demo, I'll be showing screenshots from preparing a 1 gig flash drive in my Linux VM.

First, wipe the drive you plan on using, overwriting everything with zeros. This'll cut down any chance that old data on the drive might be mistaken for something copied from RAM. It might take a while, depending on how large your drive is.

Next, create a partition table for the disk. I like to use "cfdisk". You want a very small fat-16 partition in front (marked bootable), and up to three partitions of type "40". This is the partition type that msramdmp looks for, to see where it should dump memory. When msramdmp finds one of these partitions, it will mark it as used (by changing the partition type to "41"), and then copy memory to it. The marking prevents it from overwriting a memory dump, unless you specifically go in and change the partition type back. Each msramdmp partition needs to be big enough to hold the amount of memory in your target computer (a little extra won't hurt either).

Write the partition table out to disk and exit. Now, create a filesystem for the fat-16 partition.

Now, you'll need to install SysLinux to the drive. After you have extracted and compiled the contents of the SysLinux tarball, move into SysLinux's "/mbr/" directory and write the master boot record that is there to the drive.

Back up a directory, then go back down into "/unix/", where you'll install SysLinux to the drive.

Now, you can mount the fat-16 partition, and copy "msramdmp.c32" and "syslinux.cfg" to it, from the msramdmp archive you downloaded.

Your drive should be ready now! Be sure that the computer you're dumping supports booting USB devices. This is a feature that's in many newer PCs, however it can be buggy and picky about drives.

Here's a screenshot of what msramdmp looks like when it runs on a system:

This was taken in VMWare, with a virtual hard drive as the boot device, since VMWare doesn't support booting from USB. It's interesting that while VMWare does not retain anything in VMs' memory after a cold boot, it does retain data in memory if the virtual machine is rebooted.

When you're ready to analyze the contents of memory that you've dumped, you can simply read the data straight out of the partitions marked with type "41". You can image the partition to a flat file using dd, or just examine it in-place. One way to quickly see if you've recovered data from a previous booting of the computer is to run "strings" on the RAM image, and look for strings that are not a part of the msramdmp or SysLinux software.

Notes

Some things you may want to keep in mind when trying to pull things out of RAM:

  • This isn't as straightforward as pulling a drive and imaging it, and you might only have one shot at it. Make sure your capture drive is set up correctly and working before you attempt this. You really need to know your target computer. Don't waste any time while it's off. Make sure your target partition is large enough to hold the RAM. Does the target computer have the capability of booting from USB? If not, you're going to have to do something else.
  • If you want to use this for serious forensic purposes, I would advise testing it in a laboratory environment. Do it on a system that you know isn't going to have remanence, and map out exactly what the the footprint of this tool is. This is something that I have not done yet.
  • It's very slow right now. I've got it reading and writing 8 kilobytes at a time. It might behave better if that is tuned, but I think that some computers, even with USB 2.0 ports, could be booting them as 1.0. Could be the way I'm buffering, could be the computer (I only own one that boots USB), could be the drive. All I know is I'm not getting nearly as much speed as the authors of the Princeton paper get with theirs.
  • Once you get the computer started back up, though, the RAM is going to maintain state until otherwise modified (unless BIOS RAM checking options are selected). You can take your time in the BIOS menu to make sure you've got the right settings to boot to the drive.
  • This is handy even if you're not recovering encryption keys. There's all sorts of unexpected things you might find, even doing some basic data carving of the captured images.

Also, you can probably integrate this into your existing USB toolkit. I've written a blog post on the topic, with some thoughts about how you might want to arrange it.

References

Here are some pages that were useful in the development of msramdmp: