Cold Boot Attack Tools for Linux
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.
Kyle Rankin is a VP of engineering operations at Final, Inc., the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal. Follow him @kylerankin.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- SourceClear Open