What Happens When You Pull a Tesla's Brain Out of a Wrecked Car and Boot It on Your Bench

Security researcher David Hüttner, known online as xdavidhu, has documented the process of pulling Tesla Model 3 compute hardware from crashed vehicles and getting it running on a desk. The writeup covers sourcing parts from salvage, wiring them up outside the car, and achieving a bootable system for research purposes. It is the kind of project that sounds straightforward until you are elbow-deep in it, and the details reveal a lot about how automotive computers are actually designed.

The Hardware Inside

The Tesla Model 3’s primary infotainment and compute system has gone through two major hardware generations. The earlier MCU1 units used an NVIDIA Tegra processor and are now quite old. Most Model 3s on the road, and most of the ones showing up in salvage yards, run MCU2: a more capable board built around an AMD Ryzen Embedded V1202B processor. That chip pairs two Zen CPU cores with Radeon Vega 3 graphics on a 14nm process. The board pairs it with 8GB of LPDDR4 and a 64GB eMMC for storage. This is not exotic hardware; the AMD Ryzen Embedded V1000 series was designed for medical imaging terminals and industrial HMIs, and Tesla essentially used it as a high-end automotive display computer.

Separate from the MCU is the Autopilot hardware, which in HW3/FSD-equipped cars uses Tesla’s custom FSD chip on Samsung 14nm with around 6 billion transistors. The MCU and the FSD computer communicate but are physically distinct boards. For bench research purposes, you can work with the MCU independently.

Salvage prices for Tesla MCU assemblies have become reasonable enough to make this practical. A wrecked Model 3 with a working MCU might yield the whole assembly for a few hundred dollars, which is far more accessible than buying a development kit that does not exist. Tesla does not publish a developer program for MCU hardware.

Getting It Running Without a Car

The hard part of running automotive ECUs on a bench is not usually the hardware itself; it is the ecosystem the hardware expects to exist around it. Car computers are built to live inside a vehicle that provides regulated 12V power, communicates over a CAN bus, and has a network of other modules the unit expects to see during startup.

For the Tesla MCU, power is straightforward: a bench power supply delivering 12V with enough current capacity to handle the AMD Ryzen Embedded’s power envelope works. The chip itself has a TDP around 12-25 watts depending on load, but the full MCU assembly with display outputs, storage, and the various support ICs can draw more than that transiently during boot.

The more interesting challenge is the CAN bus dependency. Tesla’s vehicle communication architecture uses multiple CAN networks: a chassis CAN for powertrain and safety systems, and a separate infotainment CAN. The MCU sits on the infotainment bus and expects to hear from the vehicle’s gateway module. If those messages do not arrive on schedule, some ECUs refuse to proceed past a startup health check. The solution for bench researchers is typically a CAN bus adapter like a PEAK PCAN-USB or a Vector CANalyzer running replay traffic, or a custom script using something like python-can to emit the expected keepalive messages the MCU wants to see.

There is also an Ethernet connection. The Tesla MCU2 exposes a 100Mbps Ethernet interface that is used for diagnostics and firmware updates over the vehicle’s internal network. On the bench, this becomes a direct path to the system if you know the right service addresses.

The Linux System Underneath

Tesla runs a Linux-based operating system on the MCU, built with Yocto. The root filesystem has a structure that security researchers have mapped reasonably well through a combination of firmware extraction and the periodic leaks that happen when Tesla updates vehicles OTA and the update packages end up partially visible. The UI is built on Qt, running a custom application that renders the infotainment display and handles user interaction.

The system runs a fairly conventional set of userspace services underneath the Tesla-specific software. Systemd manages the service lifecycle. D-Bus carries inter-process communication between the infotainment application and lower-level hardware drivers. The CAN bus is exposed to userspace through SocketCAN, which is the standard Linux kernel interface for automotive bus communication.

This Linux-on-everything approach has made Tesla a more tractable target for security researchers than manufacturers running deeply proprietary RTOSes. Tools and techniques from server-side Linux security research transfer to the MCU with some adaptation. The attack surface is recognizable: network daemons, IPC endpoints, file parsers, and a web engine for the browser functionality all carry the same classes of vulnerabilities they carry on any other Linux system.

What This Research Unlocks

Running the MCU on a bench changes the economics of vulnerability research substantially. When you have a live unit in front of you with a debugger attached, the iteration cycle for finding and exploiting bugs shrinks from days to hours. You can power-cycle without walking to a parking lot. You can attach a JTAG probe to the AMD security processor without worrying about bricking a car that someone needs to drive.

This matters because the security research community has been finding meaningful vulnerabilities in Tesla vehicles at a steady pace. Pwn2Own Automotive, which targeted Tesla and other manufacturers, has seen researchers demonstrate full MCU compromises. The TU Berlin research group presented an attack at 37C3 in late 2023 that used voltage glitching against the AMD Secure Processor (the PSP/ASP) embedded in the Ryzen chip to extract encrypted data. That class of hardware attack is much easier to develop when you can set up a rig with a glitching tool like a ChipWhisperer and iterate without destroying production hardware on every attempt.

xdavidhu’s prior Tesla research has focused on software-layer bugs: logic flaws in web interfaces, privilege escalation within the Linux environment, and similar issues. A bench MCU is the natural prerequisite for that kind of work. You instrument the system, you probe the attack surface, and you do it at a pace that is not possible when the device you are testing is also someone’s commute vehicle.

Salvage as a Supply Chain

There is something worth noting about the salvage-parts angle specifically. The growing availability of crashed electric vehicles in salvage yards has created an unintentional hardware research supply chain. A Tesla with a wrecked frame and an intact compute stack is, from a hardware research perspective, nearly as useful as an intact vehicle. As EV adoption has grown and the first generation of EVs has aged into the used and salvage market, the barrier to obtaining this hardware has dropped considerably.

This is not unique to Tesla. Automotive ECU research has a long history of bench setups, and the broader vehicle security research community has been doing this kind of work for years. The PASTA workshop and similar academic venues have published extensively on ECU bench testing methodologies. What has changed is the availability of high-value targets in salvage, and the capability of the hardware involved. Older automotive ECUs were microcontrollers running proprietary RTOSes; the Tesla MCU2 is a full x86-64 Linux computer with a network stack, a browser engine, and a Bluetooth subsystem. The software attack surface is orders of magnitude larger.

The AMD Security Processor Angle

One thread worth pulling is the AMD PSP (Platform Security Processor) embedded in the Ryzen V1202B. AMD’s PSP is an ARM Cortex-A5 running AMD’s proprietary firmware that handles secure boot, key storage, and trusted execution. In a Tesla context, the PSP is responsible for protecting the cryptographic keys that authenticate firmware updates and, presumably, some portion of the DRM that prevents arbitrary firmware from running on Tesla hardware.

The TU Berlin team’s voltage glitching attack against the PSP was significant precisely because it broke the root of trust. Once you can extract keys from the PSP, you can decrypt and analyze firmware images that Tesla has encrypted, understand what the system is actually running, and potentially sign modified firmware. Building and refining that attack requires hardware access of exactly the kind xdavidhu is describing: a unit you can physically probe, power-cycle, and abuse without consequence.

The bench setup is not just a convenience for software research; it is a prerequisite for the hardware attacks that matter most.

Why This Approach Will Keep Working

Tesla updates its vehicles OTA, which means the attack surface evolves continuously. A vulnerability found and patched in one firmware version may resurface in modified form in a later one, or the patch itself may introduce new issues. Staying current with the software requires staying current with the hardware, and the salvage supply chain makes that possible without extraordinary expense.

The broader implication is that any sufficiently popular platform eventually faces this. The combination of a large installed base, a recognizable software stack, and affordable salvage availability creates the conditions for a mature security research community to form. Tesla is several years into that cycle now, and the research output reflects it. The work being done on these bench setups is making production vehicles incrementally more secure, even if the path from researcher’s desk to patched firmware is longer and less transparent than most researchers would prefer.