Swage: Modular Framework for Rowhammer Exploits

• Swage is a modular, extensible framework for Rowhammer fault attacks that unifies diverse stages from DRAM reverse engineering to page injection.
• It is implemented in Rust, C, and Python as a pipeline, enabling reusable components like DRAM mapping, memory allocation, hammering, orchestration, and page injection.
• Its design detaches attack infrastructure from victim code, facilitating reproducibility and cross-target adaptation in universal forgery experiments.

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" (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

1. Definition and rationale

Swage is described as a modular, extensible, end-to-end framework for Rowhammer-based fault attacks (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025). 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}$ (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

The Orchestrator executes the attack against a victim process through a victim-specific wrapper exposing four methods: start, init, check, and stop (Boy et al., 16 Sep 2025). It starts the victim or victim setup, launches page injection, synchronizes hammering with victim execution, checks whether the fault succeeded, and stops the cycle (Boy et al., 16 Sep 2025).

The Page Injector manipulates the Linux allocator so that the victim’s next allocation lands on an attacker-chosen page (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

3. Detachment from victim code

A major design point is the claim that Swage is untangled from the attacked code (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

This separation is significant because prior Rowhammer artifacts were often closely coupled to the setup of a single paper (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025)?

The paper introduces an exact complexity analysis for tree grafting on concrete faulty instances (Boy et al., 16 Sep 2025). 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}$ (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025). The dynamic-programming algorithm Weak-Comp is given for counting these compositions in time $b_{15}\oplus b_{19}$0 and memory $b_{15}\oplus b_{19}$1, using a prefix-sum optimization (Boy et al., 16 Sep 2025).

From this, the signability probability is computed as

$b_{15}\oplus b_{19}$2

and grafting cost is modeled as

$b_{15}\oplus b_{19}$3

These expressions are used to rank compromised WOTSP instances by expected attack cost (Boy et al., 16 Sep 2025). Additional reported complexity terms are that identifying exposed WOTSP secret values costs only $b_{15}\oplus b_{19}$4 to $b_{15}\oplus b_{19}$5 hashes depending on the parameter set, path seeking costs about $b_{15}\oplus b_{19}$6 hash calls on average per forged signature, and grafting complexity can range from about $b_{15}\oplus b_{19}$7 hashes to $b_{15}\oplus b_{19}$8 hashes depending on the parameter set and number of signatures (Boy et al., 16 Sep 2025).

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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

The target inside OpenSSL is identified as the xmss computation in crypto/slh_dsa/slh_xmss.c, especially the lnode buffer (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025). For the largest security levels, the relevant lnode buffers are larger, which makes them better fault targets (Boy et al., 16 Sep 2025). For a top-level XMSS node, the stack space involved is roughly $b_{15}\oplus b_{19}$9 bytes, and the top-level lnode remains live for a long part of the recursive DFS-style computation (Boy et al., 16 Sep 2025).

To enlarge the timing window, the attack uses performance degradation by launching CPU-intensive worker threads with stress on the victim core (Boy et al., 16 Sep 2025). The worker count depended on the parameter set, ranging from as few as 10 to as many as 999 workers (Boy et al., 16 Sep 2025). With performance degradation in place, the attacker could collect about 1 to 3 signatures per minute, depending on the parameter set (Boy et al., 16 Sep 2025).

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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

6. Empirical validation and operational characteristics

The framework is empirically validated through its component behaviors and through the end-to-end SLH-DSA exploit (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

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 $b_{16}\oplus b_{20}$0, was selected for the SLH-DSA attack because it gave good reproducibility with controlled flips (Boy et al., 16 Sep 2025). The paper also reports that the selected pattern remained effective after adaptation to smaller contiguous chunks through block splitting (Boy et al., 16 Sep 2025).

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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025). 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 (Boy et al., 16 Sep 2025).

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 $b_{16}\oplus b_{20}$1 changes the path through the hypertree and reduces reuse of instances (Boy et al., 16 Sep 2025). Even so, practical results were achieved for some randomized parameter sets after 8 hours of hammering (Boy et al., 16 Sep 2025).

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 (Boy et al., 16 Sep 2025). The work underscores the need for additional implementation hardening or hardware defenses against Rowhammer, not merely stronger cryptographic design (Boy et al., 16 Sep 2025).