M.ALRASHID
RED TEAMIOTAUTOMOTIVEApril 12, 202512 min read

CAN Bus Hacking: Attacking and Defending the Automotive Backbone

A deep dive into the CAN bus protocol — how it works, why it's vulnerable, and what happens when attackers gain access to the backbone of every modern vehicle.

Every modern vehicle is a network on wheels. Under the dashboard of your car sits a system that connects dozens of electronic control units (ECUs) — engine management, braking, steering, airbags, infotainment — all communicating over a protocol designed in the 1980s with zero authentication. That protocol is the Controller Area Network (CAN) bus, and it is one of the most fascinating attack surfaces in embedded security.

How CAN Bus Works

CAN was designed by Bosch in 1986 for real-time communication between microcontrollers without a host computer. Its design priorities were reliability and speed — not security.

The protocol operates on a shared broadcast bus. Every ECU on the network sees every message. There are no source addresses, no authentication headers, and no encryption. A CAN frame looks like this:

┌─────────────┬─────┬──────────┬─────────────┬─────┐
│ Arbitration │ DLC │   Data   │     CRC     │ ACK │
│   ID (11b)  │(4b) │ (0-64b)  │   (15b)     │(1b) │
└─────────────┴─────┴──────────┴─────────────┴─────┘

The Arbitration ID determines message priority and type — not the sender's identity. Any node on the bus can transmit any ID. There is no concept of "this ECU is authorized to send this message." If you can access the bus, you can speak as any component.

The Attack Surface

Physical Access

The most direct vector is the OBD-II port, a standardized diagnostic connector present in every vehicle manufactured after 1996. It provides direct access to the CAN bus. Plug in a $15 CAN adapter, and you're on the network.

But physical access isn't limited to OBD-II. CAN wiring runs throughout the vehicle — behind door panels, under seats, through the trunk. Any point where you can tap into the twisted pair gives you full bus access.

Remote Vectors

The more dangerous vectors are remote. Modern vehicles bridge the CAN bus to external networks through:

  • Telematics Control Units (TCUs) — cellular modems that connect to OEM cloud services
  • Infotainment head units — running full Linux or Android stacks with Wi-Fi and Bluetooth
  • V2X communication modules — vehicle-to-infrastructure radio interfaces

The infamous 2015 Jeep Cherokee hack by Charlie Miller and Chris Valasek demonstrated this chain: they compromised the infotainment system over the cellular network, pivoted to the CAN bus through a bridged connection, and remotely controlled steering and braking at highway speed.

Practical CAN Bus Attacks

Sniffing and Reverse Engineering

The first step in any CAN bus engagement is passive reconnaissance. Using can-utils on Linux with a compatible adapter:

# Bring up the CAN interface
sudo ip link set can0 type can bitrate 500000
sudo ip link set can0 up
 
# Dump all traffic
candump can0
 
# Output:
# can0  0C1  [8]  00 00 00 00 00 00 1A 0F
# can0  1A4  [8]  00 00 F7 23 00 00 00 00
# can0  2C4  [8]  80 00 00 00 00 00 00 00

The challenge is mapping Arbitration IDs to physical functions. This requires methodical testing — toggle a control (headlights, door locks, turn signal) and correlate the resulting CAN traffic changes.

Replay Attacks

Once you've identified the CAN ID and payload for a specific action, replay is trivial:

# Unlock doors (hypothetical ID and payload)
cansend can0 2C4#8000000000000000

Because CAN has no sequence numbers, timestamps, or authentication, the ECU cannot distinguish a legitimate message from a replayed one.

Injection and Spoofing

More sophisticated attacks involve continuous injection — flooding the bus with spoofed messages at a higher frequency than the legitimate ECU. Because CAN uses bitwise arbitration for priority, an attacker who transmits at the right rate can effectively override the real controller.

A bus-off attack exploits CAN's error-handling mechanism. By deliberately causing transmission errors, an attacker can force a target ECU into the "bus-off" state — effectively disconnecting it from the network. If that ECU controls the ABS, the consequences are severe.

import can
 
bus = can.interface.Bus(channel='can0', bustype='socketcan')
 
# Flood a target arbitration ID to override legitimate messages
spoofed = can.Message(
    arbitration_id=0x1A4,
    data=[0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00],
    is_extended_id=False,
)
 
while True:
    bus.send(spoofed)

UDS Exploitation

The Unified Diagnostic Services (UDS) protocol runs over CAN and is used by dealerships and manufacturers for diagnostics and firmware updates. UDS has security access levels, but implementations are often weak — hardcoded seed-key pairs, predictable algorithms, or keys extracted from leaked service tools.

Gaining UDS security access can allow:

  • Reading and writing ECU memory
  • Flashing modified firmware
  • Disabling safety interlocks
  • Extracting cryptographic keys stored in secure enclaves (when poorly implemented)

Defensive Measures

CAN Bus Intrusion Detection (IDS)

Since CAN lacks native authentication, anomaly-based detection is the primary defense. A CAN IDS monitors for:

  • Timing anomalies — messages arriving faster than expected for a given Arbitration ID
  • Payload deviations — data values outside the normal operational range
  • Bus load spikes — sudden increases in traffic volume indicating injection
  • Missing messages — ECUs that stop transmitting (potential bus-off attack)
# Simplified CAN anomaly detector
def check_message_timing(msg_id: int, timestamp: float) -> bool:
    expected_interval = KNOWN_INTERVALS.get(msg_id)
    if expected_interval is None:
        return True  # Unknown ID — flag as anomalous
 
    last_seen = last_timestamps.get(msg_id, 0.0)
    delta = timestamp - last_seen
    last_timestamps[msg_id] = timestamp
 
    # Flag if message arrives 3x faster than expected
    return delta < (expected_interval * 0.33)

Secure CAN Protocols

The automotive industry has responded with several hardening approaches:

  • CAN-FD with SecOC — the AUTOSAR Secure Onboard Communication specification adds MAC-based authentication to CAN frames. Each message includes a truncated CMAC computed with a pre-shared key, providing integrity and authenticity verification.
  • CAN XL — the next-generation protocol supports larger payloads and is designed with security extensions from the ground up.
  • Gateway ECUs — modern architectures place a security gateway between CAN bus domains, filtering and validating traffic between safety-critical and non-critical segments.

Network Segmentation

The most effective architectural defense is domain isolation. Modern vehicles use multiple CAN buses:

  • Powertrain CAN — engine, transmission, ABS
  • Body CAN — doors, windows, lights
  • Infotainment CAN — head unit, media, navigation

A properly designed gateway ECU ensures that compromising the infotainment bus cannot reach the powertrain bus — the exact failure that made the Jeep Cherokee hack possible.

The Road Ahead

The automotive industry is slowly catching up. ISO/SAE 21434 now mandates cybersecurity engineering throughout the vehicle lifecycle, and UNECE WP.29 requires type-approved vehicles to demonstrate a Cyber Security Management System (CSMS).

But the installed base is massive. There are over a billion vehicles on the road today, most running completely unauthenticated CAN buses with no intrusion detection. The gap between what's rolling off the assembly line and what's already on the highway will persist for decades.

For security researchers, the CAN bus remains one of the most rewarding attack surfaces to study — a protocol where the fundamentals of authentication, integrity, and segmentation are either absent or afterthoughts. Every lesson learned here applies directly to the broader challenge of securing legacy embedded systems in critical infrastructure.

The bus is always listening. The question is whether anyone is watching.

Mohammed Alrashid

Mohammed Alrashid

Security Engineer & Purple Team Specialist at PassiveLogic. Focused on zero-trust infrastructure, GRC, and adversarial security research.

Related_Intel