Commodity Hardware, Crashed Cars, and What Running a Tesla MCU on Your Desk Actually Requires

The media control unit in a Tesla Model 3 Highland contains an AMD Ryzen Embedded processor, 16 GB of RAM, and a 256 GB NVMe SSD. This is not a designed-for-automotive chip or a stripped-down embedded controller; it is commodity PC-class hardware running a custom Linux distribution, connected to the rest of the car over a gigabit Ethernet backbone and a CAN bus network.

Security researcher David Huszár, who has spent years probing Tesla’s attack surface at bugs.xdavidhu.me, recently documented what that reality enables in practice: source a crashed Tesla’s MCU from a salvage auction, wire it to a bench power supply, supply the minimum required CAN bus signals, and the unit boots completely outside any vehicle. It is unglamorous work, but it is the foundation that makes serious automotive hardware security research possible.

The HN thread drew 939 points and over 325 comments, which reflects community interest that spans several overlapping audiences: security researchers, right-to-repair advocates, embedded Linux developers, and people who are simply curious about the computer they drive around in every day.

How the Hardware Evolved

Tesla has shipped three generations of media control unit since the original Model S in 2012, and each one reflects a different moment in the company’s ambitions for what a car computer needs to do.

MCU1 used an NVIDIA Tegra processor on ARM. It became notorious for an eMMC wear-out problem: the OS wrote logs aggressively to 8 GB of internal flash that had no mechanism for the kind of write-cycle management that would have extended its life in a car context. Touchscreens died. NHTSA investigated. Tesla issued a service bulletin. The hardware was not fundamentally wrong; the software running on top of it was. The root cause was architectural: a general-purpose Linux system, dropped into an always-on embedded environment, behaving like a server logging to disk.

MCU2 moved to an Intel Atom E8000-series processor with 8 GB of RAM and 64 GB of eMMC. The x86 shift mattered practically: maintaining a Linux distribution on x86 draws from a far larger pool of tooling and developer experience than ARM-based automotive platforms. Tesla offered MCU2 as a paid retrofit for MCU1 owners and used it as the platform for streaming services, more complex FSD visualizations, and early gaming integrations. The storage improvement helped, though eMMC remained a less-than-ideal long-term choice for a device that is always on and always writing.

MCU3 is the current generation, introduced in the Model S Plaid in 2021 and standardized in the Highland Model 3 refresh. The processor is from AMD’s Ryzen Embedded V2000 series, a Zen 2 design with eight cores and integrated Radeon graphics capable of running demanding game titles at the center display’s resolution. Storage moved from eMMC to NVMe, which addresses both throughput and write endurance. The RAM doubled to 16 GB. This is hardware that would be unremarkable in a mid-range gaming PC from the same era.

One architectural distinction worth holding onto: the MCU is the infotainment computer, not the driving computer. Tesla’s Autopilot and Full Self-Driving compute runs on a separate unit, currently HW3 or HW4, built around Tesla’s custom neural network accelerator. These two computers communicate over the vehicle’s internal network but run independent software stacks. Bench-testing the MCU gives a researcher the infotainment OS, the browser, the settings panels, and the OTA update mechanism. The autonomous driving stack is elsewhere.

Getting It Running Off the Car

The practical challenge in operating an MCU outside a vehicle is power delivery and communication. The unit runs on 12V, the same voltage as the car’s standard low-voltage electrical system, so a bench power supply with sufficient current capacity covers the power side. The harder part is the connector harness. Tesla uses multi-pin connectors that bundle power, ground, CAN bus lines, Ethernet, and USB into a single interface. Determining which signals are necessary for a successful boot and which ones the software simply logs warnings about requires studying wiring diagrams, working through community-documented teardowns from sources like iFixit and dedicated automotive teardown channels, and iterating.

The CAN bus question matters more than it might initially appear. Even though Tesla has migrated toward Ethernet for high-bandwidth data, CAN bus still carries low-bandwidth vehicle control messaging, and the MCU expects some of it during the boot sequence. On a bench setup, you can supply minimal CAN traffic to satisfy initialization, or in some cases the MCU will complete booting while simply reporting communication faults. Either way, what you end up with is a fully running infotainment system: the Tesla UI rendering on an attached display, the browser accessible, the settings panels navigable.

The salvage market is the economic enabler for all of this. Platforms like Copart and IAAI process crashed Teslas in large volumes. The MCU assembly is typically one of the better-surviving components in a collision. Salvage prices for MCU3 units are a fraction of Tesla’s service-replacement cost, which runs into thousands of dollars for an authorized MCU3 upgrade. The result is a quiet ecosystem: researchers, independent repair technicians, and hardware-curious engineers cross-referencing community wiring diagrams and each other’s bench notes to replicate what Huszár has documented.

The Security Research Layer

Getting an MCU booting reliably on a bench is prerequisite work, not the research itself. What it enables is sustained, controlled access to hardware for investigation that would be impractical on a vehicle someone needs to drive.

Tesla’s MCU3 secure boot is built around AMD’s Platform Security Processor, which cryptographically verifies each stage of the boot chain. Security researchers at KU Leuven demonstrated in 2023 that this chain can be broken via voltage fault injection against the AMD chip: a precisely timed voltage perturbation during the signature verification step can cause it to pass when it should fail, yielding a root shell on the underlying Linux OS. The attack requires physical access and specialized equipment, but it produces results that would otherwise require exploiting a software vulnerability in a correctly functioning system.

Having hardware on a bench makes these attacks viable in practice. You can iterate on timing parameters across dozens of attempts, attach oscilloscopes to measure the voltage envelope precisely, and try variations without risk. The bench environment is not just more convenient; it changes the research cadence entirely. Systematic vulnerability discovery on automotive platforms requires the kind of iteration that you cannot perform in a car parked in a garage.

Huszár has previously submitted disclosures through Tesla’s bug bounty program. His documented methodology follows a recognizable pattern for responsible automotive security research: establish a reliable bench environment, develop tooling to interact with the software stack, identify a vulnerability, report it, wait for a patch, then publish. That pipeline begins with hardware you can work with freely, and salvage parts provide exactly that.

The Feature Lock Problem

There is a less comfortable dimension to the accessibility of this hardware. The MCU3 in a Highland Model 3 ships with capabilities that Tesla enables and disables remotely: heated rear seats, acceleration upgrades, enhanced Autopilot tiers. The hardware present in the vehicle does not change based on the owner’s subscription tier; only the software permissions do. A researcher who understands the MCU’s software architecture, and specifically how feature entitlements are checked and enforced, is in a position to study whether those locks are robust.

This is the central tension in the car-as-platform model. Tesla built a highly capable, software-defined product on commodity hardware with a mainstream OS. That choice accelerated their development velocity considerably; the skills, tooling, and organizational knowledge required to ship Linux software on AMD hardware are far more available than what a bespoke automotive RTOS would require. The same architecture that made rapid software iteration possible also made the platform more accessible to people whose interests are not aligned with Tesla’s subscription revenue.

The right-to-repair movement has historically focused on diagnostic software access and parts availability. The MCU story suggests the terrain is broader. A car whose infotainment computer can be sourced from a salvage auction, bench-booted with commodity equipment, and studied at the OS level is meaningfully more repairable and auditable than one that requires proprietary tooling at every diagnostic step. That accessibility is not an intended design consequence of Tesla’s platform choices, but it is a real one, and the security research that flows from it has historically made the platform safer for the people who drive it.