From an unstable machine to a view of hidden memory

Download More RAM’s next obstacle is not creating an alias but surviving one. This part of the attack asks how Windows can be kept usable after the DIMM begins treating two reported ranges as the same cells, and how the range Windows avoids can then be observed through a physical-memory interface. The distinction matters because stabilization is not yet a privilege bypass, and a memory dump is not automatically an intelligible picture of the machine.

The researchers had to solve those problems in order. First, they had to stop Windows from damaging itself. Then they had to find a way to reach memory that Windows believed did not exist. Finally, they had to account for two transformations—hardware data scrambling and the difference between virtualized and raw physical memory—before deciding what the recovered bytes meant.

Keeping Windows alive inside a false map

When a module reports more addressable space than its chips contain, Windows does not know that the upper range is duplicated. It treats the reported range as ordinary RAM. The operating system, its drivers, and its applications can therefore allocate objects in both halves. A write intended for an upper address reaches the corresponding lower cells and overwrites something that may belong to the kernel, a driver, or another process. The problem is not a single predictable collision; normal memory activity continually changes which data is placed at each address.

That explains why the aliased machine is not a useful version of a computer with extra capacity. It is a machine whose allocator is making decisions against a false premise. Early boot is especially unforgiving because the system is bringing up the kernel, drivers, page tables, and other state while still depending on the map it has just received. The paper reports that the researchers could not find an aliased configuration that progressed reliably through the early boot stages. They tried different sizes and arrangements, including systems with multiple DIMMs, and observed crashes and other failures.

This failure is an important boundary on the result. An attacker cannot simply create the alias and then use normal Windows tools to browse the added memory. If Windows freely used the upper range, the same alias that might expose protected data would also corrupt the system before a sustained operation could be completed. The attack needs a stable victim and a physically present region outside the victim’s ordinary allocation decisions.

The researchers used Windows boot-configuration behavior to create that separation. One kind of setting limits the highest address Windows will allocate. Another removes a quantity of memory from the back of the available physical range. In the paper’s tested environment, only the removal-based behavior was compatible with Secure Boot. The important distinction is conceptual rather than syntactic: both tell Windows to narrow its usable view, but neither repairs the DIMM or proves that the excluded addresses are safe. They change who is allowed to allocate there.

Once the upper range is excluded, the system can operate with the lower real half.