124 - Cold Boot Attack! - dump a computer's memory to a USB drive
WARNING: Please use this hacker code responsibly!!!
In Episode 521 of Hak5 'Cold Boot Attack', Darren describes the use of a USB drive to save the entire contents of a computers memory (RAM) to a flash drive.
Watch this video for more insight. The original paper (PDF) is available here. Recent 2018 news here and 2015 DDR2\DDR3 video here.
This is based on the work of Princeton University who developed the original code. It is suggested that some RAM retains it's data for several minutes after switch-off and that you can even remove the DIMMs from a system after using freezer spray, put them in another system and then switch it on and save the memory contents to a USB drive!
WARNING: The code in scraper.bin writes to the drive 0 which will be the boot drive - however, if something goes wrong, there is a small possibility that it may destroy all the partitions on your internal hard disk!
It shouldn't go wrong - but it might! So test this on a system that does not have important files on the hard disk, just in case! You have been warned!
I suggest testing on a Virtual Machine rather than a real system first.
Make a dedicated 'scraper' USB drive
You will need a USB drive that is at least as big as the size of the system's memory that you run it on. For example, if the target system has 8GB of system RAM, then you will need an 8GB or larger USB drive.
To make such a USB drive you should...
1. Download the source files (or try GitHub BIOS_memimage 1.2) and compile it to make 32-bit and/or 64-bit versions of scraper.bin.
A pre-compiled 32-bit version of scraper.bin and usbdump has been provided by 'Jamil' - DOWNLOAD is here.
The 32-bit version of scraper.bin will only save a maximum of 4GB of memory.
The pre-compiled 64-bit version of scraper.bin is not available due to compiler issues which we could not resolve (if you have a working version please send it to me!).
2. Select a spare USB drive (the contents of this drive will be destroyed during this preparation process) - it is best to use the fastest USB drive you have, as saving 8GB of memory to a USB drive can take quite a while! A USB 3.0 drive with a fast write speed is good!
3. Select the drive in RMPrepUSB and use the File->Drive button, select the scraper.bin file and a USB start and File start address of 0 and length of 0 (defaults).
4. You should now have a FAT16 formatted USB drive with scraper.bin as the boot code.
Note: if now you put any files on this drive, they will be destroyed when you boot from it, so don't bother adding any files!
To use the USB drive, just boot from it on the target system, it should begin to immediately copy all system memory to the sectors on the USB drive (and destroy any files on it in the process).
Note that the last keyboard characters from the keyboard buffer are also displayed to the user!
When it finishes, it will reboot the system.
You can then use the linux program usbdump (also in the download) to make a file from the data that was collected on the USB drive. This will retrieve the data from the sectors of the USB drive.
What scraper.bin does is write to sector 126 and beyond, so you cannot use this drive to store files on. The actual memory data storage begins at sector 128.
Recently, Jamil contacted me and wanted a way to add scraper.bin to an Easy2Boot multiboot USB drive.
The first problem was how to get scraper.bin to boot directly from grub4dos.
This was achieved by using the following chainloader grub4dos command.
The problem with this was that when scraper ran, it would immediately destroy the filesystem on the USB drive and all the Easy2Boot files!
This problem was overcome by Jamil, by mapping a virtual disk to hd0 and then pretending to boot from hd0 (the USB drive) so that the scraper code saw the virtual disk as hd0.
Even if the size of the target system's memory was larger than the size of the virtual disk, it would stop writing sectors when the end of the virtual disk was reached.
In this way, the contents of the E2B drive (the files, etc.) were protected.
Note: if the USB drive boots OK under QEMU or a VM, but does not boot on a real system, ensure that you MBR\CSM boot (UEFI booting is not supported). If you have a UEFI system, disable Secure Boot and enable Legacy\CSM booting.
If it still does not boot, try creating a small extra primary partition at the very end of the USB drive using EaseUS Home Partition Master. The partition does not need to be formatted and it does not matter if the partition contents is destroyed during 'dumping. of an image. Some BIOSes may need to see two partitions in order to boot from the USB drive.
How to add Scraper.bin to Easy2Boot (or a grub4dos bootable USB drive)
1. Create a Virtual Hard Disk (.vhd) file using Windows Disk Management (click on the bottom pane, then click Action - Create VHD - enter the path of the VHD and size (ensure you have 'Fixed size' selected)
The VHD file needs to be at least as large as the target's system memory. You must specify a destination on your internal hard disk (not the USB drive).
Right-click on the newly mounted VHD in the bottom window (extreme left 'Disk x' box) and click 'Detach' to detach it. We will now have a large .VHD file full of 00 bytes.
Note: The .VHD file is just a large empty file, instead of using Windows to make it, you can use any other method (e.g. dd if=/dev/nul or fsutil file createnew)
2. Copy the large vhd file (it does not need to be 'initialised' or formatted) to the root of your bootable Easy2Boot\grub4dos USB drive.
3. Copy the scraper.bin file to the root of your USB drive
4. Create a .mnu file (e.g. \_ISO\MAINMENU\MNU\scraper.mnu) (this file is in the download) - if using just grub4dos then create a \menu.lst file.
title Capture all RAM (scraper.bin)\n Dumps all RAM to Scraper.vhd file
# hook the BIOS interrupts so the mapping takes affect
# set the root (boot) device as hd0
# copy scraper.bin to VHD (disk 0) - assumes code is smaller than 80Kb
dd if=(hd1,0)/scraper.bin of=(hd0)0+160
# boot to disk 0 as a BIOS would
If you wish, for Easy2Boot, you can move the scraper.bin and VHD file to the same folder as the .mnu file - and then alter the paths in the .mnu file (e.g. map $HOME$/Scraper.vhd (hd0) and ... (hd1,0)$HOME$/scraper.bin )
When you have captured the memory of a target system, you can use the usbdump linux program (e.g. usbdump /dev/sda4 > memdump)
You could just analyse the data in the .vhd file, however, it may be much larger than the amount of memory that you captured and the end of the file may contain data from previous captures.
You can Attach the VHD to your Windows system as a unformatted drive using Windows Disk Management and then use RMPrepUSB - Drive->File button, select the 'attached' VHD drive in the RMPrepUSB Drive List box (you will need to change the RMPrepUSB - Settings to allow Hard Disks to be seen) and specify a USB start address of 128SEC, a length of whatever the size of RAM was on the captured system and a File Start of 0. The Total Memory size is displayed on the screen as scraper runs. Divide this by 512 to get the number of sectors you need to save.
Alternatively, ensure you copy the .VHD file you made using Disk Management on your hard disk to the USB drive each time you are about to use it. The VHD file will contain all 00 bytes.
You can then analyse the data file using the usual forensic\hacker techniques. How you actually do this, I will leave up to you to find out as it is not within the scope of this article!
Note that E2B uses several MBs of memory when it boots to the E2B menu and so the final memory dump will not be as 'pure' as if you used a dedicated 'scraper.bin' USB drive (as described above) and so some of the lower memory will be overwritten by grub4dos and E2B when it boots to the E2B menu system.
Some BIOSes do not support writes to USB devices past 137GB (128GiB). So you should ensure that the scraper.vhd file is within 137GB from the start of the USB drive.
Making sense of the recovered data
You will now need to resort to some linux hacking tools to find out what is in the data file - I leave this bit up to you!
However, one thing you could try is to use PhotoRec directly on the USB Flash drive to try to find recognisable file formats within the memory dump - such as .jpg or .doc files. If it finds any files, it will make a copy of them for you. You can then try to view\load them later to see if they are OK or corrupt.