Christopher Domas Bypasses AMD Family 16h APU Protections

A new research project demonstrates a deep hardware-level way to bypass protections on certain AMD processors from the “Family 16h” era. The technique doesn’t exploit a typical software or firmware bug—instead, it changes how the DRAM memory controller translates addresses, creating temporary memory aliases that can make protected regions reachable to the operating system. The work was published with accompanying tools on GitHub by security researcher Christopher Domas.

Quick facts

The attack targets AMD processors in the AMD Family 16h generation.
It works by altering DRAM address translation in the memory controller to create temporary aliases.
Protected regions reportedly remain protected from the layers above the memory controller, which continue to validate the original address ranges.
Demonstrated targets include AMD Platform Security Processor (PSP) private memory, SMRAM (SMM-reserved memory), C6 sleep memory, and DRAM-stored microcode data.
The published tools require highest system privileges (root) and a custom Linux kernel module; no remote/browser attack is described.
No CVE, security advisory, or BIOS update is listed in the repository.

Memory controller “address translation” as a backdoor

Domas’ approach focuses on the lowest layers of address handling. Before a physical address reaches a DRAM cell, the memory controller translates it into components such as channel, rank, bank, row, and column. The research points to multiple transformations being involved, some of which can be influenced via BIOS configuration.

A key detail in the demonstration is that a specific register bit controlling “bank swizzling” can be toggled during operation on the studied AMD processors without blocking access. By doing so, a physical address can be temporarily redirected to a different DRAM cell than intended.

From those mismatches, the project computes an alternate address—an alias—so that the same data can be accessed without targeting the original protected physical address. The controller is reconfigured only for the specific memory access and then restored back to the BIOS-set configuration afterward.

Where the protection checks still look in the “wrong place”

The higher-level protection mechanisms continue checking the originally intended physical address ranges. Because they don’t “see” the modified mapping underneath, the research claims they can’t detect that the actual DRAM cell accessed differs from what the operating system expects.

Using this behavior, the project describes access paths to multiple protected memory areas: private memory belonging to AMD’s Platform Security Processor (PSP), the SMRAM region reserved for System Management Mode, and memory used during the C6 low-power sleep state. It also lists microcode data stored in DRAM as a target area for reading and writing.

Published tools: read and write, not permanent microcode changes

The repository isn’t limited to theory. It includes programs named “dram_dump” and “dram_poke.” In the described workflow, “dram_dump” reads protected areas via the computed aliases, while “dram_poke” can write to those aliased locations.

However, the project does not describe a goal of permanently altering microcode stored inside the processor. Instead, it focuses on volatile data in system memory. The write-up also notes that the PSP in this device class has been present for more than a decade in AMD platforms.

Only proven on AMD Family 16h; later Ryzen generations not indicated

The attack was developed and tested explicitly on AMD Family 16h processors. This includes older Jaguar- and Puma-based APUs such as Kabini, Temash, Beema, and Mullins. By contrast, Ryzen processors fall into Family 17h or later, and the publication does not claim them as affected.

The project also discusses that PlayStation 4 and Xbox One consoles use Jaguar-derived CPU cores, but it does not provide a working demonstration on those systems. It argues that shared CPU architecture alone isn’t enough to conclude vulnerability, since the memory controller, firmware, and platform configuration are decisive.

Domas further states that Family 16h is the last AMD generation where public documentation includes the DRAM-controller translation registers needed for this method, and that this documentation indicates they are not locked. From Family 17h onward, those specific public details are said to be missing, which prevents the same level of certainty. The research notes that similar address transformations can exist on newer AMD chips and on platforms from Intel, ARM, and RISC-V—but frames that as a starting point for further study rather than proof of the same issue.

Not a remote exploit; requires elevated control and a kernel module

Operationally, the published tooling requires root privileges and a custom Linux kernel module. That means the project does not describe an immediate attack from a browser or across a network—an attacker would already need significant control of the system.

Even so, the research argues the method matters because regions like PSP and SMM-related memory are intended to provide extra separation even when the operating system or kernel is compromised.

At the time of publication, the repository does not list a CVE identifier, a security bulletin, or a BIOS update. The research is also described as being presented as a contribution to Black Hat USA 2026, while whether AMD can still provide mitigations for older platforms remains unanswered.