alt Hacker NewsHey 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!
Replies
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.
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.