From Salvage Yard to Workbench: What Getting a Tesla MCU Running Actually Requires

David Hüttner’s recent writeup on getting a Tesla Model 3’s MCU running on his desk landed near the top of Hacker News with close to a thousand upvotes, and the reaction makes sense. There is something viscerally satisfying about a piece of car hardware, stripped from a wreck, booting on a bench in someone’s home office. But the real story here is methodological. Running an automotive ECU in isolation is genuinely hard, and the fact that it is possible at all with Tesla’s hardware tells you something specific about how Tesla’s systems are designed, and what that design leaves open for researchers.

What the Hardware Actually Is

The Tesla Model 3’s infotainment and vehicle control hub is called the MCU, the Media Control Unit. Over the years Tesla has shipped three substantially different hardware generations.

MCU1, used in early Model S and X units and some early Model 3 builds, shipped with NVIDIA Tegra silicon and later moved to Intel Atom E8000 processors. The eMMC storage on these units became notorious for wearing out, bricking infotainment systems in cars still under warranty and eventually prompting an NHTSA investigation.

MCU2 brought Intel Atom A3960 silicon from the Apollo Lake family, 8 GB of LPDDR4, and 64 GB of eMMC storage. It runs a custom Ubuntu Linux build. The display pipeline, cellular modem (a Sierra Wireless LTE module), Wi-Fi, and Bluetooth all live on this board or connect to it over internal USB and PCIe.

MCU3, introduced with the Model S Plaid refresh and later appearing in the refreshed Model 3 and Y, is a significant leap: AMD Ryzen Embedded V2000 series silicon, 16 GB of LPDDR4X, and a 256 GB NVMe SSD. The move from eMMC to NVMe storage alone eliminates a whole class of reliability failures. It still runs Ubuntu Linux, Tesla’s custom build, with a Qt-based UI application on top.

There is also the Autopilot/FSD computer, which is a separate physical board entirely. HW3, Tesla’s own chip, runs dual custom silicon with ARM Cortex-A72 cores and two neural processing units delivering roughly 144 TOPS combined, fabbed at Samsung on 14nm. The FSD computer and the MCU communicate over the vehicle’s internal Ethernet backbone, not directly over CAN.

Why Bench Testing Is Non-Trivial

Pulling an MCU board from a salvage car and plugging it into a 12V bench supply does not give you a working system. Several things need to happen first.

The MCU expects to see CAN bus traffic from other nodes on the vehicle’s network. The Gateway ECU, the battery management system, the body control module — all of them emit periodic messages. Without those heartbeats, the MCU enters a degraded or restricted mode. Researchers who have gotten this working typically do one of two things: replay captured CAN traffic using a USB-CAN adapter running SocketCAN on Linux, or pull the Gateway ECU from the same salvage car and power it up alongside the MCU.

The automotive Ethernet backbone is a second complication. Tesla uses BroadR-Reach (now IEEE 100BASE-T1 and 1000BASE-T1), a single-pair automotive Ethernet standard that is physically incompatible with standard RJ45 networking gear. Tapping into it requires a media converter with the right PHY, typically built around a Marvell 88Q1010 or similar automotive Ethernet chip. Without this, you cannot observe or inject traffic on the high-speed link between the MCU and the Autopilot computer.

Power draw is also worth mentioning. The MCU3 with its AMD Ryzen silicon pulls meaningfully more current than the older Intel Atom units. A benchtop PSU capable of clean 12V at 10A or more is necessary to avoid brownouts during boot.

The Debug Surface

Once you have the board running, what does physical access actually buy you that remote research does not?

First, UART. Tesla’s MCU PCBs have unpopulated or exposed debug header pads. With a logic analyzer and a USB-UART bridge like a CP2102 or FTDI chip, you can read the full Linux boot console output. That gives you kernel version, boot parameters, device tree information, which services start and in what order, and any boot-time errors. This is the same information a kernel developer would see on any embedded Linux board, and it is far richer than anything visible from outside the vehicle.

Second, storage. The MCU’s filesystem uses LUKS encryption, and the keys are derived in part from hardware attestation values stored in the TPM. Chip-off attacks on the eMMC or NVMe are possible in principle but decrypting the result offline without the original hardware’s TPM is not straightforward. The encryption is not theater, but the presence of a debug UART can sometimes give you a running system with the filesystem already decrypted in memory.

Third, Secure Boot. MCU2 and MCU3 both implement UEFI Secure Boot. The bootloader verifies the kernel signature before execution. Bypassing this without breaking into the firmware signing infrastructure is the central challenge for anyone who wants to run modified code. Bench access makes it easier to probe exactly where that verification happens and whether the implementation has any gaps.

The Salvage Methodology in Automotive Research

Using crashed or salvage vehicle parts for security research is standard practice in the automotive security community, and for good reasons beyond cost. Working on a real vehicle introduces the obvious risk of unintended effects on a road-going machine. Working on a salvage MCU on your bench means you can be as invasive as you like: probe every test point, extract storage chips, put the board under a microscope. You can also acquire multiple units from the same software version to verify findings or test mitigations.

Copart and Insurance Auto Auctions sell crashed Teslas regularly, and individual ECUs and MCU boards appear on eBay from dismantlers. The price for a Model 3 MCU2 unit has historically been in the $200-600 range depending on condition and generation, which is modest for a research investment.

The community around this hardware is not small. The researcher known as greentheonly has been working with salvage Tesla hardware for years, reverse-engineering CAN bus protocols and extracting software for analysis. The depth of public knowledge about Tesla’s internal architecture owes a great deal to that kind of patient bench work.

What Has Come Out of Physical Tesla Research

The wins at Pwn2Own Automotive 2023 and 2024 are instructive. Synacktiv won $100,000 at the 2023 event for a chain that started with a heap overflow in Tesla’s Connman (the connection manager) triggered by a malicious Wi-Fi SSID, leading to a root shell on the MCU. In 2024 they demonstrated a chain starting from TPMS (tire pressure sensors), moving through Bluetooth, and ending on the MCU. These are not purely remote research findings. Understanding the MCU’s process model, its exposed services, and its privilege boundaries requires knowing the system from the inside, which bench work enables.

Keen Security Lab’s 2020 research went further: they exploited the MCU’s browser, pivoted to the CAN bus, and sent CAN frames to the body control module to unlock doors and manipulate the steering. The CAN bus pivot was only possible because they understood the boundary between the MCU’s Linux environment and the vehicle’s CAN network, knowledge that comes from exactly the kind of hardware-level investigation that bench research supports.

The OTA Question

One thing worth noting is that Tesla’s OTA system is designed to make physical research harder over time. Updates are delivered as binary deltas, signed with ECDSA, and applied via a Mender-derived framework with A/B partition switching. Rollback protection is enforced through the TPM. A vulnerability present in one software version may be patched within weeks, which puts pressure on researchers to work faster than Tesla’s update cadence.

Bench hardware helps here too. You can freeze a unit at a specific software version by keeping it off the network and study it indefinitely, something that is much harder with a car you actually drive.

What This Kind of Work Is For

Hüttner’s approach, sourcing salvage MCU hardware and building the bench infrastructure needed to run it, represents the natural progression for a researcher who has already worked through Tesla’s higher-level attack surfaces. API vulnerabilities and web endpoint bugs have a relatively short window before they are patched. Physical hardware research opens a different layer, one where the findings tend to be more durable and the understanding more complete.

The accessibility of this methodology matters. The hardware is available, the tooling is documented, and the community knowledge around Tesla’s specific challenges is substantial. That is probably the most interesting thing about this work: it is hard, but it is not mysterious. The barrier is effort and patience, not access to specialized resources that only nation-states can afford.