Unleashing the Power of My 20+ Years Old Car

Unleashing the Power of My 20+ Years Old Car: ECU Reverse Engineering and Automotive Control Modification

**Overview**

Tinydot, a French automotive security researcher at White Motion (an automotive cybersecurity firm), presents a case study in reverse engineering and modifying the Engine Control Unit (ECU) of a ~20-year-old performance car. The goal: enable a custom infotainment system and unlock the car's performance potential. Because the car predates modern OBD-II CAN bus protocols, the researcher had to reverse-engineer the proprietary communication protocol, dump the ECU firmware, analyze the binary, identify control maps, and build tools to read and modify engine parameters. This talk demonstrates both the practical techniques for automotive reverse engineering (binary analysis, map identification, protocol documentation) and the underlying architecture of older ECU systems. While framed as a personal project, the research illuminates how firmware extraction, reverse engineering, and parameter modification are accessible to motivated researchers with basic electronics knowledge and reverse engineering skills—raising security implications for modern vehicles.

**Technical Details**

Automotive ECU Communication and Protocols:

1. **OBD Port and Protocol Selection**: - OBD-II port (On-Board Diagnostics): Standardized port under steering wheel with specific pin assignments - Manufacturer-specific protocols: Pins 12-13 on this car's port indicate manufacturer-specific protocol, not standard OBD-II CAN - XSM protocol: Manufacturer-specific protocol (XSM 1, 2, 3, 4 versions exist); XSM 4 in modern vehicles, this car uses XSM 1 - Prior documentation: Researcher found existing reverse-engineered protocol documentation online (credit to "Phil"), avoiding duplication of effort

2. **XSM 1 Protocol Characteristics**: - Serial protocol running at ~2000 baud rate - 5-volt TTL logic (requires level converter for 3.3V interfaces) - Minimal command set: read, write, get ROM ID, stop - Behavior: Devices flood responses until explicitly told to stop - Simple hardware requirements: RX, TX, ground, and level converter (~$15 total)

3. **XSM Protocol Command Structure**: - Read command: Specify address (most significant byte, least significant byte), get value (typically 1 byte) - Write command: Modify values at specific addresses - ROM ID: Identify firmware/hardware revision - Stop: Cease streaming responses - Memory-mapped interface: All ECU functions are memory-mapped; engine parameters are bytes in memory at specific addresses

4. **Firmware Extraction**: - ECU size: 64 kilobyte of firmware (0x0000 to 0xFFFF address range) - Extraction method: Sequential reads of each byte address - Extraction rate: ~5 bytes per second (limited by ECU response frequency, not baud rate) - Duration: ~9 hours to dump full ECU (64K bytes × 2 reads for verification) - Bottleneck: ECU firmware only responds to requests at certain frequency, not after each individual request

5. **ECU Hardware Architecture**: - CPU: Mitsubishi M37 series (7770 family) - Memory: Read-only firmware (ROM) - Immobilizer chip: Separate security component - Secondary chip: Additional processor or coprocessor - Contact strip: For physically switching between firmware versions via solder/resistor modification (update mechanism for read-only firmware) - Characteristics: 20-year-old ECU showing excellent preservation despite age; fully functional without degradation

6. **M37 Architecture Challenges**: - M flag: Mode flag that changes instruction decoding at runtime - M=0: Instructions are 3 bytes each - M=1: Instructions are 4 bytes each - Disassembly complexity: Incorrect M flag value causes catastrophic disassembly failure (all subsequent instructions misaligned) - Reverse engineering impact: Must correctly identify M flag state to successfully disassemble firmware

7. **Firmware Structure and Content**: - Non-code data: Linear data patterns indicate maps rather than code - Maps identified: Ignition maps, advance maps, fuel maps, load maps - Map structure: Two-dimensional arrays with RPM as one axis, engine load as another axis - Map values: Determine ignition timing, fuel mixture ratio, and other engine parameters - Identification technique: Look for linear/grid patterns in hex data; find cross-references to these data blobs in code; verify with IDA Pro

8. **Reverse Engineering Process**: - Step 1: Convert entire 64KB firmware to disassembly in IDA Pro - Step 2: Identify map data (linear patterns, two-dimensional grid structure) - Step 3: Find code cross-references to map data; those functions use the maps - Step 4: Reverse engineer functions that reference maps to understand engine control logic - Step 5: Build Python representations of maps for analysis and modification

9. **Engine Control Maps**: - Ignition map: Determines spark timing based on RPM and load - Advance map: Determines ignition advance timing - Fuel map: Determines fuel quantity for given RPM and load - Load calculation: Derived from sensor readings, often manifold absolute pressure - Parameter encoding: Single bytes with transformation functions (e.g., multiply by 25 to get RPM value)

10. **Infotainment System Integration**: - Hardware: 7-inch touchscreen connected to Tinkerboard - Data source: Queries ECU via XSM protocol for engine parameters - Parameters monitored: RPM, speed, coolant temperature - Features: Data logging, alarm systems, GPS tracking, track recreation - Benefits: Enable precise performance tuning, track analysis (corner speed comparison across runs), real-time engine monitoring

**Defense & Takeaways**

Securing automotive ECU against unauthorized access and modification: (1) Modern protocols vs legacy—newer vehicles use CAN bus with encryption and authentication; older vehicles use simple serial protocols with no security; assess which model vehicles use before deploying them in security-sensitive roles; (2) Protocol documentation—don't assume proprietary protocols are secure due to obscurity; automotive security research has made many protocols publicly known; assume any protocol has been analyzed; (3) Firmware extraction prevention—implement mechanisms preventing arbitrary memory reads (authentication, access restrictions); simple sequential read access enables full firmware extraction; (4) Physical security—ECU physically accessible under dashboard; restrict physical access if preventing firmware modification critical; implement tamper detection; (5) Encrypted firmware—store sensitive parameters encrypted in firmware; prevent attackers from directly reading and modifying values; require authentication to unlock encryption; (6) Code signing—sign firmware with manufacturer keys; prevent loading of modified code even if extraction possible; require firmware updates to be signed; (7) Secure boot—verify firmware integrity before execution; prevent execution of modified firmware; implement immutable root of trust; (8) Memory protection—use memory protection features to prevent unauthorized reads/writes; restrict which addresses can be accessed without authentication; (9) Rate limiting—slow down firmware extraction by limiting response frequency; current implementations enable extraction in hours; raise cost to prohibitive levels; (10) Anomaly detection—monitor for unusual access patterns (sequential address reads, high-frequency queries); alert on suspicious behavior; (11) Immobilizer integration—link engine control to immobilizer; prevent starting even if ECU modified without proper authorization sequence; (12) Telemetry monitoring—detect performance anomalies suggesting ECU modification; compare against known baseline parameters; alert on deviations; (13) Update mechanisms—provide secure mechanism for authorized ECU updates; prevent unsafe modifications via encrypted/authenticated firmware updates; (14) Vendor communication—document known vulnerabilities in older protocols; warn users of older vehicles about reverse engineering risk; provide firmware updates when practical; (15) Architecture modernization—transition vehicles to protocols with authentication and encryption; design new ECUs with security from the start. The critical insight: Automotive security in older vehicles relies largely on obscurity and physical access difficulty. This research demonstrates that with modest hardware (~$15), basic electronics knowledge, and reverse engineering skills, an attacker can extract firmware, analyze it, identify control parameters, and modify ECU behavior. Modern vehicles address this through encrypted protocols, firmware signing, and secure boot—but millions of older vehicles remain vulnerable. As vehicles remain in service for 20+ years, their security characteristics matter throughout their lifecycle. The accessibility of these techniques—no sophisticated tools required, all documentation and examples available online—means that ECU modification is within reach of enthusiasts and adversaries alike. Automotive OEMs must balance enablement of legitimate research and modification (right to repair) against preventing unsafe modifications (safety-critical parameter changes). Future protocols must provide security without completely preventing authorized analysis and tuning.