Rogue Memory: A Hidden Security Threat

Memory Icon
Computers rely on a processor to perform calculations and memory (DRAM) to store code and data. Adding more memory can boost performance, with different tasks demanding varying amounts. When a computer starts up, it communicates with the connected DRAM modules to learn their size, speed, and configuration. But what if the DRAM module can be tricked into lying to the processor?

For the first time, we have studied the security risks of “bad RAM” — rogue memory modules that deliberately provide false information to the processor during startup. Our findings reveal a surprising and previously underexplored weakness in modern processor security technologies.

A $10 Hack That Erodes Trust in the Cloud

Cloud Security Icon
Modern computers increasingly use encryption to protect sensitive data in DRAM, especially in shared cloud environments with pervasive data breaches and insider threats. AMD's Secure Encrypted Virtualization (SEV) is a cutting-edge technology that protects privacy and trust in cloud computing by encrypting a virtual machine's (VM's) memory and isolating it from advanced attackers, even those compromising critical infrastructure like the virtual machine manager or firmware.

We found that tampering with the embedded SPD chip on commercial DRAM modules allows attackers to bypass SEV protections — including AMD’s latest SEV-SNP version. For less than $10 in off-the-shelf equipment, we can trick the processor into allowing access to encrypted memory. We build on this BadRAM attack primitive to completely compromise the AMD SEV ecosystem, faking remote attestation reports and inserting backdoors into any SEV-protected VM.

To mitigate the BadRAM vulnerability, AMD has issued firmware updates to securely validate memory configurations during the processor’s boot process.

BadRAM in 3 Simple Steps

  1. Compromise the memory module

    BadRAM makes the memory module intentionally lie about its size, tricking the CPU into accessing nonexistent "ghost" addresses that are silently mapped to existing memory regions.

  2. Find aliases

    Two CPU addresses now map to the same DRAM location. Our practical tools find these aliases in minutes.

  3. Bypass CPU Access Control

    Through these aliases, attackers can bypass CPU memory protections, exposing sensitive data or causing disruptions.

BadRAM in Action

Questions and Answers

While BadRAM may be possible on your system, it is primarily relevant in a cloud scenario with TEEs, where you inherently may not trust the cloud providers owning the systems. However, even in that scenario, there is no need to worry since we worked together with AMD to ensure appropriate countermeasures were developed that allow trusted firmware to detect BadRAM at boot time. Cloud providers will apply these updates to ensure your data remains secure.

BadRAM attacks require access to the SPD chip on the DIMM to modify its contents. This SPD chip can be exposed in several scenario's:

  1. Insider Threats in Cloud Environments

    In a cloud environment, employees of the cloud provider or local law enforcement could gain physical access to the hardware. These insiders could trivially modify the SPD chip to enable BadRAM attacks.

  2. Software-Based Attacks

    Some DRAM manufacturers fail to properly lock the SPD chip, leaving it vulnerable to modification by operating-system software after boot. This has previously already caused several cases of accidental SPD corruption. Additionally, some manufacturers intentionally leave SPD unlocked in the BIOS to support features like RGB lighting for gaming setups. If SPD is not securely locked, attackers with root privileges could launch BadRAM attacks entirely through software, without physical access. Furthermore, since memory initialization is handled by the BIOS, a compromised BIOS could also enable BadRAM exploits.

AMD Secure Encrypted Virtualization (SEV) is a hardware-based trusted execution environment designed to enable secure cloud computing without needing to trust the cloud provider or local law enforcement. AMD SEV protects data in use by implementing strong access controls within the CPU and encrypting all data before storing it in untrusted off-chip DRAM. AMD SEV encrypts memory with a dedicated key unique to each virtual machine, ensuring data privacy even if the host system is compromised. This technology has evolved through several iterations, with the latest being SEV-SNP, designed to offer advanced protection against page-remapping attacks from an untrusted hypervisor.

AMD SEV is widely used in cloud computing to enhance security and privacy, with major cloud providers like Amazon AWS, Google Cloud, Microsoft Azure, and IBM cloud offering this technology to protect their customers' data.

We found that other popular cloud TEEs, Intel TDX and scalable Intel SGX , include dedicated countermeasures against BadRAM aliasing attacks. At boot time, a trusted firmware module checks the protected memory range for aliases, and additional DRAM metadata tracks the protection status of each memory address. Thanks to these protections, we were unable to exploit BadRAM on these TEEs.

The older desktop version of SGX, now discontinued, is partially vulnerable to BadRAM. Compared to scalable SGX and TDX, this "classic" SGX featured much stronger memory encryption, including cryptographic freshness guarantees. However, this came at the cost of a limited protected memory size, prompting the industry to shift towards weaker, but more scalable, static memory encryption technologies. Using BadRAM, we observed changes in the encrypted, protected memory space, partially replicating a previous attack on classic SGX, dubbed MemBuster. While MemBuster originally required ~$170,000 and was only demonstrated on DDR4, we achieved it for less than $10 on both DDR4 and DDR5.

Arm has also announced a cloud TEE called CCA . Based on the specification, it appears that alias checking countermeasures are required. However, since no hardware is available yet, we were unable to test BadRAM on CCA.

The table below summarizes our findings across different TEEs. Each column indicates whether we were able to read, write, or replay ciphertexts in protected memory regions.

TEE Read Write Replay
AMD SEV-SNP
Intel Classic SGX
Intel Scalable SGX
Intel TDX
Arm CCA

BadRAM can be mitigated by considering the SPD data as untrusted and performing memory alias checking at boot time, as seen in Intel's Alias Checking Trusted Module for TDX and scalable SGX. The countermeasures introduced by AMD will similarly validate SPD metadata during the boot process in trusted firmware.

Alternatively, strong cryptographic memory encryption that provides additional integrity and freshness guarantees, as employed in "classic" Intel SGX, almost entirely mitigates the security risks posed by BadRAM’s memory aliasing technique.

While it is good practice to keep your system up-to-date, there’s no immediate need for individual users to update their systems. At this time, most cloud providers will have updated their firmware to include the countermeasures provided by AMD.

BadRAM can circumvent critical CPU-based memory isolation features based on physical address checks, which has significant consequences for TEEs like AMD SEV-SNP.

While TEEs commonly encrypt data in memory, this encryption is static, meaning that the same plaintext always maps to the same ciphertext. This can prevent threats like cold boot attacks, but is not a significant roadblock for BadRAM. BadRAM can do more than just observe encrypted data—it can corrupt or replay ciphertexts. Since encryption is static, the replayed data decrypts to the same value, effectively allowing stale data to be used.

Even more concerning, we discovered that the critical Reverse Map Table (RMP) in AMD’s latest SEV-SNP architecture, designed specifically to protect against "SEVered" page-remapping attacks, is left unencrypted. With the RMP unencrypted, BadRAM can directly modify the memory mappings, completely bypassing the protections SEV-SNP was built to prevent. This allows attackers to arbitrarily swap memory mappings and enable arbitrary code execution and decryption of SEV-SNP virtual-machine memory.

Cold boot attacks exploit the residual data in DRAM by quickly restarting or transferring memory modules to extract secret data. These attacks can nowadays easily be mitigated by enabling full memory encryption, whereas this is not a big hurdle for BadRAM. BadRAM is also a more powerful attack, it is not only able to observe the memory at any given point, but can also actively modify or replay data.

On a Linux desktop or laptop equipped with DDR4 memory, you can easily verify if your DIMMs are locked from software access. To do this, use i2cdetect from the I2C tools to identify which I2C bus corresponds to the SMBus:

sudo i2cdetect -l

Once you have identified the correct bus number for the SMBus, you can scan it using:

sudo i2cdetect -y <number>

On the SMBus, you should see some I2C devices at addresses 0x50 through 0x58. These are the SPD chips associated with your DIMMs. If no devices appear within this range, it may indicate that your DRAM is soldered or that the SPDs are not directly accessible from the SMBus.

If no devices are detected at addresses 0x31 and 0x34, it means the SPDs are correctly locked. However, if devices are visible at these addresses, your DIMMs are not protected.

In our paper, we show that BadRAM affects DDR4 and DDR5. These generations both have unlockable SPD chips, making it easy to overwrite its contents. For older generations, like DDR3, that allow permanent write protection to the SPD, we show how BadRAM attacks are still possible by removing or swapping the SPD.

For the upcoming DDR6, specifications have not been released yet. However, it would be safe to assume they will also contain some kind of SPD device on the DIMM. As long as an attacker can modify the contents of this SPD, BadRAM might still be possible.

No, this paper is not related to the BadRAM feature that can be found in Linux and other operating systems. In that context, BadRAM is used to specify and filter out defective DRAM regions, which can be detected by tools such as Memtest86+. This feature can, however, be used to filter out the "ghost" memory regions created by BadRAM modules.

The SPD chip can be easily modified using a low-cost, off-the-shelf microcontroller. We used a Raspberry Pi Pico, for a total cost of around $10. Below is a bill of materials and an image of our Raspberry Pi Pico setup to unlock and modify DDR4 and DDR5 SPDs.

Component Cost Link
Raspberry Pi Pico $5 Link
DDR Socket $1-5 DDR4: [1], [2]
DDR5: [1], [2]
9V source $2 9V battery / Boost converter

For more details, you can access the research paper and additional resources on our GitHub repository .

The logo is free to use, rights waived via CC0.

Logo (white background) SVG PNG
Logo (transparent background) SVG PNG

CVE-2024-21944 is the identifier that is used to track BadRAM. It is also tracked by AMD under AMD-SB-3015.

Yes, our GitHub repository contains all scripts to modify the SPD chip, and proof-of-concept code for our attacks.

Follow-up Research

This section tracks subsequent research building on BadRAM, including both our own work and independent research by the wider community.
Missing a paper? Feel free to open a pull request if you want your own work using BadRAM to be featured here.

Download More RAM: Dismantling Windows Operating System Defences with Mischievous Memory
Sam Collins1, Tom Chothia1, William Burgess1, Marius Muench1, David Oswald2
1 University of Birmingham    2 Durham University
Virtualisation-Based Security (VBS) is the cornerstone of modern Windows desktop defences, relied upon by both the operating system and third-party software, with a virtualised secure kernel providing strong security guarantees against even privileged attackers. In this paper, we introduce Download More RAM, a software-only memory aliasing attack that breaks these guarantees without physical access. On systems running the most common consumer DIMMs, our attack allows arbitrary memory read/write, letting a privileged user compromise the OS at every level, including the secure kernel, Hypervisor Enforced Code Integrity (HVCI), and all defences it provides. With this access we develop a series of case study attacks targeting VBS-protected processes, Windows Defender, anti-virus & EDR software, and game anti-cheats. Our work breaks the strongest security guarantees offered by the Windows OS, questioning key trust assumptions on such systems. Microsoft have assigned CVE-2026-23670 to our findings and issued a patch that partially mitigates our attack.
Read Full Paper

Jailbreaking the AMD Secure Processor: Enabling Live Analysis of SEV-SNP’s Undocumented Security Boundaries
Muyan Shen1,2, Hongzhan Ma1, Ketong Shang1, Ruofei Qu1, Yu Qin1, Dengguo Feng1
1 Institute of Software, Chinese Academy of Sciences    2 School of Cryptology, University of Chinese Academy of Sciences
AMD's Secure Nested Paging (SEV-SNP) protects virtual machines using its hardware root of trust, the AMD Secure Processor (ASP). However, its security relies on complex, opaque firmware features, such as a dynamic hot-patching mechanism, that create attack surfaces shielded from independent scrutiny. To overcome this "black-box" challenge, we present ASPBreaker, the first practical, fully deterministic jailbreak of the ASP, achieved by exploiting a novel combination of memory aliasing and time-of-check-to-time-of-use (TOCTOU) vulnerability.

Using this jailbreak as a tool for live analysis, we demonstrate how achieving arbitrary code execution on a vulnerable firmware version can be used to subvert the security of a subsequent, fully-patched one. Our analysis revealed critical flaws, enabling two practical attacks against the latest firmware: one that allows an adversary to decrypt the memory of a virtual machine and another that bypasses existing mitigations to forge attestation reports. Our findings, which were responsibly disclosed, demonstrate a fundamental break in the forward-security model of SEV-SNP and highlight the critical need for independent auditing of opaque firmware boundaries.
Read Full Paper

DisARMed: Attacking ARM TrustZone from Userspace with Memory Aliasing
Jacqueline Henes* 1, Matthew Bowden* 1, Mihai Ordean1, David Oswald2
1 University of Birmingham    2 Durham University
Modern systems security relies on memory isolation mechanisms like trusted execution environments and kernel privilege separation to enforce strong isolation boundaries. However, many of these mechanisms place implicit trust in system memory, leaving them open to hardware attacks on external DRAM. In this paper, we introduce DisARMed, an attack on ARM processors that exploits memory aliasing techniques from userspace, compromising both the Linux kernel and ARM TrustZone. We demonstrate for the first time that memory aliasing attacks are practical for adversaries that do not have access to the kernel. We additionally implement and evaluate a mitigation for DisARMed, using a lightweight alias detection mechanism. Our solution has minimal impact on boot time of about one second. Finally, we discuss the wider applicability of DisARMed, considering other relevant potential attack vectors, applicable memory massaging techniques, and security mechanisms that may be affected.
Read Full Paper

Physical Memory Please: Practical Memory-Aliasing Attacks on RISC-V PMP
Antonis Louka1, Jesse De Meulemeester2, Steven Keuchel1, Ingrid Verbauwhede2, Jo Van Bulck1
1 DistriNet, KU Leuven    2 COSIC, KU Leuven
Recent years have seen a surge in security architectures builton the open RISC-V instruction set architecture. A key enabler of this trend has been the standardized Physical Memory Protection (PMP) extension, safeguarding critical firmware and forming the foundation for, amongst others, versatile Trusted Execution Environments (TEEs). However, while production TEEs on popular x86 and Arm platforms have undergone extensive security vetting, emerging RISC-V TEEshave received far less scrutiny.This paper studies the impact of recent memory-aliasingattacks, originally demonstrated on x86, within the RISC-Vecosystem. We show that a practical memory-aliasing setupcan fully bypass PMP-based isolation, enabling arbitrary read and write access to protected memory regions. Using this primitive, we demonstrate end-to-end attacks on the popular RISC-V Keystone TEE, achieving full enclave memory disclosure and, ultimately, completely undermining remote attestation guarantees by extracting the long-term platform measurement key. Leveraging open-source RISC-V firmware, we further develop a practical mitigation that detects rogue DIMM configurations at boot time, effectively preventing software-based memory-aliasing attacks. Our findings nuance the trust in PMP-based isolation and highlight how microarchitectural attack vectors from established architectures like x86 can translate to emerging RISC-V settings.
Read Full Paper

BROL: Cache-Only Execution for Software Protection
Ruben Mechelinck, Stijn Volckaert
DistriNet, KU Leuven
Industrial-scale reverse engineering is a growing problem for manufacturers of specialized equipment and machines. Both software and hardware intellectual property form the foundation of these manufacturer's competitive advantage and revenue, making them attractive targets for malicious competitors. The produced systems typically have limited resources and lack built-in protection mechanisms for the software it runs, leaving the software vulnerable to unauthorized duplication and reverse engineering. We present BROL, a technique that protects software against reverse engineering and piracy by binding it to a specific machine and hiding its code in the CPU's instruction cache. BROL loads the protected code from disk, decrypts it with a machine-specific key, and uses physical memory aliasing and targeted cache eviction to make the code unavailable in any level of the memory hierarchy except for the instruction cache. We implemented BROL for x86 and ARMv7 platforms and show that it reliably protects code without relying on dedicated security hardware to achieve maximum security. However, our evaluation also shows that BROL has non-trivial constraints that limit its applicability.
Read Full Paper

Battering RAM: Low-Cost Interposer Attacks on Confidential Computing via Dynamic Memory Aliasing
Jesse De Meulemeester1, David Oswald2, Ingrid Verbauwhede1, Jo Van Bulck3
1 COSIC, KU Leuven    2 University of Birmingham & Durham University    3 DistriNet, KU Leuven
Confidential computing, powered by trusted execution environments (TEEs) like Intel SGX/TDX and AMD SEVSNP, is now widely available from major cloud providers. At the core of these technologies is hardware-level memory encryption to protect against privileged attackers and physical threats such as bus snooping and cold boot attacks. Recent extensions add access-control checks to defend against software-based ciphertext manipulation and aliasing attacks. In this work, we challenge the protection modern memory encryption technologies offer against physical adversaries by building a low-cost (<$50) DDR4 interposer that dynamically tampers with address lines to bypass aliasing checks in current TEEs. We demonstrate how the runtime nature of our interposer bypasses boot-time firmware mitigations introduced by AMD and Intel in response to software-based memory aliasing attacks. Using our interposer, we present the first attack on Scalable SGX’s single-key domain, achieving arbitrary plaintext read/write access and extracting SGX’s platform provisioning key, thereby dismantling trust in remote attestation. We further re-enable a full attestation breach on up-to-date AMD SEV-SNP platforms, bypassing recent firmware defenses against static aliases. Our results challenge core assumptions about encrypted memory security and highlight critical shortcomings in the performance-security trade-offs of current confidential computing systems. Costing orders of magnitude less than commercial DRAM interposers, our device underscores the need for stronger protections against low-cost physical attacks in scalable TEE designs.
Read Full Paper