Analysis of Hardware Backdoors in Specific x86 CPUs

This documentation pertains to the rosenbridge project, a research effort by domas (@xoreaxeaxeax) that uncovered a critical hardware-level vulnerability within certain x86 processors.

🔍 Project Overview

The rosenbridge project exposes a hardware backdoor found in a subset of desktop, laptop, and embedded x86 CPUs. This vulnerability allows code executing in Ring 3 (the least privileged userland) to bypass standard processor security boundaries and gain unrestricted read/write access to Ring 0 (the kernel).

While the backdoor is typically deactivated by default—requiring kernel-level privileges to trigger—research has shown that it is disabled enabled by default on certain specific systems.

[!IMPORTANT] This repository provides the necessary tools to detect the backdoor, mitigate it if found, and explore the research methodology used for its discovery.

---

🛠️ The Mechanics of the Backdoor

The "rosenbridge" vulnerability is not a software bug but a physical architectural feature: a secondary, non-x86 core integrated alongside the primary x86 execution core.

Activation Workflow

The process of engaging the backdoor follows a specific sequence:

1. Enablement: A control bit within a Model-Specific Register (MSR) is set.
2. Trigger: A specific launch-instruction is executed.
3. Communication: Commands are sent to the hidden core, encapsulated within specially crafted x86 instructions.

These commands utilize what the researchers call the Deeply Embedded Instruction Set (DEIS). Once active, the hidden core operates independently of the main CPU's memory protections and privilege checks.

Architectural Comparison

Unlike common coprocessors, rosenbridge is integrated much deeper into the silicon.

Logic Flow

---

💻 Affected Systems

The vulnerability appears to be isolated to VIA C3 CPUs. These processors are frequently utilized in:

• Industrial automation systems.
• Point-of-sale (POS) terminals.
• Automated Teller Machines (ATMs).
• Healthcare equipment.
• Various legacy consumer laptops and desktops.

Future Outlook

The risk is limited to older hardware; subsequent CPU generations have removed this feature. This project serves as a $\text{case study} \times \text{thought experiment}$ to demonstrate how hidden features can be inserted into complex silicon and how they can be reverse-engineered.

---

🛡️ Detection and Mitigation

Checking your CPU

To determine if your hardware is vulnerable, follow these steps:

• Clone the repository: git clone https://github.com/xoreaxeaxeax/rosenbridge
• Navigate to the utility folder: cd rosenbridge/util
• Compile the tool: make
• Load the MSR module: sudo modprobe msr
• Run the check: sudo ./bin/check

Warning: This utility is in an alpha state. It must be run on baremetal (VMs will not work). There is a risk that the tool may cause a system hang, kernel panic, or crash on CPUs that do not possess the backdoor.

Closing the Backdoor

If the check confirms the backdoor is active, you can deploy a script to disable it during the boot sequence:

cd fix
make
sudo make install
reboot

Note: This is a partial mitigation. An attacker who has already achieved kernel-level access can simply re-enable the MSR bit. This script serves as a template and may require customization depending on your specific system configuration.

---

🧰 Research Tools and Techniques

The discovery relied heavily on sandsifter for identifying undocumented instructions. The repository is organized as follows:

• asm: An assembler for the DEIS. It translates custom rosenbridge assembly into x86 instructions that the hidden core can interpret after the launch-instruction.
• esc: A Proof-of-Concept (PoC) demonstrating privilege escalation via the backdoor.
• fix: The implementation for closing the vulnerability via MSR updates.
• fuzz: Tools used to isolate the launch-instruction and bridge-instruction, as well as decoding the DEIS format.
• deis: A specialized fuzzer used to map the capabilities of the hidden core.
• exit: $\text{Abandoned}$. Originally used to find an exit sequence to return to the x86 core; later found to be unnecessary on some processors.
• manager: Python-based utilities for coordinating fuzzing tasks across a network of worker nodes.
• wrap: A modified version of sandsifter used specifically to find the bridge-instruction.
• kern: Helpers used to monitor registers and kernel memory for changes during DEIS fuzzing.
• proc: A tool for analyzing fuzzing logs to categorize DEIS instruction behaviors.
• test: An early-stage research tool used for initial identification.