Salvage Yards as Security Labs: The Technical Reality of Bench-Running Tesla's Computer

David Hu’s recent writeup on running a Tesla Model 3’s central computer off-vehicle landed on the front page of Hacker News with nearly a thousand points, and the attention is warranted. Not because the concept is novel, but because the execution details matter enormously, and few people document them this carefully.

The core idea is straightforward: source a wrecked Tesla’s Media Control Unit from a salvage yard, supply it with bench power, satisfy whatever bus communication it expects to see from the rest of the car, and get it to a bootable state in your own lab. The gap between that description and actually doing it is where the interesting engineering lives.

The Hardware Generations Worth Knowing

The Tesla Model 3 has shipped with two meaningfully different main computers depending on production year. Early and mid-generation Model 3s use MCU2, built around an Intel Atom A3950 (Apollo Lake, quad-core at 1.6 GHz) paired with 8 GB of eMMC storage. The 2023 Highland refresh moved to MCU3, which uses an AMD Ryzen embedded processor and substantially more RAM and storage. Both run a modified Ubuntu Linux distribution, which is the detail that makes this kind of research tractable in the first place.

Separate from the infotainment computer is Tesla’s Autopilot/FSD hardware, which has its own generational history and is a distinct board. That system handles all the sensor fusion and driving logic; the MCU handles maps, media, climate, phone integration, and the UI. For software security research aimed at the attack surface a user or remote adversary would encounter, the MCU is the right target.

The MCU communicates with the rest of the vehicle over a combination of CAN bus and Ethernet. Tesla adopted vehicle Ethernet (100BASE-T1, sometimes 1000BASE-T1) earlier than most manufacturers, which is relevant because it means the MCU’s communication with the gateway module is more like network programming than the raw frame manipulation that CAN-only cars require.

Why Salvage Parts Make Sense

Tesla’s accident rate, combined with insurance total-loss thresholds and the volume of vehicles on the road, produces a steady supply of write-off cars with functional electronics. A Tesla that hits a concrete barrier hard enough to deploy airbags and bend the frame is often totaled despite having a perfectly operational MCU. Salvage yards partition and resell these components, and prices for a used Model 3 MCU typically run in the $300 to $600 range depending on generation and condition, far below the cost of buying a second car for research.

This is the same economic logic that has driven automotive security research for years. When Charlie Miller and Chris Valasek did their foundational CAN bus injection research, they bought used vehicles specifically because it let them destroy hardware freely. You cannot do destructive testing on a car you still need to drive, and you cannot do serious hardware research at all if each mistake costs you thousands of dollars.

There is also a legal dimension. Research conducted on hardware you own carries substantially fewer ambiguities than research on a vehicle connected to Tesla’s infrastructure. Working with an isolated unit on your bench means any network communication is under your control and consent is unambiguous.

The Bench Boot Problem

Getting an automotive computer to boot on a workbench is harder than plugging in a PC. Automotive ECUs are designed to operate in an environment that provides them constant context: battery voltage, ignition signals, CAN traffic from neighboring modules, and in Tesla’s case, Ethernet traffic from the gateway. Remove that context and many systems refuse to proceed past their startup self-checks, or they enter a degraded mode that limits what you can observe.

The first requirement is power. Automotive systems nominally run at 12V, but the actual tolerance range is wider than that suggests: the battery under load can dip to 10V, and alternator output can push over 14V. A quality bench power supply set to 13.5V (simulating a healthy, charging system) is the starting point. Current capacity matters too; during boot, the MCU draws significantly more than during idle, and an undersized supply will cause brown-out resets that can corrupt eMMC state.

Beyond raw power, the MCU may expect to see an ignition-on signal (IGN or ACC lines held at 12V), a wake-up signal on a specific CAN ID, or communication from the Body Control Module before it fully initializes. Figuring out which signals are required versus which ones the system simply reports as absent is a significant part of the bring-up work. Automotive wiring harness documentation, OBD-II protocol analyzers, and a logic analyzer on the CAN lines are all standard tools here.

Tesla’s use of Ethernet for intra-vehicle communication adds another layer. Some initialization behavior may depend on receiving expected traffic from the gateway, which means either capturing that traffic from a real car and replaying it, or building a partial gateway simulation. This is substantially more work than a pure CAN-bus car, but it also means that once you have it working, you can intercept and modify that traffic with standard network tools.

What Physical Access Opens Up

Remote security research against a connected system is real and valuable, but it has a fundamental constraint: you can only observe and probe what the attack surface exposes to you. Physical hardware access expands that surface considerably.

With the MCU on a bench, you can attach to UART debug headers that are often present on automotive boards and provide a console login or at minimum kernel boot messages. You can dump the eMMC contents and analyze the filesystem offline. You can monitor power consumption side-channels during cryptographic operations. You can simulate network conditions that would be difficult to arrange otherwise, including deliberate packet corruption or injection of crafted frames.

Tesla’s Linux system has been the subject of significant prior research. Keen Security Lab at Tencent published multiple papers between 2019 and 2022 documenting attack chains that combined web browser vulnerabilities (Tesla’s browser is Chromium-based) with local privilege escalation to reach the CAN gateway. Ralf-Philipp Weinmann’s TBONE research demonstrated a remote compromise via the car’s WiFi chip without any user interaction. What these projects had in common was the need to understand the full software stack, including components not easily visible from outside the vehicle.

Tesla runs a bug bounty program and has paid out significant rewards for valid findings. The existence of a well-funded, well-structured bounty program changes the calculus for researchers: the salvage parts investment becomes an R&D cost against a potential payout, and the research has a legitimate disclosure path.

The Broader Methodology

What makes this approach noteworthy in 2026 is how mature it has become. Ten years ago, the automotive security research community was small enough that major car hacks were conference headliners precisely because so few people had done the groundwork. The tooling was sparse, the wiring diagrams were proprietary and hard to source, and the research community had not yet built up the shared knowledge base around things like CAN database formats, UDS protocol implementations, or automotive Ethernet physical layers.

Now there are open-source UDS libraries, communities dedicated to reverse engineering specific vehicle platforms, and a secondary market infrastructure (eBay, specialized salvage resellers, pick-and-pull yards) that makes sourcing specific components reasonably predictable. The bench power and CAN analyzer hardware that used to require serious investment is now cheap enough that a hobbyist can assemble a functional automotive research setup for under $500.

That democratization is double-edged. It means legitimate security researchers can do this work more efficiently, find vulnerabilities faster, and get fixes shipped to vehicles sooner. It also means the barrier for less scrupulous actors is lower. The difference, in practice, is almost entirely in what you do with the access once you have it.

For Hu’s project, the goal is clearly security research aimed at responsible disclosure and the bug bounty program. The technique of sourcing from crashed cars is a practical solution to a practical problem: getting research hardware without an unreasonable financial commitment, while working on isolated hardware that cannot affect real vehicles or Tesla’s infrastructure. It is the same reasoning that makes any hardware security research lab stock older devices and deliberate teardown samples.

The 939 upvotes on Hacker News reflect something the security research community already knows: the unsexy logistics of getting hardware to boot on a bench are often more interesting than the vulnerability itself, because the methodology is reusable across targets and researchers, while the specific bug is only fixed once.