---
title: 'Swage: Modular Framework for Rowhammer Exploits'
url: https://www.emergentmind.com/topics/swage
type: topic
---

# Swage: Modular Framework for Rowhammer Exploits

Searching arXiv for the named system and closely related Rowhammer/SLH-DSA work to ground the article in current literature.
Swage is a modular, extensible, end-to-end framework for Rowhammer-based fault attacks introduced as the central systems contribution of "SLasH-DSA: Breaking SLH-DSA Using an Extensible End-To-End Rowhammer Framework" [2509.13048]. It was developed to unify attack stages that had previously been distributed across separate tools and evaluation setups, including DRAM reverse engineering, contiguous-memory acquisition, hammering-pattern discovery, victim interaction, page injection, and online replay of previously discovered attack artifacts. Within the reported attack chain, Swage functions as reusable infrastructure rather than victim-specific exploit code, and this separation is presented as a defining property of the framework [2509.13048].

## 1. Definition and rationale

Swage is described as a **modular, extensible, end-to-end framework for Rowhammer-based fault attacks** [2509.13048]. The motivating problem is that practical Rowhammer exploitation requires a sequence of capabilities that are individually nontrivial and were often handled by distinct tools: reverse engineering the physical-address-to-DRAM mapping, obtaining physically contiguous memory, finding reproducible hammering patterns that bypass TRR, influencing victim allocation of sensitive data, synchronizing hammering with victim execution, and reusing attack artifacts in the online phase [2509.13048].

The framework is intended to reduce the ad hoc character of such attacks. Earlier tools are identified as covering only fragments of the pipeline, including **DRAMA** and **Xiao et al.** for address mapping, **Blacksmith** for hammering-pattern discovery, **Spoiler** or **Huge Pages** for contiguous memory, and **Mayhem** or **Rubicon** for page injection [2509.13048]. Swage unifies these stages into one framework and is described as **untangled from the attacked code**, meaning that the attack infrastructure is not embedded into a single victim binary or tightly coupled evaluation scenario [2509.13048].

This design suggests a shift from paper-specific exploit scripts toward a general Rowhammer experimentation platform. A plausible implication is that reproducibility and cross-target adaptation become easier because the framework preserves attack-stage boundaries rather than collapsing them into one-off exploit logic.

## 2. Architectural organization

Swage is implemented in **Rust, C, and Python** and is organized as a pipeline of modules [2509.13048]. The architecture decomposes the attack chain into distinct components that can be instantiated with different backends while preserving a common orchestration model.

| Module | Function | Reported backends or integrated methods |
|---|---|---|
| DRAM Inspector | Address-mapping knowledge for Rowhammer | DRAMA; Xiao et al. |
| Allocator | Physically contiguous memory acquisition | HugePage; Spoiler |
| Hammerer | Pattern search and replay | BlacksmithFuzz; DevMem; ConfigFile |
| Orchestrator | Victim execution and attack-cycle control | Victim wrapper with `start`, `init`, `check`, `stop` |
| Page Injector | Linux allocator manipulation for victim placement | Mayhem; Rubicon mentioned |

The **DRAM Inspector** learns the CPU-specific mapping from physical addresses to DRAM bank, row, and column layout, typically once per target CPU in an offline phase, after which the mapping can be loaded from a configuration file [2509.13048]. On the reported target system, the bank mapping is given explicitly: bank bit 0 equals physical bit 13, while bank bits 1–4 are XORs of bit pairs \(b_{14}\oplus b_{18}\), \(b_{15}\oplus b_{19}\), \(b_{16}\oplus b_{20}\), and \(b_{17}\oplus b_{21}\) [2509.13048]. This mapping is used to reason about row-buffer conflicts and aggressor–victim row selection.

The **Allocator** provides a unified interface for contiguous memory. Two backends are reported: **HugePage** for privileged prototyping and **Spoiler** for realistic unprivileged allocation [2509.13048]. In the Spoiler-based workflow, the first stage identifies **1 MiB contiguous blocks** within a large allocation via the Spoiler side channel; the second stage uses the row-buffer side channel together with the DRAM mapping to determine which of those blocks are adjacent and can form **4 MiB contiguous blocks** [2509.13048].

The **Hammerer** is the central component for producing and replaying Rowhammer patterns. Its backends include **BlacksmithFuzz**, a fork of Blacksmith for searching reproducible patterns; **DevMem**, a prototyping backend that flips bits architecturally through `/dev/mem`; and **ConfigFile**, which loads a previously discovered hammering pattern for online replay [2509.13048]. A specific contribution is the ability to **split large hammering patterns into smaller chunks** so that they require only 1 or 4 MiB contiguous pieces rather than one large physically contiguous region [2509.13048].

The **Orchestrator** executes the attack against a victim process through a victim-specific wrapper exposing four methods: `start`, `init`, `check`, and `stop` [2509.13048]. It starts the victim or victim setup, launches page injection, synchronizes hammering with victim execution, checks whether the fault succeeded, and stops the cycle [2509.13048].

The **Page Injector** manipulates the Linux allocator so that the victim’s next allocation lands on an attacker-chosen page [2509.13048]. The reported implementation uses a technique from **Mayhem**, exploiting the per-CPU page-list optimization in Linux allocation to inject the desired page into a co-located victim process. **Rubicon** is noted as a more advanced cross-core page injection approach [2509.13048].

## 3. Detachment from victim code

A major design point is the claim that Swage is **untangled from the attacked code** [2509.13048]. Rather than hard-coding victim behavior into the Rowhammer machinery, the framework treats the victim as a wrapper with a small interface, separates infrastructure from attack logic, supports different instantiations of the same attack stage, and allows offline preparation to be reused online [2509.13048].

This separation is significant because prior Rowhammer artifacts were often closely coupled to the setup of a single paper [2509.13048]. In Swage, the modular boundary is explicit: address mapping, allocation, pattern search, page injection, and synchronization are infrastructural primitives, while victim-specific knowledge is concentrated in the wrapper and target selection logic. The paper presents this as enabling reuse across targets and making analysis and adaptation easier [2509.13048].

A common misconception would be to treat Swage as merely a hammering-pattern generator. The framework is broader: it encompasses the entire exploit chain from offline DRAM characterization to online replay and fault verification [2509.13048]. Another misconception would be to view it as inseparable from the SLH-DSA case study. The paper instead positions the SLH-DSA attack as one instantiation of a general framework.

## 4. Attack-planning and post-processing functionality

Swage is not limited to fault induction. The same work introduces attack-planning analysis for deciding what to do after faulty outputs have been collected [2509.13048]. In the SLH-DSA case, the post-processing problem is: given a set of faulty signatures, which compromised WOTSP instance should be targeted to minimize offline forgery time [2509.13048]?

The paper introduces an exact complexity analysis for tree grafting on concrete faulty instances [2509.13048]. For a compromised WOTSP instance, exposed partial chain values are used to count valid message/checksum combinations. The definitions include the Winternitz parameter \(w\), chain capacities \(k_i=w-1-m_i\), and a set of reachable checksum tuples \(\mathcal{T}\) [2509.13048]. For a candidate checksum tuple \(\tau\), the remaining capacity is

\[
\kappa(\tau)=\toInt(c,w)-\toInt(\tau,w).
\]

The number of valid message decompositions is then the number of bounded weak compositions satisfying

\[
\sum_i x_i=\kappa(\tau), \qquad 0\le x_i\le k_i.
\]

This is formulated as a restricted weak integer composition problem [2509.13048]. The dynamic-programming algorithm **Weak-Comp** is given for counting these compositions in time \(\mathcal{O}(\tau\cdot \ell_1)\) and memory \(\mathcal{O}(\tau)\), using a prefix-sum optimization [2509.13048].

From this, the signability probability is computed as

\[
\mathbb{P}(\text{Signable})=\frac{\sum_{\tau\in\mathcal{T}}N(\kappa(\tau,\mathcal{K}))}{w^{\ell_1}},
\]

and grafting cost is modeled as

\[
\mathbb{C}(\text{Grafting})=\frac{1}{\mathbb{P}(\text{Signable})}.
\]

These expressions are used to rank compromised WOTSP instances by expected attack cost [2509.13048]. Additional reported complexity terms are that identifying exposed WOTSP secret values costs only \(2^{8.04}\) to \(2^{12.98}\) hashes depending on the parameter set, path seeking costs about \(2^{h-h'l^*}\) hash calls on average per forged signature, and grafting complexity can range from about \(2^{12.58}\) hashes to \(2^{52.92}\) hashes depending on the parameter set and number of signatures [2509.13048].

This suggests that Swage should be understood not only as a fault-injection framework but also as decision support for post-fault exploitation. The infrastructure therefore spans both systems-level Rowhammer mechanics and attack-cost evaluation on collected faulty artifacts.

## 5. Use in the SLH-DSA attack

Swage served as the tooling backbone for the reported **first software-only universal forgery attack on SLH-DSA** against **OpenSSL 3.5.1** on commodity desktop and server hardware [2509.13048]. In this attack, the framework was used to reverse engineer the DRAM mapping, find and verify contiguous memory, discover reproducible hammering patterns, split and adapt those patterns to realistic memory allocations, inject the victim page, orchestrate hammering and victim synchronization, and replay the final attack pattern during the online phase [2509.13048].

The target inside OpenSSL is identified as the `xmss` computation in `crypto/slh_dsa/slh_xmss.c`, especially the `lnode` buffer [2509.13048]. The rationale is twofold. First, **spatial suitability**: the buffer is large enough to allow useful bit flips. Second, **temporal suitability**: the topmost `lnode` remains on the stack for much of the recursive XMSS computation [2509.13048]. For the largest security levels, the relevant `lnode` buffers are larger, which makes them better fault targets [2509.13048]. For a top-level XMSS node, the stack space involved is roughly \(n\cdot (h'-1)\) bytes, and the top-level `lnode` remains live for a long part of the recursive DFS-style computation [2509.13048].

To enlarge the timing window, the attack uses performance degradation by launching CPU-intensive worker threads with `stress` on the victim core [2509.13048]. The worker count depended on the parameter set, ranging from as few as 10 to as many as 999 workers [2509.13048]. With performance degradation in place, the attacker could collect about **1 to 3 signatures per minute**, depending on the parameter set [2509.13048].

The reported end-to-end successes include **universal forgery against SLH-DSA-SHA2-256f** after **8 hours of hammering** plus **36 seconds of post-processing**, and **universal forgery in deterministic mode for SLH-DSA-SHA2-128f** after **1 hour of Rowhammer** plus **82 seconds of post-processing** [2509.13048]. The paper also reports results across all security levels and both SHA2 and SHAKE families, with some parameter sets substantially easier to break than others [2509.13048].

## 6. Empirical validation and operational characteristics

The framework is empirically validated through its component behaviors and through the end-to-end SLH-DSA exploit [2509.13048]. Offline validation reports that DRAM mapping was successfully recovered on the test system, **Spoiler-based allocation** took on average **41.6 seconds**, the false-positive rate for contiguous **4 MiB** block detection was **66%**, and page injection generally succeeded, with failures retried [2509.13048].

For hammering-pattern discovery, an **8-hour Blacksmith fuzzing run** produced several candidate patterns whose reproducibility varied widely: some were non-reproducible, some were highly reproducible, and one pattern, denoted \(\mathcal{G}\), was selected for the SLH-DSA attack because it gave good reproducibility with controlled flips [2509.13048]. The paper also reports that the selected pattern remained effective after adaptation to smaller contiguous chunks through block splitting [2509.13048].

These figures delineate the framework’s operational model. Offline preparation may be time-consuming, but once artifacts such as mappings and hammering patterns are obtained, they can be reused in the online phase [2509.13048]. The paper’s emphasis on configuration loading and replay supports this interpretation.

A plausible implication is that the main practical constraint is not merely whether bit flips can be induced, but whether the entire chain—contiguous memory, page placement, synchronization, and exploitable post-processing—can be assembled reliably. Swage is specifically designed to assemble that chain.

## 7. Significance and security implications

Within the reported study, Swage’s importance lies in systematizing practical Rowhammer exploitation against modern cryptographic software [2509.13048]. The surrounding result is that **cryptographic soundness is not enough**: even a conservative, NIST-standardized post-quantum signature scheme such as SLH-DSA can fail in practice when its implementation is vulnerable to Rowhammer-induced memory faults [2509.13048].

The paper distinguishes between deterministic and randomized signing. **Deterministic SLH-DSA** is reported as more vulnerable because the same message and secret-key choices repeat more often, increasing collision opportunities and making grafting easier, whereas **randomized SLH-DSA** is harder because the random value \(R\) changes the path through the hypertree and reduces reuse of instances [2509.13048]. Even so, practical results were achieved for some randomized parameter sets after **8 hours of hammering** [2509.13048].

Swage’s broader significance is therefore methodological. It provides a reusable substrate for composing Rowhammer attacks across stages that had previously been fragmented, and it demonstrates that implementation-level and hardware-level weaknesses can dominate the security outcome of theoretically well-founded primitives [2509.13048]. The work underscores the need for additional implementation hardening or hardware defenses against Rowhammer, not merely stronger cryptographic design [2509.13048].

Source: https://www.emergentmind.com/topics/swage