Cold Boot Attack Tools for Linux

to:

CFLAGS= -ffreestanding -Os -Wall -I../include 
 ↪-march=i386 -fno-stack-protector

Once the code has compiled successfully, you are ready to install the tools. The procedure is different for the USB and PXE tools. For the USB tool, you need a USB drive that you are willing to erase and that is big enough to fit the RAM you want to dump. In the usb directory is a bootable image called scraper.bin. Connect your USB disk (in my example, /dev/sdb), and then use the dd tool as root to overwrite the beginning of the drive with the boot image:

$ sudo dd if=scraper.bin of=/dev/sdb 
19+1 records in
19+1 records out
9792 bytes (9.8 kB) copied, 0.0101028 s, 969 kB/s

Now the disk is ready. Go to the machine you would like to image, connect the USB drive, and then force a CPU reset or pull and then restore the power quickly. Then, set the BIOS to boot from the USB key. This will vary depending on the computer. On some BIOSes, you will press F12 or some other key to see a list of boot options; others require you to enter the BIOS configuration to change the boot order. In any case, once you boot from the USB key, the scraper tool immediately will start dumping the contents of RAM to the disk. Once it has completed, it will attempt an APM power-off or otherwise will reset the machine. Then you can unplug the USB drive and return to your machine.

You can use the provided usbdump tool under the directory of the same name to dump the RAM from the USB disk to your local drive. Simply specify the USB drive as an argument and then redirect the output to a file of your choice:

$ sudo ./usbdump /dev/sdb > memdump.img
recover segment0 [base: 0x0 size: 653312]
recover segment1 [base: 0x100000 size: 1062993920]

The PXE-based scraper works somewhat differently from the USB-based scraper. First, if you don't already have a PXE server, you need to configure one. That process is out of the scope of this article, but I explained how to set up a PXE server in the article “PXE Magic” in the April 2008 issue of Linux Journal. Once you have a functional PXE server, copy the pxe/scraper binary to your tftp directory and change your pxelinux configuration so that it points to that file.

Next, connect the target system to the network (or if you set up the PXE server on a laptop, just connect the target system to the laptop via a crossover cable). Then, initiate a CPU reset or power off, and then immediately power on the target system. As with USB booting, different BIOSes have different ways to boot from PXE. On some BIOSes, you can press a function key, and others require that you change the boot order from the BIOS configuration.

Once the target machine gets a DHCP address and boots from the network, it will display a status message and then wait for the pxedump utility to connect. Unlike with the USB-based scraper, the PXE scraper doesn't automatically dump the memory over the network. Instead, you need to execute the pxedump binary found under the pxedump directory as follows:

$ ./pxedump target_machine_IP_address > memdump.img

Once you have a dump from the target system's RAM, what can you do with it? Well, one of the primary things you can do is to scan the image for encryption keys. On the same page as the bios_memimage package, you will find tarballs for aeskeyfind and rsakeyfind utilities. To use these utilities, simply extract the source from the tarball and then run make within the source directory. Each source tree includes a README file that describes options with these utilities, but for basic scanning, just execute the aeskeyfind or rsakeyfind binary with the path to the memory dump as an argument. The tools will output any keys they find.

Unfortunately, there aren't a lot of other publicly available tools out yet that can reconstruct other useful information from a memory dump; however, you always can use the strings utility and grep to scan the image for keywords:

$ strings memdump.img | grep keyword

This attack can be very effective, particularly against laptops. That being said, there are a number of limitations to this attack. For one, the machine you attack must be powered on, suspended or hibernated, because the RAM will start to degrade once the machine is powered off. Second, some BIOSes and all systems with ECC RAM will scrub the RAM before it boots an OS. In those cases, you either would have to attempt to disable this scrubbing or chill the RAM and move it to a system that doesn't do any scrubbing.