Robot can rip the data out of RAM chips | Hacker News Reader

Robot can rip the data out of RAM chips

theregister.com

130 pointslaktak67 comments

Incredibly "cool"! The physical-chip-swapping version of the cold-boot attack is extremely general, but it's always been very labor intensive—that's why automation like this could be a game changer.

Here are some photos from our original experiments 15 years ago, to help you picture what's involved in doing these attacks manually:

https://web.archive.org/web/20080225131822/http://citp.princ...

Needless to say, our setup (and approach to lab safety) was rather privative by today's standards:

https://web.archive.org/web/20100616201843/http://citp.princ...

AMD Ryzen Pro CPUs have a memory encryption feature (SME): <https://www.amd.com/system/files/documents/amd-memory-guard-...>

It may require to have support from the motherboard.

EFI firmware has a var (/sys/firmware/efi/efivars/) named MemoryOverwriteRequestControl that if set is supposed to instruct the firmware to overwrite memory on next boot. If you set it and if you can somehow trigger a reboot memory should not be recoverable.

You can also set init_on_free=1 in linux cmdline, the kernel will overwrite freed memory. If a reboot is physically interrupted or if the EFI firmware does not honor the var mentioned above, encryption keys and any other private data may have been freed.

> You can also set init_on_free=1 in linux cmdline, the kernel will overwrite freed memory.

Does this only work with kernel buffers? I’m wondering how glibc handles freed memory. I feel like there’s a good chance it doesn’t always notify the kernel that the memory has been freed.

None Pro Ryzen CPUs can use Transparent SME (TSME) if the motherboard includes support for it (and many of them do). Like ECC on non Pro Ryzen chips it isn't 'officially supported' but the option is there and works.

A lot of the critical infrastructure embedded things that we depend on, almost none of them are addressing this kind of attack

Because it's beyond impractical and to attempt to "defend" against such things is effectively fighting against the base principles of (physical) property ownership?

The direction that "security" research has headed in is really disturbing.

I think this makes sense, if only because physical property ownership has always been an illusion.

You don’t really “own” anything as long as someone with a badge and a gun can break down your door and take it from you. I don’t care if you live in a democracy or a dictatorship, it happens in both.

Encrypted information, on the other hand, can theoretically be “owned” if it’s implemented correctly. No police, no court or law, no government, nothing can take your encrypted digital property from you. It’s probably the most real manifestation of property humans have ever come up with.

> Encrypted information, on the other hand, can theoretically be “owned” if it’s implemented correctly. No police, no court or law, no government, nothing can take your encrypted digital property from you.

Exactly! You can always access it from your jail cell.

Oh wait

Not at all.

If I am forced to surrender my phone at a border crossing, for example, I would like to know that the fact I powered it off is sufficient to deter these kinds of attacks.

It's relatively easy to thwart this attack--the CPU only sends encrypted data to external memory chips. The devil is in the implementation--encryption adds latency to memory access.

They can still overwrite your OS/kernel with a patched version that will upload the keys somewhere on first boot+unlock. This + a dump done at a border will let them get all your data.

You have neglected the man with a big gun security hole.

Do I need to link to the XKCD comic?

If they want ME, I'm cooked no matter how you look at it.

If they are just running a generalized dragnet, I just need for scanning my information to be just slightly too expensive.

Enormous difference between widespread dragnet data collection and targeted wrench attacks. Most people are not actual suspects worth any scrutiny. It is only when grabbing and storing the data becomes cheap that it becomes routine action (eg duplicate all phones at the border).

Sounds like a use case for a BIC (Bomb-In-Chip) implementation.

Why eat a murder or obstruction charge when you don't have to?

Power off if the cover is opened. ESD is a bitch, right? Gotta protect against that...

Must be 25 years ago now I was chatting with a family friend, my friends dad, and he told me roughly what it was that he does:

"If I have physical access to your computer, I can probably get whatever data you have off of it". It was the first time I had even heard of computer security as a concept.

I don't know precisely what methods he was using back then (it was the 90s) but he was dead serious.

The point he made has become more and more true over time: Whoever can touch the machine, you presume they have better access than the admin.

I do not think that holds up today. While there do still exist a wide variety of unsecured vectors, those are closing rapidly. Look at any of the closed hardware platforms (Xbox, Playstation, iPhone, TPM, etc). People with strong desires to exfiltrate data are stymied.

It's not that simple. Everything, even secure hardware, can have bugs. https://www.washingtonpost.com/technology/2021/04/14/azimuth...

While people with strong desires are stymied, I wouldn't trust any of those systems against a motivated nation-state.

While nothing is perfect, newer security models do have strong theoretical security guarantees (barring implementation problems). Significantly strong enough that it will certainly stop random guy-who-is-good-with-computers. Which is the actual threat model for 99.99% of the population. Nation states have significantly more and different attack options available (eg unencrypted cloud backups, rubber stamped warrants, and old-fashioned rubber-hose attacks).

It totally holds up today. The difference is that modern security measures make it much more expensive to do.

The "natural law of security" -- If you can access it legally, you can access it illegally -- remains true.

25 years ago it would be very unlikely for your hard drive to be encrypted. So you could just take the hard drive and read it direct ly.

It really just depends if people have full disk encryption or not and whether of not the machine was fully powered off afaik.

He was talking about taking out the hdd, obviously.

I thought ram chips had volatile memory. As soon as it loses power it effectively wipes all data, no? How does the physical removal process preserve the contents? Are modern RAM chips not volatile anymore?

They literally freeze them with liquid nitrogen, which makes them preserve their state.

Huh, TIL: https://en.wikipedia.org/wiki/Cold_boot_attack

A RAM module should keep some power in the module to erase itself when the external power is lost. Or when suddenly the temperature drops by a lot.

An alternative is to encrypt the data.

AMD calls that SME for example. https://www.amd.com/en/developer/sev.html

(quote from link)

> The key is generated by the AMD Secure Processor at boot.

Wouldn't this key _also_ be accessible? Maybe not on the same _chip_ but it's still at some level in a memory chip somewhere, they would just need to find it?

It isn't nearly as easy since the key never leaves the inside of the CPU. The key never goes to main memory or is exposed outside of the part used to encrypt/decrypt memory inside the CPU. Attacking a specific register instead the 'secure' enclave of a CPU is much harder than attacks like the OP where your rip out the RAM.

This type of system has been used pretty successfully for nearly a decade on the AMD SOCs used in the XBOX consoles.

Possibly, but now you have only one circuit to harden against such attacks, and you can continue using commodity DRAM ICs and modules.

It's stored inside the CPU of the secure element, in something like a register. Otherwise both the key and the ciphertext would be in the ram and the protection would be pointless.

Seemingly it'd be possible to attack an operating memory controller by etching with a laser, editing the circuit with a Focused Ion Beam (FIB) machine and putting some probes down to extract the key. But it's then an arms race with chip manufacturers who would try and bake in ever more sophisticated and complex tamper-detection to their chips.

Look up Christopher Tarnovsky talks from Black Hat 2009, Black Hat 2010, DEF CON 20, hardwear.io 2019.

It doesn't lose content as soon as you lose power.

One fun way I saw this was when working on LCD support in a bootloader. You do a quick power cycle and if the framebuffer location is fixed in memory and you don't initialize the contents, you may see faded traces of the picture from previous boot.

In my experience that's more of a side effect from TFT displays. Each pixel has its own gate and can hold a charge for quite a long time.

It can also be a side effect of older LCDs, when power is lost the crystal can take a long amount of time to depolarize. If you apply backlight you'll see an afterimage.

LCDs are driven by the controller and have no knowledge of the framebuffer location, or even access to the host address and data busses. So if you see an afterimage, that's in the pixel.

No, physical attacks are possible for many years now. They just require very high manual skill level. Ram chips must be immediately (as fast as possible after power goes down in case you don’t have control over when computer loses power) frozen by liquid gas and then moved into ram-reading jig.

Or you know a can of bottled air upside down and a bootable usb will do it unless the efi is locked down and USB-boot disabled, in that case you also need to move it over to your own laptop.

I remember switching my Commodore 64 off and on rapidly while it was displaying something on the bitmap graphic screen. The system would reset, but you could enable graphic mode and see 90% of what was there.

At normal DRAM module operating temperatures and assuming you want to stick to JEDEC specifications, retention times may typically be 50uS[1]. This low number is due to the standard having an extremely low tolerance for errors, and the inevitable problem of some MOS transistors/capacitors (a cell) being defective and having a much higher leakage rate than typical cells. Hence the standard has to cater for the weakest cell due to the extremely low tolerance for errors.

In [2], the authors used readily available compressed gas[3] to chill (probably to approx -50oC) DDR1 and DDR2 DRAM modules during operation, then whilst the DRAM modules remained chilled, cut power to the computer, waited a period of time and then read out the DRAM module data for comparison. With power cut for 10 minutes, a read error rate of just 36 bytes per megabyte was observed. This increased to an error rate of 1700 bytes per megabyte at 60 minutes when chilling to a lower temperature using LN2.

The authors of [2] tested DDR1 and DDR2 DRAM retention without use of cooling, and results varied between different DRAM modules (different sense amplifiers, different MOS transistor/capacitor fabrication methods, different DRAM module heatsink designs, etc) but generally it showed 5 minutes unpowered would generally erase all data, but some remnants could still remain (e.g. enough to make a faint outline out of a photo stored in memory).

Note that like the 2008 paper[2], this paper also uses DDR1 and DDR2 DRAM chips. The main reason for this choice is DDR3+ specifications and modern memory controllers implement "data scrambling"[4], originally not for security reasons (that's just a bonus side effect), but for electrical reasons to reduce di/dt noise on the data bus. "Data scrambling" means that data is XOR'd with a pseudorandom function, thus if you write 11111... or 00000... you'd expect on average the data bus to have the same average electrical characteristics. Since row hammer, the pseudorandom function has been improved to provide security against cold boot attacks. It's possible for the memory controller to use low-latency strong encryption such as ChaCha8. AMD "Memory Guard" uses AES128/NIST SP 800-90[5] and Intel's "Total Memory Encryption" uses AES128/256-XTS[6].

[1] Page 19 (PDF), https://www.egr.msu.edu/classes/ece410/mason/files/Ch13.pdf

[2] https://www.usenix.org/legacy/event/sec08/tech/full_papers/h...

[3] https://en.wikipedia.org/wiki/Freeze_spray

[4] https://web.archive.org/web/20190616183914/https://www.eecs....

[5] https://www.amd.com/system/files/documents/amd-memory-guard-...

[6] https://cdrdv2-public.intel.com/679154/multi-key-total-memor...

Paper: https://wootconference.org/papers/woot23-paper3.pdf

And slides:

https://wootconference.org/slides/3-Cryo-Mechanical_Memory_E...

Thank you for this!

The whole thing hinges on the elastomeric sockets and I had no idea what they were talking about until you referenced the paper.

Those sockets are mega cool. I need to go down the rabbit hole of those for a while.

Here's an interesting line from this article:

>They also conducted a similarly successful attack on DDR3 DRAM in a CISCO IP Phone 8800 series to access the runtime ARM TrustZone memory.

Generic Pattern/Idea expressed in above statement:

a) IF a given CPU implements a security processor (i.e., Intel Management Engine, AMD PSP, Apple Secure Enclave, an ARM security coprocessor, etc.) then:

b) IF that security processor uses a small part of physical RAM of the computer it is in for its activities, and that physical RAM, during those activities is inaccessible to programs, OS'es and Hypervisors alike, then:

c) It may still be possible to get a memory dump of that protected subsection of RAM during those activities by one or more methods, including (but not limited to!) the physical freezing/robotic extraction of the RAM...

I would suggest that if point-in-time RAM extraction were the desired goal (and it apparently is) -- that it might be far simpler to use an FPGA connected to appropriate RAM and have that device emulate aka proxy (via signal paths) the device's RAM from which data is to be extracted from...

Also... prediction: Future RAM will be built such that it can be easily proxied/tapped/tee'd/traced/interposed by third party hardware devices... That is, future RAM interconnect signal paths will be intentionally engineered for that purpose...

In future computers, CPU, memory and all devices will be modular; where all interlinking signal paths could be proxied/tapped/tee'd/traced/interposed by third party hardware devices...

Think of it this way; what the original IBM-PC did for computing of the era (open the bus, open the backplane to accept 3rd party expansion cards) -- should be done between every possible set of electronic components in future PC's/computing devices...

Why not build a thermocouple into the RAM package and program the operating system to overwrite memory with random data on detection of a sudden temperature drop?

Using the OS to do this is unlikely to be effective; the attacker with this access could usually halt the CPU before they remove RAM. As in the article, the best mitigation against this kind of attack is memory encryption, either in hardware or software (although in software, you have to figure out how to keep your keys out of RAM).

There are security oriented ICs of various types (flash, RAM, secure element) which do clear data with a tripwire in a lot of ways; some even have onboard current storage of some kind which allows them to clear all data as a "dying breath" when the package is tampered with. But COTS DDR RAM needs to be cheap and doesn't usually have this kind of threat model.

> although in software, you have to figure out how to keep your keys out of RAM

I think you can do this with modern “trusted computing” modules.

You can also pot the PCB, and/or enclose it in a physically secure enclave where if it detects ambient light, actuation of a switch, breach of a conductive trace embedded in the case around it, etc, it wipes the RAM and, depending on your paranoia levels, blows the hardware up. Some key management Hardware Security Modules do this.

Also this: https://en.wikipedia.org/wiki/Harvey's_Resort_Hotel_bombing

The designer could probably have made more cash patenting his systems!

That's still a reactive defense. A safer approach is to encrypt the data and keep the keys in the CPU, which is what TME (intel) and SME (amd) do. The downside is some added latency, power consumption and die area.

How much more would you pay for hardware with this extra protection against you hacking it?

I’m not important enough to be a target of this attack in the first place!

Money

Anyone know how the memory chips are removed from the target board? They can't be desoldering them if it's a cryogenic process

It’s in the article, they’re desoldered and reballed like normal and then socketed: “What makes the attack possible, he said, is something called a conductive elastomer IC test socket.” The cryogenic pick and place robot then moves the now-socketed chip from the board to the test fixture at runtime.

The elastomeric sockets are really cool. They're like 2D versions of those zebra connectors for LCDs: you just press them down and the land pattern is replicated on the other side. Furthermore, they work into the GHz range, which you need, say, for messing with modern DDR RAM standards.

https://www.ironwoodelectronics.com/products/ghz-elastomer-s...

This is ridiculous. You need to steal the hardware, analyse the specific model, build a machine for it and manipulate it and then bring it back to the original user and then steal it again after he has entered his credentials and then you have to use a dedicated machine to perform the actual attack and you only have one attempt.

If it is a laptop, yeah, not super practical, but there are plenty of devices secured by encrypted firmware that gets decoded on boot and stored in memory

Yeah, way more practical for servers in a datacenter than for a random laptop you confiscated. Though tooling for each of the most recent iPhones might also be worth it

Wrong use case. It's a reverse engineering tool to extract firmware, secrets, and code to develop and exploit, not an exploit in and of itself.

This would be a horrendous way to recover user credentials but it's a great way to recover encrypted firmware, session/authorization/authentication keys derived in "Secure World" on embedded systems, and static runtime secrets decrypted using a derived key (key vaults, etc.).

Get things cold enough and you can pop off most BGA-based packages from the boards ..

Isn't the solution to make it very hard to remove the ram without destroying it? Like, epoxy it onto the motherboard?

The XBOX-360 had encrypted main memory, which largely warded off bus attacks. It stood as an impenetrable stone wall until the exploits were found.

What is the advantage of this vs. some sort of "go-between" module which mirrors all RAM traffic to an external device?

Because when you pull the RAM chip to add the module, it loses its data and the system crashes. This attack is for people who just got access to a running system. I have heard about this for FBI who have running system that they can’t turn off cause then it would be encrypted.

Their targets are unlikely to allow law enforcement to add monitoring to their computers. And if they had prior access, compromising the software or other hardware would be better.

Ah the article was talking a lot about keys in the bootloader, so I was assuming this was intended to be used after a fresh boot.

You probably can't do that without screwing up the signal integrity

Only if it's passive -- I would expect an active (buffered) solution to work fine.

Reply on news.ycombinator.com