Salvage Yards as Security Labs: Running a Tesla Model 3's Brain on a Bench

When security researcher David Huchon pulled a Tesla Model 3’s central computer out of a crashed car and got it running on his desk, it landed on Hacker News with nearly 940 points. The appeal is obvious. There is something viscerally satisfying about the image: a system that normally lives behind a touchscreen in a $50,000 car, booting up between a power supply and a laptop on a workbench.

But the interesting part is not the novelty. The interesting part is that it worked at all, and what working actually required.

Tesla’s MCU Is Not a Traditional Automotive ECU

Most automotive control units are microcontrollers. They run AUTOSAR, they speak CAN, they have kilobytes of flash. They are designed to do one thing deterministically, forever, at temperature extremes. The Tesla Model 3’s central computer is something else entirely.

The Media Control Unit 2 (MCU2), introduced in mid-2018 and fitted to all Model 3 vehicles, is built around an AMD Ryzen Embedded V-series processor. This is the same chip family used in thin-and-light laptops and industrial PCs. It runs a Yocto Project-derived Linux distribution. It has a full GPU. The infotainment system is a browser-based application rendered by a Chromium fork. When the car is parked, the MCU is essentially an x86 Linux workstation sitting under your dashboard.

This architecture is what made Tesla’s early infotainment fast compared to the industry, and it is also what makes it interesting to researchers. If you know how to work with Linux, x86 hardware, and standard debugging tools, the Tesla MCU is approachable in a way that a conventional ECU is not.

What You Actually Need to Power It

A Tesla vehicle runs two electrical systems. The high-voltage battery pack, operating at 350-400V, drives the motor and the thermal system. A DC-DC converter steps that down to 12V for the low-voltage bus, which powers everything from the door modules to the MCU. This is the same 12V architecture that has been in cars since the 1950s.

That means the MCU itself can be powered with a bench power supply set to 12V. There is no special protocol negotiation, no high-voltage interlock to satisfy. If you provide stable 12V at adequate current (the MCU2 under load draws several amps), the hardware will attempt to boot.

The harder part is the CAN bus. Tesla vehicles use multiple CAN networks, and the MCU participates in at least the vehicle CAN. On boot, many automotive ECUs send out initialization messages and expect responses from other modules. If those responses do not arrive, the ECU may refuse to proceed past a certain point, enter a diagnostic mode, or flag fault conditions. Getting a fully operational system means either stimulating the bus with a CAN adapter and some well-crafted frames, or determining empirically which messages the MCU actually requires versus which ones it tolerates missing.

Tesla also uses Ethernet internally, specifically the 100BASE-T1 and 1000BASE-T1 single-pair Ethernet standards used in automotive applications. The camera subsystem and the Autopilot computer communicate over this backbone. Running the MCU in isolation means the Autopilot hardware is absent, and the software has to be tolerant of that, which it largely is since the car is designed to operate in various degraded configurations.

The Salvage Economy

The source of the hardware, crashed cars, is part of the story. Salvage auctions like Copart and IAAI list totaled vehicles every day, and a crashed Tesla with a functioning MCU is genuinely common. Tesla has sold millions of vehicles, and a significant fraction of them end up totaled, often due to body damage or airbag deployment rather than drivetrain or computer failure. The MCU survives most crashes intact.

Prices vary. A complete Model 3 center console assembly, which includes the MCU, can be found for a few hundred dollars on eBay from salvage dismantlers. This is an order of magnitude cheaper than buying equivalent compute hardware new. For a researcher, this price point is significant. It means you can have two units: one to experiment on destructively, one to keep as a reference.

This is not unique to Tesla. The broader practice of sourcing automotive hardware from salvage for security research has a long history. Researchers studying CAN bus vulnerabilities, remote access modules, and telematics units have sourced hardware this way for years. What changed with Tesla is that the hardware is interesting enough, and common enough, that the research has accelerated considerably.

Prior Work in This Space

Huchon’s bench setup builds on a body of Tesla hardware research that goes back several years. The most notable prior work is from the team at TU Berlin, who in 2023 demonstrated a voltage glitch attack against the AMD processor in the Tesla MCU to extract the encrypted storage key. By injecting a brief, precisely timed voltage fault on the CPU’s power rail, they caused the processor to execute incorrectly during the secure boot measurement phase, allowing them to break out of the trusted execution environment and access the contents of the encrypted NVMe storage. The attack required physical access, a custom PCB attached to the motherboard, and a fair amount of iteration, but it worked.

That research required a bench setup similar to what Huchon describes. You cannot perform voltage fault injection on a running car. You need the hardware accessible, stationary, and connected to your own tooling.

Separate from hardware attacks, researchers have also investigated Tesla’s network stack, its over-the-air update mechanism, and the CAN bus attack surface. Keen Security Lab published multiple reports on Tesla vulnerabilities between 2016 and 2020, finding issues ranging from remote code execution via the browser to CAN bus injection enabling steering control. Most of that research started with hardware in hand.

What a Bench Setup Unlocks

Once the MCU is running on a desk, the attack surface opens up considerably. The system runs Linux, which means standard Linux tooling applies. If you can get a shell, either via a known vulnerability, a debug interface, or a physical attack, you can use gdb, strace, ltrace, and everything else in the standard toolkit.

The MCU has a debug UART header on the board. On early units this was not protected and provided a root shell. Tesla has progressively hardened this over software updates, but the physical interface remains, and the cat-and-mouse between hardening updates and hardware bypass techniques continues.

The eMMC storage on early MCU1 units became notorious for wear-out failures due to excessive write cycles from the log-heavy software stack. This created a large population of users with failed infotainment systems and, separately, a community of repair technicians who learned to reball and replace eMMC chips. That repair community generated a significant amount of documentation about the hardware layout that security researchers later found useful.

The Broader Implication

There is a meaningful difference between attacking automotive software through an interface the manufacturer intended you to use, and attacking it with physical access to the hardware on a bench. Both are valid research methods. The bench approach lets you do things that are simply not possible otherwise: probing buses with logic analyzers, attaching debuggers, running fault injection, reading flash chips directly.

Tesla’s architecture, by being closer to conventional computing hardware than a traditional automotive ECU, lowers the barrier to this kind of research. A researcher who knows x86 Linux does not need to learn an obscure embedded architecture, a proprietary RTOS, or a vendor-specific toolchain. The skills transfer directly.

The salvage economy makes the hardware cheap enough that this is accessible to independent researchers, not just well-funded security teams. That combination, commodity hardware architecture plus cheap salvage availability, is what keeps Tesla as a recurring subject in automotive security research. Huchon’s bench setup is a good example of how much you can accomplish before you need anything exotic: a power supply, some CAN adapters, and parts that someone drove off a lot three years ago.