- msramdmp
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 theitten 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:
- http://citp.princeton.edu/memory/
- http://syslinux.zytor.com/comboot.php
- http://home.teleport.com/~brainy/interrupts.htm
- Memory map on osdev.org
- File System Forensic Analysis – Great book, used the descriptions of the partition tables.
[...] also touch on the McGrew Security RAM Dumper and [...]
[...] also touch on the McGrew Security RAM Dumper and [...]
Hi,
what is the exact format of the “type 40″ partition?
Thanks.
There is no filesystem on the msramdmp partitions, so there isn’t really a format. I would recommend zero’ing out the partition with dd before running msramdmp, though, so you can be sure that any data written there was written from RAM.
After msramdmp runs and marks the partition type as being used (“41″), then the partition contains an image of RAM, without any filesystem structure. You may simply dump the partition back out to a file on your computer using dd.
Thanks very much, just wanted to clear that up.
[...] McGrew Security http://www.mcgrewsecurity.com/tools/msramdmp/ [...]
I worked this out in the lab. This is what I got :
mbr.bin : 0×193 bytes
syslinux: 0×4983 bytes
msramdmp: 0xd37 bytes
cfglinux: 0×30 bytes
Total of 587d bytes or
22,653 bytes (22.6 KB)
Nice. Thanks!
Please, change your DD command to dd if=….. | dd of=
Using a Pipe! speeds up things up to 7 times. Compile it in the thing and post the new version please :)
On a second run – just read your source – the idea of DD can be used the same way… but I’m not that good in C to make it work.
Thanks for the tip, Alexander.
The problem is that, to keep from stomping on too much memory, msramdmp runs straight from the syslinux bootloader, which provides only a bare minimum of services to its plugins. There is no kernel loaded, and therefore no filesystem support, pipes, and definitely no DD.
It may be possible to tweak how much is read from RAM before flushing out to USB to improve performance a bit, but being implemented as it is now, msramdmp appears to be limited in speed by the (widely varying) capabilities of each system’s BIOS to use interrupts to write to USB as if it were a normal IDE or whatever drive.
Hi, very good and interesting stuff here.. I’ve tried to download the syslinux-3.61 but i received a http 404 error..can someone reupload it again?
Thanks in advance!
Hi Lorenzo! It will probably work fine with other, newer, versions of syslinux as well. Once I’m back from travel I’ll try to remember to test it out with a recent version and update the link. Thanks
Followed the instructions on the lab. When mramdmp is ran from a usb, How long does it take to dump about 3 gig of RAM. I have had mine running for about 5 min and still no “Done You can turn off your machine and remove your device”
Thx
Depends on the machine, how the BIOS implements mapping BIOS disk calls to USB devices, and the USB device itself. It can be quite slow if that sort of writing drops to USB 1 speeds on that system.
I suppose your options are:
* Benchmark it on the same kind of system with a smaller amount of RAM installed
* Hack up the msramdmp source to only grab a small portion of the RAM and extrapolate the time for the whole thing from that
* Hack up the msramdmp source to display progress information every so often
Best of luck!
Thanks for the quick reply.
How did you transfer the contents of RAM from the USB stick to a file?
What program did you use to anlyze the data? In other words what program grabbed the AES key?
Thanks Again
msramdmp, for the sake of being small and simple (no USB or filesystem drivers in user-space), makes INT 13h BIOS calls to write to disk.
I haven’t recovered whole-disk encryption keys with msramdmp personally, although I believe others have. I was more interested in other volatile data left by programs running at the time the plug was pulled, such as stored passwords, text, images. I have run tools like daisydukes (for carving out passwords) and foremost (for carving out images), and just picking through manually. I want to see what the new versions of FTK can do, since it now has the capability to analyze memory dumps.
Thanks. Well how do you transfer the contents of data in “partition 40″ to a file so you can analyze
You can dd the partition back to a file, something along the lines of
dd if=/dev/ of=image_filename
You may want to trim the file down to the size of the memory you actually dumped if the target partition was actually larger. Pretty much any other disk/partition imaging software could be used also, I imagine.
Thanks.
Actually, I created a 4GIG partition of type 40 to store the RAM image. I tried to make 2 seperate files to analyze of 2 gig each using dd command:
dd if=/dev/sdb2 bs =1GB count=2GB of=ram.dmp
this worked fine, but to get the second 2gigs
dd if=/dev/sdb2 bs=1GB count=2gb skip=2gb of ram1.dmp did not write any data.
Also I am still looking for a good program to anaylze the memory dump in unix
Thanks for all the help
You’ve got your count= messed up. Count is simply a multiplier for how many blocks of bs= you want to get. If your block size is 1GB, then to get two gigs, your count= should be 2.
In Unix, I would recommend using file carving tools like foremost, specialty password carving tools like daisydukes (did Inguardians publicly release it?), whatever scripts you can conjure up for yourself, or even just “strings”. Someone pointed out Volatility to me last night, and while I haven’t tested it, it looks really great:
https://www.volatilesystems.com/default/volatility/
Thanks for the info you have been really helpful. I downloaded aeskeyfind, one of the tools that the guys from princeton wrote. It searches the RAM and constructs the AES keys from RAM if it finds them. I did not read there full paper in detail though, but they do provide the source code for their application. I used the tool on the results from msramdmp and it found an aes key. However, for my test I encrypted a volume using truecrypt and truecrypt does in fact store its keys in RAM, but I am unable to verify that the AES key I found is the one truecrypt used to encrypt their volume. I am still looking into this.
Thanks Again
Is it possible to use your program msramdmp or modify it so we can load the RAM image to another computer over the network
It would be possible to modify it, I suppose, but it’d be some work getting network code up and going.