Hackszine.com: Recover data from RAM after a crash

Recover data from RAM after a crash

After Princeton's cold-boot encryption key recovery hack, I got to thinking about what other useful things might be lying around in memory. It's old news that passwords of logged-in users are hanging out in there, but what about something more useful to the everyday user? What about that file you were editing before accidentally closing its window without saving?

In Linux and on PPC Macs, the root user can access the machine's ram through the /dev/mem device. I'm not sure why this is unavailable on newer Intel Macs—it's a bummer.

In theory, if you're processing some words, spreading sheets, or posting a blog entry and your program crashes, it's likely that the data you were editing will still be in RAM, unharmed, waiting to be allocated to another process. If you immediately dump the entire contents of RAM to disk before starting another large process, chances are good you can find your data again. It's tricky though—writing that RAM to disk requires you start up at least one process, such as dd. It's possible that this new process, or a another process that's currently running, could allocate memory and obliterate your file. You don't really have other options, though, so you might try something like this:

dd if=/dev/mem of=/tmp/ramdump strings /tmp/ramdump | grep "some text in your file"

I found a post by David Keech where he describes exactly this process. He was able to use it to successfully recover the text from a killed vi session:

I tested this by starting vi and typing in "thisisanabsolutelyuniqueteststring", killing the vi process without saving the file and running the command above immediately with a small modification. Instead of piping the output to a file, I piped it to grep thisisanabsolutelyuniquetest. The grep command found itself, as it always does, but it also found the original string, identified by the rest of the unique string that I didn't include in the grep command. You have to be careful when search through running memory. I now remember having this problem with the Mac all those years ago. Whenever I searched for parts of my brother's letter, I would just end up finding the part of memory that contained the search string.

He also mentions scanning the swap partition, which is also a likely place for your data to be found. It's the same process, but you replace /dev/mem with /dev/hda2 or whatever your swap partition is.

Here's the fun part. Based on what we now know about DRAM holding data even a few seconds of being unpowered, you might even be able to use the method to recover program data after a full system crash and reboot. The swap data will for sure be there, but if you reboot into single user mode without starting up X or any large applications, the possibility exists that unallocated areas of /dev/mem will still contain data from before the reboot.

How to recover your data after a crash - Link
Extracting encryption keys after a cold boot - Link

Posted by Jason Striegel | Mar 1, 2008 10:16 AM
Data, Linux | Permalink | Comments (3)

Comments

Newest comments listed first.

Posted by: Jack Johnson on March 1, 2008 at 4:35 PM

Part of me wonders if, like the vi recovery, this could be useful? If you allocated memory with recognizable patterns and built-in checksums, could you recover from a crash with some data intact and automatically pick up where you left off? If you took it further, could you segregate RAM for the OS and RAM for the applications, and use error correcting codes in the application space to facilitate a recovery?

Posted by: xSmurf on March 2, 2008 at 12:30 PM

Under Intel Macs (and probably other platforms) you can do something similar if you have deep sleep "hibernate" enabled. Using pmset -g hibernatefile will spit out the path of the file used to store the RAM's content on hibernate. That file is never whiped until the next hibertante. Run strings over it to have a nice list of all the strings it contains! Note that the file has a permission mask of 500.

Posted by: on May 23, 2008 at 5:29 PM

This doesn't work on some Linuxes. See http://ubuntuforums.org/showthread.php?p=5029123