Security researcher David Hübl (xdavidhu) published a writeup this week about running a Tesla Model 3’s Media Control Unit on his desk, sourcing the hardware from crashed vehicles. It got a lot of attention on Hacker News, partly because it’s a satisfying hardware hacking story, but mostly because the engineering challenges it surfaces are genuinely interesting. Getting an automotive ECU to function without a car around it is not like plugging in a random PC board. There are assumptions baked into that hardware at every layer.
What the Tesla MCU2 Actually Is
The Model 3 uses what Tesla calls MCU2, which is the second generation of its infotainment and vehicle control computer. Under the hood it is a fairly conventional x86 Linux machine: an Intel Atom A3960 running at around 1.6 GHz, with 8 to 16 GB of RAM, NVMe or eMMC storage, an Intel Wi-Fi card, and an LTE modem. The OS is a customized Linux distribution running a Xen-based hypervisor that hosts several isolated VMs simultaneously: one for the Qt-based touchscreen UI, one for the instrument cluster, and one that acts as a gateway for CAN bus communication.
This architecture is a deliberate safety decision. Exploiting a memory corruption bug in the browser that renders the center screen should not give an attacker access to steering or braking. The CAN gateway VM is its own isolated domain, and the autopilot computer (a completely separate board with either Tesla’s own FSD chip or an earlier NVIDIA Drive PX 2) communicates with the MCU over 100BASE-T1 automotive Ethernet rather than sharing a bus. You can achieve code execution in the UI VM and still be separated from anything safety-critical by hardware and hypervisor boundaries.
The earlier MCU1 generation, used in Model S and X through 2018, was built around an NVIDIA Tegra 3 and became notorious for a hardware failure mode: an 8 GB Hynix eMMC chip that accumulated wear from constant log and browser cache writes until it bricked the touchscreen entirely. NHTSA issued a recall covering about 135,000 vehicles. MCU2 replaced it with a larger, faster storage solution and an x86 platform that is essentially a consumer PC with automotive connectors on it.
Parts from the Salvage Yard
The cost economics of automotive security research changed when insurance salvage auctions became widely accessible online. A crashed Model 3 with a functional MCU, or just the MCU pulled from one, is available for a few hundred dollars from salvage yards and services like Copart or Pick-n-Pull. For vulnerability research purposes, this is transformative. You get genuine production hardware running genuine production firmware without needing to own a vehicle or put a research car on a lift every time you want to test something.
The catch is that a Tesla MCU was never designed to exist outside a car. It assumes a vehicle around it, and the moment you remove that assumption, you have to reconstruct it artificially.
The CAN Bus Keepalive Problem
This is where things get technically interesting. Modern ECUs communicate over Controller Area Network (CAN) buses, and the Tesla MCU sits on several of them: a chassis bus for powertrain and braking, a body bus for lights, locks, and HVAC, and a battery bus for the high-voltage pack. Each bus carries periodic status messages from every node. When a node goes silent, other nodes notice.
Run an MCU2 bench setup with no CAN traffic at all and some subsystems refuse to initialize fully. The gateway VM expects to see keepalive messages. Certain features check for the presence of specific CAN nodes before enabling themselves. Automotive engineers call these “network management frames” and they are pervasive enough that any serious bench setup needs a CAN bus simulator: typically a USB adapter like the PEAK PCAN-USB running a small script that broadcasts periodic messages on the right arbitration IDs at the right intervals.
This is annoying to set up correctly because the exact IDs and timing are not publicly documented. Researchers like greentheonly, who has spent years reverse-engineering Tesla’s internal protocols, have mapped enough of this to make bench setups viable. Getting there from scratch means capturing traffic from a real vehicle first, then replaying it.
Power and Boot
The 12V automotive electrical system is straightforward to simulate with a bench power supply, but the power draw characteristics are worth knowing. The MCU2 pulls around 25 to 30 watts at idle and can spike to 60 watts during boot when the NVMe is spinning up and all VMs are initializing simultaneously. A marginal supply will brown out during boot, which produces confusing symptoms that look like software failures.
There is also a dedicated wake line, a separate signal that tells the MCU the vehicle is transitioning from sleep to awake. Without it, some subsystems stay in a low-power sleep state indefinitely. The full boot sequence requires simulating both the 12V rail and this wake signal at the right timing relationship.
Tesla’s Firmware Security Model
For security research, understanding what protections you are working against matters as much as the hardware setup itself. Tesla’s firmware uses dm-verity to enforce root filesystem integrity: the kernel verifies blocks against a signed hash tree at mount time, so patching system files directly is not straightforward. The bootloader enforces Secure Boot using Tesla’s own PKI, so unsigned kernels do not load.
However, the threat model for bench research is different. You are not trying to install persistent malware on a production system; you are trying to find vulnerabilities that could be exploited remotely on an unmodified vehicle. For that, you want the firmware to be exactly as it shipped. The dm-verity and Secure Boot protections are actually helpful here because they ensure your bench unit matches what runs in customer cars.
The interesting attack surface is everything that receives external input: the Wi-Fi stack, the LTE modem firmware, the Bluetooth implementation, the browser (which renders a full web UI), and the various network-facing services running inside the VMs. Synacktiv demonstrated this at Pwn2Own Automotive 2024 in Tokyo, achieving a full chain root on Tesla infotainment via Bluetooth. Having the hardware on a bench means you can attach a UART console to test points, watch kernel log output in real time, and instrument the running system in ways that are impractical inside a physical vehicle.
The Autopilot Separation is a Hard Boundary
One thing worth being clear about: the MCU and the autopilot computer are separate boards, and compromising the MCU does not give you the autopilot. Tesla’s safety architecture keeps them physically and logically isolated. The FSD chip board, introduced in 2019, contains two custom Tesla-designed neural network accelerators built on Samsung’s 14nm process, each providing around 36 TOPS, with two chips per board for redundancy totaling around 144 TOPS claimed. It runs its own OS stack, receives camera inputs directly, and communicates with the MCU over the automotive Ethernet link for coordination.
If your research goal is to influence vehicle control, the autopilot computer is a separate target entirely, with its own firmware, its own communications, and its own attack surface. The MCU bench setup gets you to the infotainment layer, not the driving layer.
Why This Kind of Research Matters
The value of running automotive hardware off-vehicle is not just convenience. It changes what tooling you can bring to the problem. Fuzzing a network-facing service on a live car means your feedback loop is whatever the car does visibly. Fuzzing the same service on a bench MCU means you can attach a debugger, set breakpoints, collect crash dumps, and iterate in minutes rather than hours.
This is the same argument that security researchers have made for decades about any embedded system: the faster your iteration loop, the more ground you can cover. Insurance salvage parts bring the cost of that setup down to something a solo researcher can afford, which expands who can participate in this kind of work.
David has been doing responsible disclosure with Tesla for years, reporting vulnerabilities through proper channels before publishing. The bench setup described in the article is a research platform, not an attack tool. The fact that it requires this much engineering just to get the hardware to boot is, in a way, a reasonable implicit security measure: the barrier to entry is high enough that casual attackers do not bother, while motivated security researchers can clear it given enough time and the right documentation trail from the people who came before them.