The work of automotive security research rarely starts with a clever exploit. It starts with a pile of hardware that won’t turn on.
xdavidhu published a detailed account of getting a Tesla Model 3 Media Control Unit running on a workbench, sourced from crashed cars acquired through the salvage market. The post covers power sequencing, connector identification, CAN bus simulation, and the incremental engineering required to coax an automotive ECU into booting outside its intended environment. It is also a window into the infrastructure layer that most automotive security write-ups skip entirely.
The Hardware Underneath the Touchscreen
Tesla’s Model 3 runs two distinct computers that are easy to conflate. The Full Self-Driving computer handles autonomy, camera processing, and neural network inference. The Media Control Unit handles everything the driver touches: the 15.4-inch center touchscreen, climate controls, media playback, navigation, phone integration, and the browser. The two units communicate over an internal Ethernet backbone but occupy separate trust zones within the vehicle’s network.
The MCU2, which replaced the failure-prone NVIDIA Tegra 3-based MCU1 starting around 2018, is built around an AMD Ryzen V1605B, a quad-core, eight-thread embedded APU from AMD’s V1000 series. This is a Zen+ microarchitecture part running at 2.0 to 3.6 GHz, with Radeon Vega 8 integrated graphics, 8 GB of LPDDR4 RAM, and a 64 GB NVMe SSD. The NVMe was a direct response to the reliability disaster of MCU1, where 8 GB eMMC chips wore out from continuous write activity at a rate that triggered an NHTSA investigation (PE 20-020) and a recall affecting hundreds of thousands of vehicles.
The MCU3, introduced with the Model 3 Highland refresh, steps up to a higher-end AMD embedded Ryzen variant, 16 GB of RAM, and 256 GB of NVMe storage, adding enough GPU headroom to run Steam games and a fully GPU-accelerated browser. Each generation is, fundamentally, an embedded x86-64 Linux PC mounted behind a center console.
That framing matters for bench work. The AMD Platform Security Processor (PSP) is present on these chips, the same ARM Cortex-A5 coprocessor that handles Secure Boot and key management on consumer Ryzen desktop processors. The NVMe SSD is a standard M.2 slot. The operating system is a Tesla-customized Linux distribution. The unit exports serial UART on test pads visible under the PCB silkscreen. None of this requires exotic tooling to interact with once you have physical access.
Why Salvage Cars Are the Research Supply Chain
New MCU2 units from Tesla’s parts program cost upward of $1,500. During the MCU1-to-MCU2 upgrade program, installed pricing ran $2,000 to $2,500. On the salvage market, a crashed Model 3 can yield the MCU for $200 to $500 depending on condition and whether the associated wiring harness section is included.
The harness is the part that matters. Tesla’s MCU connects to the vehicle via large multi-pin automotive connectors, the sealed, high-current type that automotive engineers specify precisely because commodity connectors fail under vibration, thermal cycling, and contamination. Sourcing the mating connector new requires identifying the exact series, which in Tesla’s case involves a mix of proprietary and Molex-family automotive connector variants, then finding a distributor willing to sell quantities suitable for a lab rather than a production line.
Sourcing the connector from a salvage harness requires only a wire stripper. You get a pre-crimped, correctly terminated connector that will seat properly, plus a length of wire stub that shows you which pin positions carry which signals before you attach an oscilloscope. The pin-out documentation that Tesla does not publish is partly reconstructible from the harness itself, and partly from prior reverse engineering work shared across forums and security research publications.
This is the economic logic behind salvage hardware as a research supply chain. It is not just cost, though cost matters. It is that crashed cars come with their connectors.
The Power Problem Is Not Just Twelve Volts
Most automotive ECUs run from a 12V supply, which sounds simple until you enumerate the actual requirements. A bench power supply capable of sourcing 12V at 20 to 30 amperes peak handles the MCU2’s steady-state load, with headroom for the spikes that occur during NVMe writes and during display initialization. A modified ATX power supply works for this if you short the PS_ON pin to ground, giving you a 12V rail across the yellow wires at up to 30A from a typical server-grade unit.
Automotive power architecture complicates this in a way that causes bench experiments to fail silently. Most ECUs distinguish between two supply rails: a permanent battery rail (often called KL30) that is always live, and an ignition-switched rail (KL15) that only goes high when the car is in an active state. The KL30 rail typically powers a small standby microcontroller responsible for wake-on-CAN logic and sleep state management. The KL15 rail triggers the main boot sequence.
Apply power to only one rail and the unit may sit in low-power standby indefinitely, waiting for an ignition event that will never arrive. The behavior looks like a dead board. It is not: it is a board that has not seen its boot condition. Tesla’s MCU has variations in how it handles this depending on hardware revision and firmware version, and the correct sequencing for a given unit requires either documentation or experimentation.
Ground handling is a second source of silent failures. Lab bench supplies have floating grounds by default, and automotive ECUs frequently have multiple ground pins that carry meaningful current rather than serving as pure signal references. Connecting grounds incorrectly can produce offset voltages on logic-level signals that manifest as intermittent boot failures or communication errors that are difficult to distinguish from firmware issues.
CAN Bus as a Gatekeeper
Even with correct power applied, the MCU will likely stall during initialization. Tesla’s MCU participates in a CAN network where ECUs exchange heartbeat messages and configuration frames during startup. The vehicle’s Gateway ECU mediates between the infotainment network and the safety-critical powertrain and chassis buses, and the MCU expects to see certain frames arrive from the Gateway and from other nodes during its boot sequence.
In a vehicle, this is invisible. On a bench with no other ECUs present, the CAN network is silent. The MCU can enter a wait state, timing out on expected messages, or it can initialize partially and refuse to render the display interface.
The solution is CAN bus simulation. A USB-to-CAN adapter, products like the PEAK PCAN-USB, CANable, or Kvaser devices are common in automotive research, feeds replayed or synthesized messages that satisfy the MCU’s startup requirements. Tesla’s vehicle CAN runs at 500 kbps on the standard chassis network, with a 1 Mbps variant for higher-bandwidth domains.
The SocketCAN subsystem in Linux provides a network socket abstraction over CAN hardware, and tools from the can-utils package, particularly candump, cansend, and canplayer, handle traffic capture and replay. Researchers who have previously instrumented a live vehicle with a CAN logger can replay captured startup traffic against an isolated MCU. The Tesla community has also reverse-engineered and published many of the CAN IDs and frame formats needed for basic initialization, which reduces the starting point for someone setting up a bench unit.
Automotive Ethernet is a separate consideration. Tesla’s internal vehicle backbone uses 100BASE-T1, a single-pair automotive Ethernet standard also known as BroadR-Reach, which requires either a dedicated 100BASE-T1 PHY board or a media converter to bridge to standard 100BASE-TX equipment. The MCU communicates with the Gateway and with the FSD computer over this backbone. For bench work focused on the MCU alone, simulating the minimal Ethernet traffic required to keep the MCU from stalling is often sufficient, but capturing full inter-unit communication requires the correct physical layer.
What Bench Access Makes Possible
The practical value of a running MCU on a desk is disproportionate to the effort of getting it there. A vehicle in a parking lot is awkward to instrument: physical access is constrained, adding measurement equipment requires routing cables through door gaps or under panels, and any software change that crashes the unit requires reconnecting to the car and waiting for a reboot cycle.
A bench unit can be surrounded by a full lab setup. A logic analyzer can monitor every bus simultaneously. An oscilloscope watches power rail behavior during boot. A JTAG or SWD debugger can attach to the CPU’s debug port and pause execution at any instruction. A Linux workstation captures Ethernet traffic in Wireshark in real time. The NVMe SSD can be imaged at any point by pulling it from the M.2 slot, providing a filesystem snapshot before and after any modification.
The AMD PSP on the Ryzen V1605B has its own debug interface. Probing it on a bench unit carries no risk of affecting a road-legal vehicle’s operational state. The serial UART test pads on the MCU PCB provide a boot log from the first line of the Linux kernel command line through every service initialization, which is the fastest way to understand what the unit is actually running and in what order.
This methodology is the prerequisite infrastructure for the kind of research that produces Pwn2Own results. Synacktiv’s documented Tesla exploitation chains at competitive events involve multi-stage privilege escalations through the MCU, with lateral movement toward the vehicle’s CAN gateway as the end goal. That kind of research is almost certainly developed first against isolated bench hardware, where the iteration cycle is seconds rather than the time required to drive to a test location, reproduce a condition, and recover from a crash.
The Broader Picture for Automotive Security
Tesla is not the only manufacturer whose infotainment hardware appears in salvage inventory. BMW iDrive units, Mercedes MBUX systems, and GM’s infotainment controllers surface regularly at salvage auctions and on parts marketplaces. What Tesla has that most others lack is a research and hobbyist community proportionally large enough to have reverse-engineered and published substantial documentation: CAN IDs, connector pinouts, filesystem layouts, and boot sequence requirements.
The FSD computer makes the same point at higher compute density. HW3, Tesla’s first fully custom autonomy silicon, runs two instances of a custom NPU chip delivering 144 TOPS total, with each chip implementing a 96x96 MAC array, 32 MB of SRAM, and 12 ARM Cortex-A72 cores. Tesla’s own Hot Chips 2019 presentation laid out the architecture publicly. HW4, on TSMC 7nm, scales to roughly 864 TOPS across two chips. Both computers appear in salvage inventory from crash-damaged vehicles, sold as standalone units because they are physically distinct from the MCU.
The pattern is consistent: Tesla designs serious compute into its vehicles, that compute is accessible through standard lab techniques once you have physical hardware, and the salvage market provides that hardware at a fraction of retail cost. The researchers doing the most thorough work on Tesla’s systems are generally working with exactly this setup, a bench, a power supply, salvage connectors, and a CAN simulator.
What xdavidhu documents is not exotic methodology. It is the baseline for any careful work on automotive ECU firmware, applicable to nearly any modern vehicle computer. The value of writing it down in detail is that this knowledge currently lives in scattered forum posts, unpublished lab procedures, and the institutional memory of people who have done it before. Consolidating it into a published methodology is the part that compounds: each researcher who can skip the three weeks of connector archaeology and power rail debugging can spend that time on the research itself.