Cold Boot Attack Tools for Linux

Did you know that RAM doesn't clear the moment it loses power? That it can persist for up to a few minutes if chilled? Learn about attack techniques that take advantage of these facts to uncover encryption keys and break disk encryption.

If you have used a computer for any reasonable length of time, you've learned about the difference between RAM storage and hard drive storage. Besides the fact that RAM is faster than hard drive storage, we also typically think that anything stored in RAM lasts only until the computer loses power, while data stored on a hard drive persists even when the computer is unplugged. Anyone who has lost power while working on a school assignment can attest to the temporary nature of RAM storage.

The Cold Boot Attack

It turns out that what we have learned about RAM isn't entirely true. On February 21, 2008, a paper titled “Lest We Remember: Cold Boot Attacks on Encryption Keys” was released. In this paper, the researchers describe their discoveries about RAM persistence and how they can be exploited. The researchers found that RAM isn't automatically erased when it no longer has power. Instead, RAM degrades over time, and even after a few seconds without power, you still can recover a significant amount of data. They also found that if you chill the RAM first, using liquid nitrogen or even a can of compressed air turned upside down, you can preserve the RAM state for more than 30 seconds up to minutes at a time—more than enough time to remove the RAM physically from a machine and place it in another computer.

By itself, although this discovery is surprising, what's most interesting are some of the implications if RAM contents can survive a reboot. It turns out that a number of common disk encryption tools for Windows, Mac and even Linux all store encryption keys in RAM. With this cold boot attack, if people lock their screens or even suspend their laptops, you could pull the power, grab the RAM contents and scrub it for any encryption keys. Essentially, you could compromise all of the common disk encryption techniques if you had a few minutes alone with a computer.

When I heard of this discovery, the first thing that came to my mind wasn't encryption, but forensics. I've written previously about forensics in Linux Journal [see “Introduction to Forensics” in the January 2008 issue], and in that article, I discuss the debate over how to respond initially when your server has been hacked. One school of thought favors instantly pulling the power on a compromised server. The idea is that you want to freeze the filesystem in place and don't want to risk that the attacker, or even the investigators for that matter, will destroy evidence. The other school of thought believes that pulling the power would destroy a lot of valuable data that exists only in RAM, so one should gather data from RAM first and then pull the power. With this cold boot attack, now you don't have to make that choice. If a server has been compromised, you can pull power first, and then reboot and grab the contents of RAM.

Cold Boot Attack Tools Released

In the paper, the researchers not only outlined the cold boot attack, they also described tools they had created to take advantage of this flaw. On July 16, 2008, the complete source code for these tools was released to the public at In true UNIX style, each of the tools are small and single-purpose:

  • RAM imaging tools: the first set of tools enables you to image a system's RAM. Although you potentially could boot off a rescue disk like Knoppix and then copy the memory, the rescue disk itself will overwrite a substantial amount of RAM. With the provided tools, you have a small executable that you can boot either from a USB disk or over the network via PXE. The USB executable dumps the entire contents of RAM to the USB disk and then powers off or reboots the host. The attacker then can take the USB disk to another computer and use a corresponding tool to dump the memory from the disk into a file. The PXE executable sets up the target for remote control, so the attacker then can dump the RAM over the network to the PXE server.

  • Key-scanning tools: the second set of tools on the site can scan the RAM image you have created for encryption keys. The names of the tools are pretty self-explanatory. The aeskeyfind tool searches for AES keys, and the rsakeyfind tool searches for RSA keys.

Download and Build the Cold Boot Attack Tools

Since the source for all of these tools was released, you can download and use them yourself without too much setup. First, go to, and download the latest version of the bios_memimage tarball, or the efi_netboot tarball if you want to image a machine that boots with EFI. Then, unpack the tarball. For my examples in this article, I use the bios_memimage package.

The bios_memimage package contains a doc directory with good documentation on the project and how to build and use the source. The tools support both 32- and 64-bit environments. Although the 32-bit version technically will work on a 64-bit system, it can't address all the 64-bit environment's memory space, so you might not get a complete image. To build for a 32-bit environment, enter the bios_memimage directory and type make. To build for a 64-bit environment, enter the bios_memimage directory and type make -f Makefile.64.

Note: I noticed when I compiled the code on my environment, the build errored out with an undefined reference to __stack_chk_fail. This is due to GCC's new stack protection. As a workaround, edit the pxe/Makefile file and change the line that reads:

CFLAGS= -ffreestanding -Os -Wall -I../include -march=i386


Kyle Rankin is Chief Security Officer at Purism, a company focused on computers that respect your privacy, security, and freedom. He is the author of many books including Linux Hardening in Hostile Networks, DevOps Troubleshooting and The Official Ubuntu


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Unbelievable. Always a

Anonymous's picture

Unbelievable. Always a problem. Even the author's fix doesn't work. Gotta love the code monkeys who can't explain their own work. It's useless unless other people can benefit from it.

PXE files

Anonymous's picture

There are two files under the "pxe" directory, "scrapper" and "scrapper.bin", i'm assuming one is kernel and the other is init image?

i had the same problem...

RowanH's picture

i had the same problem... apparently -fno-stack-protector-all is not a valid option on my machine.. no idea why and i really don't care that much so long as i can compile.

a quick workaround:-

use an older compiler alongside your existing setup- this is actually useful in many situations,
if your a debian-derivative, e.g. ubuntu:

apt-get install gcc-3.4

make CC=gcc-3.4

hope this is helpful to someone

A MindMap of Same

Mitch Frazier's picture

For those of you that like mind maps: Cold Boot Mind Map

Mitch Frazier is an Associate Editor for Linux Journal.


splashd's picture

I could not get the code to compile, even after correcting t he pxe/Makefile as the author outlined.

I still get the "__stack_chk_fail" message


dm0n7's picture

add -fno-stack-protector to the Makefile in the following sub-directories: stand, pxe, and usb.

It should then compile.