Самое очевидное - да, адреса всегда разные, потому что сам образ загружается по разным адресам. Но вот смещения внутри программы всегда одинаковые, пока программу не перекомпилируют. Это позволяет найти в программе место, которое нужным образом работает с памятью, и потом долбить именно в него до тех пор, пока не получится нужный результат, используя для этого функциональность самой программы. Если речь идет о повышении привилегий, вроде того случая с рутованием андроида, то программой является ядро ОС, а функциональностью - его публичный API.

Альтернатива - полагаться на статистику и множество попыток, прямо как с meltdown, spectre и прочими современными веяниями. Берется очень большой буфер, заполняется сгенерированным паттерном. Потом ещё один буфер, и читается в соответствии с замороченным законом, который для каждого сценария будет свой. Собирается статистика задержек, исходя из неё делаются выводы о соответствии/несоответствии физических адресов нужным. При неудаче попытка повторяется, и так пока не добьешься результата.

Пример: https://eprint.iacr.org/2016/618.
Ещё: https://googleprojectzero.blogspot.com/ ... n.html?m=1

Заделать на стороне процессора и закончить на этом не получится. При попытке этого просто пролезут через GPU: https://www.vusec.net/projects/glitch/. Заделаешь затычкой там - не проблема, пролезут через NPU какой-нибудь. И песня будет вечной.

Что забавно, это и наоборот тоже работает. Прямо как каноничный пример с синхронным двигателем, который одновременно и генератор. Вместо модификации данных в контексте программы можно заставить целевую программу модифицировать данные в своём контексте. И тогда нормальная работа целевой программы может использоваться для косвенного наблюдения за ней: https://rambleed.com.

Короче, это не какой-то один сценарий, а целое множество. Имеющие одну причину, но по-разному реализуемые и произвольно комбинируемые между собой. Натуральный ящик Пандоры, как было с уязвимостью форматирования строки. Просто пока ещё не осознали массово, как и тогда, но у этого большое будущее.

В папке ''javascript'' вы найдете версию Rowhammer.js для процессоров Haswell с 16-путевым L3 кэшем и без L4 кэша ''rowhammer.html''. Вероятно, он не будет работать на других процессорах без модификаций
Также в папке ''javascript'' вы найдете ''rowhammer_scan.html''. Это чистый JavaScript-прототип для процессоров Haswell с 16-путевым L3 кэшем и без L4 кэша, память в одноканальном режиме (это так, если у вас только один DIMM). Кроме того, предполагается, что память JavaScript физически непрерывна в блоках по 2 мегабайта - это так, если ваша ОС выделяет 2M анонимных страниц (все наши системы Linux это делают) или если она выделяет физически непрерывные 4K страниц. Вероятно, это не будет работать на других системах без модификаций.