Cold boot attack. Dumping RAM with a USB flash drive

Imagine that you have to leave your computer or laptop unattended for 10-15 minutes (to make a phone call, or have a snack, etc.). Being a diligent user, you lock your PC. You even have an encrypted HDD or SSD, a strong login password, and all the required updates installed. Everything seems to be fine. But is your information really safe?

Now take on the role of an attacker. The first and easiest trick you can perform when time is limited is to connect directly to the target PC using a twisted pair cable. To do this, you don’t even have to be logged in. As a result, you get a network communication channel that potentially enables you to hack the target computer in one of the following ways:

• exploiting vulnerabilities (MS17-010, BlueKeep, PrintNightmare);
• NetBIOS/LLMNR spoofing (Responder);
• brute-forcing (SMB, RDP); or 
• MITM (Evilgrade, BDFProxy, MS16-101).

Each of these methods deserves a separate review, but this is beyond the scope of this article. I assume that the target system is up-to-date (i.e. has all the required updates installed), and the login password is strong enough.

The second attack vector involves hibernation. In the hibernation mode, the hard drive isn’t used; only RAM is powered. So, you can remove the hard drive and connect to it directly (e.g. using the device shown below).

In most situations, this would suffice. If you are dealing with an unencrypted HDD or SSD, you can access all documents and files (including system files), extract passwords, etc. Having a direct access to the disk, you can not only passively read data from it, but make changes as well. In theory, you can reset the password, reconnect the disk to the computer, and successfully enter the user session by pressing the Shift key five times:

I am not going to describe this scenario in detail since it is quite simple (although there are some nuances). But today my goal is to hack a PC with an encrypted disk.

The third attack vector available to you is so-called “cold boot attack”, and this article is dedicated to it.

Cold boot attack is a well-known technique making it possible to gain access to RAM using the memory retention effect. It’s achieved through so-called “cold boot”: a reboot that doesn’t involve software (i.e. a hard reset).

Why without software? Because a soft reset will close all processes and files mapped in RAM and even forcibly clear it. That’s why, to retain all valuable data in memory you have to reboot the target PC on our own, without involving the operating system.

You can perform such a reboot in the following ways:

• push the power button to turn power off and back on (very quickly);
• perform a hard reset; or 
• induce the Blue Screen of Death (BSOD).

If you use any of the above-listed methods, the OS won’t have time or won’t be able to overwrite data in RAM before rebooting. And if you plug a bootable flash drive, then control can be passed to it, thus, enabling you to execute the boot code and read that unerased memory.

Additional problems arise if you are dealing with a laptop. First, very few modern laptops are equipped with a separate hard reset button. Second, modern laptops often don’t have removable batteries (i.e. you cannot remove the battery for a short time). In such a case, you can try to force a reboot by inserting a USB flash drive with a purposively damaged file system that will induce BSOD.

You can download and write such an image on a USB flash drive as follows (assuming that you use Linux and Git is installed):

Important: you don’t have a room for error since data stored in RAM can be lost (although the modern Windows version can restore the state of RAM from the hibernation file).

In extreme cases, there is another option: remove and cool the DRAM/SRAM memory boards and plug them into another motherboard. However, it’s much more complicated technically and cannot be implemented quickly since you have to open the computer case… Therefore, the best variant is a bootable flash drive since almost all computers have an open USB port.

All the required primitives (i.e. reading physical memory and direct writing to the hard drive) can be taken from the following code:

If you compile this code and place it at the very beginning of a flash drive or disk, then BIOS will execute it as boot code:

If the target computer has a classic BIOS, the boot code is executed in real mode (16 bits), and the memory is accessed by physical addresses. The address of readable RAM is specified in the ES:BX register pair. The BIOS interrupt 0x13 is used to get write access to a hard disk or flash drive (in fact, it acts like an API for BIOS). The code is executed, and the contents of 512 bytes of RAM are copied to an HDD sector. In theory, if you loop this piece of code, you can read the entire RAM.

Don’t be afraid, you don’t have to write any more code in the assembly language. There is a handy tool created specifically for this attack. And, as you may have guessed, all you need to deliver a cold boot attack is a simple bootable flash drive.

Preparations

Let’s prepare an attacking bootable USB drive that will dump RAM into an unallocated space. This way, the file system (FS) of the flash drive won’t be damaged:

Contents of the bootloader configuration file menu_sec_part.lst:

This configuration implies that RAM contents will be saved directly to the additional partition on the flash drive bypassing the file system. In fact, using the GRUB boot manager, you can create a virtual disk from a file. This provides convenient access to the dump in the form of a file on the USB drive. No doubt, this approach is more correct, but it’s not that easy to create a large unfragmented contiguous file on modern file systems… On FAT32, you simply cannot create a file larger than 4 GB; while on NTFS, a service MFT describing files will be located exactly in the middle of the partition, and if you write a dump on such a virtual disk, you’ll overwrite your FS. Therefore, I recommend the classic variant: RAM is dumped to a partition, not to a file.

Exploitation

You don’t necessarily need automatic boot from a USB flash drive to be enabled on the target computer. Many BIOS versions make it possible to select boot media by pressing the F8 (or similar) key. But even if not, you can always enter BIOS and change its settings.

The attack takes some time and looks pretty innocent: you simply plug a USB drive. While the user is away, sensitive data are steadily leaked from target’s RAM to the attacker’s removable media. The picture below shows this process.

Once the attack is complete, an exact copy of target’s RAM will be saved in the second partition of your flash drive (/dev/sdb2). For convenience purposes, let’s convert it to a file:

In my case, the dump was slightly shifted (by 0x53000 bytes), but this can be easily fixed:

Congrats! You gained access to RAM at the time of hard reset, and all the secrets kept in it can be easily uncovered now:

Using the signature approach (i.e. knowing certain keywords such as Password, Secret or Cookie), you can search the contents for sensitive data. For instance, you can search for RSA keys (and potentially, photos, PDF documents, archives, etc.) based on signatures that most files have.

The next picture shows what was running on the victim PC before it was locked down and attacked.

After the attack, the entered string will be stored in memory of your PC.

But your capacity is not limited to signature-based data extraction from RAM! The obtained memory dump also contains OS structures that enable you to restore the chronology of events in the target system before the hard reset.

You have probably noticed that, to implement such an attack, you must run the code stored on the bootable flash drive on the target PC; as a result, some areas in its memory become overwritten. It was found experimentally (through byte-by-byte comparison of RAM contents on virtual machines at respective stages) that bootloaders overwrite not that much memory.

Below is the number of bytes in RAM to be overwritten at various boot-up stages:

• bootmgr (Windows 7, 10 bootloader) – 5,157,389 bytes;
• GRUB 2 (Linux bootloader) – 8,219,883 bytes;
• burg (alternative Linux bootloader) – 9,599,333 bytes; and 
• liveOS for forensics – 171,944,965 bytes.

The boot-up code from Coldboot-Tools used to dump memory to your disk uses some 95 KB of memory. In total, the entire GRUB4DOS + scraper64_haltonly.bin chain will overwrite 820 KB of RAM – while the total amount of RAM in modern computers reaches tens of gigabytes.

Still, even a few megabytes overwritten in the wrong place can disrupt important structures and make it impossible to restore the state of the OS. Using Windows 7, it was empirically found that the first 100 MB of RAM contains not much data, and only 5-15-MB and 105-110-MB areas must never be overwritten since this can destroy important data structures required to analyze the state of the OS.

In reality, memory dumps obtained using GRUB4DOS + scraper64_haltonly.bin are suitable for analysis. All changes in RAM occur at the very beginning, while the OS itself is stored after the first 100 MB, which virtually eliminates the risk to overwrite it. The dump entropy shows the general layout of data and gaps in RAM.

Therefore, you can use forensics to upgrade the simple signature-based dump analysis approach to a more advanced one. This advanced approach makes it possible to extract tons of important information.

Extracting secrets

Using well-known forensic tools, such as Volatility or Rekall, you can learn a lot about the state of the OS at the time of your intervention. The process list is an excellent demonstration that you are on the right track.

For instance, you can determine the location of registry files in RAM and extract password hashes for local accounts from them.

The same operation can be performed for domain accounts to get passwords in plain text:

Then you get the list of open files and their contents, network connections, clipboard, and even a desktop screenshot:

And so on, and so forth… Basically, everything is similar to a standard forensic research.

EFI

A distinct feature of the cold boot attack is that it’s effective mainly against computers with a classic BIOS.

Using EFI from different manufacturers, it was empirically found that immediately after a reboot, random bytes are written to the entire RAM in the course of the initial equipment initialization, which fully protects users of modern PCs with EFI from such attacks.

This can be easily checked using the above-mentioned GRUB4DOS bootloader. It uses special commands to read/write arbitrary RAM sections. For testing purposes, you can find any address in memory, examine its contents, and remember them:

Then you overwrite it, for instance, with the word test, and reboot:

GRUB4DOS doesn’t overwrite memory during a reboot; so, this method is identical to a cold boot.

Finally, you check whether EFI has overwritten the test memory section, or your data in RAM remain intact after a reboot. In my case, the memory was changed. Tests were performed on HP and Lenovo laptops. Still, the memory scrapper tool is available for EFI as well.

Conclusions

As you can see, all data stored in RAM are open, and the above-described attack enables you to bypass full disk encryption – even on a locked computer! In other words, you can attack computers protected in compliance with workstation security standards adopted by most companies, not to mention home computers.

Even though computers with a classic BIOS are gradually becoming history, plenty of old desktops are still used in the corporate segment where large-scale equipment replacements cost a lot of money. In addition, modern motherboards with EFI still support the old legacy BIOS mode, which makes them vulnerable to this attack. Good luck!