The lesson below the hypervisor

Download More RAM answers a precise question about Windows VBS: can a security boundary remain internally correct while the memory identity beneath it has become false? The paper’s result, and the judgment it supports, are that VBS can enforce its intended rules over the map it receives while a software-induced alias causes two reported physical addresses to reach the same cells. The reader should therefore leave with two conclusions at once: the demonstrated attack is conditional and bounded, and its design lesson reaches beyond one Windows build because it concerns who authenticates the resources that an isolation boundary protects.

The subject is not “RAM attacks” in the abstract. It is Download More RAM’s path from writable SPD metadata to a changed physical address map, a raw view of memory, and a code-integrity bypass that can reach defenses above it. Its significance lies in the relationship among those stages. A hypervisor can be a strong boundary and still inherit a lower-level identity error.

When isolation inherits the wrong identity

VBS is designed around an assumption that is easy to leave unstated: a physical address has one physical meaning. Hyper-V can separate VTL0 from VTL1. The Secure Kernel can decide whether a driver is acceptable. HVCI can enforce code-integrity checks and executable/write separation. PPL can prevent a lower-protection process from terminating an anti-malware service. Those decisions are meaningful if the memory holding the decision, the protected code, and the state being protected can be identified consistently across the layers.

Download More RAM changes that premise before the hypervisor’s isolation has anything to correct. Software rewrites configuration in a DIMM’s SPD, and the platform later uses the altered information to configure memory addressing. A row-address declaration makes the reported upper range an alias of the lower physical range. Windows sees two reported regions; the memory controller reaches one set of cells. The operating system has not necessarily made a bad page-table decision. It has been given a physical map whose names no longer correspond one-to-one with storage.

This distinction is the paper’s central systems insight. A security policy can be correct relative to a map and still be unsafe if the map is not authenticated. That is different from saying that VBS is decorative or that all hardware lies. The attack works because a lower-level component has an authority that higher layers treat as a configuration input rather than as a security claim requiring independent validation.

The rest of the chain follows from the conflict between the policy map and the hardware map. If Windows uses both reported halves, ordinary allocations collide and the machine becomes unstable. To continue, the researchers keep the upper range outside the normal allocator. Windows becomes more stable because it uses less memory, while the memory controller still responds to physical addresses in the excluded range. A physical-memory acquisition interface can then expose the range that ordinary Windows APIs do not allocate. The resulting view must be decoded for address-dependent DDR scrambling and distinguished from the virtualized VTL0 view. If it contains Secure Kernel or Hyper-V contents, the read has crossed the confidentiality boundary VBS was intended to enforce.

That read is already important, but it does not by itself explain the paper’s full-compromise claim. The write path is noisier. A RAM-disk utility can reserve the excluded range, but its filesystem writes metadata as well as user data. A large or complex allocation can overwrite live structures and crash the system. A small, targeted overlay is more plausible because it touches less unrelated state, especially when reconnaissance identifies a relatively stable integrity target.

The high-leverage target is the Secure Kernel’s code-integrity logic. The paper’s reverse engineering identifies the validation, certificate, revocation, and policy decisions that enforce the vulnerable-driver blocklist. A limited patch that makes the relevant revocation decisions report success can admit a previously blocked driver through the normal loading path. That driver then provides a more reliable physical-memory read/write capability than the filesystem-backed overlay. The chain has changed the authority that decides whether a stronger capability may enter the system.

This is why the impact cannot be reduced to “the attacker found a vulnerable driver.” The driver was already known and had been blocked. Download More RAM’s contribution is to show how a lower-layer memory alias and a constrained write can reach the mechanism that keeps the driver blocked.