AMD’s Old DRAM Swizzle Is Real. the Universal Break Is Not

Skitter Creek Bath Salts is a credible proof of concept for AMD Family 16h processors: with privileged access, it can alter a DRAM controller’s address mapping and calculate an ordinary physical-address alias for data in protected memory. That is a serious result on the hardware it tested—but it is not yet a demonstrated defeat of memory protections across modern AMD, Intel, ARM, or RISC-V systems.

The unusually named project, published on GitHub by xoreaxeaxeax, claims to reach Platform Security Processor (PSP) private DRAM, System Management Mode (SMM) memory, C6 save-state DRAM, and microcode-related paths by changing how the memory controller translates an address into the row, column, bank, rank, and channel signals sent to DRAM. Its developers say it was developed and tested on AMD Family 16h CPUs, an older generation whose controller registers were documented in public AMD manuals.

“Poke the DRAM controller and an address can be made to land wherever you want in memory.”
— Skitter Creek Bath Salts repository

That wording is deliberately maximalist. The evidence beneath it is narrower and more useful: a root-level actor on a tested Family 16h machine can tamper with a documented controller setting below the physical-address fences that normally separate privileged memory regions. The project’s broader claims about AMD Family 17h and newer, ARM, and RISC-V are extrapolations; the repository does not show reproductions on those platforms.

AMD’s documented BankSwizzleMode register enables the tested remap

The crucial mechanism is not a mysterious DRAM flaw. AMD’s 2015 Family 16h BIOS and Kernel Developer’s Guide documents D18F2x94’s BankSwizzleMode as a read-write DRAM-controller field. AMD describes the setting as an XOR-based transformation of bank-address bits using other physical-address bits—a performance-oriented remapping intended to distribute memory traffic more effectively.

Skitter Creek Bath Salts changes that final translation step. A CPU instruction starts with a virtual address, which the operating system translates into a physical address. Hardware protections can then forbid software from issuing requests to physical ranges reserved for SMM or the PSP. But after that check, the memory controller still converts the physical address into DRAM coordinates. Change the conversion, and an address permitted by the fence can end up at the same DRAM cell as an address behind it.

That is physical-address aliasing: two physical addresses that software treats as different locations resolve to one underlying DRAM location after the controller mapping changes. The project’s collection tooling experimentally maps those aliases, then uses an accessible alias to read or write a protected target where one exists.

The repository frames the security consequence bluntly:

“The fences guard physical addresses, not DRAM coordinates; rearrange the coordinates and the barriers above never notice.”
— Skitter Creek Bath Salts repository

That reasoning fits the documented hardware behavior on the tested generation. AMD’s manual establishes that the bank-swizzle control exists, is writable, and changes address-bit relationships; the project supplies the attack workflow that treats the altered mapping as a solvable aliasing problem.

The attack is also much less turnkey than “change one bit, own the CPU” suggests. The supplied userspace tools run as root and rely on a kernel module to manipulate DCT/MCT controller state. This is not an unprivileged operating-system escape, and it is not presented as a remote exploit.

Keeping a machine alive while its memory map changes beneath it is the project’s operational challenge. Its usage guide describes calibrating the system, collecting an alias map for the particular machine, and matching that map against a firmware fingerprint of the live controller state. The tool refuses a mismatched map by default, because a solved mapping is specific to the hardware and firmware configuration that produced it.

Nor is every calculated alias usable. The guide says some aliases land in a protected carveout themselves; those locations remain inaccessible and are reported as “holes” in the collected map. Its collection workflow also includes remotely power-cycling a target if alias collection hangs, a practical admission that the experiments can destabilize the platform.

The project’s headline targets are specific:

PSP private DRAM, which the AMD security coprocessor uses outside normal OS control.
SMRAM, the memory used by SMM firmware handlers.
C6 save-state DRAM, used when CPU cores enter a deep idle state.
Microcode-related memory paths, another class of privileged state the project says its method can approach.

Those demonstrations matter because they test the boundary below the kernel, where ordinary page permissions and reserved-memory maps assume a physical address continues to mean what the CPU thinks it means. But the account remains the project authors’ account: the supplied material contains no independent reproduction, vendor advisory, CVE, or evidence of exploitation on AMD Family 17h or newer, Intel, ARM, or RISC-V hardware.

AMD stopped publicly documenting the relevant translation registers after Family 16h, according to the project repository. That absence is not evidence that newer platforms retain a writable equivalent—or that they do not. The next meaningful result is not a broader claim about “everything”; it is a reproduced alias map on a newer controller, with the register path and access controls shown.

Key Takeaways

Skitter Creek Bath Salts demonstrates DRAM-controller aliasing on AMD Family 16h systems.
AMD’s 2015 documentation lists the Family 16h BankSwizzleMode control as read-write.
The technique changes the final physical-address-to-DRAM mapping beneath higher-level memory fences.
The supplied tooling requires root access, a kernel module, and machine-specific calibration.
The project has not demonstrated the technique on current AMD, Intel, ARM, or RISC-V hardware.