Unlocked: The "God Mode" Hardware Backdoor in x86 CPUs – A Deep Dive into Project Rosenbridge

^{The research starts by diving into the Deeply Embedded Core (DEC): A Stealthy RISC Processor}

^{Deeply Embedded Core (DEC). Unlike more widely recognized co-processors like Intel Management Engine (ME) or AMD Platform Security Processor (PSP), the DEC in VIA C3 processors is remarkably insidious due to its intimate integration with the main x86 core. My research indicates that the DEC is not an entirely separate entity but rather a RISC processor that shares significant segments of the execution pipeline and other architectural facilities with the x86 core. This shared microarchitecture significantly reduces its footprint, both in terms of circuitry and exposure, making it far more challenging to detect and interact with than typical co-processors. The pipeline likely diverges after the instruction fetch phase, with separate decoders for x86 and RISC pathways, yet retaining a partially shared register file.}

The Activation Mechanism

^{The activation of the DEC and the backdoor hinges on manipulating a specific Model Specific Register (MSR). MSRs are 64-bit control registers in x86 processors, typically accessible only to ring 0 (kernel-level) code. These registers control various processor features, and their addresses and functions are often undocumented by manufacturers due to their immense power and potential for misconfiguration.}

^{To uncover the relevant MSR and its "god mode bit," I employed a multi-stage methodology:}

1. ^{MSR Fault Analysis: Initially, fault analysis was used to identify implemented MSRs on the VIA C3, revealing approximately 1300 implemented MSRs out of 4 billion possibilities.}

2. ^{Side-Channel Attack for MSR Reduction: To make the analysis of these undocumented MSRs feasible, a novel side-channel attack was developed. This involved measuring the access times of all possible MSRs using rdmsr and rdtse instructions. Functionally different MSRs generally exhibit different access times due to varying microcode backing them, allowing for the differentiation of "like" and "unlike" MSRs based on timing patterns. This process reduced the candidate MSRs to a more manageable 43 functionally unique registers.}

3. ^{Processor Fuzzing with Sandsifter: With the candidate MSRs identified, the Sandsifter processor fuzzing tool was employed. This tool is capable of exposing undocumented instructions in x86. The crucial step involved toggling each bit of the candidate MSRs one by one, while monitoring for system instability (e.g., general protection exceptions, kernel panics, processor locks). An automated hardware system reset tool was utilized to manage the hundreds of reboots required for this process over a week.}

4. ^{Discovery of the Launch Instruction and God Mode Bit: This exhaustive fuzzing process, spanning over 100 million instructions, revealed a single, undocumented x86 instruction: 0f3f. This instruction, not found in any public processor documentation from any vendor, was identified as the "launch instruction" hinted at in VIA patents. Through GDB observation, it was determined that 0f3f effectively acts as a jmp %eax instruction, branching to the address held in the eax register.Further testing with 0f3f quickly pinpointed MSR 1107h, bit 0 as the specific "global configuration register" bit that activates this launch instruction and, by extension, the DEC. This bit we aptly named the "god mode bit" due to its potential to circumvent privilege protections and grant unfettered control of the processor.}

   
   

The Bridge Instruction and Privilege Escalation

^{Once the "god mode bit" is set and the DEC is active, a new challenge arises: how to execute instructions on the RISC core. While initial patent literature suggested a direct switch between decoders, empirical observation showed the processor continuing to execute x86 instructions. I theorized and confirmed that the launch instruction modifies the x86 decoder itself, activating new RISC pathways within it.}

^{This means a specific x86 instruction, termed the "bridge instruction," is used to dispatch 32-bit immediate values to the RISC core when in "RISC mode" (activated by the launch instruction). The bridge instruction identified on a VIA C3 Nehemiah core was bound %eax, 0x00000000(,%eax, 1), where 0x00000000 represents the 32-bit RISC instruction sent to the DEC.}

^{The ring 3 to ring 0 privilege escalation is then achieved by crafting RISC instructions that, when executed by the DEC, corrupt the system state in a way that is normally impossible from userland. Since the DEC has access to protected kernel memory and registers, a carefully chosen RISC instruction can cause processor locks, kernel panics, or system reboots. The ability of an unprivileged x86 instruction (the bridge instruction) to trigger such a catastrophic event is direct evidence of the successful privilege escalation. The fuzzing process to identify effective RISC instructions involved generating random x86 instructions, preceding them with the launch instruction, and then observing for system corruption to determine the bridge instruction and the corrupting RISC instruction.}

Broader Implications

^{If the assumptions about the design and power of the deeply embedded core are correct, the core could be used as a sort of backdoor on the processor, able to surreptitiously circumvent all of the most critical processor security checks; we call this backdoor rosenbridge. While the VIA C3 processors are older, the implications of rosenbridge are profound. This research provides an invaluable case study for the entire industry, demonstrating that deeply embedded hardware backdoors are not theoretical but a tangible threat. The methodologies and open-sourced tools developed during this research, are linked below.} 

Christopher Domas (@xoreaxeaxeax)

^Materials

• ^Whitepaper

• ^{Blackhat Slides}

• ^{Blackhat Recording}

• ^{Proejct:rosenbridge GitHub}

• ^{Project:sandsifter GitHub}

• ^{Hack in the box recording}