A new open-source hardware-security project shows how changing one layer of a computer’s memory map can expose regions that are supposed to remain hidden even from the operating-system kernel. The research toolkit, called skitter-creek-bath-salts, was developed and tested by security researcher Christopher Domas on AMD Family 16h processors. It includes code to read and write protected DRAM used by the Platform Security Processor, System Management Mode and CPU power-management state.
The release matters because it attacks an assumption below the familiar hierarchy of applications, kernels and firmware. Those layers enforce access controls against physical addresses. Domas’s technique temporarily changes how the memory controller converts those addresses into actual DRAM locations, creating alternate addresses for data behind the boundary.
This is not a remote takeover recipe or evidence that every modern processor has the same flaw. The published toolkit runs as root, loads a Linux kernel module and supports a specific, older AMD processor family. Its broader value is as a working demonstration that memory-controller configuration belongs inside the security boundary, not merely the performance-tuning machinery around it.
The last translation before DRAM
Software does not address a DRAM chip directly. A virtual address passes through page tables and, where applicable, a second translation layer for a virtual machine. The resulting physical address still goes through caches, the interconnect and the integrated memory controller. That controller decides which channel, rank, bank, row and column will hold the request.
Skitter Creek operates at this final stage. On the tested processor, the toolkit changes bank-swizzle and bank-swap settings in the DRAM controller. AMD’s archived Family 16h BIOS and Kernel Developer’s Guide documents BankSwap as a read-write field that exchanges normalized address bits before BankSwizzleMode is applied. These mechanisms ordinarily spread accesses across memory hardware. Changing them while the system is live also changes where a physical address lands.
That sounds like a direct route to a crash, and it often would be. The project’s kernel code prepares the narrow operation by disabling other processors and interrupts, warming the relevant caches and translation lookaside buffers, and avoiding ordinary DRAM access during the switch. It flips the controller state, performs a targeted read or write through the altered mapping, then restores the original state. The repository describes the core change as a single bit operation, but the surrounding choreography is what keeps the machine coherent long enough to use it.
The security consequence follows from where the change occurs. A protected range such as System Management RAM is fenced in the physical-address map. If the controller is made to route a different, unfenced physical address to the same DRAM cell, the request can arrive without crossing the fence that protects the original address.
Turning scrambled memory into a usable map
Changing the translation is only half the problem. Once bank selection and swizzling change, an operator does not automatically know where any particular byte has moved. Processor documentation is incomplete for this purpose, and the exact map varies with the machine’s memory topology.
Domas treats the controller’s address transform as linear algebra over bits. The toolkit writes sentinel values while the controller is in one state, restores the firmware’s state, and searches for where those values reappear. Each match supplies a pair: two physical addresses that resolve to the same underlying DRAM cell under different controller settings. After collecting enough pairs, the analysis scripts use the Z3 solver to infer a transform.
The project’s toolchain guide divides that workflow into utilities that inspect controller state, discover protected carve-outs, gather alias pairs, solve the map, and finally dump or modify a chosen protected range. Multiple maps can be combined because one controller configuration may leave gaps that another can reach. The guide also includes a remote collector that can power-cycle a target through a network-controlled power unit when a mapping experiment hangs the machine. That detail is a useful measure of the project’s maturity: this is hands-on research software for a lab system, not a diagnostic to try on a daily-use computer.
What the toolkit says it can expose
The repository provides worked examples for four targets. The first is the AMD Platform Security Processor, or PSP, a separate embedded processor involved in platform initialization and security functions. Domas says he recovered PSP code from its private DRAM, including an RSA modular-exponentiation routine used by firmware TPM operations. The claim and disassembly are published by the researcher; the repository does not link an AMD validation of the result.
A second example reads the entry code for System Management Mode. SMM is an x86 execution environment below the operating-system kernel, entered to handle low-level platform work. Its memory, SMRAM, is designed to be inaccessible outside that mode once locked. Skitter Creek calculates an alias for the handler’s physical location and feeds the resulting bytes to a disassembler.
The third target is DRAM used to save per-core state when a processor enters the C6 low-power state. The published output identifies recognizable register values in those save areas. The fourth follows from that discovery: the project says a copy of the active microcode patch is stored in the C6 area so it can be restored when the core wakes. Its tools can read that copy, and the documentation says the same aliasing method can write to it.
Those examples are more consequential than a conventional kernel memory disclosure because they cross boundaries intended to remain meaningful after an attacker obtains kernel privilege. PSP memory, SMRAM and microcode state sit in different trust domains, yet all eventually depend on where the memory controller sends an address. The release shows one way a shared hardware dependency can collapse several boundaries together.
Serious result, narrow demonstrated scope
The most important constraint is also the simplest: Skitter Creek does not provide initial access. Its documentation says to run the tools as root, and the build produces a kernel module that performs privileged hardware operations. An attacker would therefore need a separate route to kernel-level execution or equivalent control before applying this technique. What the method may add is access to secrets and code that kernel compromise alone is not supposed to reveal or alter.
Hardware scope is similarly limited. Domas says development and testing were done on AMD Family 16h, the last family for which the needed translation registers were described in sufficient detail in public documentation. The repository argues that later AMD designs and processors from other architectures use broadly similar chains of interleaving and address transforms. That is a research direction, not proof that the same controller settings are writable, unlocked or exploitable elsewhere. Newer platforms may expose different registers, restrict them, or protect the relevant data with mechanisms that change the outcome.
The public project also does not identify a CVE, vendor advisory or mitigation. It is an MIT-licensed research release with source for the kernel component, userspace tools and analysis scripts, plus data for tested memory configurations. GitHub showed roughly 1,700 stars within days of publication, a strong signal that low-level developers and security researchers see the technique as worth examining. Stars are attention, however, not independent reproduction.
There are immediate defensive questions even within the demonstrated family. Firmware could treat memory-controller translation state as security-sensitive after DRAM training, prevent later writes where hardware allows it, or monitor unexpected changes. Whether a durable fix can be delivered in firmware depends on controls available in each processor and platform. The repository does not make a general mitigation claim.
What to watch next
The project points to a forthcoming Black Hat 2026 presentation called “Spaghettifying DRAM.” The useful next evidence will be independent replication on the documented Family 16h systems, a clear inventory of affected processor and firmware combinations, and a response from AMD on whether controller registers can be locked or monitored. Attempts to extend the technique to newer AMD generations or other architectures will also need to separate a common architectural pattern from an exploitable implementation. Until then, Skitter Creek is best understood as a sharp proof on specific hardware: the address map below the kernel can be a security boundary of its own, and on the tested chips that boundary can be rewritten.