Spaghettifying DRAM: A Groundbreaking Hardware Security Exploit That Unlocks Everything

Introduction

Christopher Domas, one of the most respected security researchers in the field, has released a groundbreaking exploit that fundamentally challenges our understanding of CPU and memory security. The project, titled “skitter-creek-bath-salts” and presented as “Spaghettifying DRAM,” demonstrates how manipulating DRAM controller address translations can bypass virtually every security mechanism built into modern processors. With 637 points and 164 comments on Hacker News, the security community is both fascinated and alarmed by the implications.

The Fundamental Problem: The Odyssey of *p

At the heart of this exploit lies a deceptively simple observation: when your code dereferences a pointer *p, it doesn’t actually access DRAM at address p. Instead, p is a virtual address that must survive an incredibly complex gauntlet of transformations before a single bit of DRAM is touched.

The journey from virtual address to physical DRAM involves:

• CPU Core/MMU: Canonical form checks, segment base additions, TLB probes
• Page Walking: Multi-level page table traversals with privilege checks
• Per-Level Checks: Evaluating privilege (U/S), write permissions (R/W), execute permissions (NX), SMEP/SMAP, and protection keys
• Guest Virtualization: EPT/NPT re-walks for virtualized environments
• IOMMU: Device-initiated memory access translations
• Memory Type Resolution: MTRR range matching and PAT entry selection
• Cache Hierarchy: L1-D, L2, and LLC probes with coherence protocols
• System Data Fabric: Interconnect routing through mesh or ring topologies
• Memory Controller (MCT/DCT): Final address remapping before DRAM coordinates are issued

Every layer of this pipeline is designed to enforce security boundaries. Yet Domas’ research shows that the final layer — the memory controller — can be manipulated to bypass all the protections built above it.

The Exploit: One Bit to Rule Them All

The core exploit is deceptively simple:

xor dword [0xf80c2094], 0x00400000

This single instruction flips one bit in the DRAM controller’s bank-swizzle-mode register, fundamentally rewiring how physical addresses are translated into DRAM coordinates. The result: &x != &x. A pointer no longer points to where it should.

The genius of this approach lies in understanding that security fences guard physical addresses, not DRAM coordinates. By rearranging the coordinates at the lowest level of the memory hierarchy, all the protections built above — from page tables to SMM locks to PSP isolation — become irrelevant.

The Challenge: Keeping the System Alive

While rewiring DRAM is easy, keeping the platform functional while doing so is the real challenge. Domas’ solution involves:

1. Disabling Application Processors (APs): Prevent other cores from accessing corrupted memory
2. Priming TLBs: Pre-load translation lookaside buffers with necessary mappings
3. Warming the Cache: Ensure critical instructions are cached
4. Disabling Interrupts: Prevent context switches during the vulnerable window
5. Flushing Targets: Evict specific cache lines to force DRAM reads
6. Serializing Memory Access: Use memory barriers to prevent reordering
7. Executing the Exploit: Flip the DCT bit, read protected data, flip it back
8. Restoring State: Re-enable interrupts and APs

The entire operation must complete without touching DRAM in the spaghettified view, relying entirely on cached instructions and data.

Solving the Unknown: Linear Algebra to the Rescue

The most elegant aspect of this research is how Domas solves the fundamental problem: without knowing the exact DRAM controller transformation matrices, how can you calculate which alias addresses reach protected memory?

The answer: the DRAM controller’s address transform is a GF(2) linear map. By:

1. Gathering Alias Pairs: Switching between coherent and spaghettified views, dropping sentinel values into memory, and finding where they resurface
2. Feeding Data to Z3: Using an SMT solver to reconstruct the transformation matrices from concrete (target, alias) pairs
3. Computing the Inverse: Using linear algebra to derive the translation that converts any coherent-view address to its spaghettified-view alias

This approach transforms an impossible problem — reverse-engineering unknown hardware transforms — into a solvable system of linear equations.

Unlocking Everything: Protected Memory Regions

With the transformation matrix solved, Domas demonstrates access to virtually every protected memory region on the platform:

Platform Security Processor (PSP)

The PSP’s private DRAM carveout, containing the fTPM and cryptographic operations, becomes readable. The research includes extracting the PSP’s RSA modular-exponentiation routine — the engine behind every fTPM signature — directly from protected memory.

System Management Mode (SMM)

SMRAM, the ultra-privileged memory where ring -2 code executes, can be read and modified. The SMI entry stub and handler code become visible, despite being locked by the chipset.

C6 DRAM

When CPU cores power-gate into C6 idle states, their full x86 architectural context is stashed in protected DRAM. This includes:

• General-purpose registers
• Control registers (CR3, etc.)
• Model-specific registers (MSRs)
• APIC state
• MTRR configurations
• Saved instruction pointers

CPU Microcode

The microcode patch RAM, volatile SRAM that goes dark during C6, is backed up in protected DRAM. This copy can be read, modified, and will be reloaded when the core wakes from idle.

Target Hardware and Limitations

The exploit is developed and tested on AMD Family 16h CPUs (Jaguar architecture from 2013), the last generation whose datasheets document the DRAM controller’s translation registers and show they cannot be locked.

AMD Family 17h and beyond intentionally omit this information from public datasheets. However, the underlying principles apply across architectures:

• AMD: Zen and beyond use different memory controller IP (UMC) configured by AGESA/PSP
• Intel: Similar channel/rank/bank interleaving and swizzle mechanisms
• ARM/RISC-V: Comparable memory controller architectures

Modern CPUs likely have protections in place — firmware-locked registers, different controller designs — but the fundamental vulnerability remains: the final stage of the address translation pipeline is a potential weak point.

Security Implications

This research has profound implications for:

Confidentiality

Any data in DRAM, regardless of how well-protected by software, can potentially be accessed if the DRAM controller can be manipulated.

Integrity

Protected code regions (SMM, PSP, microcode) can be modified, enabling persistent, undetectable malware.

Attestation

Cryptographic attestations based on protected memory can be forged by modifying the underlying data.

Encryption

While some modern systems encrypt DRAM, the encryption keys themselves must be stored somewhere — often in the same DRAM being protected.

The Shared Pipeline

Domas emphasizes that while this specific exploit targets AMD Family 16h, the underlying pipeline is universal:

• Channel interleave, rank interleave, bank interleave, swizzle, chip-select normalize
• Every modern memory controller implements some version of these transforms
• Every platform — AMD, Intel, ARM, RISC-V, mobile, server, embedded — has this architectural shape

Above this pipeline sits SEV, SGX, TDX, TrustZone, CCA realms, pKVM, CoVE, SEP, PSP, ME, T-SEG, SMRAM, and C6 stash. Everything sitting in DRAM rests on the final layers of a *p pipeline that has just begun to be explored.

Practical Tools and Methodology

The research includes practical tools for exploitation:

dram_read

Simple read from a protected memory address by flipping DRAM controller bits.

dram_poke

Write into protected memory ranges using solved spaghettification maps.

dram_dump

Read entire protected memory regions using GF(2) pseudo-inverse calculations.

gather_aliases.py

Collect alias pairs by switching between coherent and spaghettified views.

unspaghettify.py

Use Z3 to solve transformation matrices from gathered alias data.

The complete toolchain is available at: https://github.com/xoreaxeaxeax/skitter-creek-bath-salts

Community Reception

The Hacker News discussion reveals several themes:

Admiration for the Research

Domas’ previous work (MoVfuscator, Hardware Backdoors in x86, Psychological Warfare in Reverse Engineering) has established him as a master of low-level systems research. This work maintains that standard.

Concerns About Scope

Many commenters questioned whether this applies to modern CPUs. The answer appears to be: probably not directly, but the principles are universal and likely exploitable with sufficient effort.

Appreciation for Methodology

The use of linear algebra and SMT solvers to reverse-engineer unknown hardware transforms is elegant and generalizable.

Disappointment with Documentation

Some noted that while the technical content is sound, the README appears to be AI-generated, lacking the clarity and personality of Domas’ previous work.

Conclusion

“Spaghettifying DRAM” represents a watershed moment in hardware security research. By demonstrating that the final stage of the memory address translation pipeline can be weaponized to bypass all higher-level protections, Domas has fundamentally challenged assumptions about CPU security.

While the specific exploit targets older AMD hardware, the implications are universal. Every modern processor implements similar memory controller transforms, and the underlying vulnerability — that security fences guard addresses, not DRAM coordinates — applies everywhere.

For security researchers, this work opens new avenues of investigation. For hardware manufacturers, it’s a stark reminder that security cannot be achieved through obscurity alone. For end users, it underscores the importance of keeping systems updated and understanding that “protected” memory may not be as protected as assumed.

The research is a masterclass in creative problem-solving: taking an impossible problem (reverse-engineering unknown hardware transforms) and solving it through elegant application of linear algebra and SMT solvers. Whether or not modern CPUs are vulnerable to this specific attack, the methodology and insights will likely influence security research for years to come.

As Domas concludes: “Flip one bit in the final level of the *p pipeline, and we’ve unlocked everything.”