You've probably never thought about how your CPU decides which physical memory chip stores a particular byte. It's one of those "it just works" layers of modern computing—like the postal service or the power grid. But beneath that abstraction lies a complex web of routing decisions, timing constraints, and—as it turns out—secret algorithms that CPU manufacturers would rather you not know about.
For years, security researchers assumed that one of these hidden mechanisms, called DRAM scrambling, made certain types of attacks nearly impossible. The scrambling algorithm was secret. The memory layout was randomized. Surely, that was enough to stop attackers.
It wasn't.
The xoreaxeaxeax/skitter-creek-bath-salts repository on GitHub contains the tools and research that cracked this problem wide open. It reverse-engineers the DRAM scrambling functions on Intel and AMD CPUs, turning a "security feature" into a fully mapped, predictable system. This article explains what DRAM scrambling actually is, why it was never designed to be security, and how this open-source project demonstrates that the emperor has no clothes.
We'll cover the background of DRAM organization, the row hammer attack that scrambling was supposed to mitigate, the reverse-engineering process itself, and what this means for the future of memory security.
Dynamic Random Access Memory (DRAM) is not a single monolithic block. Instead, it's organized as a hierarchy of structures:
When your CPU writes a byte, it doesn't simply say "store this at address 0x7fff1234." The memory controller translates that address into a specific channel, rank, bank, row, and column. This mapping is critical for performance—the controller wants to spread accesses across banks to maximize parallelism and avoid bottlenecks.
Applications use virtual addresses, which are mapped to physical addresses by the CPU's memory management unit (MMU). The physical address is what the memory controller sees. However, the physical address alone doesn't tell you where in the DRAM the data goes—the memory controller applies its own mapping on top of that.
This creates a layering: virtual → physical → DRAM location. Each layer adds its own transformation.
The memory controller sits between the CPU and the DRAM modules. It handles:
The address mapping is where scrambling comes in. The controller applies a function—often involving XOR operations or linear feedback shift registers (LFSRs)—to the physical address bits before selecting the DRAM row and column.
Here's the key insight: DRAM scrambling exists for electrical and performance reasons, not security.
When many adjacent memory locations are accessed in a pattern that hits the same row, the electrical load on the DRAM can cause signal integrity issues. Scrambling distributes accesses across different rows and banks, reducing the chance of electrical interference. It also helps with power distribution—spreading the load across multiple chips rather than hammering one area.
Intel and AMD documentation describe scrambling in terms of "signal integrity optimization" and "power reduction." Security is never mentioned as a design goal.
Key Takeaway: DRAM scrambling is a hardware optimization technique that happens to obfuscate the memory layout. It was never designed as a security control.
Row hammer is a hardware vulnerability in DRAM that was publicly demonstrated in 2014 by researchers at Carnegie Mellon and Intel Labs. The attack exploits a physical property of DRAM: when a row of memory cells is accessed repeatedly at high speed, the electrical disturbance can cause bit flips in adjacent rows.
These aren't theoretical bit flips. They're real, observable changes in memory contents—a 0 becoming a 1, or vice versa—without any direct access to the affected row.
The attack works like this:
The key constraint is that the attacker needs to know which physical addresses map to the same bank and to adjacent rows. Without that knowledge, the attack is blind—you might flip bits, but you can't control where.
The 2014 paper, "Flipping Bits in Memory Without Accessing Them," demonstrated that row hammer could be used to gain root privileges on Linux systems. Since then, the attack has been refined:
When DRAM scrambling was introduced, some researchers believed it would complicate row hammer. If an attacker can't easily determine which physical addresses map to adjacent rows, they can't target their hammering. The scrambling function was secret, so mapping the memory layout would require either reverse-engineering the algorithm or brute-forcing it—both considered infeasible.
This assumption was wrong.
The confusion is understandable. DRAM scrambling looks like encryption. It transforms addresses in a non-obvious way, and the algorithm is secret. But looking like security and being security are very different things.
Here's the fundamental problem: scrambling is designed to be deterministic and reversible. The memory controller needs to map a physical address to a DRAM location and back again. If the mapping were truly random or keyed in a way that changes frequently, the controller couldn't function.
More importantly, the scrambling function is static for a given system. It doesn't change based on runtime state, process, or time. Once you figure out the mapping, it stays the same until the CPU is replaced.
CPU manufacturers keep the scrambling algorithm secret through obscurity, not through cryptographic strength. The algorithm is implemented in hardware, which means it's subject to physical analysis. You can't hide a hardware implementation from someone with the right tools and enough patience.
The security community has a term for this: security through obscurity. It's widely considered a bad practice because it provides no real protection—only the illusion of it.
The skitter-creek-bath-salts research demonstrates that the scrambling function can be recovered using timing side channels. Here's the high-level idea:
This isn't a brute-force attack. It's a clever use of observable physical differences in memory access times.
Key Takeaway: Secret algorithms implemented in hardware are not security. They're just secrets waiting to be discovered.
The repository, created by security researcher Dan Goodin (known as xoreaxeaxeax), provides a complete toolkit for reverse-engineering DRAM scrambling on modern CPUs. The name is a play on "Skitter Creek" (a reference to the author's location) and "bath salts" (a metaphor for the "salty" or randomized nature of the scrambling).
The project's stated goals:
The tools support:
The implementations differ between the two vendors because their scrambling algorithms are fundamentally different. Intel uses a hash-like function, while AMD uses an LFSR-based approach.
The core tool, called skt, works in several phases:
The process is largely automated. On a typical system, it completes in under an hour.
Here's a simplified walkthrough:
The repository includes documentation and scripts to automate this entire process.
The final output is a complete mapping of physical addresses to DRAM coordinates: channel, rank, bank, row, and column. This mapping is what enables targeted row hammer attacks.
The tool also includes a real-time mapper that can translate any physical address to its DRAM location on the fly, with over 99% accuracy.
Key Takeaway: The reverse-engineering process is not theoretical. It's a practical, automated tool that works on real hardware in under an hour.
The most obvious application is offensive: using the DRAM mapping to perform targeted row hammer attacks. With the mapping, an attacker can:
The repository includes demonstrations of successful bit flips on DDR4 memory with ECC disabled.
Consider a scenario where an attacker wants to modify a page table entry to gain access to privileged memory:
This is significantly more powerful than blind row hammer, which relies on luck to hit the right bits.
The tool isn't just for attackers. Hardware vendors and security teams can use it to:
Beyond security, the tool has forensic applications:
Key Takeaway: The tool is dual-use. It enables offensive attacks, but it also strengthens defensive research and testing.
Several mitigations exist for row hammer:
All current mitigations have weaknesses:
The fundamental issue is that DRAM is physically vulnerable to row hammer. No amount of software patching can fix a hardware vulnerability. The long-term solution requires:
The skitter-creek-bath-salts research serves as a wake-up call. It demonstrates that:
Key Takeaway: Row hammer is a hardware vulnerability that requires hardware solutions. DRAM scrambling was never designed to be security, and treating it as such is a mistake.
DRAM scrambling is a performance optimization that happens to obscure memory layout. It was never designed as a security control, and it fails when treated as one. The skitter-creek-bath-salts project demonstrates this conclusively by reverse-engineering the scrambling function on modern CPUs in under an hour.
This research is valuable precisely because it's open. Anyone can download the tools, verify the findings, and build upon the work. This transparency is essential for understanding and addressing hardware vulnerabilities.
If you're a security researcher, hardware enthusiast, or just curious about how your CPU really works, the repository is worth exploring. The documentation is thorough, the tools are practical, and the implications are significant.
Whether you're interested in offensive research, defensive testing, or just understanding the hardware you use every day, there's something here for you. The project welcomes contributions, whether that's code, documentation, or testing on new hardware.
Explore the skitter-creek-bath-salts repository on GitHub and join the research community to better understand and defend against row hammer attacks.
DRAM scrambling is a technique used by memory controllers to transform physical addresses before accessing DRAM. It spreads memory accesses across different rows and banks to improve signal integrity and reduce power consumption. The transformation is deterministic but uses a secret algorithm.
DRAM scrambling is designed for electrical and performance reasons, not security. It's deterministic and static for a given system, and the algorithm is secret only through obscurity. Unlike cryptographic systems, it provides no real protection against determined attackers.
Row hammer is a hardware vulnerability where repeatedly accessing certain DRAM rows causes bit flips in adjacent rows. An attacker can exploit this to modify memory contents without direct access to the affected memory, potentially leading to privilege escalation.
The tool uses timing side channels to identify which physical addresses map to the same DRAM rows. It measures memory access times to detect row buffer hits and misses, then uses this data to reconstruct the scrambling function. The process is automated and takes under an hour.
Yes, for researchers with basic Linux experience. The repository includes documentation, scripts, and a user-friendly interface. It requires root access to allocate memory and read physical address mappings, but the process is largely automated.
Scrambling itself doesn't need to be fixed—it works fine for its intended purpose. What needs to change is the assumption that it provides security. Future systems should either implement cryptographically strong scrambling or rely on other mitigations for row hammer.
No. The tool currently supports Intel Sandy Bridge through Coffee Lake and AMD Zen through Zen 2. Newer CPUs may use different scrambling algorithms. However, the methodology can be extended to support additional generations.
The research is legal and was presented at major security conferences including DEF CON and Black Hat. The tools are for educational and research purposes. Using them to attack systems without permission would be illegal, but studying the research is not.
The research shows that DRAM scrambling does not provide meaningful security against row hammer attacks. This has implications for anyone who assumed that memory layout obscurity was a defense. It also highlights the need for hardware-level mitigations.
The repository is publicly available on GitHub at xoreaxeaxeax/skitter-creek-bath-salts. It includes the tools, documentation, and research findings.