BIPI
BIPI

Automotive CAN Bus Security: Pentesting Vehicle Networks Without Bricking the Car

Cybersecurity

Controller Area Network is a 1986 protocol still running safety-critical systems in every modern vehicle. A methodology for responsible CAN bus assessment, fuzzing, and attack simulation.

By Arjun Raghavan, Security & Systems Lead, BIPI · June 6, 2025 · 12 min read

#automotive-security#can-bus#ics#ot-security#embedded

Every passenger vehicle sold since 2008 in the US and 2001 in Europe has an OBD-II port that connects directly to one or more CAN buses. The same bus that reports engine RPM to the dashboard carries brake actuator commands and airbag deployment signals. CAN has no authentication, no encryption, and no source validation.

CAN Bus Fundamentals for Security Testers

CAN is a multi-master broadcast bus. Any node can send any arbitration ID at any time. Priority is determined by the arbitration ID — lower ID wins bus contention. A node that loses contention backs off and retries. An attacker on the bus can win every arbitration by continuously sending ID 0x000. This is a denial-of-service vector that stops all other nodes from transmitting.

Lab Setup

  • OBD-II to USB adapter with candump/cansend support (ELM327 is passive-only; use Peak PCAN-USB or Canable for active testing).
  • Raspberry Pi running SocketCAN — socketcan kernel module, ip link set can0 up type can bitrate 500000.
  • Python-can library for scripted message injection.
  • ICSim (Instrument Cluster Simulator) for safe lab practice without a real vehicle.
  • Kayak or SavvyCAN for graphical CAN traffic analysis.

Passive Reconnaissance

Record 60 seconds of idle traffic with candump -l can0. Open in SavvyCAN. Sort by frequency: engine and transmission messages arrive at 10–100 ms intervals. Body messages (lights, locks) arrive at 100–500 ms. Infotainment may be on a separate high-speed CAN or a LIN sub-bus. Identify messages that change when you press the lock button, honk, or adjust the mirror. These are your control message candidates.

CAN bus pentesting without a proper lab environment has caused real accidents. Always work on stationary vehicles with wheels chocked, handbrake set, and a second engineer ready to disconnect the OBD-II dongle.

Replay and Fuzzing

Replay a captured lock sequence: cansend can0 182#0000000000000001. Observe whether the vehicle responds. If it does, you have identified the lock arbitration ID and data pattern. Fuzzing follows: iterate over all 2048 standard IDs (or 536 million extended IDs) with randomised data bytes. In the lab, watch for dashboard indicator changes, actuator movement, or error frames. Document every ID that produces an observable effect.

UDS and Diagnostic Attacks

Unified Diagnostic Services (ISO 14229) runs over CAN and allows ECU programming, security seed challenges, and fault code clearing. Many ECUs accept UDS session requests without any authentication in engineering mode (session type 0x03). Test for: reading VIN and calibration data (service 0x22), clearing DTCs (0x14), and attempting ECU flashing sequences (0x34/0x36/0x37).

0
Authentication mechanisms in baseline CAN 2.0 specification
150+
ECUs in a modern premium vehicle all sharing bus access
2ms
Typical CAN message cycle time for safety-critical brake systems

Remote Attack Surfaces

The Jeep Cherokee hack in 2015 reached the CAN bus via a cellular modem on the infotainment unit. Modern attack paths include: Bluetooth stack in the head unit, V2X (DSRC/C-V2X) radio, cellular telematics unit, and EV charging protocol (ISO 15118 runs over Ethernet but bridges to CAN). Each of these is a potential entry point that must be scoped in any automotive security assessment.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.