What CAN Injection Exposes in Connected Vehicles

By Reuel Magistrado, Automotive Threat Researcher   
 
In today’s connected vehicles, the tools of a car theft are no longer limited to crowbars or key duplicators. Attackers are now using laptops and code to exploit weaknesses in vehicle networks. One such method, known as Controller Area Network (CAN) injection, allows them to mimic legitimate commands sent between electronic control units (ECUs) — enabling unauthorized actions such as unlocking doors, opening windows, and, in some cases, driving away with the car. 

To explore this in a safe, controlled way, VicOne’s threat research team recently joined the SPIRITCYBER Automotive Capture the Flag (CTF) competition at the Singapore International Cyber Week (SICW) 2025. This event challenged participants to simulate real-world attacks on virtualized automotive systems. Our goal wasn’t simply to “hack” a vehicle, but to highlight why these vulnerabilities persist, and how automotive engineers can design more robust systems to prevent them. 

CAN injection at a glance 

Modern vehicles rely on dozens or even hundreds of ECUs that communicate via in-vehicle networks. Among these, the CAN bus remains one of the most widely used because it’s fast, reliable, and cost-effective.  

However, the CAN bus was designed in the 1980s, long before cybersecurity became a design priority. It lacks message authentication, encryption, and source addressing. This means that anyone who gains access to the bus — whether physically through the on-board diagnostics (OBD-II) port or logically via a compromised ECU — can inject crafted messages that impersonate legitimate ones. 

This weakness forms the basis of what’s known as CAN injection, a technique that has been observed in real-world car thefts. Criminals exploit diagnostic access points or exposed wiring to send fake signals that unlock a vehicle and even control its critical systems. 

To demonstrate how this happens, our team tackled the “Time to Drive” challenge at SPIRITCYBER’s Automotive CTF, a safe simulation designed to expose and understand these same weaknesses. 

Demonstrating CAN injection at the CTF challenge 

Setup 

The challenge recreated an in-vehicle network using real hardware and software components:  

• Resistant Automotive Miniature Network (RAMN) board: A training platform with multiple ECUs controlling steering, pedals, and gear selection 
• CARLA simulator: An open-source autonomous driving simulator 
• peakCAN adapter: Hardware interface for connecting to the CAN bus 
• Direct CANH and CANL access: Physical connections to emulate real wiring 

The simulated vehicle continuously transmitted CAN messages as it drove on autopilot, simulating typical ECU traffic in a real car. 

Phase 1: Observing CAN traffic 

We first established a CAN interface on Kali Linux:  

# Configure CAN interface with standard 500 kbps bitrate 

sudo ip link set can0 up type can bitrate 500000 && sudo ip link set can0 up 

# Verify connection by capturing live traffic 

candump can0 

By observing the traffic output and correlating it with physical inputs on the RAMN board, we mapped specific CAN IDs and payloads to each vehicle function.

Table 1. Mapping of CAN message IDs to simulated vehicle functions

Phase 2: Message collision problem 

When we attempted to inject commands using the cansend tool, the vehicle didn’t respond. The autopilot system continuously transmitted its own CAN messages at regular intervals, which overwrote ours before they could take effect. This is known as a message collision, a common issue in CAN attacks where legitimate traffic dominates the bus. 

Without the ability to silence the legitimate ECUs, our injected messages were lost in the traffic. We needed a solution to “mute” the active ECUs so our commands could take effect. 

Phase 3: Exploiting diagnostic services 

The solution required using Unified Diagnostic Services (UDS), a standardized protocol for vehicle diagnostics that allows external testers to execute custom routines on ECUs. 

Using the Routine Control (0x31) service, we discovered that running Routine ID 0x0200 could stop the following ECUs from transmitting their periodic messages, providing us the opening we needed: 
 

• ECU B - steering, brakes, lighting; receives on 0x7e1, transmits on 0x7e9
• ECU C - accelerator, gear, horn; receives on 0x7e2, transmits on 0x7ea 

We used the isotpsend tool to send UDS commands over ISO-TP (ISO 15765-2), the transport protocol for diagnostic services: 

# Stop ECU B from transmitting 

echo "31 01 02 00" | isotpsend -s 7e1 -d 7e9 -l can0 

# Stop ECU C from transmitting 

echo "31 01 02 00" | isotpsend -s 7e2 -d 7ea -l can0 

After sending these commands, the periodic CAN traffic from both ECUs stopped. The autopilot was disabled, and we had complete control of the vehicle. 

Phase 4: Manual vehicle control 

With the autopilot silenced, we created a bash script to send custom CAN commands for engine control, gear selection, acceleration, braking, and steering. From there, we successfully completed a full simulated lap in the CARLA environment and captured the flag: SICW_CAR{drive_by_two_wires} — a nod to the two wires, CANH and CANL, that form the CAN differential signaling system. 

Figure 1. The author, pictured during the SPIRITCYBER Automotive CTF’s “Time to Drive” challenge

Real-world cybersecurity implications 

This automotive CTF challenge mirrors actual attack vectors that exist in production vehicles: 

• Diagnostic service abuse. Exploitation doesn’t always require automotive zero-day vulnerabilities. An attacker with access to the OBD-II port or other diagnostic interfaces can use legitimate UDS commands to alter ECU behavior. 
• Message injection. Once legitimate ECU communication is disrupted, forged CAN messages can assume control of critical vehicle functions. This is similar to how researchers have demonstrated steering and braking manipulation in controlled environments. 
• CAN lacks built-in authentication. At its core, CAN assumes every message on the bus is trusted. It provides no message-level authentication to verify that a signal truly originates from a specific ECU. Any device on the network can impersonate another, with no built-in verification mechanism. 

Security takeaways for the automotive industry 

The SPIRITCYBER Automotive CTF served as a small-scale version of what real attackers could achieve. Here are key takeaways for car manufacturers (OEMs) and Tier-1 suppliers: 

1. Add message authentication. Incorporate message-level signing or encryption. Even lightweight cryptographic checks, such as CAN with Flexible Data-Rate Security (CAN FD-SEC) or the upcoming MACsec for Automotive Ethernet, can help prevent unauthorized CAN traffic from being accepted. 
2. Enforce network segmentation. Separate safety-critical ECUs, such as braking, steering, and powertrain, from infotainment and telematics domains. A single diagnostic port should not provide access to all vehicle subsystems. Gateway ECUs should also enforce strict filtering rules as to which messages can cross network boundaries. 
3. Deploy real-time anomaly detection. Intrusion detection systems (IDS) that monitor CAN traffic patterns can flag suspicious message rates, unexpected IDs, or abnormal payload structures. Such anomalies often reveal tampering early, before attackers can achieve their objectives. 

Together, these best practices make CAN injection attacks significantly harder to execute. 

Conclusion: Security is a design decision 

CAN injections highlight a simple truth: as vehicles become increasingly software-defined, their attack surfaces also expand. Ethical hacking contests such as the SPIRITCYBER Automotive CTF, the Global Vehicle Cybersecurity Competition, and Pwn2Own Automotive demonstrate how vehicle functionality can easily become a vulnerability if left unprotected. They create safe spaces for security researchers to understand how vulnerabilities emerge — and, more importantly, how to design them out from the start. 

In conclusion, automotive cybersecurity can no longer be treated as an afterthought or a feature added later. It’s a design decision that must be integrated throughout the vehicle’s development lifecycle.