logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·02.11.26
← Back to news

Spaghettifying DRAM

Original article
github.com|289 points|83 comments|by matt_d|Aug 13, 2026

Spaghettifying DRAM

This project, hosted on GitHub as xoreaxeaxeax/skitter-creek-bath-salts, focuses on the total liberation of CPU resources through the manipulation of DRAM scrambling. By targeting the memory controller, it aims to expose every hidden corner of the processor—including the PSP, C6, SMM, and microcode—effectively bypassing the restrictions defined in official specifications.

Core Concept: By "poking" the DRAM controller, a specific memory address can be redirected to land anywhere in the physical memory.

The skitter-creek-bath-salts tool operates at the lowest strata of the memory hierarchy. It rewires how physical DRAM addresses are translated, which essentially "scrambles" the platform memory. This process reveals protected DRAM "carveouts" that remain invisible even to the operating system kernel. Once these translation primitives are broken, the security mechanisms relying on them collapse, granting full access.

🔓 The Unlock List

Target ComponentDescription
PSPPlatform Security Processor
SMMSystem Management Mode
C6 DRAMDeep sleep state memory
MicrocodeThe CPU's internal instruction translations

🎯 Target Hardware & Scope

The project was developed and validated on AMD Family 16h CPUs. These specific processors were chosen because their datasheets explicitly document the translation registers of the DRAM controller and, crucially, reveal that these registers cannot be locked are unlockable.

While this implementation focuses on AMD, the "odyssey of *p" (the journey of a pointer) is a universal concept. Similar transformations exist across:

  • AMD (various generations)
  • Intel architectures
  • ARM-based systems
  • RISC-V implementations

skitter-creek-bath-salts serves as the foundational proof-of-concept for this approach.


🌌 The Absurdity of Memory Abstraction

Memory access is far more complex than it appears. When a programmer dereferences a pointer *p, they assume they are accessing DRAM at location p. In reality, p is merely a Virtual Address (VA) that must survive a grueling gauntlet of translations and checks.

The Memory Pipeline Journey

The following diagram illustrates the path from a virtual address to the actual electrical coordinates on a DIMM:

Detailed Breakdown of the Gauntlet

  1. MMU Layer:

    • The system performs a canonical-form check on bits [63:48][63:48][63:48].
    • It adds the segment base (via MSR_FS_BASE or MSR_GS_BASE).
    • It probes the TLB (tagged by PCID/VPID).
    • On a miss, the page walker traverses the hierarchy: PML5→PML4→PDPT→PD→PT→PTE\text{PML5} \rightarrow \text{PML4} \rightarrow \text{PDPT} \rightarrow \text{PD} \rightarrow \text{PT} \rightarrow \text{PTE}PML5→PML4→PDPT→PD→PT→PTE
    • Security Checks: The CPU evaluates privilege (U/S), write permissions (R/W), and execution rights (NX), alongside SMEP, SMAP, and protection keys (PKRU).
  2. I/O and Type Resolution:

    • If the access is device-initiated, the IOMMU (VT-d/AMD-Vi) performs its own walk.
    • The memory type is determined by matching IA32_MTRR_DEF_TYPE and IA32_PAT entries to decide if the memory is Write-Back (WB), Uncacheable (UC), etc.
  3. The Uncore and Fabric:

    • Data passes through L1, L2, and the shared LLC.
    • Coherence is maintained via MESI or MOESI protocols across the Infinity Fabric or QPI/UPI.
  4. The MCT/IMC (The Target Zone):

    • This is where the "spaghettification" happens. The Memory Controller takes the physical address and applies:
      • Remapping: Handling DRAM holes and reserved regions.
      • Hashing: XORing bits to determine the channel, rank, and bank.
      • Scrambling: Applying vendor-specific XOR scrambles and bank swizzles.
      • Normalization: The DCT maps the rank to the final Chip-Select line.

🍝 Conclusion: Physical Addresses as Suggestions

This project operates at the absolute deepest level of the *p pipeline: the MCT/DCT layer. This is the final stage where a physical address from the interconnect is rewritten into raw DRAM coordinates (Bank, Row, Column) sent to the DIMM.

In this context, physical addresses are absolute physical addresses are merely suggestions. By flipping a single bit in the DRAM controller, the entire memory map can be distorted, allowing the user to point a standard memory access at a highly protected, "invisible" region of the hardware.

// Conceptual representation of the "scramble"
void spaghettify_dram() {
    uint64_t target_reg = MCT_TRANSLATION_REG;
    uint64_t scramble_mask = 0xDEADBEEFCAFEBABE;
    
    write_msr(target_reg, scramble_mask); 
    // Now, physical address 'k' maps to 'hidden_region_x'
}

DRAM Scrambling Visualization