⏱️ Lectura: 10 min
A researcher who goes by domas published proof on GitHub that certain VIA C3 processors ship, out of the factory, with a hidden core capable of jumping from ring 3 (applications) to ring 0 (kernel) without asking permission. The finding, named Rosenbridge, includes the source code, detection tools, and a method to close the flaw in the official repository, which today has accumulated 2,400 stars and 222 forks.
📑 En este artículo
What’s unsettling isn’t just that a hardware backdoor exists in these chips: according to the project’s own documentation, it comes enabled by default on some systems. Any unprivileged program could, in theory, modify the kernel without going through any operating system check.
TL;DR
- Rosenbridge is a hardware backdoor documented in VIA C3 x86 processors, published on GitHub by the researcher who goes by domas.
- A hidden core, separate from the main x86 core, is activated with a control bit in an MSR and a specific ‘launch-instruction’.
- That core runs the ‘Deeply Embedded Instruction Set’ (DEIS), which jumps from ring 3 (user) to ring 0 (kernel) without privilege verification.
- The project reports that the backdoor appears active by default on some systems, without the kernel enabling it.
- VIA C3 chips were marketed for industrial automation, point of sale, ATMs, medical equipment, and some desktop PCs and laptops.
- The repository includes ‘util/check’ to detect the flaw and ‘fix’ to close it at boot, though an attacker with root access can re-enable it.
- According to the authors, CPU generations after the C3 no longer include this hidden core.
- The research relied on sandsifter, the same author’s fuzzer for finding undocumented x86 instructions.
Introduction: What Is a Hardware Backdoor
A hardware backdoor is an access door that lives in the silicon, not in the software: no operating system patch can remove it, because the problem is etched into the circuit itself. Unlike a software vulnerability, which gets fixed with an update, a hardware backdoor requires replacing the affected component or mitigating it at the firmware level.
Rosenbridge is exactly that: a secondary core, foreign to the x86 architecture, embedded alongside the main core in some VIA C3 processors. VIA Technologies is a Taiwanese manufacturer that competed with Intel and AMD in the low-power segment, and its C3 chips were mainly used in embedded hardware, not in the mass-market consumer laptops most developers use today.
What Happened
The researcher documented that the hidden core is turned on via a control bit in a model-specific register (MSR), and is then triggered with what the project calls the launch-instruction: an x86 instruction that looks normal but actually switches execution to the hidden core. Once active, that core receives commands encoded inside x86 instructions with a special format: the set the project named the Deeply Embedded Instruction Set (DEIS).
DEIS instructions bypass the processor’s usual memory protections and privilege checks. In practice, the hidden core has read and write access to the entire system memory, the register bank, and the CPU’s own execution pipeline. That level of access is deeper than other known x86 coprocessors, such as the Intel Management Engine or the AMD Platform Security Processor: Rosenbridge isn’t a remote management chip, it’s a second brain inside the same silicon die.
flowchart TD
A["Program in ring 3"] --> B["Writes the control bit in the MSR"]
B --> C["Executes the launch-instruction"]
C --> D["Hidden core activates"]
D --> E["Runs DEIS instructions"]
E --> F[("Memory, registers, and pipeline in ring 0")]
Context and History
The VIA C3 processors and the later C series targeted niche markets: industrial automation, point-of-sale terminals, ATMs, and medical equipment, plus some budget desktop computers and laptops. This is hardware that’s rarely replaced quickly: it’s still running inside critical retail and banking infrastructure in several countries, including much of Latin America, where payment terminal replacement cycles tend to be long.
To reach this finding, the research relied heavily on sandsifter, a fuzzer by the same author designed to discover undocumented x86 instructions by systematically testing the processor’s opcode space. That technique, applied first to map the hidden instruction set and then to isolate the launch-instruction and the DEIS format, is what made it possible to reconstruct the hidden core’s full protocol without access to VIA’s internal documentation.
Technical Details and Performance
The repository is organized by function. The asm folder contains an assembler for DEIS, which translates programs written in Rosenbridge’s own assembly into x86 instructions that, when executed after the launch-instruction, send commands to the hidden core. The esc folder includes a privilege escalation proof of concept that uses the backdoor to get kernel access from a user application.
The fix folder provides a mitigation script meant to be installed early in the boot process. The fuzz folder groups the utilities used during the research: the deis fuzzer, which explored the hidden core’s effects and capabilities; exit, the (later abandoned) search for an exit sequence back to the normal x86 core; manager, a set of Python utilities for coordinating fuzzing tasks distributed across a network; and wrap, a reduced version of sandsifter focused on isolating the bridge-instruction. The project also includes supporting directories (kern, lock, proc, test) used during the different stages of the research.
📌 Note: according to the repository itself, the scope of this vulnerability is limited: processor generations after the C3 no longer contain this hidden core.
As for performance figures for the hidden core (DEIS execution speed, launch-instruction latency), the repository doesn’t publish benchmarks, so it wouldn’t be right to make them up. What’s verifiable is the binary behavior: on an affected system, util/check returns a positive result; on an unaffected system, the tool fails to activate the core and ends with no evidence of a response from the backdoor.
How to Start Testing It
The first step is to clone the repository and compile the check utility. This only makes sense on Linux running on bare metal, because the tool needs to load the kernel module msr and read model-specific registers directly from the physical processor.
git clone https://github.com/xoreaxeaxeax/rosenbridge
cd rosenbridge/util
make
sudo modprobe msr
sudo ./bin/checkThat command compiles the check binary, loads the Linux kernel’s msr module, and runs the detection. If your processor is a vulnerable VIA C3, the result indicates the hidden core responded to the activation sequence.
⚠️ Warning: the project itself warns that the tool is in alpha state and can hang or crash systems that don’t have the backdoor, because it tests non-standard instruction sequences directly on the hardware.
If the check confirms the processor is vulnerable, the closing script can be installed early in the boot process:
cd rosenbridge/fix
make
sudo make install
rebootRegarding operating systems: on native Linux (not inside a virtual machine, since direct access to the physical MSR isn’t available inside a hypervisor) the procedure above works as-is. On Windows there’s no native build of the utility; the option is to boot the machine from a Linux USB (or dual boot) to run the check on the real hardware, since WSL doesn’t expose the CPU’s raw MSR either. On macOS this doesn’t directly apply (Apple never used VIA C3 processors), though if you manage old embedded hardware with a real C3, the same bootable Linux USB approach works to audit it.
Impact and Analysis
The real risk depends on the deployment context. An attacker needs, at minimum, the ability to run unprivileged code on the target machine; from there, if the backdoor is active by default, they can escalate to kernel level without exploiting any software bug. That’s particularly relevant for embedded terminals (POS, ATMs, industrial equipment) where it’s sometimes wrongly assumed that hardware is an immutable trust layer.
| Coprocessor | Manufacturer | Access Scope | How It’s Disabled |
|---|---|---|---|
| Intel Management Engine (ME) | Intel | Remote management subsystem with its own firmware and network stack | Partial disabling via HAP bit or third-party tools; not always supported by the manufacturer |
| AMD Platform Security Processor (PSP) | AMD | Dedicated ARM coprocessor with security and boot functions | Partial disabling on some boards via UEFI; no full official support |
| Rosenbridge | VIA (C3) | Embedded core with direct access to memory, registers, and the main x86 core’s pipeline | Mitigation script in rosenbridge/fix, reversible by an attacker with root access |
The key difference is in the scope column: while the Intel ME and AMD PSP are independent coprocessors with their own firmware, Rosenbridge lives inside the same x86 core, sharing the pipeline and register bank with the code that’s supposed to be isolated from it.
What’s Next
The authors themselves present Rosenbridge as a case study, not as an alert about an active large-scale vulnerability: the scope is limited to the VIA C3 family, and later processor generations don’t include it. The project’s value lies in the methodology: using sandsifter to map undocumented instructions is applicable to any modern x86 processor, and it serves as a starting point for deeper research into processor backdoors in general.
For security teams managing legacy embedded infrastructure (retail, banking, healthcare), the practical lesson is to inventory what hardware is still in production and run the check before assuming the firmware is clean just because the operating system is.
📖 Summary on Telegram: View summary
Try it yourself: if you manage legacy VIA C3 hardware, clone the repository and run sudo ./bin/check on bare metal before trusting that equipment for production.
Frequently Asked Questions
What is Rosenbridge?
It’s a hardware backdoor documented in VIA C3 x86 processors: a hidden core, separate from the main x86 core, that allows running commands with kernel access from unprivileged code.
Is my computer at risk?
Only if it uses a VIA C3 processor or one from the affected C series. The vast majority of current consumer hardware, with Intel or AMD CPUs, doesn’t face this specific risk.
How is the backdoor activated?
With a control bit in an MSR and a special instruction (launch-instruction) that turns on the hidden core; commands are then sent to it encoded as DEIS instructions.
Is it the same as the Intel Management Engine?
No. The Intel ME and AMD PSP are independent coprocessors with their own firmware. Rosenbridge is embedded inside the same main x86 core, with direct access to its pipeline and registers.
Can the backdoor be closed?
The repository includes a mitigation script that installs at boot, but an attacker with prior kernel access could revert it, as the authors themselves warn.
Does it still exist in current VIA processors?
According to the project, no: generations after the C3 no longer include this hidden core.
References
- Official Rosenbridge repository: source code, detection tools, and mitigation script.
- Sandsifter: the fuzzer used to discover undocumented x86 instructions during the research.
- VIA C3 on Wikipedia: context on the affected processor family.
- Hardware backdoor on Wikipedia: general definition of this type of vulnerability.
📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Chris Ried en Unsplash
0 Comments