Skip to content
←

필사 모드: DRAM Address Scrambling and the Layer Beneath a Security Boundary — What Happens When the Fence Sits Above the Translation

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

This post is based on items I read directly from the Hacker News API and the GeekNews feed on 2026-08-15. Scores and rankings keep moving.

What was up there

An item read from the Hacker News API. The title is Spaghettifying DRAM, the item number is 49286341, and as of 2026-08-15 it stood at 691 points with 174 comments. The link points to the xoreaxeaxeax/skitter-creek-bath-salts GitHub repository. The same item appeared in the GeekNews feed.

What the README describes is a research tool that bypasses CPU security boundaries by manipulating the DRAM controller.

The problem is not the check. It is the order of the layers.

A memory address is translated several times on its way from the CPU to the DRAM chips. A virtual address becomes a physical address, and the physical address in turn becomes DRAM coordinates — channel, bank, row, column. The memory controller handles that last translation.

And the protections sit above it. The targets the README names are the security processor's private memory, the region used by system management mode, and the area where the CPU parks its internal state when entering an idle power state. These are carve-outs kept invisible to the operating system, and the fences blocking access to them are built in terms of physical addresses.

The structural flaw appears right there. The fence judges by physical address, but which DRAM cell that physical address reaches is decided in a layer below the fence. So what happens if you change the rules of that lower layer? The same cell becomes reachable through a different physical address — and that other address is not inside the fence, so it passes the check.

The README describes this manipulation as touching bank-swizzle modes and interleave settings, and shows an example in the form of flipping a single bit in a controller register. The point is not an elaborate attack chain but one configuration value.

How the aliases are found

The difficulty is that the swizzle rules are not documented. You may know that changing the setting rearranges addresses, but not which address now collides with which.

The procedure the README describes is observation followed by inversion. First, toggling through various scrambling modes, it collects alias pairs. That two physical addresses reach the same DRAM location is confirmed by writing at one and reading at the other. Enough such facts get gathered.

Then comes the technical core. Address swizzling is expressed as exclusive-or combinations of bits, which makes it a linear transformation over GF(2). The observed alias pairs therefore become equations in an unknown matrix, and feeding them to an SMT solver recovers that matrix.

Once you have the matrix the direction reverses. Now you can take a specific address inside a protected region as the target and compute another physical address that reaches that cell. That is the spaghetti in the title, and the un-spaghettifying in the tooling is the inverse operation.

The examples the README gives of what can be read out are concrete: on the security processor side, the firmware TPM's RSA engine; on the system management side, the interrupt handler's entry vectors; and in the idle-state carve-out, saved CPU registers and microcode patches.

The scope has to be stated precisely

The exaggeration needs stripping out here, and this is the first thing the comments established too.

First, root is already required. Several comments confirmed this, and the README's own procedure presumes administrator privileges. So this is not a privilege escalation vulnerability. It is about an attacker who already holds the highest privilege reaching regions that are supposed to sit below even that.

Second, the target is one CPU family. The README covers only AMD Family 16h, and gives its reason: it is the last generation whose datasheets document the DRAM controller's translation registers, and which demonstrates that they cannot be locked. The comments repeatedly noted that this is a low-power architecture from around 2013 and that there is essentially nothing about whether it works on current generations. The README itself says applicability to 17h and later is unknown.

Third, the preparation differs per platform. Pre-computed mapping files are required, and a different DIMM configuration means building new maps.

Put together, the real threat model is this: not a remote attack path, but research that extracts secrets from below ring -2 on specific older hardware that is physically accessible and already rooted. Game consoles came up in the comments precisely because that threat model fits them — the attacker holds the device, and while getting kernel access is hard, once obtained, what lies below it is the last line of defense.

What this leaves for our own systems

Most readers do not touch DRAM controllers. But the shape of this research repeats well outside hardware.

Generalized: a rule enforced at layer N is void if the attacker can operate at layer N-1. And the failure comes not from the rule being wrong but from the name the rule refers to being reinterpreted lower down.

The same shape is easy to find in software. Access blocked by path string while a symbolic link sends that path elsewhere; a check on a URL string while the library normalizes it differently; a policy attached to a container name while a mount shows different files underneath. All the same structure.

So one check worth taking to work is this: the name your access control bases its judgment on — who reinterprets it after that judgment? If even one translation step sits between the decision and the actual access, and an attacker can touch that step, the check is decoration. This connects to the thread in what a hardware backdoor actually is.

The second check is the relation between documentation and locking. This research picked a particular generation because that generation documented the registers — which, inverted, means settings that merely went undocumented but were never locked may well persist into later generations. Removing something from the docs is not a defense.

Who this does not apply to

For teams running applications on managed cloud, this item is not an action item. It presumes physical access and root, and by the time those hold, you have far larger problems.

The same goes for environments running only current server CPUs. The target is a specific family from around 2013, and the README carries no validation for later generations.

Conversely, who genuinely has to care is clear: products where the attacker physically owns the device — kiosks, set-top boxes, game consoles, field-installed equipment, and embedded boards. If such a product roots its trust in a firmware TPM or a security processor, it is worth checking which layer's fence that trust depends on.

Summary

What this repository shows is not a new cryptanalysis but a mistake in layout. Build the fence above the address translation, and to anyone who can change the translation that fence may as well not exist. And the scope is honestly narrow: root is required, it was confirmed on one CPU family, and preparation differs per platform. What remains is a lesson about the order of layers, not about a particular chip.

Sources and related reading

The generalization about layer ordering and the software-side examples are my own, built on what I read in the repository's documentation.

현재 단락 (1/31)

An item read from the Hacker News API. The title is `Spaghettifying DRAM`, the item number is 492863...

작성 글자: 0자원문 글자: 7,578자작성 단락: 0/31