DDRop is a small, low-cost hardware interposer device that can make writes to a server’s memory disappear, causing the computer to read old data as if it were newly written. This trick has serious consequences for confidential computing technologies designed to protect sensitive workloads on shared cloud infrastructure. DDRop can interfere with protected virtual machines on Intel and AMD platforms and, on Intel TDX, even forge the security evidence used to prove that a virtual machine is trusted.
The missing guarantee: freshness
DDRop interferes with writes rather than trying to read encrypted data, so memory encryption does not stop the attack. It also uses interfaces that the hypervisor relies on to move protected memory, so the victim VM does not need to contain a software bug. On Intel TDX, we use the attack to put a confidential VM into debug mode and forge attestation reports.
A silent switch on the DDR5 bus
Earlier DDR5 interposers were passive and required bulky equipment. They also had to slow the memory bus to work with second-hand lab hardware, making the change easier to notice. DDRop is a compact board of analog switches that runs at native DDR5 speed and can be installed in minutes.
DDR5’s redesigned command bus makes the address-aliasing tricks used by earlier attacks impractical. DDRop instead interferes with the bus’s error handling. The interposer deliberately introduces a parity error and then suppresses the alert. The memory module discards the command, and the processor does not learn that the command was dropped. The write is gone.
All schematics, board files, and firmware are released as open source on our GitHub repository.
| Component | Supplier | Cost |
|---|---|---|
| Interposer PCB with stencil | JLCPCB | $45 |
| Interposer electronic parts | Digikey, LOTES | $30 |
| Controller board PCB | JLCPCB | $4 |
| Controller electronic parts | Digikey | $40 |
| Teensy 4.1 microcontroller | Digikey | $40 |
| Total | $159 |
Bill of materials for a single interposer system (at a build quantity of 10). Excludes R&D and assembly labor.
DDRop in action: Breaking Intel TDX
Intel TDX isolates confidential virtual machines, called Trust Domains (TDs), from a potentially compromised host hypervisor. To prevent the privileged hypervisor from tampering with guest memory translations, TDX delegates address mappings to Secure Extended Page Tables (SEPT), which are encrypted in RAM under the respective TD’s key and managed exclusively by trusted firmware (the TDX module).
When the host allocates a new SEPT page (TDH.MEM.SEPT.ADD), the TDX module writes empty entries to securely initialize it. DDRop silently drops these writes, so the page keeps pre-crafted stale ciphertext that decrypts into malicious page-table entries. This primitive is 100% deterministic and lets an attacker-controlled TD remap its own memory onto any physical address in RAM.
Under TDX’s default logical integrity (LI) mode, this allows the attacker to corrupt the ciphertext of other TDs and their control structures. Even TDX’s stronger cryptographic integrity (CI) mode would only prevent tampering across different key domains, still allowing an attacker to forge the attestation measurement of their own TD.
Case Study: Toggling Debug Mode on a Victim TD LI only
In production, Intel TDX strictly prevents the hypervisor from inspecting a TD's memory. A debug flag in the TD's attributes ensures the host cannot use the debug read/write API. However, the compromised SEPT mappings allow an attacker to corrupt these attributes, including the debug flag. Because this data is encrypted under a different key, it decrypts into pseudorandom noise, giving each attempt a 50% chance of setting the debug bit. Once active, the hypervisor dumps the victim's plaintext memory via the debug API and then cleanly restores the original captured ciphertext, leaving the victim running unaware with an unmodified attestation status.
Case Study: Forging Attestation of an Attacker TD LI + CI
To support remote attestation, the TDX module records the initial state of a TD in a launch measurement, which is signed on request so that a remote tenant can verify what was booted. Here the attacker targets a TD of their own: a rogue VM they launch and control, running whatever backdoor they like. Because this TD's control structure (TDCS) is encrypted under the attacker's own key, the injected SEPT entries give direct plaintext write access to it, allowing them to overwrite the launch measurement with that of a legitimate workload. When the rogue VM then requests an attestation report via TDG.MR.REPORT, the TDX module returns a valid report containing the forged measurement, so the backdoored VM passes remote attestation as if it were the trusted one.
Questions & Answers
DDRop is joint work by researchers at KU Leuven, ETH Zurich, Durham University, and Google:
- Jesse De Meulemeester (COSIC, KU Leuven)
- Stefan Gloor (ETH Zurich)
- Patrick Jattke (ETH Zurich)
- Daniel Moghimi (Google)
- David Oswald (Durham University)
- Martin Thompson (Durham University & ZF Automotive UK Ltd)
- Kaveh Razavi (ETH Zurich)
- Ingrid Verbauwhede (COSIC, KU Leuven)
- Jo Van Bulck (DistriNet, KU Leuven)
For everyday laptops and phones, no: DDRop is a research attack aimed at confidential-computing servers in the cloud that run Intel TDX, Intel Scalable SGX, or AMD SEV-SNP on DDR5.
If you rely on those technologies to protect workloads from the cloud provider itself, this matters: DDRop shows that an attacker with brief physical access can undermine them. We disclosed everything to Intel and AMD in advance under coordinated disclosure.
Confidential computing is meant to protect sensitive data, even from the cloud provider. DDRop needs a brief, one-time visit to install the interposer. Besides that, DDRop assumes the standard TEE threat model, with the adversary controlling the OS/hypervisor and BIOS. Once the interposer is installed, the attack is carried out entirely in software. Possible ways to get that access include:
It is a family of hardware features that let you run a workload in the cloud without having to trust the cloud provider. Popular platforms include Intel TDX and Scalable SGX, and AMD SEV-SNP. The hardware locks memory behind access control and encryption, so a physical adversary sees only scrambled data.
Only partly. Vendors can make the attack harder by restricting the memory-management interfaces DDRop uses, checking that critical writes actually arrived, or looking for the interposer during boot. The paper discusses several defenses.
These measures do not add freshness to the memory-encryption hardware. The underlying problem is in hardware: today's scalable memory encryption does not keep track of whether a value is current. A lasting fix would require memory-encryption engines with integrity and freshness.
No. Memory encryption on TDX, SEV-SNP, and Scalable SGX protects confidentiality against someone reading the memory bus, but it lacks freshness and replay protection for this attack: it cannot distinguish a current value from an old one.
Physical attacks on encrypted cloud memory fall into two broad groups: attacks that listen to the memory bus and attacks that modify what happens on it. DDRop is the first active hardware interposer for current DDR5 servers.
The passive attacks (Membuster, WireTap, TEE.fail) observe traffic and use side channels to infer information. They use slower bus speeds to work with older lab equipment. DDRop is active and runs at native speed; the paper shows how it can copy plaintext between pages, alter page-table entries, and forge attestation. The defenses discussed in the paper can make the attack harder, but they do not add freshness to the memory-encryption hardware.
We followed coordinated disclosure and shared our hardware, techniques, and proof-of-concept exploits with Intel and AMD ahead of time; we also informed Arm. These vendors have acknowledged our findings, but noted that physical attacks on DRAM are out of scope for their current products.
Intel has recently characterized research on hardware interposers as "out of scope but not out of mind" and indicated that it is considering next-generation memory-encryption schemes with stronger hardware protections. Research such as DDRop matters for understanding the fundamental limitations of today's technology and the attacker capabilities such attacks require, thereby informing the design of more robust memory-encryption schemes.
Following a coordinated disclosure on September 14, 2026, both vendors have issued a public security advisory: Intel advisory | AMD advisory.
Yes — the logo is released under CC0 (all rights waived).
