When David Hu published his writeup on running a Tesla Model 3’s infotainment computer on a desk using hardware sourced from salvage auctions, the Hacker News reaction split between people encountering automotive hardware hacking for the first time and researchers quietly recognizing the documented version of work they had already been doing privately.
The project is technically specific: source a Tesla MCU (Media Control Unit) assembly from Copart or IAAI, wire it to a bench power supply, fabricate breakout cables for the multi-pin connectors, and get the system booting. Getting there requires solving the power requirements, the connector pinouts, and the CAN bus simulation needed to keep the MCU from entering a fault state without a vehicle attached. The significance of this class of work extends past the individual steps, though. Tesla’s architecture has made it possible in a way that traditional automotive hardware never did, and the supply of crashed Teslas at salvage auctions has made it cheap enough for individual researchers.
Why Tesla’s Architecture Is Different
A conventional OEM vehicle distributes its computing across dozens of small ECUs, each sourced from a different Tier 1 supplier, running proprietary firmware on microcontrollers with no standard debug interface and no shared operating system. The body control module from Bosch runs different firmware than the transmission controller from ZF, which runs different firmware than the ABS module from Continental. Each requires vendor-specific diagnostic software to interrogate. Sourcing individual ECUs for bench research is possible, but understanding how they interact requires the full vehicle wiring harness and often dealer-tier tooling locked behind licensing agreements.
Tesla centralized instead. The MCU handles infotainment, navigation, connectivity, and user interface. A separate Autopilot computer handles camera processing and driving decisions. A gateway ECU bridges the CAN bus segments. That is roughly three boards doing what a conventional OEM might distribute across 30 to 70.
The MCU runs Linux. The Intel Atom E8000 variants introduced in 2018 and the AMD Ryzen Embedded variants (A3950, Zen+ architecture) that followed both run a custom Linux distribution where systemd manages services, giving researchers who already know Linux an immediate foothold. The filesystem layout, the init system, the network interfaces, and the process table are all familiar. Contrast that with reverse engineering a proprietary RTOS on a Renesas microcontroller with no debug symbols, no documentation, and tooling that costs thousands of dollars to license. Tesla’s decision to build around consumer-grade silicon and a standard operating system was driven by cost and iteration speed, not by any intent to help security researchers, but the effect is the same.
The Autopilot computers went through their own interesting evolution. The HW2 hardware introduced in late 2016 used NVIDIA’s Drive PX 2 platform with dual Tegra Parker SoCs. The HW3 FSD Computer, introduced in 2019, was Tesla’s first fully in-house silicon: a Samsung 14nm chip with custom neural processing units delivering 72 TOPS across the dual-chip assembly. HW4, shipping in current production, moves to finer process nodes and drops radar entirely in favor of higher-resolution cameras. Each generation left hardware in the field, and each generation eventually ends up at salvage.
The Salvage Market as Research Infrastructure
The second structural advantage is supply. Tesla sells a large number of cars, and a significant fraction end up in accidents. The Model 3 is among the most common vehicles at Copart and IAAI, the two dominant US salvage platforms. Complete MCU assemblies sell for $150 to $600 depending on variant and condition. FSD Computer boards containing the custom HW3 dual-chip silicon appear regularly at $400 to $900. For that price, a researcher gets hardware that would cost $2,000 or more as a factory option in a new vehicle.
The availability matters beyond cost. Researchers can destroy boards without regret. Voltage glitching, a technique that involves applying carefully timed power faults to bypass secure boot or extract cryptographic material, requires multiple hardware attempts because most attempts brick the target. When the TU Berlin team demonstrated a voltage glitching attack against the AMD Platform Security Processor in the Tesla MCU2 in 2023, extracting AMD firmware signing keys and achieving root access, they worked through multiple boards refining fault timing. That research would be implausible on a single vehicle you own. The salvage market absorbs the cost of iteration.
The TU Berlin result is worth understanding in detail because it reveals a structural issue in Tesla’s hardware choices. The AMD Platform Security Processor (PSP) is a security coprocessor embedded in AMD consumer silicon; it manages secure boot, key storage, and attestation. It was designed with software-based attacks as the primary threat model. Voltage fault injection, where an attacker briefly drops the supply voltage to cause the processor to skip or corrupt an instruction, was not a hardened-against scenario. The researchers used a ChipWhisperer to deliver the fault and extracted root keys that unlocked full filesystem access. Purpose-built automotive secure elements from suppliers like Infineon or NXP would have been significantly more resistant to this attack. The choice of consumer AMD silicon traded automotive-grade physical security for integration simplicity and cost.
The Bench Setup in Practice
Getting a Tesla MCU running without a vehicle is achievable with moderate electronics experience. The MCU uses multiple connectors: large multi-pin housings in the Molex MX150 and Aptiv GT 280 series carry power and CAN bus signals, while FAKRA connectors handle the LTE antenna and camera feeds. The main power rail is 12V, but the MCU draws substantial current, especially during boot on the AMD Ryzen variant where 10 to 15 amps is a reasonable expectation. A regulated bench PSU at 12V, 20A handles this; many researchers repurpose surplus server PSUs (HP DPS-800GB units with the enable pin jumpered) for their high current ratings and low acquisition cost.
The CAN bus situation requires specific attention. When the MCU boots without a vehicle, it expects CAN messages from other ECUs. Without them, it enters fault states that restrict what the UI will do and which services will initialize fully. The solution is injecting CAN frames from a PC via an inexpensive USB-CAN adapter, a CANable or Peak PCAN-USB being the most common choices, running under Linux with the SocketCAN kernel subsystem. The candump and cansend utilities from can-utils are sufficient to monitor and replay frames. Researchers who go deeper have published Tesla-specific DBC files documenting the CAN message IDs and signal encodings for various model years.
Tesla also uses 100BASE-T1 automotive Ethernet for high-bandwidth internal communication, carrying camera video feeds from the eight cameras to the Autopilot computer. Standard PC Ethernet adapters cannot connect to a 100BASE-T1 network directly; it requires a media converter such as those based on the Microchip LAN9500 chipset, or professional tools from Vector or Kvaser. This is one of the less-documented parts of benchtop Tesla research, since most work focuses on the MCU rather than the autopilot data pipeline.
UART console access rounds out the basic setup. Test pads on the MCU board expose a 3.3V UART at standard baud rates; an FTDI adapter connects to a PC, and the boot log is detailed enough to map the software architecture from first principles. Earlier firmware versions gave a root shell directly; later versions require an exploit chain to escalate.
The Research Community That Built the Foundation
Hu’s work joins a substantial body of prior research. The researcher known as greentheonly has spent years extracting Tesla firmware, documenting the autopilot software stack, and demonstrating features Tesla had not yet publicly enabled. Tencent KeenLab demonstrated remote exploit chains against Tesla in 2016, 2017, and 2019, progressing from WiFi-based browser exploits through the gateway ECU to CAN bus injection affecting physical vehicle behavior. Pwn2Own Automotive 2024 saw multiple teams compromise Tesla’s infotainment stack, with findings including heap overflows in the Bluetooth stack.
There is a meaningful difference between what each of these research approaches can accomplish. Remote exploit research, like KeenLab’s work, requires no physical hardware and scales to finding vulnerabilities without owning a vehicle. Benchtop hardware research, like Hu’s, requires physical access but allows a different depth of analysis: probing signals, observing boot behavior, testing fault injection, and examining filesystem contents without time pressure. The two approaches are complementary; remote exploit chains typically require understanding the software stack in ways that benchtop access makes tractable.
The Broader Implication
Most vehicles on the road today still use the distributed ECU architecture that Tesla departed from. But other manufacturers are consolidating. Volkswagen’s new software-defined vehicle platform, GM’s Ultium architecture, and Hyundai’s newer designs are all moving toward centralized compute boards running Linux or comparable open foundations. The skills and tooling the Tesla research community developed, including CAN simulation, automotive Ethernet analysis, voltage glitching against embedded security processors, and Linux filesystem forensics on automotive targets, will transfer directly to those platforms as they age and enter the salvage market.
What the benchtop Tesla approach established is that automotive security research does not require institutional resources or a fleet of test vehicles. It requires a few hundred dollars of salvage hardware, a bench power supply, a USB-CAN adapter, and familiarity with Linux. That is a significant change from even five years ago, and it is a direct consequence of architectural choices Tesla made to ship products faster and cheaper. David Hu’s write-up documents what this looks like in practice, and the HN thread that followed it reflects a community that has been building this capability steadily, one crashed car at a time.