Security
Tesla Model 3 on a Desk: Salvage Bring-Up, Rosenberger Cables, and Security Research
TLDR
SignalStack Tech Report · March 27, 2026 · Security / Hardware / Automotive
Why this is on SignalStack: we cover offline research surfaces when they change blast radius—here, a bench setup that separates security work from live-vehicle risk.
A security researcher built a “Tesla-on-a-desk” by extracting a Model 3 computing stack from crashed vehicles.
This bench setup enables deep bug bounty research and reverse engineering without needing a full, drivable car.
The biggest blockers were hardware-level: sourcing a proprietary display cable, recovering from a shorted power chip, and eventually buying a full dashboard harness to get reliable connector paths.
- Power / inrush: ~8 A peak @ 12 V—use a supply with real headroom and short, heavy leads (see Context & primary sources for part vendors + policy links).
- Thermals: in-car liquid cooling is missing on the bench—expect throttling without aux cooling.
- ODIN / service mode: workshop-style diagnostics and HTTP tool surfaces—high leverage, not a public API.
Bring-up notes for builders: inrush during boot was reported up to ~8 A on 12 V—budget headroom beyond that peak (many bench supplies advertise “10 A” but sag under short bursts). Short thick leads and solid return paths matter as much as the label on the supply: IR drop across skinny wires can brown out logic just long enough to fault boot. Treat 10 A as a floor for the reported peak class, not a comfortable ceiling if your cabling runs long or thin.
What happened
The project goal was to recreate a realistic Tesla environment for security work in the bug bounty context.Core parts were sourced from eBay salvage channels, including Model 3 hardware removed from crashed cars. The stack included the Media Control Unit (MCU), the Autopilot (AP) computer mounted with it, and the 15-inch touchscreen.
A 12 V adjustable DC supply rated to ~10 A was used, with boot-time peaks near ~8 A. In practice, pairing headroom (some teams target 12 A+ class supplies or remote sensing) with heavy gauge supply wiring reduces nuisance reboots from transient voltage droop.
Thermals: liquid vs bench air
In the vehicle, MCU/AP assemblies typically rely on liquid cooling loops tied to the thermal management system. On a bench without that loop, sustained workloads can hit thermal limits sooner—CPU/GPU throttling, slower UI, or protective shutdowns compared to in-car operation. Mitigations people mention in bring-up threads include small blowers or heat-spreader-to-fan jury rigs aimed at the cold plate / stack surfaces; details depend on your salvage bracket. This is not service guidance—just realism: offline research still needs thermal awareness so you do not mis-attribute instability to “software” when the stack is simply heat-soaked.
The hardware: sourcing from salvage
- MCU (Media Control Unit): infotainment and display core. - Autopilot (AP) computer: mounted as part of the compute stack. - 15-inch touchscreen: primary interaction surface for Tesla OS. - 12V DC power supply (up to 10A): necessary for stable bring-up and boot peaks.The implementation hurdles
The hardest blocker was the proprietary 6-pin Rosenberger display cable between MCU and screen. Salvage dismantling often leaves these lines cut, making intact cable paths difficult to source.An early bypass wiring attempt caused a short and damaged a MAX16932 power controller. Recovery required component-level SMD repair and replacement work.
The stable fix was to buy a complete dashboard harness from a scrapped vehicle and extract the needed connector path rather than forcing ad-hoc cable substitutions.
Why it matters
This proves modern EV compute stacks can be isolated for offline vulnerability research, firmware work, and UI debugging.For researchers, bench testing is safer and more controllable than live vehicle testing, and it lowers the risk of bricking a functional car during experiments.
It also surfaces a repairability gap: even one cable can require purchasing a full harness, showing how closed and bundled modern automotive hardware has become.
For developers exploring CAN interactions, diagnostics, and third-party integrations, reproducible “car computer on desk” environments are highly practical.
Key details at a glance
| Area | Detail | Note |
|---|---|---|
| Goal | Desk testbed for bounty / RE | Reduces live-vehicle risk |
| Power | 12 V; ~8 A boot peak reported; budget headroom + heavy leads | IR drop can faux-fault boot |
| Cooling | Vehicle liquid loop absent on bench | Expect throttling; plan airflow / heatsinking |
| Stack | MCU + AP + 15” display off chassis | Matches in-car topology |
| Blocker | Proprietary 6-pin Rosenberger display path | Often only intact in full harness |
| Incident | Early workaround short; MAX16932 damage | Component-level repair |
| Resolution | Full dashboard harness from salvage | Stable routing vs ad-hoc wiring |
What to watch next
- Service-mode surfaces — After boot, researchers often care about Tesla Service Mode / workshop-style flows that expose diagnostic menus, component telemetry, and calibration hooks that are intentionally absent from normal UI—paired with ODIN-class HTTP endpoints (commonly discussed on 8080 in write-ups) for tool-automation-style reads and actions where signing still gates writes. Treat these as authorized-workflow analogues on the bench: powerful for measurement, dangerous if treated like toy APIs.
- SSH reality — Presence of sshd does not imply open access; key material and policy still dominate (see bounty scope).
- Deeper buses — CAN mapping, firmware extraction, structured documentation of diagnostic flows.
- Community replication — Reliability of the bring-up path, tooling, and ethics of downstream use cases.
The SignalStack angle
What we are not doing: glamorizing unauthorized vehicle modification. What we are doing: noting how automotive stacks become repairable research targets when hardware is bundled and cables are scarce.
1. Bench beats bricking a daily driver
Isolated hardware lowers the risk of disabling a working car during experiments. SignalStack’s read: reproducible “car computer on desk” environments matter for defensive research and preservation—not only exploits.
2. Repairability is a security story
When one proprietary cable forces buying a whole harness, the ecosystem tilts toward closed maintenance paths. That affects long-term ownership and independent research access.
Disclaimer: Follow vendor terms, local law, and bug bounty rules when researching.
Context & primary sources
Curated links—enough to brief hardware and policy stakeholders without turning the article into a link farm. Verify part numbers and interfaces against your salvage revision.
- HSD / Rosenberger family (display-side physics): Rosenberger — RosenbergerHSD® overview (automotive differential interconnect context; Tesla harness pinouts still require authorized documentation).
- Power IC (MAX16932) — vendor page: Analog Devices — MAX16932 (specs / ordering context for the cited buck controller).
- OEM documentation path: Tesla Service — official wiring and service information for **authorized** accounts; independent researchers often hit **salvage harnesses** precisely because OEM docs are gated.
- Bug bounty scope — Tesla on Bugcrowd: bugcrowd.com/tesla — what Tesla treats as **in scope** / **out of scope** for rewards (not legal advice).
- Policy framing — NHTSA cybersecurity primer: NHTSA — vehicle cybersecurity — federal framing for automotive cyber risk (high-level).
- Right-to-repair bridge: repair.org — why “one weird cable ⇒ whole harness” is a political and economic story, not only a nerd inconvenience.
- Open-source components — Tesla GitHub org: github.com/teslamotors — OSS disclosures relevant to stack composition (not a firmware dump of the MCU).
Conference trail: Automotive security talks move year to year—search DEF CON / Black Hat archives for MCU, infotainment, and EV sessions rather than relying on a single evergreen URL.
FAQ
Q What is the 'car computer' in a Tesla Model 3? A In this context, it is effectively a "sandwich" of the MCU (infotainment/display) and the Autopilot computer in a shared liquid-cooled enclosure.Q Why was the display cable hard to get?
A The needed connector path is usually part of a larger dashboard harness, not commonly sold as a standalone cable in salvage listings.
Q What is ODIN?
A In third-party write-ups, ODIN refers to an onboard diagnostic / workshop-automation-style HTTP surface (often discussed alongside port 8080) used with Tesla service workflows—not a single “button,” but a family of endpoints that can expose diagnostics, telemetry, and tool-driven actions when the stack is booted and policy allows. Service Mode is the operator-facing side (menus and tests); ODIN-like interfaces are the machine-facing side researchers intersect cautiously because writes can brick or misconfigure components.
Q Why does my bench thermal-throttle compared to a car?
A The in-car liquid cooling loop is not present on a desk. Without auxiliary cooling, sustained workloads can hit limits sooner—different symptom than a network bug.
Q Could anyone just SSH into the unit?
A No. The SSH service was present, but access still depended on Tesla-signed credentials.
Q Why not just test on a real car?
A Bench testing is safer, easier to probe, and reduces the risk of disabling a working vehicle during low-level experiments.
Q Is the bench system actually usable?
A Yes. It boots into Tesla OS and allows practical UI and network-surface exploration for research workflows.
