Integrating msramdmp into your existing USB toolkit
I’ve been in email contact with a gentleman that’s wanting to get msramdmp integrated into his incident response USB toolkit. Here’s some of my thoughts on how one might could accomplish that, straight from my response to him:
To keep this thing very-low-footprint, it runs straight from the bootloader and accesses the disk directly through INT 13h bios calls. To reduce complexity and footprint, it doesn’t know anything about filesystems, and simply dumps memory to a partition, marked with a specific type (0×40).
You could probably get this working on your drive with this kind of partition layout:
- Primary 1: Very small FAT-16 partition, marked bootable – Install syslinux to this and put msramdmp on it like I discuss on my howto.
- Primary 2: The partition you keep all of your tools in, whatever filesystem, however you want it.
- Primary 3: A 2 to 4 gig msramdmp (type 0×40) partition, large enough to hold an image of RAM of any machine you plan to dump.
Between using it on different machines, you’ll want to mark the partition type back to 0×40 (msramdmp marks used partitions as 0×41), and zero it out with dd.
I haven’t tested this out, but there’s no reason this shouldn’t work, assuming you have a large enough drive to comfortably do it :)
I tried your msramdmp tool last night. It had a lot of data, but there were random bits flipped. I used my laptop and only turned it off for under a minute. My laptop is kind of old. Is that normal, or do newer machines keep the state of their ram longer. I can’t see how useful this would be for anything that wouldn’t be intuitive by just looking at it. One thing I was able to see was a partial list of URL’s from firefox.
To answer your question, it is normal for it to degrade like that over a short time period. If you take a look at the Princeton paper, you’ll see a cool demonstration of how a bitmap image in memory will sort of “dissolve” over time without power.
Different computers will hold state for wildly varying times. Many will only hold state for about 10 seconds or less without having to be cooled down with something cold (like r-134a propellant in a air duster can). On the other hand, some computers hold it for a long period of time. One my laptops went 10 minutes with very little degradation. I haven’t really noticed any correlation between the age of the computer and the amount of time it holds.
If you want to recover things beyond “just looking at it” type stuff, I would recommend treating the image like you would treat a hard drive image with a screwed up partition table/filesystem metadata. You’ll have to carve it out based on known structures of what the headers/footers/other-characteristics of the data you’re looking for. Some of the same tools work for this, like AccessData’s FTK, and open source tools like photorec and Magic Rescue.
n00b question I’m sure but how do you mount/read the Venix filesystem? I was successful in building the USB drive, booting from it, and dumping memory to it, but I don’t seem to be having any luck reading it. Thanks in advance for any ideas you might have.
Thanks for posting, Parker!
Venix/PPC Boot are just labels that cfdisk/fdisk are associating with the partition types I’m using. 0×40 and 0×41 were chosen somewhat arbitrarily, mostly trying to avoid partition types that are more common. Venix, in particular is an old Unix derivative that ran on 286′s, so I don’t think I’ll see many complaints from that camp.
So, it’s not a Venix filesystem. In fact, it’s not a filesystem at all. msramdmp is simply copying memory byte for byte into the partition you create. There’s no filesystem metadata there that would allow you to mount it–it’s just going to be a block of data.
To get the image of memory, use dd:
dd if=/dev/whateverdriveandpartition of=memory.dd
(you might want to set a blocksize, count, etc, too, but the above should get you started)
Thank you for your reply. I was able to dump an image of what I extracted. Now it’s on to figuring out what to do with it. Thank you for your time!
Okay, last question, I promise. :) I know I’m missing something here so I thank you in advance for your patience. How do I view the dumped data (either directly from the partition or from an image file)?
To view the ram, use dd of=/dev/sda2 if=/path/ram.dd and then you can open the file with a hex editor. -Jesse Varsalone
New question. Is there a tool I can use to extract the key from ram?
Hi Jesse!
I haven’t been able to do a lot with key extraction, since this is only a side-project for me, and I don’t have any of the commercial encryption products to test with. I have done some experimentation with dm_crypt, with some information that I found in this paper:
http://events.ccc.de/camp/2007/Fahrplan/attachments/1300-Cryptokey_forensics_A.pdf
The technique in that paper tries to find the key by looking for characterisics of the struct that it’s in. I got so far as getting the code from that to compile, however it did not manage to find the key. Either something that I did to get it to compile managed to foul things up, or possibly newer versions of the kernel have a different struct. The next step would be to dive into the kernel source, see what the struct actually looks like, and perhaps encrypt a volume with a known key just to verify. I haven’t gotten around to this yet, but I may soon. Feel free to pick up there if you’d like, though :)
Note that if you think that the key is contiguous in memory, you could write a script to try all the possible keys by sliding a key-sized window across the dump. You could probably speed it up a bit by only trying possible keys with a certain amount of entropy. It’d still probably be the sort of thing you keep running for a while, but doable.
Thanks for the note!
i was wondering, why is it not possible to dump RAM while the OS is running? maybe use firewire on the same system?
Have you guys looked into the tool memdump? I tried it but did not really work with me specially with the -m parameter.
Also, on that paper you mentioned, there is a program that lets you scan keys on an RAM image, have you tried it? it wont run with me… anyone got it to work??
Lastly, which hex editor do you prefer the most for reading memory images from msramdump?? thanks.
Thanks for the comment Security_first.
Yes, it is possible to dump the memory of a live system with firewire, which may or may not be configured to allow DMA to the entirety of main memory.
There seem to be several tools, all by the name of “memdump”. I have used the one in The Coroner’s Toolkit some years ago, and I recall using a windows one at some point. Not sure what sort of problems you might be running into, unless it’s a matter of running it as a user with the appropriate permissions to read memory.
I haven’t been able to get the program in that paper to work either, however I’m currently playing with another set of scripts by the Intelguardians. I’m hoping to integrate some of that functionality into msramdmp to make the dumping faster/more-focused in certain situations.
When I am reading and extracting things out of msramdmp images, I typically use dd piped through xxd to examine things by hand, the strings command to view printable strings, and forensic tools such as foremost to carve out things I have a signature for.
Happy hacking :)
Thanks for your reply.
- I just tried out msramdump tonight, it booted from syslinux, I got pass the point where it says: Writing section from 0×00000001 to 0x0008FFFF, but then I got stuck at: Writing Section from 0×00100000 to 0×80000000 for over 10 minutes. I dont think it should take this long to dump it. How long did it take you? I have 2 GB of ram though. or maybe its my
USB key that is faulty.
- As far as the program in that paper, in what language is it written? C? I think maybe its just missing couple lines i
n the beginning…
- Where are you going to post any updated versions of msramdump??
- I did not get this point: “I typically use dd piped through xxd ” –> can you please explain a little more? specially
the “through xxd” part.
- I also found out today that the new OS X from MAC does not have /dev/mem and or /dev/kmem. I guess that should not ma
tter as far as booting from the USB key, correct?
thanks and good luck with the new versions of msramdump.
UPDATE:
My memory dump file was 326 MB from /dev/sda2.
I found and installed many programs for reading the dump files from memory, including: tweak, bless (with GUI), hexcurse (within terminal), and others.
So far I really like Bless, its a GUI for opening, reading, searching memory dump files (with hex, decimal, binary, etc searching) and much more. If you have Debian, just do apt-get install bless and you are set.
I guess at this point, the easiest way is to know the password pattern of passwords in HEX form within dm-crypt (and other programs) and manually search for it.
If it does not bother the admin, I can post updates and discvoeries as I proceed with this mini-project :)
I’m not sure why you only got 326 megs in your dump from a system with 2 gigs of RAM. Did you set the partition size of the msramdmp partition large enough? I haven’t personally dumped a system with 2 gigs of RAM with it, but I have dumped systems with 512 MB, and other users have dumped more.
The issue with using msramdmp on a Mac (at least an intel based one) doesn’t have much to do with OS X, actually. The issue is that the newer Macs use EFI instead of BIOS, so a msramdmp-alike on a Mac would likely need to make its disk-writing calls via EFI calls instead of BIOS. Maybe there’s some BIOS emulation that could be used to coax msramdmp to run, but I haven’t really looked into it.
Speeds have varied *wildly* for different users. I was worried when my first test laptop took 20+ minutes to dump 512 megs, but I’ve heard everything from a few minutes all the way up to my worst case from other users. I think it depends heavily on how your laptop handles BIOS access to USB devices, and the USB device you are using. In some situations, you may only be writing at USB 1.1 speed.
With xxd, I mean taking the section of memory I want and looking at it with a command line like:
dd if=image.dd of=- skip= count= bs=1 | xxd | less
I got into the habit of viewing hex like this after working through sections of Carrier’s “File System Forensics”.
New versions of msramdmp will be released on the project’s website on here (/projects/msramdmp) and an announcement will be posted to the blog. Hopefully, at that time, I’ll come back on the PaulDotCom Security Weekly podcast to discuss the new signature-based dumping functionality.
Please keep posting! Very interesting to hear about people’s results. Dumping and analyzing images of live memory isn’t a well-travelled/documented activity :)
Syslinux needs a drive formatted in FAT16.
CFDISK only makes a partition doesnt actually format.
you need to use this command on the partition after you’ve made it.
sudo mkdosfs -F 16 /dev/sdd1
Yes, that’s actually covered in the documentation for msramdmp located here:
http://www.mcgrewsecurity.com/tools/msramdmp/
hi
i have dumped 512 mb of ram on 2gb usb flash drive in approximately 15 min.
for new users i would like to tell if they are getting some problems in compiling syslinux then try installing few libraries using command:
apt-get install mtools lilo nasm libc6-dev netbpm
One other thing if some one wants to try dumping tools are also available at Princeton univ. link
including both pxe boot & usb boot:
http://citp.princeton.edu/memory/code/
do you have any idea regarding extraction of keys form memory dump..????
hi
after viewing the strings in hex editor i didnt get any kind of significant results i wanted.
have you tried this by performing cold boot.
i have dumped512mb of ram on 2gb usb in 15 min.
do you have idea regarding pxe boot instead of usb.??
HI WESLEY
I NEED YOUR HELP FOR COMPILING MSRAMDUMP.
I AM USING UBUNTU & IT DOESN’T HAVE CONSOLE.H & COM32.H.I HAVE TRIED INSTALLING MANY PACKAGES BUT IT IS NOT WORKING,PLZ TELL ME VAT PACKAGE DO I NEED TO INSTALL.
PLZZZZZZZZ… HELP
how are you compiling the syslinux tarball after you have extracted it?
At the start of my dump I see the following plaintext, any ideas whats going on?
Missing operating system.
f
Multiple active partitions.
f
Operating system load error.
MSRAMDMPC32
I FAT12
Boot error
SYSLINUX 3.75 2009-04-16
Load error –
tg<
tZ<
tf<
It appears your computer has less than 256K of low
RAM. Linux needs at least this amount to boot. If you get
this message in error, hold down the Ctrl key while
booting, and I will take your word for it.
Invalid image type for this media type!
Could not find kernel image:
Invalid or corrupt kernel image.
Loading
Cannot load a ramdisk with an old kernel image.
Could not find ramdisk image:
: attempted DOS system call INT
COMBOOT image too large.
aborted.
complience:
The parts of syslinux that are used in the instructions here are already compiled in the tarball.
complience:
msramdmp dumps the entirety of memory, including msramdmp, syslinux, and all of their strings and messages :)
er.,. so its not an error i need to worry about then?