Security researchers who want to study automotive software have always faced a friction problem: the hardware is designed to live inside a vehicle, surrounded by the network signals, power rails, and peripheral inputs it expects. Strip it out and it either refuses to boot or enters a degraded mode that tells you very little. Tesla hardware presents this same challenge, but with an interesting twist: the architecture is close enough to commodity PC hardware that a determined researcher can actually get somewhere.
David Huertas’s writeup on getting a Tesla Model 3 computer running on a desk, sourced from salvage vehicles, is a good illustration of what this kind of work actually involves. The hardware came from crashed cars, the kind that cycle through Copart and IAAI and end up at specialized Tesla salvage yards. That supply chain matters, because the research is only tractable if the parts are accessible and affordable. A $200 ICE unit from a totaled Model 3 is a very different proposition from a $2,000 dealer-only component.
The Hardware Generation That Makes This Interesting
The Tesla Model 3 Highland, released in late 2023, moved to an AMD Ryzen-based infotainment unit. Tesla calls this the ICE (Infotainment Computer Electronics), a naming choice that creates some irony given the company’s stance on internal combustion engines. The previous generation MCU2 ran an Intel Atom E3940, which was already a conventional x86 processor running a custom Yocto Linux build. The Ryzen step-up is meaningful: it brings more cores, more memory bandwidth, and hardware video decode acceleration, but the core architecture story stays the same. This is a real general-purpose computer in the way that, say, a 2010-era ECU was not.
Compare this to traditional automotive infotainment systems, which often run QNX or Android Automotive on ARM SoCs with proprietary firmware blobs and no meaningful path to a shell. Tesla’s Linux base means that a researcher who gets the system booted and gets a root shell is working in a familiar environment. The tools they know, the filesystem conventions they expect, the process model they understand — all of it transfers.
Power, Connectors, and the Boot Problem
The hard part of bench-testing any automotive ECU is not the software; it is power and signal environment. Automotive systems are nominally 12V, but the actual requirement is more nuanced. Modern vehicles use power sequencing: different rails come up in a defined order, and the main processor often will not start until it sees signals indicating the car is in the right state. The ICE in a Model 3 listens for inputs from the Body Control Module and expects specific messages on the vehicle network before fully initializing.
Tesla’s vehicle network is not a simple CAN bus. Starting with the Model 3, Tesla moved to a 100BASE-T1 automotive Ethernet backbone for high-bandwidth communication, supplemented by CAN FD for lower-bandwidth control signals. The ethernet backbone carries camera feeds, the display output to the touchscreen, and communication between the ICE and the Autopilot computer. Getting the ICE to boot happily in isolation means either providing the expected traffic on these interfaces or finding the right combination of power state signals to bypass the checks.
This is where the salvage-market approach pays off in an unexpected way: multiple units from multiple crashed vehicles let you experiment destructively. You can probe connectors, apply incorrect voltages to understand protection circuits, and generally treat the hardware as expendable in a way you cannot if you are working with your only sample.
How Tesla’s Architecture Differs from Traditional Automotive Research
Most automotive security research, including the famous Miller and Valasek work on the Jeep Cherokee from 2015, centers on CAN bus access. CAN is a broadcast network: every node sees every message, there is no authentication, and injecting messages means any node can impersonate any other. The attack surface is well-understood and, by now, well-documented.
Tesla’s Ethernet backbone changes the topology. Messages are unicast or multicast to specific destinations. The network runs through a managed switch, which means traffic is not inherently visible to every node. This is better for security in some ways, but it also means that bench research requires a proper Ethernet tap or managed switch configuration rather than a simple CAN bus sniffer. Tools like Wireshark apply directly, which is a genuine convenience, but understanding the proprietary protocols that run over the Ethernet layer is its own research problem.
Tesla uses a mix of custom binary protocols and, in some cases, more standard formats over their internal network. Keen Security Lab’s research series on Tesla systems, published between 2017 and 2020, documented several of the interfaces and found vulnerabilities in the browser stack, the gateway ECU’s CAN forwarding logic, and the Autopilot computer’s firmware update mechanism. That research was done mostly against live vehicles. Bench research opens the possibility of more controlled experiments: longer fuzzing sessions, memory inspection without timing constraints, and filesystem analysis at rest.
The Salvage Economy as Research Infrastructure
There is a broader story here about what makes Tesla hardware uniquely accessible to independent researchers. Tesla’s repair policies, combined with high crash rates for a fleet that includes many performance vehicles, have created a substantial secondary market. Salvage yards in the United States and Europe maintain significant Tesla inventory. Organizations like Fenix Parts specialize in late-model salvage, and the Tesla-specific used parts market on eBay and dedicated forums is active and reasonably priced for ECU-class hardware.
This is not the case for most vehicles. A GM or Ford infotainment unit from a late-model vehicle is often VIN-locked: it will not operate in another vehicle, and it will not operate outside the vehicle at all without dealer-level programming tools. Tesla’s approach to software licensing, where the hardware runs the features and software unlocks are applied over the air, means the hardware itself is more portable. A salvage ICE generally boots and operates without VIN binding at the bootloader level, which is what makes this kind of bench research tractable.
What You Can Learn From an Isolated System
Running the ICE in isolation, separated from cameras, vehicle sensors, and the rest of the vehicle network, exposes things that are harder to examine in situ. The filesystem is accessible for static analysis. Boot logs are capturable from the beginning of the power cycle. The processes that run, the network sockets they open, and the files they read during initialization are all observable in ways that are difficult when the system is inside a car doing actual infotainment things.
For vulnerability research, this matters because many interesting bugs are in initialization paths: code that runs once at startup, reads configuration, or handles the first network message. These paths are underexercised in normal operation and therefore less well tested. A bench setup lets a researcher run through the boot sequence hundreds of times with different inputs, which is the kind of iteration that fuzzing and fault injection require.
The display interface is worth mentioning separately. Tesla’s touchscreen uses LVDS or, in newer hardware, a direct eDP connection from the ICE to the display assembly. Getting display output working on the bench requires either the original display assembly (also available salvage) or an LVDS-to-HDMI adapter, depending on the specific interface. Researchers who want to see the full UI in operation rather than just logging output need this, and the salvage ecosystem supplies it.
The Disclosure Side
Tesla has run a bug bounty program through Bugcrowd since 2013, and it covers vehicle software. The program has paid out for browser vulnerabilities, privilege escalation on the Linux side, and gateway ECU issues. Pwn2Own Automotive, which Trend Micro’s Zero Day Initiative runs, has featured Tesla as a target since 2024, with substantial payouts for remote code execution chains.
Bench research occupies an interesting position in this ecosystem. It is legal under most interpretations, since the researcher owns the hardware. It produces findings that are clearly applicable to live vehicles. And it removes the liability and logistics of researching on a vehicle that someone is actually driving. The responsible disclosure path is the same regardless of whether the finding came from a live car or a salvage ICE on a workbench.
What Huertas’s project represents, beyond the technical specifics, is a maturation of the research ecosystem around Tesla hardware. When the methodology for getting a system running on a bench is documented in enough detail that others can reproduce it, the pool of researchers who can do meaningful work on that system grows. That is generally good for security, even if it is uncomfortable for the manufacturer.