xoreaxeaxeax/skitter-creek-bath-salts: Unlocking Everything on the CPU with DRAM Scrambling

Introduction

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.

Background: DRAM and Memory Addressing

How DRAM Is Organized: Rows, Banks, Columns

Dynamic Random Access Memory (DRAM) is not a single monolithic block. Instead, it's organized as a hierarchy of structures:

Channels: Independent memory buses connecting the CPU to memory modules.
Ranks: Groups of chips on a module that are accessed together.
Banks: Independent sub-arrays within a chip that can be accessed in parallel.
Rows and columns: The actual grid of memory cells within each bank.

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.

Physical vs. Virtual Addresses

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 Role of the Memory Controller

The memory controller sits between the CPU and the DRAM modules. It handles:

Scheduling: Deciding which pending memory request to service next.
Refresh: Periodically recharging DRAM cells to prevent data loss.
Address mapping: Translating physical addresses into DRAM coordinates.

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.

Why Scrambling Is Used: Performance and Signal Integrity

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.

The Row Hammer Attack: A Primer

What Is Row Hammer?

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.

How Row Hammer Exploits DRAM Bit Flips

The attack works like this:

An attacker identifies two rows in the same DRAM bank.
The attacker repeatedly reads (or writes) those rows, thousands of times per second.
The electrical disturbance causes bits in the row between them to flip.
If the flipped bits are in privileged memory (e.g., a page table entry), the attacker can gain unauthorized access.

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.

Historical Context: From 2014 to Present

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:

2015: Google's Project Zero demonstrated a reliable row hammer exploit.
2016: Researchers showed row hammer could work on DDR4 with some mitigations.
2018: "RAMBleed" showed that row hammer could be used to read data from other processes.
2019: The skitter-creek-bath-salts research showed how to break DRAM scrambling, enabling targeted attacks.

Why DRAM Scrambling Was Thought to Be a Defense

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.

DRAM Scrambling: Not a Security Feature

The Misconception: Scrambling as Security

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.

Why Scrambling Is Not Designed for Security

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.

The Secret Algorithm Problem

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.

How Side-Channel Attacks Can Break Scrambling

The skitter-creek-bath-salts research demonstrates that the scrambling function can be recovered using timing side channels. Here's the high-level idea:

The DRAM row buffer caches the most recently accessed row in each bank.
Accessing a row that's already in the buffer is faster than accessing a different row.
By carefully timing memory accesses, an attacker can determine which physical addresses map to the same DRAM row.
With enough measurements, the attacker can reconstruct the full scrambling function.

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.

Inside skitter-creek-bath-salts

Project Overview and Goals

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:

Demonstrate that DRAM scrambling is not a security boundary.
Provide open-source tools for mapping physical addresses to DRAM rows.
Enable researchers to study row hammer attacks and mitigations.

Supported CPUs: Intel and AMD Generations

The tools support:

Intel: Sandy Bridge (2011) through Coffee Lake (2017).
AMD: Zen (2017) through Zen 2 (2019).

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.

How the Tool Works: Timing Side-Channels and Memory Access Patterns

The core tool, called skt, works in several phases:

Row buffer detection: It measures access times to different physical addresses to identify which ones share a DRAM row buffer.
Bank identification: By analyzing access patterns, it determines which addresses map to the same bank.
Scrambling function recovery: Once enough data points are collected, the tool fits a mathematical model to the observed mapping, recovering the full scrambling function.

The process is largely automated. On a typical system, it completes in under an hour.

The Reverse-Engineering Process Step by Step

Here's a simplified walkthrough:

Allocate a large memory buffer and obtain its physical addresses.
Time memory accesses to different addresses within the buffer.
Identify row buffer hits (fast accesses) vs. misses (slow accesses).
Build a graph where nodes are addresses and edges represent "shares a row."
Use graph analysis to identify rows and banks.
Fit a polynomial or LFSR model to the observed mapping.
Verify the model by predicting the mapping for new addresses.

The repository includes documentation and scripts to automate this entire process.

Output: Mapping Physical Addresses to DRAM Rows

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.

Practical Applications and Demonstrations

Using the Tool for Offensive Security Research

The most obvious application is offensive: using the DRAM mapping to perform targeted row hammer attacks. With the mapping, an attacker can:

Identify which physical addresses correspond to adjacent rows.
Hammer those rows to flip bits in target memory regions.
Target page table entries, function pointers, or other sensitive data.

The repository includes demonstrations of successful bit flips on DDR4 memory with ECC disabled.

Real-World Example: Targeted Row Hammer Attack

Consider a scenario where an attacker wants to modify a page table entry to gain access to privileged memory:

Map the physical addresses of the target page table entries.
Use the DRAM mapping to find the corresponding rows.
Hammer the adjacent rows to induce bit flips.
Monitor the page tables to detect successful flips.
Repeat until the desired bit is flipped.

This is significantly more powerful than blind row hammer, which relies on luck to hit the right bits.

Defensive Uses: Testing Mitigations

The tool isn't just for attackers. Hardware vendors and security teams can use it to:

Evaluate row hammer mitigations: Determine if current defenses (e.g., increased refresh rates) actually prevent targeted attacks.
Test new DRAM: Verify that new memory modules are resistant to row hammer.
Validate system configurations: Ensure that ECC and other protections are working as intended.

Forensic and Reliability Applications

Beyond security, the tool has forensic applications:

Memory corruption analysis: If a system experiences unexplained memory errors, the mapping can help determine if row hammer was the cause.
Hardware debugging: Understanding the DRAM mapping can help diagnose hardware issues related to memory access patterns.
Reliability testing: Evaluate how different access patterns affect DRAM reliability.

Key Takeaway: The tool is dual-use. It enables offensive attacks, but it also strengthens defensive research and testing.

Mitigations and the Future of Row Hammer Defense

Current Mitigations: ECC, Refresh Rates, and Software Patches

Several mitigations exist for row hammer:

ECC (Error Correcting Code): Detects and corrects single-bit errors, but can be bypassed with multi-bit flips or targeted attacks.
Increased refresh rates: More frequent DRAM refresh reduces the time window for bit flips, but increases power consumption and reduces performance.
Software patches: Operating systems can detect row hammer patterns and throttle memory access, but this is reactive and incomplete.
Hardware mitigations: Some newer CPUs include targeted row refresh, which tracks frequently accessed rows and refreshes their neighbors.

Limitations of Existing Defenses

All current mitigations have weaknesses:

ECC is not a silver bullet: It corrects some errors but can be overwhelmed or bypassed with sufficiently targeted attacks.
Refresh rate increases are expensive: They consume power and reduce performance, making them undesirable for always-on implementation.
Software detection is slow: By the time software detects a row hammer pattern, damage may already be done.
Hardware mitigations can be defeated: The skitter-creek-bath-salts research shows that even with targeted row refresh, attackers can find patterns that bypass it.

The Role of Hardware Changes

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:

New DRAM designs that are physically resistant to row hammer.
Better memory controllers that can detect and prevent aggressive access patterns.
Secure scrambling that is actually cryptographically strong—if scrambling is used for security, it needs to be designed for that purpose.

What This Research Means for the Future

The skitter-creek-bath-salts research serves as a wake-up call. It demonstrates that:

Obscurity is not security: Secret algorithms can always be reverse-engineered.
Hardware vulnerabilities are real: DRAM is physically susceptible to attack, and no amount of clever software can fully mitigate this.
Open research is essential: By publishing tools and findings, researchers enable the entire community to understand and address threats.

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.

Conclusion

Recap: DRAM Scrambling Is Not Security

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.

The Importance of Open-Source Research

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.

Call to Action: Explore the Repository and Contribute

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.

FAQ

What is DRAM scrambling?

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.

Why is DRAM scrambling not a security feature?

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.

What is the row hammer attack?

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.

How does the skitter-creek-bath-salts tool work?

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.

Is the tool easy to use?

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.

Can DRAM scrambling be fixed?

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.

Does the tool work on all CPUs?

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.

Is this research legal?

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.

What are the implications of this research?

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.

Where can I find the repository?

The repository is publicly available on GitHub at xoreaxeaxeax/skitter-creek-bath-salts. It includes the tools, documentation, and research findings.

In This Article