skitter-creek-bath-salts on GitHub (xoreaxeaxeax/skitter-creek-bath-salts)

What is this?

A security research project that shows how to unlock protected regions on an AMD CPU — the Platform Security Processor, System Management Mode, C6 DRAM, and CPU microcode — by scrambling the DRAM controller's physical-to-DRAM address translation.

Is this a working tool or just a technical write-up?

Both: it is a detailed technical essay explaining the memory-controller address-translation attack, accompanied by C code (built with make) that demonstrates the exploit running on real hardware.

How do I actually run this proof-of-concept?

You build the C source with make and run it on a physical AMD Family 16h machine; the code directly reprograms the memory controller's MCT/DCT translation registers at runtime (e.g. `xor dword [0xf80c2094], 0x00400000`) to scramble DRAM addressing.

Does this need special AMD hardware?

Yes — it is developed and tested specifically on AMD Family 16h CPUs, the last generation whose public datasheets document the DRAM controller's translation registers.

Does the attack work on newer AMD CPUs too?

Not out of the box — starting with 17h, AMD stopped documenting these translation registers in its datasheets, so the exact technique shown here is specific to Family 16h, even though the author believes the underlying idea extends to other architectures.

Do I need to be a hardware security researcher to make sense of this?

Yes — it assumes deep familiarity with physical memory addressing, DRAM controllers, cache/TLB behavior, and CPU microarchitecture; it is not a plug-and-play security tool.

How does flipping one DRAM controller bit break CPU security?

Every hardware security mechanism (PSP, SMM, C6, microcode locks) enforces access control on physical addresses, but the memory controller remaps those physical addresses to raw DRAM coordinates one more time below all of them; changing that final remap moves protected data to a new location the security checks never see, so `&x != &x` and the fences above never notice.

How does the attack reconstruct where data actually landed after scrambling memory?

Because the DRAM controller's address transform is linear over GF(2), the project composes the inverse of the scrambled transform with the forward of the normal transform using linear algebra, letting it calculate exactly which alias address reaches a given secret in DRAM.

Does scrambling all of DRAM crash the machine?

No — the code disables the other CPU cores and interrupts, primes caches and TLBs, performs the remap and memory access, then reverts the mapping and resumes normal operation, so the platform returns to a working state afterward.

Is this limited to AMD, or could it apply to other CPU architectures?

The demonstrated exploit targets AMD, but the author states the same underlying address-scrambling idea extends to ARM, RISC-V, and other architectures, calling this project only a starting point.

What are similar projects?

dirtyfrag, Relapse-Exploit, UniRoot, Claude-Red, x64dbg, exploitarium, h4cker, copy-fail-CVE-2026-31431

Which topics is it in?

vulnerability-research, exploitation, bare-metal, exploit-development, x86-64, cpu, x86, infosec, vulnerability, exploit, hacking-tool, offensive-security

Creator: xoreaxeaxeax
Size: 3.8 MB
Stars: 2.1K
Updated: CommitAug 13
Age: 2mo
Commits · 90 Days

skitter-creek-bath-salts README

skitter-creek-bath-salts

TL;DR

Target

The odyssey of `*p`

Spaghettifying DRAM

Unlocking everything