Booting a Tesla's Brain Off-Car: The Salvage Market as a Research Platform

David Hu’s recent writeup on running a Tesla Model 3’s computer on his desk is one of those projects that looks deceptively simple from the outside. Pull the board from a crashed car, wire it up, boot it. The reality involves working through a stack of automotive security design decisions that Tesla has layered over what is, at its core, a fairly conventional AMD-based Linux machine.

Understanding why it is hard to run this hardware off-car requires understanding what the hardware actually is, and the gap between what it looks like on paper and what Tesla has done on top of it.

What the MCU2 Actually Is

The Model 3’s second-generation Media Control Unit, which Tesla introduced around 2018, centers on an AMD Ryzen Embedded V2748 processor: four Zen 2 cores, eight threads, a base clock around 2.9 GHz, and an integrated Radeon Vega GPU. It pairs with 8 GB of LPDDR4 RAM and 32 GB of eMMC storage in earlier configurations, with some later variants moving to NVMe. That is desktop-class compute for 2018, shoved behind a 15-inch touchscreen in a car.

The OS is a custom Linux distribution built on an Ubuntu base, running a standard systemd init. The UI layer uses Qt with a custom QML frontend that renders directly to the AMD GPU framebuffer rather than going through X11 or Wayland in any conventional sense. Individual vehicle subsystems, navigation, climate, media, OTA updates, each run as discrete systemd services. The MCU communicates with the rest of the car over a combination of CAN bus networks and automotive Ethernet (100BASE-T1 and 1000BASE-T1), with the Autopilot compute module sitting on a completely separate board.

None of this is secret. Tesla’s OTA update bundles have been picked apart by researchers for years. GreenTheOnly, a prolific reverse engineer in the Tesla community, has documented enormous amounts of the internal API surface and CAN bus message definitions. The general architecture is well understood by anyone who has spent time in the Tesla modding ecosystem.

What is harder is getting the hardware to do anything useful when it is not bolted into the car it came from.

The VIN-Binding Problem

Tesla MCUs are paired to a specific vehicle at manufacture and through subsequent OTA updates. The pairing is not a trivial software flag. It involves the AMD Platform Security Processor (PSP), an ARM Cortex-A5 core embedded in the AMD SoC that runs its own firmware independently of the main CPU, and a discrete TPM (Trusted Platform Module) chip on the board.

The storage is encrypted using dm-crypt (LUKS), with the key sealed to the TPM and the AMD PSP. When the system boots, the PSP validates the secure boot chain before the main CPU gets any execution. If the attestation fails, or if the board detects that it is not communicating with the expected vehicle CAN network, various things can go wrong ranging from the system refusing to fully boot to cloud authentication failing because the board’s identity does not match what Tesla’s servers expect.

This is not a design flaw. This is the design working as intended. From a stolen-hardware or warranty-fraud perspective, it is exactly what you want. From a security research perspective, it is the first wall you have to get over.

How Prior Research Got Past It

The most thorough public work on breaking Tesla’s MCU security was presented at the Chaos Communication Congress in 2023 by researchers from the Technical University of Berlin: Christian Werling, Niclas Kühnapfel, and colleagues. Their attack targeted the AMD PSP directly using voltage fault injection. By precisely glitching the supply voltage to the SoC during the PSP’s boot sequence, they could cause the PSP to skip security checks and execute unverified code.

Once they had PSP-level code execution, they could extract the encryption key used to seal the LUKS volume, decrypt the eMMC, and gain full root access to the Tesla Linux filesystem. From there they recovered NFC key card seeds (enabling key cloning) and got persistent root on a live vehicle.

The voltage fault injection setup involved custom hardware: a dedicated FPGA-based glitching board, precision power supply circuitry, and the kind of oscilloscope work that becomes second nature in hardware security research but is completely opaque if you approach it as a software person. The attack required physical access to the board and was not the kind of thing you could do in a parking lot.

What is relevant to Hu’s project is that this prior work established a pathway. Getting a salvage MCU to boot on a bench requires solving at least some subset of these problems, even if the goal is not malicious. The board needs to authenticate. The storage needs to be accessible. The system needs to believe it is operating in a valid context, or at minimum, needs to be persuaded not to halt.

The Salvage Market as Infrastructure

The parts sourcing side of this project is its own ecosystem. The two dominant US salvage auctions, Copart and IAAI, regularly have crashed Teslas available, many rear-ended or otherwise damaged in ways that leave the front dashboard electronics intact. MCU2 boards show up on eBay regularly, pulled from salvage cars, priced anywhere from $200 to $800 depending on condition and whether the display assembly is included.

There is an active community built around this supply chain. YouTube channels like Rich Rebuilds have documented the Tesla salvage economy in detail, showing how totaled Model 3s and Model Ys get parted out and the components find second lives in repairs, research, or experimental builds. The community around Tesla Motors Club forums has threads devoted to identifying compatible parts across model years, which matters when you need to match board revisions.

The result is that the barrier to obtaining Tesla hardware for research purposes is low in a way it never could have been if the market were not this active. A researcher who would have had to buy a functioning car to study its internals a decade ago can now get the relevant board for a few hundred dollars from a car that hit a guardrail in Nevada.

What Running It on a Bench Enables

Once the hardware is running off-car, the research surface opens up considerably. The system boots into a full Linux environment. Standard tools apply: you can attach debuggers, trace system calls, instrument the Qt rendering pipeline, monitor the CAN bus interfaces (even without a car attached, the software will attempt to communicate and its behavior under those conditions is informative), and watch how the OTA update daemon handles incoming firmware.

Automotive security research has historically been constrained by the need to work on actual vehicles, which is expensive, limits the number of researchers who can participate, and creates liability concerns about doing invasive work on hardware that might later go back on the road. A bench-mounted MCU sidesteps most of that. You can run it indefinitely, instrument it destructively if needed, restore from a known-good eMMC image if you brick the boot chain.

This matters particularly for vulnerability research. Tesla runs an active bug bounty program that covers the MCU, with payouts reaching into the tens of thousands of dollars for significant vulnerabilities. The ability to do that research on a $400 salvage board rather than a $45,000 car changes who can participate meaningfully.

Broader Context: Automotive Computers as Research Subjects

Tesla is an unusual case because the MCU is a relatively general-purpose computer running a mainstream OS on mainstream silicon. Most automotive ECUs are far more specialized: microcontrollers running AUTOSAR-compliant RTOS stacks on architectures like Renesas RH850 or Infineon TriCore, communicating over protocols like FlexRay and CAN-FD, with toolchains that require expensive vendor licenses to access.

The conventional automotive stack is, in some ways, harder to study despite being less sophisticated, because the tooling is proprietary and the hardware is purpose-built in ways that resist general-purpose debugging. Tesla’s decision to use commodity x86 silicon and Linux means the entire existing ecosystem of Linux security tooling applies directly. That is a double-edged sword from a security standpoint, but it is unambiguously good for the research community.

Projects like Hu’s sit at an interesting intersection: hardware forensics, automotive security, and the kind of patient salvage-and-solder work that used to be the exclusive domain of engineers with lab access. The crashed-car supply chain has democratized a hardware category that was, until recently, genuinely difficult to study outside of a well-funded research context. The security architecture Tesla has built is serious, but it is being taken seriously by researchers who now have both the hardware access and the prior published work to stand on.