When memory metadata becomes an address map
Download More RAM turns a normally forgettable configuration record into the starting point for a security failure. The question is how Serial Presence Detect data can cause a memory controller to construct an address map larger than the physical DIMM, and why the paper’s choice of row-address information creates a useful alias rather than merely a broken capacity label. Following that mechanism gives the reader the exact condition behind the attack: two reported physical addresses can become two names for one set of cells.
The mechanism is unusual because no pointer needs to be corrupted. Software can ask for a valid address, the processor can perform its normal translation, and the memory controller can still deliver data from a location that another address already names. The error appears at the point where platform configuration becomes physical geometry.
SPD is a configuration input, not just a label
A memory module contains an electrically erasable memory chip that stores Serial Presence Detect, or SPD, data. The record describes properties the platform needs in order to initialize the DIMM: its memory type, frequency, voltage, optional performance profiles, capacity, and aspects of its organization. During boot, firmware and the memory controller use that information to decide how the module should be addressed.
It is tempting to treat capacity as a passive description. A sticker can say that a module contains 8 GB, but changing the sticker does not manufacture another 8 GB. SPD is different because the platform does not merely display its contents. It uses the values to configure the logic that interprets later memory requests. In that sense, an SPD field can act like a control input for the address map.
A DIMM’s physical organization is hierarchical. A request is eventually distinguished by several coordinates, including a bank, a row, and a column. The address bits that select those coordinates are not interchangeable. Some choose positions within a row; others choose which row or bank is reached. The module and controller must agree about how many bits are meaningful at each level.
Download More RAM exploits a missing safeguard in that agreement. The researchers’ target is a consumer DIMM whose SPD write protection is disabled. On such a module, a privileged Windows process can reach the platform path used to update SPD and change the reported memory geometry from software. The attack does not require physically removing the DIMM or inserting hardware between the module and motherboard. It relies on the fact that the configuration record can be rewritten and later trusted during initialization.
The crucial change is to the reported number of row-addressing bits. In the paper’s example, a module with 8 GB of physical storage is made to report 16 GB. The extra range is not backed by additional chips. The highest row bit exists in the platform’s interpretation but not in the physical storage organization. When that bit changes in an address, the memory controller effectively ignores it while selecting the underlying cells. An address in the upper reported half therefore reaches the same location as the corresponding address in the lower half.
This is an address-identity error. The lower and upper values are different as numbers, and the operating system can treat them as different physical pages, but the DIMM’s cells do not distinguish them. A write through one name can overwrite data that software believes belongs to another region. A read through the other name can reveal the result without violating the ordinary pointer rules used to form the request.
The relationship can be expressed without hardware shorthand:
- The operating system receives a reported physical range.
- Firmware and the memory controller configure that range according to SPD.
- The lower half maps to the real cells.
- The upper half appears to map to new cells but resolves back to the lower half.
The memory controller is the mediator between the reported address and the electrical storage. It does not independently prove that the SPD description matches the number of row selectors physically implemented in the chips. That implicit trust is what lets a metadata change become a change in memory identity.
The sequence has two different protection outcomes. If the SPD blocks writes to the relevant configuration area, the first transition stops and the software-only path does not begin. If the write is accepted, the altered data persists until firmware reads it and configures the controller. The vulnerability is therefore not “all RAM can be aliased by an administrator.” It is the combination of an exposed configuration path and a controller that treats the resulting data as authoritative.
The timing matters as much as the data. The software change is made while Windows is running, but the altered geometry takes effect when the platform initializes memory on a subsequent boot. That makes the attack a lifecycle problem crossing two owners: a runtime process changes a record, and firmware later consumes the record as if it were a description of installed hardware. Some firmware implementations may cache or selectively reread module data, so the paper had to account for platform behavior rather than assume that every restart would produce the same result. The broader lesson is that a configuration interface can be security-sensitive even when its effect is deferred to a component with a different privilege boundary.
A small address example makes the duplication concrete. Imagine that the real module has a lower range from 0 through 8 GB, while the altered configuration tells the platform that a second range from 8 through 16 GB exists. Under ordinary assumptions, an address 1 GB into the first range and an address 1 GB into the second range identify different storage. With the added row bit ignored by the physical chips, both requests select the same row and column in the real module. The operating system can maintain two separate bookkeeping entries, but the memory controller has no corresponding second set of cells to select.
That is why the error is dangerous even if every layer above the controller is internally consistent. Windows can reserve the upper range, mark a page unavailable, or assign permissions to the lower range according to its own tables. Those rules describe numbers in the reported map. They do not automatically establish a one-to-one relationship between those numbers and cells. Detecting aliasing would require the platform to test or authenticate that relationship, not merely to accept the geometry used to construct it.
Why row bits create a cleaner alias
The paper considers two ways of making a DIMM report a larger address space: changing column-address bits or changing row-address bits. Both can produce duplicated physical destinations, but they arrange the duplicates differently. That difference determines how much of the system can be kept understandable after the deception is introduced.
A simplified address can be imagined as selecting a bank, then a row within that bank, then a column within the row. The controller consumes higher column distinctions before it needs the higher row distinctions. If a column bit is added to the reported geometry, real and aliased locations alternate within each row. Part of a row refers to real storage and another part refers to an aliased region. The result is interleaved: scanning a range encounters both behaviors repeatedly.
Adding a row bit produces a cleaner split. The lower row values select the real region, while the higher reported row values select addresses whose extra bit is ignored by the physical chips. At the scale of the reported address space, the lower half is real and the upper half is aliased, with the exact organization expressed across banks. The regions are comparatively contiguous rather than alternating at every row.
That geometry is not a cosmetic choice. A fragmented map makes it harder to separate safe operating memory from the duplicated region. A contiguous upper range gives the researchers something they can later ask Windows to avoid while leaving the physical cells present. It also makes the relationship easier to analyze: an address in the upper region can be paired with a corresponding address in the lower region instead of being mixed with unrelated addresses throughout the system.
The row choice also explains why the attack is more than a memory-capacity spoof. If the only consequence were an incorrect amount shown in a system-information panel, higher-level security would remain intact. Here, the number of address bits affects the controller’s routing decision for every later access. The same software-visible physical address can be associated with a different physical destination than Windows assumes, and a second address can reach storage that the first protection decision was meant to cover.
This is different from an ordinary overwrite in an important way. An overwrite begins with a single software address and writes beyond an intended object because a bounds check, pointer calculation, or other program rule failed. Aliasing begins with two address values that the system’s own configuration says are legitimate. The page-table machinery may correctly distinguish them as separate physical pages. The duplicate is created after that distinction, in the hardware logic that selects rows and columns. A page permission can be correct relative to each mapping while the underlying cells remain shared.
The security consequence follows from that mismatch. Suppose the operating system marks a region as unavailable or protected. If another address can reach the same cells, the protection applies to the label Windows recognizes, not necessarily to every name understood by the memory controller. Conversely, if Windows allocates the reported upper range as ordinary RAM, writes there can damage data stored under the lower range. The same alias that can help an attacker cross a boundary can also make the victim system unusable.
The paper’s experiment therefore depends on conditions at several levels. The target DIMM must accept the SPD change. The platform must read and apply the altered configuration. The chosen memory geometry must create an alias pattern the researchers can reason about. Firmware behavior can vary, including whether configuration is reread or cached during boot. And the operating system must be dealt with after it begins using an address map that does not correspond to unique physical cells.
Partial protection is a meaningful boundary. The researchers’ survey found modules with all SPD blocks unprotected, but also modules with partial protection. Protection of the core configuration blocks was enough to prevent this attack path in their testing. That result does not imply that every partially protected module has the same design or that no other memory-manipulation technique could work. It does establish that the software-only starting point is gated by a hardware security choice manufacturers and platforms can change.
The role of software is consequently precise. Software does not create new DRAM cells or directly toggle a missing row selector. It changes the description that tells the controller how to interpret addresses. The hardware then performs the aliasing according to its normal logic. That division of labor is why a Windows security feature operating above the controller cannot simply assume the issue away: VBS can protect the execution domains it manages, but the memory identity it receives has already been chosen below it.
The attack’s next problem is almost self-defeating. Once Windows believes the upper range exists, it may use it, and accesses can collide with the lower range. A machine that crashes at early boot is not a useful platform for a longer attack chain. Download More RAM therefore has to turn the clean row-based geometry into an operational advantage: keep Windows from allocating the upper aliases while finding a separate way to reach them. The next stage is about that unstable compromise between a usable operating system and memory the operating system believes it cannot use.