FLIPPYRAM: A Large-Scale Study of Rowhammer Prevalence

FLIPPYRAM: A Large-Scale Study of Rowhammer Prevalence

Speakers: Martin Heckel

Conference: NDSS Symposium 2026

YouTube: https://www.youtube.com/watch?v=-LhUrFtmpIw

Overview

How many real-world systems are actually vulnerable to Rowhammer attacks? This large-scale empirical study, which distributed bootable USB sticks at 38C3 and collected data from 106 systems, provides the first broad answer: at least 12.5% of tested systems are vulnerable to fully automated Rowhammer attacks, with bit flips occurring in practical timeframes. The study reveals that 27.2% of DDR3 DIMMs and 8.8% of DDR4 DIMMs tested showed bit flips, while DDR5 showed no flips -- though the researchers attribute this to lack of appropriate tooling rather than inherent safety.

The FLIPPYRAM framework automates the entire testing pipeline: DRAM addressing function reverse engineering, verification, injection into multiple Rowhammer tools, and result collection. The study also exposes significant gaps in the Rowhammer research ecosystem -- most existing tools fail on the majority of systems due to missing huge page support, failed address function reverse engineering, or crashes, suggesting that the true vulnerability rate may be considerably higher than 12.5%.

Background

▶ Watch: DRAM cell structure and how Rowhammer works (0:00)

Rowhammer is a hardware fault attack that exploits physical characteristics of DRAM memory. DRAM cells store data as electrical charge in capacitors, organized in arrays of rows and columns. When rows are accessed repeatedly (or "hammered"), the electrical interference can cause bit flips in physically adjacent rows that are never directly accessed. This occurs because capacitors leak charge over time, and the periodic refresh cycle (64ms for DDR3/DDR4, 32ms for DDR5) may not compensate quickly enough when neighboring rows are aggressively activated.

The original Rowhammer paper by Kim et al. demonstrated the basic attack pattern: alternately reading two rows with a single row between them, flushing the cache after each access, and repeating until bit flips appear in the untouched middle row. Since then, various hammering patterns have been developed: single-sided (aggressors several rows apart), double-sided (aggressors with exactly one row between them), one-location (single row), and many-sided patterns. Modern Rowhammer mitigations are largely based on pattern detection, so advanced attacks attempt to evade these detectors.

DRAM addressing is complex: physical addresses used by the operating system must be translated to specific channels, DIMMs, ranks, banks, rows, and columns by the memory controller. This address mapping is not publicly documented by vendors, making it necessary to reverse-engineer these functions before Rowhammer tools can target specific rows -- a process that frequently fails.

Key Findings

▶ Watch: The WD40/tape/isopropanol USB drive preparation saga (4:00)

The study's primary finding is that 12.5% of tested systems (126 out of 1,006 data sets) are vulnerable to fully automated Rowhammer attacks -- "way more than we expected," according to the presenter.

Key results by DRAM generation:

• DDR3: 27.2% of DIMMs affected. Simple, fast hammering patterns (like those used by rowhammer.js) work well
• DDR4: 8.8% of DIMMs affected. Pattern fuzzing to find non-uniform patterns (like Blacksmith) is more effective
• DDR5: 0% affected, but likely due to lack of appropriate tools at the time of the study rather than DDR5 immunity

The minimum time to first bit flip ranged from 0 to 150 minutes on average, representing a practical timeframe for real-world attacks. On barely susceptible systems, detection could take up to 617 minutes, indicating that longer testing times yield more accurate vulnerability assessments.

By DRAM vendor: Samsung and third-party resellers showed similar vulnerability rates, while Micron DIMMs showed only 2.4% vulnerability -- though this could reflect tooling bias rather than better mitigations. By CPU vendor, most affected systems were Intel-based, with fewer AMD results attributed to fewer available tools rather than lower susceptibility.

A critical meta-finding: the Rowhammer research tooling ecosystem is unreliable. Reverse engineering of DRAM addressing functions failed on more than 50% of systems. Many tools crashed due to lack of 1GB huge page support. Several tools failed at compilation when addressing functions didn't meet specific requirements. This means the 12.5% vulnerability rate is almost certainly a lower bound.

Technical Deep Dive

▶ Watch: Key result: 12.5% of systems vulnerable, DDR3 at 27.2% (8:00)

The FLIPPYRAM framework operates as a bootable Linux environment (based on Arch Linux) that orchestrates multiple Rowhammer testing phases:

Phase 1 - Address Function Reverse Engineering: The framework attempts to reverse-engineer DRAM addressing functions that map physical addresses to bank/row/column coordinates. This is necessary because Rowhammer tools need to target specific rows within the same bank. Multiple reverse engineering approaches are tried, but the success rate was below 50% -- the most significant bottleneck in the pipeline.

Phase 2 - Verification and Injection: Successfully reverse-engineered addressing functions are verified and compiled into the various Rowhammer tools. Failures at this stage occur when addressing functions don't meet tool-specific requirements.

Phase 3 - Tool Execution: Multiple Rowhammer tools are run, including Blacksmith (TRRespass-based pattern fuzzing, effective on DDR4), FlipFloat, rowhammer-test, and others. Different tools are effective against different DRAM generations and configurations.

The study found that for DDR4, Blacksmith's approach of fuzzing non-uniform hammering patterns to bypass Target Row Refresh (TRR) mitigations is significantly more effective than simple repeated access patterns. For DDR3, which lacks TRR, simple patterns work well.

An important practical insight: bit flips tend to be stable and reproducible. When the same pattern is applied to the same addresses with the same data, the same bits tend to flip. This enables a two-phase exploitation strategy: first scan memory for exploitable flip positions, then construct the exploit based on the discovered flip locations.

The distribution infrastructure was notably low-tech: the team hand-flashed hundreds of USB drives for distribution at 38C3, encountering practical challenges including paint scratching from the flashing process, requiring a WD40/tape/isopropanol workflow for drive preparation.

Demo / Proof of Concept

▶ Watch: CPU vendor and DDR5 results -- tooling gaps identified (10:00)

The study itself serves as the proof of concept -- a large-scale empirical demonstration that Rowhammer is a practical threat against real-world consumer and server hardware. The framework is available as:

• A bootable ISO image downloadable from the project website
• A Docker container for running on existing Linux systems
• A GitHub repository with build scripts

The 38C3 distribution was successful despite initial concerns: attendees accepted the USB drives, participated in testing their personal systems, and uploaded results. The framework collected system information, ran the full testing pipeline, and uploaded anonymized results with user consent.

The results dataset demonstrates that Rowhammer is not a laboratory curiosity but a field-relevant vulnerability affecting a measurable fraction of deployed hardware.

Defensive Implications

▶ Watch: Call for action: add tools and run larger-scale studies (14:00)

The study's findings have several implications for defenders:

Risk assessment: With 12.5% of systems vulnerable (and this as a lower bound), organizations cannot assume their hardware is safe from Rowhammer. DDR3 systems are particularly exposed at 27.2% vulnerability rate, and many DDR3 systems remain in production use.

Testing gaps: Current Rowhammer testing tools are fragile and frequently fail due to platform-specific issues. Organizations wanting to assess their exposure face a significant tooling challenge. The FLIPPYRAM framework provides the best available automated testing pipeline, but it still fails on the majority of systems.

Mitigation uncertainty: DRAM vendor mitigations like TRR (Target Row Refresh) are effective at blocking simple patterns but are bypassed by advanced fuzzing tools like Blacksmith. The study suggests that mitigation effectiveness varies significantly by vendor, with Micron showing lower vulnerability rates.

Hardware lifecycle considerations: DDR5 DIMMs showed no vulnerability in this study, but the researchers attribute this to tooling limitations rather than proven safety. As DDR5-specific Rowhammer tools mature (several have been published since the study began), DDR5 vulnerability remains an open question.

The researchers call for the community to use their open-source framework to add new Rowhammer tools and run larger-scale studies, particularly with AMD-specific and DDR5-specific tools that have been published since the study's data collection phase.

Key Takeaways

• At least 12.5% of tested real-world systems are vulnerable to fully automated Rowhammer attacks -- likely a lower bound due to tooling failures
• 27.2% of DDR3 DIMMs and 8.8% of DDR4 DIMMs showed bit flips; DDR5 showed none but likely due to tool limitations
• Time to first bit flip ranges from 0 to 150 minutes on average, a practical timeframe for real-world exploitation
• Rowhammer research tools fail on more than 50% of systems due to DRAM addressing reverse engineering failures and missing huge page support
• Simple patterns work on DDR3; DDR4 requires pattern fuzzing (Blacksmith) to bypass TRR mitigations
• Micron DIMMs showed significantly lower vulnerability (2.4%) compared to Samsung and others, though the cause is unclear
• The FLIPPYRAM framework and all data sets are publicly available for reproduction and extension

About the Speaker(s)

Martin Heckel presented the research, which was conducted collaboratively with a team that includes Hanis (who distributed USB drives at 38C3). The research group operates in the hardware security space with expertise in DRAM fault attacks and reverse engineering of memory addressing functions. Their distribution of the testing framework at 38C3 reflects an engagement with the hacker community for large-scale empirical security research.