New DRAM Scrambling Attack Challenges CPU Memory Security Boundaries

New DRAM Scrambling Attack Challenges CPU Memory Security Boundaries

A new hardware security research project is drawing attention to a layer of computer memory architecture that normally sits beneath many of the mechanisms used to isolate sensitive processor data.

The open-source project skitter-creek-bath-salts, published by security researcher Christopher Domas, demonstrates how changing DRAM address-translation behavior can cause physical addresses to map to different locations in memory. The project describes this as modifying the bottom layers of the memory hierarchy and rewiring physical DRAM address translations.

The research was developed and tested on AMD Family 16h CPUs. The repository notes that Family 16h is the last AMD generation whose datasheets document the relevant DRAM-controller translation registers and indicate that they cannot be locked. It also notes that AMD Family 17h and later generations leave this information undocumented.

Cyber Security News reports that the demonstrated technique can reach memory associated with the Platform Security Processor, System Management Mode and CPU microcode.

The important finding is not a conventional operating-system or application vulnerability. Instead, the research examines what happens when the physical-to-DRAM address mapping itself is changed beneath security mechanisms that depend on physical addresses remaining consistent.

The Memory Layer Where the Research Operates

Modern systems contain several layers between a program requesting memory and the physical DRAM cells that ultimately store the data.

A virtual address generated by software passes through mechanisms such as the MMU, page tables and translation caches before becoming a physical address. From there, the system's memory infrastructure determines where that physical address ultimately reaches in DRAM.

The research project maps this journey in considerable detail and identifies the memory-controller layer as its target.

At the memory controller, a physical address can be transformed through operations involving memory-region remapping, channel interleaving, rank interleaving, bank mapping, bank swizzling and chip-select selection before becoming DRAM coordinates.

The project specifically operates at the MCT/DCT layer, where a physical address entering the memory controller is rewritten into the raw DRAM coordinates issued to the memory modules.

That distinction is central to understanding the research.

Security mechanisms above this layer can protect physical memory ranges. But if the relationship between a physical address and its underlying DRAM location is changed, the resulting memory access can behave differently from what those higher-level protections expect.

What DRAM Scrambling Changes

The research calls the process of altering the memory mapping "spaghettifying" DRAM.

In simplified terms, the memory controller applies transformations that determine how portions of a physical address correspond to DRAM resources.

The repository describes several components of this process, including channel and rank interleaving, bank interleaving, bank swizzling and chip-select mapping.

Changing the relevant mapping can alter the relationship between a physical address and the DRAM location it reaches.

The research demonstrates that this can create an alias in which a different physical address under the altered memory mapping reaches the same underlying DRAM location associated with a protected target.

This is the foundation of the demonstrated memory-aliasing technique.

The repository explains that the memory mapping can be temporarily changed and then restored, allowing the researchers to work with the altered view before returning the system to its normal mapping.

The full exploit implementation is not reproduced here.

Why Existing Memory Protections Can Be Challenged

The significance of the research comes from where the remapping occurs.

Security mechanisms and protected memory configurations rely on assumptions about how physical memory addresses correspond to memory locations.

The Cyber Security News report discusses technologies and protections including AMD SEV, Intel SGX, Intel TDX and ARM TrustZone in the context of the broader architectural issue.

The research should not be interpreted as demonstrating that every implementation of these technologies is universally vulnerable.

Instead, it demonstrates a deeper architectural concern on the tested platform: security mechanisms that rely on physical memory addresses can be affected when the underlying address-to-DRAM mapping is changed beneath them.

This makes the finding different from a conventional privilege-escalation vulnerability.

The research changes the memory-controller transformation rather than simply obtaining a higher software privilege level.

The repository describes the resulting effect as an alias that can reach the same DRAM data without following the original physical-address path used by the platform's protections.

The Research Demonstrated Access to Sensitive Processor Data

On the AMD Family 16h platform used for the research, Domas demonstrates access to several categories of protected or normally inaccessible information.

Platform Security Processor Memory

The project reports extracting the Platform Security Processor's RSA engine from memory that the PSP is expected to own and that is fenced off at the memory-controller level.

Cyber Security News describes this as access to an fTPM-related RSA signing routine in Platform Security Processor memory.

System Management Mode Memory

The research also demonstrates access to the SMI handler stored in SMRAM.

System Management Mode operates at a highly privileged processor level, and SMRAM is intended to isolate its contents from ordinary software access.

The repository documents a demonstration that reads the SMM handler through the alias mapping.

C6 Processor State

The project also examines memory associated with processors entering the C6 low-power state.

The repository explains that the architectural state of cores is stored in DRAM during this state and demonstrates reading information from the corresponding memory area. It identifies values including CR3 and APIC configuration within the saved state.

CPU Microcode

The research also examines the microcode copy stored in DRAM during C6 transitions.

The repository explains that the loaded microcode patch is retained in the C6 save area in DRAM and demonstrates recovering that copy through the alias mapping.

These demonstrations illustrate how deeply the technique operates within the tested platform's memory architecture.

The Mathematics Behind the Mapping

The research is not based solely on trial and error.

A key part of the project is reconstructing the memory controller's address transformation.

The repository explains that the DRAM controller's address transform can be represented as a linear map over GF(2). Because of this property, the relationship between the normal memory view and the scrambled view can be reconstructed using linear algebra.

The researchers use Z3, an SMT solver, to help solve the transformation.

The project describes collecting pairs of physical addresses that correspond to the same underlying DRAM cell under the normal and altered memory mappings. These observations provide constraints that can be supplied to the solver to reconstruct the translation between the two views.

This mathematical component is important because the exact internal mapping is not fully documented.

Rather than requiring complete knowledge of the undocumented transform in advance, the research uses observed memory behavior and mathematical reconstruction to determine the relationship between the coherent and scrambled views.

Why the Research Targets AMD Family 16h

The proof of concept was developed and tested on AMD Family 16h CPUs.

The choice of platform is significant because the repository states that Family 16h is the last AMD generation whose datasheets document the relevant DRAM-controller translation registers and indicate that the registers cannot be locked. AMD Family 17h and later generations leave this information out of the public documentation, according to the project.

This makes the demonstrated platform particularly useful for investigating the memory-controller mechanism.

It also creates an important limitation.

The demonstration should not be interpreted as evidence that the same implementation can simply be transferred unchanged to every current AMD, Intel, ARM or RISC-V processor.

The repository argues that the underlying memory-address transformations extend across generations and architectures and describes the project as showing how to begin applying the technique beyond the tested platform.

Cyber Security News similarly reports that related architectural mechanisms such as channel and rank interleaving, bank swizzling and chip-select mapping exist across AMD, Intel, ARM and RISC-V designs.

However, the sources do not demonstrate equivalent exploitation on all of those architectures.

That distinction is essential.

A Different Kind of Hardware Security Problem

Traditional CPU security research often focuses on vulnerabilities involving software, privilege boundaries, firmware, speculative execution or individual hardware components.

The DRAM scrambling research examines a different layer.

It asks what happens when the address transformation beneath those protections is itself changed.

A simplified representation is:

Security Mechanism

→ Protects physical address A

Memory Controller

→ Changes the physical-to-DRAM mapping

DRAM

→ Address A's original data can become reachable through another alias

The security mechanism has not necessarily been directly disabled.

Instead, the relationship between the protected address and the underlying DRAM location has changed.

That is what makes the research important from a hardware-security perspective.

It suggests that a complete memory security model must consider not only which physical addresses can be accessed, but also how those physical addresses are translated into the actual DRAM coordinates used by the memory system.

The Hardest Part Is Keeping the Platform Stable

Changing a memory mapping while a system is running creates another problem: the rest of the system still expects memory to have its original layout.

The repository describes the practical challenge as keeping the platform operational while temporarily changing the memory mapping. Its demonstration uses carefully controlled processor, cache, TLB, interrupt and memory-ordering conditions around the remapping operation.

This is an important limitation of the research.

The demonstration is not presented as a simple attack that can be casually executed against any computer.

It depends on a specific hardware platform, knowledge of the relevant controller configuration and careful management of system state.

The repository provides implementation material for its tested platform, but the existence of that code does not establish equivalent exploitation on newer processors.

Does This Mean Modern CPUs Are All Vulnerable?

No.

The proof of concept targets AMD Family 16h processors.

The researchers argue that related memory-controller transformations exist across multiple architectures, but that does not establish that every modern CPU can be exploited using the same technique.

Processor generations can differ significantly in memory-controller design, configuration interfaces, documentation, firmware behavior and security architecture.

The strongest conclusion supported by the sources is that DRAM address translation represents a potentially important hardware-security layer that deserves further investigation.

The research demonstrates the issue on the tested AMD platform. It does not establish a universal vulnerability affecting all current processors.

What This Means for Hardware Security

The research raises a broader question for processor designers and security architects:

Where exactly does a hardware security boundary end?

If a security mechanism assumes that a physical address always corresponds to a particular DRAM location, the memory controller becomes part of that security assumption.

This means memory-controller configuration is not necessarily just a performance or system-configuration concern.

It can also become part of the security model.

For enterprises, cloud providers and platform designers, the research reinforces the importance of understanding the complete memory-access pipeline when evaluating hardware-backed isolation.

It also highlights why hardware security cannot be assessed solely through operating-system permissions or software-level access controls.

At the same time, the sources do not provide a general vendor mitigation or security patch for current processor generations.

Additional details were not disclosed by the sources.

What Happens Next?

Cyber Security News reports that the findings are scheduled to be presented in greater detail at Black Hat 2026.

The open-source project provides researchers with a technical foundation for examining DRAM address translation and the relationship between memory-controller behavior and processor security boundaries.

For the wider hardware-security community, an important question will be whether related techniques can be reproduced on newer processor generations where memory-controller documentation is more limited.

The available sources do not provide evidence that equivalent demonstrations have already been completed across current AMD, Intel, ARM or RISC-V processors.

The Bigger Security Lesson

The DRAM scrambling research highlights an often-overlooked principle in hardware security:

Security depends on every layer that contributes to the system's view of memory.

Operating systems can enforce permissions.

Virtualization systems can isolate workloads.

Firmware can reserve protected memory.

Trusted execution technologies can establish hardware-backed boundaries.

But beneath these mechanisms is the physical memory system itself.

The skitter-creek-bath-salts project demonstrates that changing the final physical mapping between addresses and DRAM coordinates can create a different memory view on the tested AMD Family 16h platform.

That does not mean existing CPU security technologies are universally broken.

It does show why memory-controller behavior deserves a place in the broader hardware-security model.

As processor architectures become increasingly dependent on hardware-backed isolation, the layers underneath those security guarantees become just as important as the protections visible to operating systems and applications.

The research therefore represents more than an unusual DRAM manipulation technique. It is a reminder that the security of a memory address depends on every transformation between the CPU and the physical cell that stores the data.