BareMetal RAM Dumper – Bare-metal x86 tool for Cold Boot Attack experiments

https://github.com/pIat0n/BareMetal-RAM-Dumper

by liffik • 18 days ago

72 44 18 days ago

liffik11• 18 days ago

Hey security researchers!

I've released BareMetal-RAM-Dumper — a low-level x86 utility for dumping physical RAM directly to disk, designed for Cold Boot Attack research.

What it does: • Custom 512-byte bootloader (no OS needed) • Boots via BIOS Legacy CSM • Switches to Unreal Mode to access 32-bit physical memory • Dumps RAM in 32KB chunks directly to USB drive • BIOS INT 0x15 E820 for safe memory map parsing • Real-time progress indicator

Cold Boot Attack Use Case: Freeze a laptop's RAM to -60°C → quickly reboot from USB → capture full memory contents for forensic analysis & crypto key recovery

How it works: 1. Stage1: 512-byte boot sector (loads Stage2 via INT 0x13) 2. Stage2: Main logic (memory detection, unreal mode, disk writes) 3. Writes to LBA 64+ on boot drive

Warning: This overwrites data starting at sector 64! Use a dedicated blank USB.

Built with pure Assembly (NASM) — no bloat, direct hardware access

GitHub: https://github.com/pIat0n/BareMetal-RAM-Dumper License: AGPL-3.0

Perfect for: Forensic researchers Security auditors testing cold boot resilience Students learning low-level x86 Penetration testers

Feedback & improvements welcome!

saidnooneever2• 18 days ago

interesting stuff, never tried this specifically. you could try to adapt it to uefi too, edk2 is tricky to work with but not too hard to do it.

it might make it more easy for ppl to play with since most modern machines dont come with BIOS anymore.

uefi might trample more ram during its init but its not a lot of memory.

liffik11• 18 days ago

Good point! I originally went with Legacy BIOS because 16-bit boot support is historically enabled by default on the vast majority of target machines out there. It keeps the bootloader tiny and hardware access as direct as possible. However, as CSM is virtually dead on the newest hardware, adapting it to UEFI is the inevitable next step.

skrellm• 18 days ago

Hi dev,

Warning: This overwrites data starting at sector 64! Use a dedicated blank USB.

This would be much more usable if you'd put a file system on the USB stick with a sufficiently large, empty, bianco file.

Note, you don't need to implement a file system driver. Just create it with a big enough file and use that file's starting sector instead of 64. You could even update the file's size with the data written (just one more sector write, and again, you don't need to interpret the file system, just patch one integer in a sector).

I'd recommend ext2 (FAT is not good, because it limits files to 2G, and exFAT is in patent hell). Create with mkfs.ext, add a large file with dd, then save the data as a bunch of "db" lines into your asm source. You'd then assemble the file system along with stage1/2 without the need to interpret what you're writing.

Oh, one more thing: some BIOS checks the first bytes of the boot sector as well (not just the last two bytes), so you should start your boot sector with a short jmp and a nop. Also it's not guaranteed that direction flag is cleared, add a cld after cli.

To get some ideas, here's a boot sector that loads an EFI PE/COFF executable from a FAT file system (without interpreting the fs), sets up long mode and executes it:

https://gitlab.com/bztsrc/easyboot/-/blob/main/src/boot_x86....

(Notes: written for the flatassembler, which uses a very very similar Intel syntax like nasm, and the 2nd stage EFI executable is written in C very carefully so it doesn't matter if it's loaded by this boot sector on BIOS or by the UEFI firmware, the same binary just works everywhere.)

As for developing EFI apps, I don't use EDK2, because it's messy and bloated, instead I've written my own UEFI SDK: https://gitlab.com/bztsrc/posix-uefi it's much easier to use, you might find it useful too.

liffik11• 18 days ago

Thanks for the incredibly constructive feedback! This is extremely helpful.

The jmp short + nop header and adding the cld instruction are excellent points. I will add those to the bootloader right away to ensure better BIOS compatibility and stability.

The pre-allocated dummy file trick on ext2 is a brilliant way to have a mountable filesystem without the overhead of writing a filesystem driver in Assembly. That solves the "overwriting arbitrary data" issue elegantly.

I will definitely look into posix-uefi. EDK2's bloat and memory footprint were my main concerns for the UEFI port, so a lightweight SDK is exactly what I need.

P.S. I use a translator to write this because I don't speak English. I really appreciate you taking the time to share these technical pointers!

Retr0id6• 18 days ago

successfully tested

Could you elaborate on this? What device did you test on, what was the test procedure, and what was the outcome?

liffik11• 18 days ago

Sure! The testing was conducted on a specific industrial x86 board (DPX-W250 Rev. A1). I won't go into details about the exact equipment it came from, but it provided a perfect bare-metal environment for this research))))

The testing procedure was a classic physical Cold Boot Attack:

Froze the RAM modules while the target system was fully operational.

Performed a hard power-off.

Quickly swapped the original system drive with my own prepared drive containing the BareMetal-RAM-Dumper.

Powered the system back on and booted directly into the custom bootloader via Legacy BIOS.

The result: Absolutely successful. The dumper immediately took control, switched to Unreal Mode, and successfully dumped the raw physical memory directly to the disk without any OS interference or data trampling.

P.S. I'm using AI to translate my messages because I don't speak English. Hope everything is clear!

ranger_danger• 18 days ago

Not the author, but this is an extremely simple tool that is not written with any device-specific code... it should work on most any x86-based PC device (plain BIOS or a UEFI system with CSM support enabled).

liffik11• 18 days ago

Right

Retr0id6• 18 days ago

The code in the repo is trivial, that's not really what I was referring to. Getting DRAM cooled and swapped from one system to another is nontrivial, and I assumed most hardware/firmware zeroed memory on boot (to prevent being used to cold-boot-attack itself, without even needing a ln2-cooled board swap.) Those are the interesting aspects, not the code!

Dwedit2• 18 days ago

Does it stop EFI from running first? I'd think that EFI would be clobbering a whole lot of RAM.

saidnooneever2• 18 days ago

this will work on BIOs systems and possibly systems with CSM mode which emulate legacy BIOS in efi.

UEFi has a different interface, not IVT to make BIOS calls and no code to catch them. you would use raw disk access protocols its really easy maybe even easier once u know how to use handles and protocols in uefi to implement this for uefi.

the problem then becomes secureboot, which if enabled will be bypassable only via misconfigurations or exploits. it would refuse to from the usb or an alternate disk image when set up correctly and no exploits are known by the dumper.

for that reason there's i think attacks that can be done by removing the ram sticks and sticking them into specialized device to dump it.

theres some tutorials on how to connect ram sticks to breadboards etc. , but idk if theres other details besides raw talking to the ram and dumping it that would make it less reliable. (not sure how long bits are retained, usually ud wanna reboot and instant dump afaik if its totally off for a while its unrecoverable but i am not really sure on that last part. (so removing it to seat them in another device might make bits decay and data less reliable?)

liffik11• 18 days ago

Spot on! That is exactly why I chose the legacy 16-bit method via CSM. It was a deliberate design choice to completely avoid the EFI bootloader and, consequently, bypass Secure Boot entirely.

By relying on Legacy BIOS, the system doesn't check for signed EFI binaries or block the custom boot drive. It drops directly into the 16-bit real mode, allowing me to do the job without dealing with UEFI handles, protocols, or security restrictions. It essentially eliminates the need for any exploits or moving physical RAM sticks to specialized breadboards!

P.S. I'm using AI to translate my messages because I don't speak English. Hope my point is clear!

Dwedit2• 18 days ago

Anyway, to get access to RAM before it is clobbered by other software, you need to run your code really really early. By the time the BIOS has decided to let you run code from a USB stick, it could be way too late.

RAID cards have option ROM that can run before a bootloader has started, that is one way to get something running earlier.

anyaya1• 18 days ago

DevTool ecosystem

floralhangnail4• 18 days ago

Are there any tricks or guides out there to protect from this attack? Obviously not leaving hardware running and unattended, but what else can help protect you if your running laptop is stolen out of your hands? Workstations can be configured to shutdown upon intrusion switch being activated but what about laptops? I guess hot gluing the RAM in would be a physical obstacle. What about a BIOS password being required for booting from external media or having secure boot enabled? There are exploits to bypass those things, but to an attacker not finding out they are up against that until they reboot, I would hope that would slow them down enough that they fail. If half of or all of the RAM is mounted under the keyboard, I think they would have difficulty getting it out in time. Besides spraying the RAM directly, can you freeze an entire laptop while it's still running? Won't condensation cause problems pretty quickly?

Retr0id6• 18 days ago

Hardware memory encryption, with key randomly generated per-boot within the memory controller.

liffik11• 18 days ago

@Retr0id is absolutely right. Hardware-level memory encryption (like AMD SME or Intel TME) is the ultimate silver bullet here. The encryption key is generated by the CPU/memory controller per-boot and is lost the moment power is cut, making the RAM contents useless even if frozen.

To answer @floralhangnail's questions from the perspective of how my dumper operates:

Removing RAM vs. Rebooting: My tool actually doesn't require removing the RAM sticks at all! The attack involves freezing the RAM in place, performing a hard power-off, quickly swapping the main system drive with my prepared USB/drive, and powering back on. So physical obstacles like hot-gluing the RAM or hiding it under the keyboard won't stop this specific reboot-based attack.

BIOS Passwords & Secure Boot: You nailed it—these are your best practical defenses on standard hardware. If a BIOS password prevents booting from external media, or if Secure Boot blocks my unsigned 16-bit bootloader, the time it takes to bypass them means the RAM bits will decay. This is exactly why my dumper targets systems with CSM/Legacy BIOS enabled and boot options accessible.

Condensation & Freezing: You don't freeze the entire laptop. You open the bottom cover and spray inverted canned air (-60°C) directly onto the memory modules. Condensation definitely happens and will eventually short the board, but the hardware usually survives just long enough (the few minutes needed) to complete the raw memory dump to disk.

P.S. I'm using AI to translate my messages because I don't speak English. Hope this clears up the physical attack vector!

memoriyato32• 18 days ago

for SecureBoot you could use the Linux shim bootloader, to boot your stick, or a tiny Linux that runs your code, right?

floralhangnail4• 18 days ago

Excellent info, thank you.

I still think with laptops that have 2 RAM sticks under the bottom cover and the other 2 sticks underneath the keyboard, the spray can attack would be trickier. I assume though it's possible the attacker can keep the laptop running while the palmrest and keyboard are being disassembled. If the attacker cannot freeze all sticks of RAM though, would the attack be less likely to be successful? Would the disk encryption key be spread across all RAM sticks, or possibly just one?

I will look more into the hardware memory encryption as suggested.

WJW• 18 days ago

I'm not an expert but why would a sufficiently sophisticated attacker not be able to extract the key from SME/TME type hardware protections? I'm thinking about government type attackers who can do extremely sophisticated things to hardware in a lab, not hobby type people.

nh2• 18 days ago

When I asked about this 5 years ago, I was told that for many processors you can still just JTAG them and get everything:

https://security.stackexchange.com/questions/189950/how-does...

Has this changed?

masa-kozu• 18 days ago

Just as a side note, memory encryption isn't limited to niche secure hardware anymore. Mainstream x86 CPUs have supported it for years: AMD has SME/TSME (and SEV on the server side), while Intel provides TME/MKTME. The memory controller transparently encrypts DRAM contents with hardware-managed keys, so protection against physical memory extraction attacks is already available on many ordinary PCs and servers.

memoriyato32• 18 days ago

on AMD/Intel CPUs from the last 5 years you just need to enable hardware memory encryption in the BIOS

Joel_Mckay2• 18 days ago

Encrypted MMU were very common on enterprise hardware at one time.

Now, memory can be cryogenic spray treated (upside-down air-duster) and removed within a minute... the content can be reader dumped for key recovery. This is why systems are bolted to the floor, and locked. It buys time to armadillo a system, and lock the SMART power-cycle tamper detection.

With physical access it is almost impossible to block forensic recovery with collocated keys. TPM and IME would be illegal if they actually worked. lol =3

3eb7988a1663• 18 days ago

Have the laptop continually monitor the physical environment - if anything abruptly changes, system automatically locks. If a decryption key is not provided after X seconds, force a reboot.

Something like bluetooth beacon paired to discreet BLE jewelry, WiFi signals -if the paired connection suddenly disappears, newly inserted human input devices (mouse jugglers to disable screensavers), unregistered face-detected, minimal gryoscope add-on looking for sudden velocity change, etc

All of these carry significant usability trade-offs, so probably only worthwhile if you are running the Silk Road and actively hiring hitmen.

floralhangnail4• 18 days ago

Think I may have to give USBKill and BusKill a try.

himata4113• 18 days ago

I just run everything thru a remote controlled power socket so I can remotely shut down everything and also (unintentionally) realized that I can detect when the my case is opened by observing temperature on one of the motherboard sensors so I thought about making that trigger a shutdown. My laptop shuts down power when opened as a feature already.

wmf2• 18 days ago

Haters, please stop flagging liffik's comments. I know you don't like AI but this thread was legitimately upvoted onto the front page so at least let the author respond to people.

Retr0id6• 18 days ago

The code in the submitted repo is trivial and could be oneshot by an LLM, even if it wasn't. The potentially interesting thing here is what OP was able to achieve with it, and we're only getting pasted LLM output for that, which isn't very interesting.

liffik11• 18 days ago

Guys, it’s just easier for me to communicate via AI because I don’t speak English I’m using a translator right now. Everything I described (including the AI part) is real, and the method works too; I’m just lazy. I used this software on some specific hardware I won't say what kind—but it works perfectly.

Joel_Mckay2• 18 days ago

Threadlocker red, checkmate... lol =3

alfiedotwtf2• 18 days ago

Phew! Luckily I store all my keys at the 5Gb mark!

BareMetal RAM Dumper – Bare-metal x86 tool for Cold Boot Attack experiments

Related Stories