This is the second part of my write-up on vulnerabilities in the Realtek SD card reader driver. In this part, I will show how exposing device registers to non-privileged users can lead to access to physical memory. The post focuses solely on the DMA vulnerability because its PoC is quite complex. The first part of the write-up, which describes other flaws of the driver, can be found here . In January 2022, I discovered several vulnerabilities in the Realtek SD card reader driver, including one that allows access to the device’s registers. Once Realtek released a fix, I started writing the blog post and realized that potential access to the DMA controller was still present. I had missed it when Realtek asked me to verify the fix – and so had they. The reason for this oversight was that the original PoC for the vulnerability wasn’t very indicative; it interacted with only a few device registers without producing any noticeable effects. So, I decided to create a full-fledged PoC that clearly demonstrates the problem by allowing a non-privileged user-mode application to access the host’s physical memory. And damn, it was not an easy ride! The card reader is a complex device, and Realtek does not provide any specifications for it. When interacting with the reader, it behaves like a not-very-talkative black box with zero error tolerance. The DMA controller is not a standalone device; it works based on the results of SCSI command execution. This means that not only must the DMA controller be programmed correctly, but the SCSI command must execute flawlessly as well. These factors made the development quite challenging. After a few months of staring at the driver code in IDA, comparing it to open-source versions, conducting a crazy number of experiments, and a couple of despair peaks, I managed to create a PoC that can write to the first 4GB of physical memory. And yes, it works from user mode. Well, I always wanted to work with a device that has DMA capability, but I didn’t think it would happen in such an unusual way! [Intro] Before diving into the technicalities, let’s talk about what we’re going to do and why. Direct Memory Access (DMA) allows devices to transfer data directly to and from system memory without involving the CPU. It is implemented using a dedicated controller that connects peripheral devices to physical memory and manages data transfers, offloading this task from the CPU. DMA transfers typically follow one of two patterns, depending on the direction of data movement: Device to memory: The driver programs the device to place data into a buffer accessible to the DMA controller, prepares one or more DMA descriptors that point to the target physical memory location, and then triggers the transfer. Memory to device: The driver prepares DMA descriptors that point to the source memory location and initiates the transaction. The DMA controller moves the data into a device-accessible buffer, after which the driver programs the device to store the data. So, from the card reader’s perspective, writing to physical memory corresponds to performing an SD card read operation, which moves data from the card into memory. Conversely, reading from memory means writing that data to the card. While DMA is a powerful optimization mechanism, it can also serve as a potent tool for covert memory access. At the physical memory level, boundaries between processes – as well as between kernel and user-mode memory – do not exist. Moreover, on Windows, DMA transfers are invisible to EDRs and even the operating system itself. The goal of this post is to demonstrate how to gain access to physical memory by leveraging the system’s DMA capabilities through Realtek’s SD card reader and its Windows driver. The specifics of attacks – such as which Windows kernel structures are worth targeting – are beyond the scope of this post. To access physical memory, the attacker needs to understand the following: How to program the card reader as a PCI device, described in the Device section How to issue SCSI commands. This is explained in the SCSI Command section How to program the DMA controller, detailed in the DMA section After covering these topics, I’ll walk through a PoC that uses the SD card reader to perform a DMA transfer – writing data to an arbitrary physical memory address from user mode. Additionally, I will outline the tools I used during the research, along with a few other topics. [Device] First things first, let’s start with general card reader programming. The card reader is a regular PCI device managed via memory-mapped I/O. Simply put, this means certain regions of the system’s physical memory are mapped to the device’s internal memory and registers. Reads and writes to these regions are routed to the card reader at the hardware level, making interaction with it straightforward. The PCIe standard defines Base Address Registers (BARs) to request and store device-mapped memory regions. At system startup, the system queries P...