Skip to content
←

Split View: DRAM 주소 스크램블링과 보안 경계의 아래층 — 울타리가 번역보다 위에 있으면 생기는 일

✨ Learn with Quiz
|

DRAM 주소 스크램블링과 보안 경계의 아래층 — 울타리가 번역보다 위에 있으면 생기는 일

이 글은 2026-08-15에 Hacker News API와 GeekNews 피드에서 직접 확인한 항목을 바탕으로 합니다. 점수와 순위는 계속 바뀝니다.

무엇이 올라와 있었나

Hacker News API로 확인한 항목입니다. 제목은 Spaghettifying DRAM, 아이템 번호는 49286341이고 2026-08-15 기준 691점에 댓글 174개입니다. 링크는 xoreaxeaxeax/skitter-creek-bath-salts GitHub 저장소입니다. GeekNews 피드에도 같은 항목이 올라와 있었습니다.

README가 설명하는 것은 DRAM 컨트롤러를 건드려 CPU의 보안 경계를 우회하는 연구 도구입니다.

문제는 검사가 아니라 층의 순서입니다

메모리 주소는 CPU에서 DRAM 칩까지 가는 동안 여러 번 번역됩니다. 가상 주소가 물리 주소가 되고, 물리 주소가 다시 채널과 뱅크와 행과 열이라는 DRAM 좌표가 됩니다. 마지막 변환을 담당하는 것이 메모리 컨트롤러입니다.

그리고 보호 장치들은 그보다 위층에 있습니다. README가 지목하는 대상은 보안 프로세서의 전용 메모리, 시스템 관리 모드가 쓰는 영역, 그리고 CPU가 절전 상태로 들어갈 때 내부 상태를 잠시 넣어 두는 구간입니다. 이 구간들은 운영체제에 보이지 않게 떼어 놓은 예약 영역이고, 접근을 막는 울타리가 물리 주소 단위로 세워져 있습니다.

여기서 구조적 결함이 드러납니다. 울타리가 물리 주소를 보고 판단하는데, 그 물리 주소가 어느 DRAM 셀로 가는지는 울타리보다 아래층에서 정해집니다. 그렇다면 아래층의 규칙을 바꿔 버리면 어떻게 될까요. 같은 셀이 다른 물리 주소로도 도달 가능해집니다. 그리고 그 다른 주소는 울타리 안쪽이 아니므로 검사를 통과합니다.

README는 이 조작을 뱅크 뒤섞기 모드와 인터리브 설정을 건드리는 것으로 설명하고, 컨트롤러 레지스터의 비트 하나를 뒤집는 형태의 예를 보여 줍니다. 요점은 정교한 공격 사슬이 아니라 설정 값 하나라는 점입니다.

별칭을 어떻게 찾아내는가

문제는 뒤섞기 규칙이 문서화되어 있지 않다는 것입니다. 설정을 바꾸면 주소가 재배치된다는 것은 알아도, 어느 주소가 어느 주소와 같은 셀을 가리키는지는 알 수 없습니다.

README가 설명하는 절차는 관측과 역산입니다. 먼저 스크램블링 모드를 여러 가지로 토글하면서 별칭 쌍을 모읍니다. 두 물리 주소가 같은 DRAM 위치를 가리킨다는 사실은 한쪽에 쓰고 다른 쪽에서 읽어 보면 확인됩니다. 이렇게 사실을 충분히 모읍니다.

그다음이 이 연구의 기술적 핵심입니다. 주소 뒤섞기는 비트들의 배타적 논리합 조합으로 표현되므로, 이것은 GF(2) 위의 선형 변환입니다. 즉 관측한 별칭 쌍들은 미지의 행렬에 대한 방정식이 되고, SMT 솔버에 넣으면 그 행렬을 복원할 수 있습니다.

행렬을 얻고 나면 방향이 뒤집힙니다. 이제 보호 영역 안의 특정 주소를 목표로 두고 그 셀에 도달하는 다른 물리 주소를 계산할 수 있습니다. README가 제목으로 쓴 스파게티라는 표현이 이것이고, 도구 이름에 들어간 되돌리기가 그 역연산입니다.

읽어 낼 수 있는 것으로 README가 드는 예는 구체적입니다. 보안 프로세서 쪽에서는 펌웨어 TPM의 RSA 엔진, 시스템 관리 모드 쪽에서는 인터럽트 처리기의 진입 벡터, 절전 예약 영역에서는 저장된 CPU 레지스터와 마이크로코드 패치입니다.

범위를 정확히 해야 합니다

여기서 과장을 걷어 내야 합니다. 댓글에서 가장 먼저 확인된 것도 이 부분이었습니다.

첫째, 이미 루트 권한이 필요합니다. 여러 댓글이 이 점을 확인했고 README의 실행 절차도 관리자 권한을 전제로 합니다. 즉 이것은 권한 상승 취약점이 아닙니다. 이미 최고 권한을 얻은 공격자가 그보다 더 아래에 있어야 할 영역까지 도달하는 이야기입니다.

둘째, 대상이 한 CPU 계열입니다. README는 AMD Family 16h만 다루며, 그 이유를 데이터시트가 DRAM 컨트롤러의 변환 레지스터를 문서화한 마지막 세대이고 그것이 잠기지 않는다는 사실을 보여 주기 때문이라고 밝힙니다. 댓글에서는 이것이 2013년 무렵의 저전력 아키텍처라는 점과, 최신 세대에서 통하는지에 대한 언급이 사실상 없다는 점이 반복해서 지적됐습니다. README도 17h 이후에 적용되는지는 알 수 없다고 스스로 적고 있습니다.

셋째, 플랫폼마다 준비 작업이 다릅니다. 미리 계산해 둔 매핑 파일이 필요하고 DIMM 구성이 다르면 매핑을 새로 만들어야 합니다.

이 셋을 합치면 실제 위협 모델은 이렇습니다. 원격 공격 경로가 아니라, 물리적으로 접근 가능하고 루트를 이미 가진 특정 구형 하드웨어에서 링 마이너스 2 아래의 비밀을 꺼내는 연구입니다. 댓글에서 게임 콘솔이 언급된 것도 그 위협 모델이 정확히 들어맞기 때문입니다. 콘솔은 공격자가 기기를 손에 들고 있고, 커널을 잡는 것이 어려운 대신 잡고 나면 그 아래가 방어의 마지막 선이기 때문입니다.

이 이야기가 우리 시스템에 남기는 것

대부분의 독자는 DRAM 컨트롤러를 만지지 않습니다. 그런데 이 연구의 형태는 하드웨어 밖에서도 반복됩니다.

일반화하면 이렇습니다. N층에서 강제한 규칙은 공격자가 N-1층에서 동작할 수 있으면 무효입니다. 그리고 이 실패는 규칙이 틀려서가 아니라 규칙이 참조하는 이름이 아래층에서 다시 해석되기 때문에 생깁니다.

같은 형태를 소프트웨어에서 찾으면 금방 나옵니다. 경로 문자열로 접근을 막아 두었는데 심볼릭 링크가 그 경로를 다른 곳으로 보내는 경우, URL 문자열로 검사했는데 라이브러리가 다르게 정규화하는 경우, 컨테이너 이름으로 정책을 걸었는데 마운트가 그 아래에서 다른 파일을 보여 주는 경우가 모두 같은 구조입니다.

그래서 실무에서 가져갈 점검 하나는 이것입니다. 여러분의 접근 통제가 판단 근거로 삼는 이름을, 그 판단 이후에 누가 다시 해석하는가. 판단과 실제 접근 사이에 번역 단계가 하나라도 끼어 있고 그 단계를 공격자가 건드릴 수 있다면 검사는 장식입니다. 이 관점은 하드웨어 백도어가 실제로 무엇인가에서 다룬 갈래와 이어집니다.

두 번째 점검은 문서화와 잠금의 관계입니다. 이 연구가 특정 세대를 고른 이유는 그 세대가 레지스터를 문서화했기 때문인데, 뒤집어 보면 문서화하지 않았을 뿐 잠기지 않은 설정은 다음 세대에도 남아 있을 수 있습니다. 문서에서 지우는 것은 방어가 아닙니다.

누구에게는 해당 없는가

관리형 클라우드에서 애플리케이션을 운영하는 팀에게 이 항목은 직접적인 조치 대상이 아닙니다. 물리 접근과 루트를 전제로 하기 때문이고, 그 전제가 성립하는 시점이면 이미 다른 문제가 훨씬 큽니다.

최신 서버 CPU만 쓰는 환경도 마찬가지입니다. 대상이 2013년 무렵의 특정 계열이고 이후 세대에 대한 검증은 README에 없습니다.

반대로 실제로 챙겨야 하는 쪽은 분명합니다. 공격자가 기기를 물리적으로 소유하는 제품, 즉 키오스크, 셋톱박스, 게임기, 현장 설치 장비, 그리고 임베디드 보드입니다. 이런 제품에서 펌웨어 TPM이나 보안 프로세서를 신뢰 기반으로 삼고 있다면 그 신뢰가 어느 층의 울타리에 의존하는지 확인할 가치가 있습니다.

정리

이 저장소가 보여 주는 것은 새로운 암호 해독이 아니라 배치의 실수입니다. 울타리를 주소 변환보다 위에 세우면, 변환을 바꿀 수 있는 사람에게 그 울타리는 없는 것과 같습니다. 그리고 범위는 정직하게 좁습니다. 루트가 필요하고, 한 CPU 계열에서 확인됐으며, 플랫폼마다 준비가 다릅니다. 남는 교훈은 특정 칩이 아니라 층의 순서입니다.

원문과 관련 글

층의 순서에 대한 일반화와 소프트웨어 쪽 사례는 저장소 문서에서 확인한 내용을 바탕으로 제가 정리한 것입니다.

DRAM Address Scrambling and the Layer Beneath a Security Boundary — What Happens When the Fence Sits Above the Translation

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.