Project Description 

Rowhammer haunted us for the better part of the past decade. Most DDR3 modules were found to be susceptible to this vulnerability which can compromise data directly inside the memory cells. What made it so scary was the fact that it could be exploited from software on PCs, clouds, smartphones, over the web and even remotely from the network. To address the problem, memory vendors designed and implemented all sorts of defenses inside their modern DDR4 chips. According to the vendors, now that DDR4 is widely-deployed we now live in a Rowhammer-free world. But do we?

Well, after two years of rigorous research, looking inside what is implemented inside CPUs and DDR4 chips using novel reverse engineering techniques, we can tell you that we do not live in a Rowhammer-free world. And we will not for the better part of this decade. Turns out while the old hammering techniques no longer work, once we understand the exact nature of these mitigations inside modern DDR4 chips, using new hammering patterns it is trivial to again trigger plenty of new bit flips. Yet again, these results show the perils of lack of transparency and security-by-obscurity. This is especially problematic since unlike software vulnerabilities, we cannot fix these hardware bit flips post-production.

What’s this Rowhammer thingy again?

There are some guarantees that the memory modules promise to give us. First of all, if we write data in memory, it should remain unchanged unless we modify it – we call this the memory integrity principle. Since 2012, the year of discovery of Rowhammer, this guarantee has been lost. The memory cells can be manipulated by unintended side effects by carefully crafting accesses to adjacent memory locations. An attacker accessing some memory rows (aggressors) repeatedly can trigger errors in the neighbor ones (victim rows). In other words, a bit in memory could change its state from zero to one or vice versa without being directly accessed. It is a hardware bug that we cannot patch with the usual updating mechanism for fixing security problems.

Enter TRR: Target Row Refresh (TRR) is what was sold as the ultimate solution against Rowhammer. This name has been widely misused to coalesce any sort of mitigation protecting DDR4 systems from Rowhammer. In reality every CPU vendor and memory manufacturer has implemented its own solution and due to the secretive policies enforced by all of them most of the discussions about the topic are somewhat confused. Nevertheless, these TRR-like solutions are deployed in any modern DDR4 module and memory vendors proudly sell Rowhammer-free memory. 

But… I’ve seen bit flips on DDR4!!!

You’re right. We also thought DDR4 was completely broken. That was until we tested a sample of 42 DIMMs against all known variants of Rowhammer variants. As an example, the figure above shows the most “double-sided” Rowhammer variant where the attacker tries to inject bit flips in row x by hammering row x – 1 and x + 1. Surprisingly, we did not observe a single bit flip with all these known variants as shown in the plot below. 

So we started wondering, is Rowhammer fixed once and for all? Well, to figure this out we had to dig deeper into the internals of these mitigations. Little spoiler: they did not fix the issue. DDR4 memory is still broken, as its Low Power variant is (yes! the one inside your phone). And they have been for a long time.  

And how did you figure this out?

Given that the operation of TRR is impossible to understand directly from a PC, we relied on a FPGA to impersonate the memory controller (that thing that allows your CPU to access your memory). We collaborated with researchers at ETH Zurich who built an FPGA-based infrastructure, called SoftMC, that allows us precise control over low-level DRAM commands. This is not very easy to do from a traditional computer since the CPU’s memory controller applies many optimizations when interacting with DRAM, making it difficult to understand the internal operations of the DRAM chips from software. Together we came up with a series of convoluted experiments using SoftMC to better understand the internals of a few DRAM chips. 

The DIMMs we tested from SoftMC showed a worrying trend: (1) the vulnerability has gotten worse compared to DDR3 and (2) once you understand the mitigation the bit flips start to pour.

Many-sided Rowhammer

One of the key insights we gain from our manual analysis on SoftMC is that TRR needs to keep track of how many accesses an attacker performs to which (aggressor) rows to identify them and then refresh the neighboring rows (the victims). The mitigation clearly cannot keep the information about all accessed rows at the same time, since it would require an unaffordable amount of additional memory nor can it refresh all the victims. The known Rowhammer variants use at most two aggressor rows to perform the attack, a small number rows that are being accessed frequently can easily be monitored by TRR. But what if we use more aggressor rows?

As can be seen from the figure, once we select more aggressors, we start observing Rowhammer bit flips (in default settings). This is a surprising and somewhat counter-intuitive result. Remember that during a Rowhammer attack, we like to stress the victim rows as much as possible. This means that having more aggressor rows reduces this effect. But having more aggressors overwhelms the TRR mitigation since it can only track a few aggressor rows at a time. “Luckily” DDR4 chips are more vulnerable, giving us the possibility to reduce the number of accesses to each of the aggressors to trigger bit flips. Or in other words, to increase the number of the aggressors in order to bypass the mitigation.

Our analysis further showed that hammering rows that are close to each other is significantly more effective than randomly selecting them to be anywhere inside memory. An example of an effective hammering pattern is what we call many-sided rowhammer shown below. In many-sided rowhammer, the attacker hammers many different (aggressor) rows that are separated by single (victim) rows in between. But what is the correct number of aggressors? The answer is that it depends on the mitigation that is deployed inside the DIMM.

TRRespass: the Rowfuzzer

A fuzzer is a tool designed to discover errors in software by producing many random data as input. While fuzzing is a common technique in software testing, we implemented the first fuzzer aimed at triggering Rowhammer corruptions in DRAM. We used the insights gained from our analysis with SoftMC in the design of our fuzzer, called TRRespass. TRRespass repeatedly selects random different rows at various locations in DRAM for hammering. TRRespass is open source and you can try it out for yourself.

We tried TRRespass on the three major memory vendors (compromising more than 99% of the market) using 42 DIMMs. The results did not portray a happy future for data integrity. 

Give us the numbers!!

TRRespass found bit flips on 12 of the 42 DIMMs in our testbed. The table below shows statistics from the analysis of 256MB of memory for each module. We also report the manufacture date and the pattern that better performs. 

Best Pattern
A4 16-51 9-sided 4008 3948
A8 17-09 19-sided 10289 10519
A9 17-31 19-sided 12580 12274
A10 19-02 10-sided 1809 11533
A11 19-02 10-sided 1682 11148
A14 19-08 14-sided 16490 16233
A15 17-08 3-sided 12351 10046
B0 18-11 3-sided 10 7
B1 18-11 3-sided 16 6
B2 18-49 3-sided 2 3
B9 19-08 3-sided 12
C12 15-01 10-sided 63904 126133
C13 18-49 9-sided 239 455


Bit flips on recent mobile phones

We also ported a simplified version of TRRespass to ARM and managed to trigger bit flips on a variety of smartphones such as Google Pixel 3 and Samsung Galaxy S10. This results show that LPDDR4 is similarly affected to the Rowhammer variants that TRRespass can find.



We followed a multi-party coordinated vulnerability disclosure involving the main memory vendors and all the other major affected third parties. We were supported by the Dutch National Cyber Security Centre  (NCSC) in the process. 

Frequently Asked Questions

    • Which DIMM should I buy to be safe?
      No real answer here. TRRespass could find flips in many DIMMs, but also not in many others. However, this does not mean that they are safe. Finding the right hammering pattern could be just a matter of time for our fuzzer or we may need additional parameters to improve the fuzzing strategy.
    • How can I check whether my DRAM is vulnerable?
      The TRRsspass code is available on GitHub . We are also going to release an Android App so that you will be able to test your own smartphone.
    • What if I have ECC-capable DIMMs?
      We observed many bit flips on the same victim row during our experiments (way more compared to the flips on DDR3 modules). This would lead at least to a denial of service attack. However, since ECC has been shown not to be completely effective against Rowhammer, we believe that a stubborn attacker could still exploit memory errors.
    • What if my system runs with a double refresh rate?
      Doubling the refresh rate has been demonstrated to be a weak solution. In the paper we report that even double refreshing the memory does not stop all the flips.
    • Why did you anonymize the name of the memory vendors?
      We believe that all of the three major DRAM vendors are somewhat equally vulnerable as our manual analysis suggested. This is an industry wide issue caused by the fact that they have been cramming more and more cells inside these chips. Unfortunately, our evaluation does not portray this picture and we think it would be unfair to penalize a vendor or the other. That being said, the vendors are three. Not so much entropy to figure it out. Have fun!  
    • OMG!! I have one of the phones on the list!! Am I vulnerable?
      As mentioned multiple times we believe most of the memory modules out there are vulnerable. That being said, even if you have one of the phones over there it doesn’t mean it has the same memory manufacturer. Indeed, the same phone could have different memory chips depending on the production batch, manufacturing site, etc. Our evaluation on smartphones is preliminary and future work is definitely required to get a better understanding of the mobile landscape. 
    • If this is so important, did Steve Gibson talk about this yet?
      He sure did:


This work was supported by the European Union’s Horizon 2020 research and innovation programme under grant agreements No. 786669 (ReAct) and No. 825377 (UNICORE), by Intel Corporation through the Side Channel Vulnerability ISRA, and by the Netherlands Organisation for Scientific Research through grants NWO 639.023.309 VICI “Dowsing”, NWO 639.021.753 VENI “PantaRhei”, and NWO 016.Veni.192.262. The public artifacts reflect only the authors’ view. The funding agencies are not responsible for any use that may be made of the information they contain.

Systems and Network Security Group at VU Amsterdam