Domas Turns DRAM Scrambling Into a Skeleton Key

For thirty years, "physical address" has been the floor of the stack. It's where the abstractions stop and the silicon begins — the coordinate every hypervisor, every secure enclave, every System Management Mode lockdown ultimately trusts to mean this exact capacitor, and no other. Christopher Domas just showed that floor has a trapdoor, and the DRAM controller has been holding the key the whole time.

His new release, skitter-creek-bath-salts, reaches past the physical address into the layer nobody audits: the translation the memory controller applies to turn a physical address into an actual DRAM coordinate — rank, bank, row, column. That mapping isn't identity. Controllers deliberately swizzle and interleave it for signal integrity and bank-level parallelism. Domas's insight is that if you rewrite the swizzle, you change where a given physical address physically lands — and you can make two different physical addresses alias the same DRAM cell, or make one address reach a cell it was never supposed to touch.

Why the fences don't hold

The payoff is that the CPU's most sacred memory regions turn out to be guarded at the wrong layer. AMD's Platform Security Processor keeps private firmware in DRAM. SMRAM holds the ring -2 SMI handlers. C6 idle state and microcode patches also live in ordinary capacitors. Every one of those is fenced off — but the fence checks the physical address against the coherent view of memory. It never checks the DRAM coordinate. Build a scrambled alias that resolves to the same cell through a different physical address, and you walk straight in. The guards are watching the front door while the data sits in a room with a second entrance nobody drew on the map.

The whole exploit reduces to something almost insultingly small — a single register write, xor dword [0xf80c2094], 0x00400000, flips an interleave bit and the address space folds. The hard part isn't triggering it; it's aiming it. The scrambling transform is undocumented, so Domas recovers it as a system of linear equations over GF(2): plant sentinel values, hunt for where they reappear under a modified mapping, collect enough target/alias pairs, and hand the lot to the Z3 SMT solver to reconstruct the matrix. Out comes a --map file that translates any protected address into the alias that reaches it. With it, he dumps PSP firmware including its RSA routines, reads SMI entry vectors, and edits live microcode patches out of DRAM.

This is the Domas pattern, one layer down

If this feels familiar, it should. Domas has spent a decade proving that whatever you think the bottom of the machine is, it isn't. sandsifter fuzzed x86 and found instructions Intel never documented. project:rosenbridge uncovered an entire hidden RISC core inside a VIA CPU. "The Memory Sinkhole" reached ring -2 by abusing the APIC's physical placement. The through-line is always the same: security models are drawn at the documented boundary, and the real boundary is a layer below it, built out of optimizations engineers never expected anyone to weaponize. Bank interleaving exists to make DRAM fast. It also, it turns out, makes the address space a lie you can rewrite.

That reframing is the actual news here, more than any single secret extracted. Confidential-computing pitches — SEV, TDX, TrustZone-style isolation — all rest on the premise that if you encrypt or fence a physical page, the attacker who controls software still can't reach the plaintext bytes. Domas's work is a reminder that the memory controller sits underneath that premise, unaudited and, on this hardware, unlockable.

What developers should actually take from it

Be precise about the threat model before you panic. This is not a privilege escalation. You need ring 0 already — the ability to poke controller registers means you're the kernel or you own the platform. What it buys an attacker who's already there is the jump from ring 0 to ring -2/-3 and to hardware secrets that were supposed to survive a fully compromised OS. For a rootkit author or a firmware-implant team, that last hop is the entire game. For your web app, it changes nothing.

And the honesty check: this was built and tested on AMD Family 16h — Jaguar/Puma, circa 2013 — chosen precisely because it's the last generation whose datasheets document these translation registers and show they can't be locked. Family 17h (Zen) onward simply omits the documentation and moved to the UMC controller IP. So the load-bearing question the release doesn't answer is whether modern parts merely hid these registers or actually locked them. Security through omitted datasheets is not security; a determined reverse-engineer finds undocumented registers for a living — see every project above. If Zen only obscured the interface, this technique is a dormant primitive waiting for someone to redo the calibration. If AMD locked the registers at boot, it's a beautiful museum piece. Nobody outside AMD can say yet, and that uncertainty is exactly where I'd point a platform-security team's next audit.

One footnote the community couldn't stop circling: the README reads like it was polished by a language model — the rule-of-three cadence, the relentless em dashes — a jarring break from Domas's usual voice. It's a small thing, but a telling one for a field where the artifact's provenance is part of its trust. The exploit is real regardless. It's just worth noticing that even the researchers who tear open silicon for sport now sound, in print, like everyone else.

The register write is trivial. The idea underneath it isn't: the address you trusted was only ever a suggestion, and the memory controller was always free to route around you.