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.
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 colocated keys. TPM and IME would be illegal if they actually worked. lol =3
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!
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.
As for the shim bootloader: it only chainloads signed EFI binaries. To run a custom unsigned bare-metal dumper through it, you would have to use a known vulnerable version of shim (like the one from the BootHole vulnerability) to bypass the signature check for the next stage. It's possible in theory, but adds a massive layer of complexity compared to just using CSM.
Guys, I'm writing using a translator without AI now. Are you happy?
Could you elaborate on this? What device did you test on, what was the test procedure, and what was the outcome?
To clarify, I actually didn't swap the RAM modules to another system. Moving cooled RAM is incredibly difficult and leads to rapid data decay. Instead, I left the frozen RAM exactly where it was on the original board. After the hard power-off, I just quickly swapped the system drive for my prepared drive and booted the same machine back up.
Regarding memory zeroing on boot: that is a highly relevant point. Modern systems (especially with TCG MOR enabled) try to scrub memory during POST to prevent exactly this. However, two things help here:
Fast Boot / Board Specifics: Many BIOSes, including the one on the industrial board I tested (DPX-W250), skip full memory checks and zeroing to speed up boot times.
Hard Power-Off: By cutting power abruptly, the OS doesn't get a chance to set any "clean shutdown" flags. Upon reboot, the BIOS just did a quick POST and handed control to my 16-bit bootloader via CSM, leaving the frozen memory completely intact.
P.S. I'm using AI to translate my messages because I don't speak English. Hope this explains the physics of the attack!
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!
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?)
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!
CSM doesn't magically bypass an active Secure Boot state. Rather, to even boot via CSM, Secure Boot typically must be disabled in the firmware settings beforehand. What I really meant is that by targeting Legacy/CSM, I bypassed the development requirement of writing an EFI application, dealing with complex UEFI protocols, or figuring out how to get a payload signed.
You are also completely right about the initialization sequence. UEFI still runs first (SEC/PEI/DXE phases) and touches RAM before the CSM hands control over to my MBR payload. My 16-bit approach mostly just helps minimize any additional memory clobbering that a more complex, modern UEFI bootloader environment might introduce.
Thanks for keeping me technically honest!
P.S. Still using AI to translate my thoughts!
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!
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.