David Schütz has been running a Tesla Model 3’s infotainment computer on his desk, sourced from parts pulled off crashed cars. Getting there required solving the mundane but genuinely difficult problems of bench-testing an automotive ECU: figuring out power requirements, sourcing the right connectors, replicating the communication environment the module expects when it lives in a car. These details rarely make it into security research write-ups, and his account of working through them is a useful record of what the setup actually costs in time and frustration.
The project reflects a broader shift in who can do automotive security research, driven by two converging factors: Tesla’s decision to build its vehicles around relatively standard silicon, and the growing volume of crashed EVs generating cheap salvageable electronics.
What Is Inside the Car
Tesla’s current infotainment stack centers on the MCU3 (Media Control Unit, third generation), which runs an AMD Ryzen embedded processor — likely a V2000-series APU — paired with 16GB of LPDDR5 RAM and a 256GB NVMe SSD in an M.2 form factor. The MCU3 drives the 15.4-inch center touchscreen along with up to two rear headrest displays, and it runs Tesla’s custom Linux distribution. It is capable enough to run full AAA games through Tesla Arcade; Cyberpunk 2077 is one of the titles on offer. The choice of AMD over a custom automotive SoC is an engineering decision made for cost and performance reasons, but its side effect is that the MCU3 is, for practical purposes, a small PC running a recognizable Linux userspace.
The autopilot hardware sits in a separate unit. Tesla’s Hardware 3 (HW3) computer uses a custom ASIC designed in-house and manufactured by Samsung on a 14nm process. Each chip contains twelve ARM Cortex-A72 CPU cores, a custom neural processing unit, an Imagination Technologies Mali G71 MP12 GPU, and 8GB of LPDDR4X. Production vehicles ship with two of these chips in tandem, giving a combined throughput of 288 TOPS for inference workloads. The FSD computer handles only vision and decision processing; it communicates with the rest of the vehicle over automotive Ethernet and CAN bus rather than having direct control of actuators.
These two subsystems — the MCU and the FSD computer — are architecturally distinct, but both live on the same vehicle network and both run Linux. That is a significant and approachable attack surface by automotive standards.
The Salvage Market Has Changed the Economics
Until recently, hardware security research on a modern vehicle meant either buying one, borrowing one under a coordinated disclosure agreement with a manufacturer, or working at an OEM. The car was the cost of entry.
That calculus has shifted. Copart and similar salvage auction platforms regularly list Tesla electronics from totaled vehicles. A Model 3 MCU from a crashed car sells for a few hundred dollars. The hardware is identical to what runs in an intact vehicle; salvage status means only that the chassis took damage. As Tesla’s installed base has grown and accident rates have generated a steady stream of write-offs, the secondary market for Tesla electronics has matured into something reliable enough to plan a research project around.
Researchers at Keen Security Lab, who published detailed Tesla CAN bus vulnerability research starting around 2019, and the teams competing in Pwn2Own Automotive have worked with this hardware. But detailed accounts of the physical setup work — how you actually get one of these modules running on a bench without a whole car attached — are sparsely documented in public records. Schütz’s write-up fills that gap.
The Technical Problem of Bench Testing an Automotive ECU
Pulling an ECU out of a car and getting it to boot off the vehicle requires solving three distinct problems: power, communication, and context.
Power. Tesla modules run on 12V automotive power. The MCU draws substantial current during boot, and a bench power supply rated for 20 to 30 amps is typically necessary to avoid voltage sag that causes boot failures or unexpected resets. The connectors are proprietary; Tesla uses Molex MX150 and TE Connectivity variants. Sourcing the mating connectors and building a bench harness is a prerequisite, and getting the wiring wrong can damage the module before it ever boots.
Communication. Tesla’s internal vehicle networks combine multiple CAN buses with automotive Ethernet. CAN bus segments require 120-ohm termination resistors at each end to function correctly; without them, signal reflections produce transmission errors that look like firmware problems but are actually a missing two-dollar component. The automotive Ethernet runs on BroadR-Reach (now standardized as 100BASE-T1 and 1000BASE-T1), which uses a single twisted pair in full-duplex mode — incompatible with standard Ethernet adapters and requiring a media converter to interface with a PC.
Context. Many automotive ECUs expect to see periodic messages from other modules before they will proceed past a certain initialization state. An MCU in a running car receives continuous heartbeat and status frames from the gateway, body controller, instrument cluster, and other ECUs. On a bare bench, those messages are absent, and modules can sit in a degraded state or refuse to complete their boot sequence. Reproducing the necessary CAN traffic to satisfy initialization checks requires knowing which message identifiers the module watches for, what the payload format looks like, and at what rate those frames should appear.
This is where having a CAN analysis tool — a Peak PCAN-USB, a Kvaser interface, or a socketCAN setup running candump on Linux — pays off. Logging what a live vehicle generates and then replaying the relevant frames on the bench is the standard approach for bootstrapping this kind of work.
Why Tesla Is the Right Target
Most automotive ECUs from traditional manufacturers are built on proprietary real-time operating systems: AUTOSAR-based stacks, custom OSEK kernels, toolchains that require manufacturer cooperation or expensive specialized equipment to work with. The attack surface is real, but getting to it is a significant investment in unfamiliar tooling and binary formats.
Tesla’s stack is different. The MCU runs a recognizable Linux userspace. The filesystem layout, process model, and IPC patterns are familiar to anyone who does Linux security research. Prior work from Keen Security Lab and from Pwn2Own teams has shown that the attack surface is approachable with standard tools once you have physical access — ssh, gdb, strace, all the usual instruments work once you find an entry point.
The FSD computer is more opaque due to the custom ASIC, but the ARM Cortex-A72 cores run standard ARM Linux code that disassembles and decompiles with Ghidra or IDA. The ASIC’s NPU is harder to reason about statically, but it is not the primary target for most security research; the Linux environment surrounding it is.
There is also a historical dimension worth noting. When Tesla first shipped vehicles with MCU1 (built around a Tegra 3 SoC) and later MCU2 (Intel Atom E8000 series, 8GB RAM), the hardware was already closer to an embedded PC than a traditional automotive ECU. Each generation has moved further in that direction. MCU3’s NVMe SSD and AMD GPU make it roughly comparable to a budget gaming PC from a few years ago. That trajectory is not accidental; it reflects Tesla’s view that the infotainment computer is a general-purpose platform that should run increasingly demanding software.
The Bug Bounty Context
Schütz’s prior work provides useful context for why he is doing this. He is best known for discovering CVE-2022-20465, a physical bypass of the Android lock screen on Pixel devices requiring only a SIM card, which earned a $70,000 bounty from Google. His write-ups are methodical and detailed, walking through failed approaches alongside the successful ones in a way that makes them useful beyond the specific vulnerability being disclosed.
Tesla runs a bug bounty program through Bugcrowd, with payouts ranging from a few thousand dollars up to $100,000 for critical issues affecting vehicle safety systems. Physical attack vectors — those requiring direct hardware access — are in scope. A researcher with a working bench setup of Tesla’s computer can iterate at a pace that is simply not possible when every test requires being inside an actual car. The bench setup is a research multiplier: tedious to build, but compounding in value across every subsequent hour of work.
A Pattern Worth Watching
The EV salvage market will keep growing as the installed base ages and accidents accumulate. Components from wrecked cars are increasingly identifiable by part number, available on auction platforms at predictable prices, and compatible with standard research workflows once the power and communication problems are solved. The combination of accessible hardware and a recognizable software stack makes Tesla the most researchable production vehicle on the road by a wide margin.
Whether Tesla’s openness to this kind of research — running a bug bounty, engaging with Pwn2Own participants, publishing some security documentation — translates into a meaningfully more secure vehicle than competitors who are harder to research is a genuinely open question. Security through obscurity has a poor track record, but so does security through openness if the engineering does not follow through. The next few years of public research will be an interesting test of which effect dominates.