The Tesla hardware stack, briefly
The Model 3’s “computer” is actually several computers. The infotainment system, called the MCU (Media Control Unit), handles the touchscreen, audio, navigation, and most connectivity. It runs a Linux-based OS on conventional x86 silicon. Separately, the Autopilot computer handles the driving automation stack; in HW3-equipped cars this runs Tesla’s own custom FSD chip capable of 144 TOPS, while HW4 hardware in the refreshed Highland generation uses a newer variant. Between them sits a gateway ECU that bridges the CAN bus carrying vehicle signals to the compute subsystem.
For security research purposes, the MCU is the most approachable target. It runs a full Linux userspace, handles WiFi and Bluetooth, connects to Tesla’s backend over LTE, and processes a constant stream of vehicle data. Previous MCU vulnerabilities have enabled researchers to pivot toward more safety-critical systems.
Tesla’s MCU hardware has gone through three generations. MCU1 used an NVIDIA Tegra 3 SoC with 512MB of RAM, found in Model S vehicles from 2012 through roughly 2017. MCU2 replaced that with an Intel Atom e8000-series processor and significantly more eMMC storage, addressing what Tesla publicly described as NAND wear failures on the older units. MCU3, introduced in refreshed Model S and X variants and later rolled into the updated Model 3 platform, moved to AMD Ryzen embedded silicon, roughly doubling the compute headroom and enabling the sharper UI refresh that shipped alongside it.
That AMD-based board is almost certainly what David Husz sourced for this project. It is a reasonably conventional x86-64 single board computer running beneath an unusual set of electrical and communication constraints imposed by its automotive context.
What getting it to boot actually requires
Automotive electronics are not tolerant of missing context. A standalone MCU will throw diagnostic faults if it doesn’t see the signals it expects from the rest of the vehicle. Some of those faults are cosmetic; others affect whether the system boots fully.
Power is the first problem. The MCU draws from the car’s 12V bus, but the harness has multiple rails and the board’s internal regulators derive the voltages needed by the SoC and peripherals. A benchtop supply capable of 10 to 15 amps at 12V with clean regulation handles the main rail. The tricky part is providing the correct power sequencing, since most automotive electronics distinguish between the always-on battery feed and the switched ignition line (typically labeled IGN or ACC), and some startup logic waits on that transition before continuing initialization.
CAN bus is the second problem. The vehicle’s CAN network carries hundreds of messages per second from every ECU in the car. The MCU listens to those messages for vehicle speed, gear position, door states, and dozens of other signals it uses to adjust the display and enable certain features. Without those messages, the infotainment software spends part of its startup sequence waiting for data it will never receive. The practical workaround is either a CAN bus simulator (a microcontroller emitting a minimal set of valid frames at plausible rates) or simply terminating the bus with the standard 120-ohm resistors across each CAN pair and accepting that some features remain in a degraded state.
Tesla also uses 100BASE-T1 automotive Ethernet for some inter-system links. That physical layer is incompatible with the 100BASE-TX ports on standard networking gear; it uses a single twisted pair instead of two, and the signaling is different enough that you need a media converter to bridge them. For most software-layer research the MCU also exposes a standard Ethernet port, which is sufficient for traffic capture and service interaction without requiring automotive Ethernet hardware.
Why crashed Teslas are the right source
Tesla has been selling vehicles at volume since 2012. Those vehicles have been getting into accidents since 2012. That means there is over a decade of Tesla hardware in the salvage ecosystem through platforms like Copart, IAAI, and eBay, and supply is significant because Tesla’s market penetration in certain regions is high enough that crashed inventory is not rare.
For a researcher, this matters for a few reasons. The hardware is identical to production vehicles. A salvage MCU board runs the same firmware and carries the same cryptographic provisioning as any car on the road. This is different from developer evaluation kits or simulation environments, which often ship with intentionally relaxed security configurations that make them poor proxies for production attack surfaces. The economics are also reasonable: MCU boards from salvage Teslas sell for a few hundred dollars depending on generation and condition, compared to the significant cost of a vehicle you would need to be careful with. And the hardware can absorb experiments that would be irresponsible to run on anything someone might be driving.
That last point is underappreciated. When you are fuzzing a CAN bus, replaying captured traffic at unusual timing intervals, or probing an eMMC controller with a logic analyzer while the system is live, you want hardware you can brick and replace. Salvage hardware turns destructive testing into recoverable testing. The risk model changes completely.
What bench access enables
In-car security research is genuinely uncomfortable. Physically accessing the MCU involves removing interior panels, working in constrained positions, and either keeping the car powered up or constantly dealing with sleep modes cutting power at inconvenient moments. You cannot attach an oscilloscope to a CAN bus tap and also run fuzzing software and also review the output simultaneously without either a very large car or a very patient co-researcher.
Bench access changes the physical ergonomics entirely. You can attach a logic analyzer to every bus at the same time. You can use a JTAG debugger if the SoC’s debug interface is accessible. Tesla has done significant hardening work on hardware debug interfaces in recent generations, but earlier MCU hardware was more reachable, and understanding what changed tells you something about the threat model Tesla was designing against.
You can dump the eMMC contents with a dedicated reader and study the filesystem layout, the partition structure, the A/B update scheme, and what ends up in persistent storage. The OTA update mechanism is particularly interesting: Tesla’s update system pushes software to every connected vehicle, and understanding how the update is verified, staged, and applied is foundational to assessing whether the verification can be bypassed or the rollback protections can be circumvented.
The connectivity attack surface matters most. Tesla vehicles maintain a persistent LTE connection to Tesla’s backend infrastructure. They run a WiFi stack for the phone-as-key feature and guest network functionality. They implement Bluetooth for the mobile app and NFC for key cards. All three represent remote attack surfaces, and studying how they are implemented is substantially easier when you can attach packet capture hardware without worrying about where the car is parked or whether you are interfering with a vehicle in use.
Prior art and the lowering access cost
This kind of hardware-first Tesla research has a history. Keen Security Lab published multiple papers between 2016 and 2020 demonstrating remote and local attack chains against Tesla vehicles, including one that achieved persistent control of the MCU and leveraged it to inject arbitrary CAN messages toward the vehicle bus. That research drove several rounds of Tesla software patches and contributed to architectural changes in how the gateway ECU validates messages originating from the infotainment side, a meaningful defense-in-depth boundary.
At Pwn2Own 2023, a team from Synacktiv compromised a Model 3 through a chained Bluetooth exploit that earned a $100,000 payout from Tesla’s bug bounty program. Tesla has maintained an active program through Bugcrowd covering both software and hardware vulnerabilities, and that has contributed to a more functional disclosure relationship than most automotive OEMs have managed.
What’s shifted is the barrier to entry. When Keen Security Lab was doing their early work, you needed a full vehicle, a dedicated team, and significant operational overhead. The salvage market has matured alongside Tesla’s sales volume. The hardware is out there, it’s priced in the range of a hobbyist budget, and the research community has accumulated enough documentation about electrical requirements that a single motivated person can get an MCU running on a workbench without reverse-engineering the power harness from scratch.
That is roughly where this project sits. The value of a write-up like Husz’s isn’t necessarily any single vulnerability finding; it’s the documentation of the setup process, what parts you need, what signals you have to simulate, and how you get from a pile of salvage electronics to a running system you can meaningfully probe. That kind of documentation compounds. Once the bench setup is reproducible, the barrier for the next researcher drops further, and the findings from one person’s work become the infrastructure for the next person’s.