[floralhangnail]

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?

[Joel_Mckay]

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

[Retr0id]

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

[3eb7988a1663]

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.

[floralhangnail]

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

[himata4113]

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.

[memoriyato3]

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

[liffik]

@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!

[floralhangnail]

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.

[nh2]

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?

[WJW]

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.

[XorNot]

You've got to actually get the hardware to a lab.

And then put it through some type of process without losing state: the question is very much, how? There aren't a lot of options here.

More over you're doing the classic thing of basically worrying about the super-soohosticated scifi attack: but the government doesn't have better technology then universities can produce, they just have good coordination: and a much better use of that is just to socially engineer the password out of the target.

[floralhangnail]

The tool that they use to transport it to the lab is pretty slick.

https://wamatek.com/products/cru-hotplug-field-kit-110v

[memoriyato3]

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

[liffik]

Booting a tiny Linux kernel would overwrite way too much RAM, destroying the exact data (like crypto keys) we want to recover. That's why my bootloader is strictly 512 bytes to minimize the footprint.

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?

[masa-kozu]

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.