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
ADVERTISEMENT
