Skill: Automotive & Vehicle Security

Supplementary Files:

• payloads.md — Command catalogue for SocketCAN setup, can-utils (candump/cansend/cansniffer), cantools DBC reversing, CAN-FD, UDS (ISO 14229) enumeration, KWP2000, OBD-II PIDs, ECU firmware extraction, IVI pentest (Android Automotive/QNX), CANToolz framework, Scapy automotive (XCP/UDS/GMLAN), key fob replay/relay (HackRF/Flipper), GNSS spoofing, EV charging (ISO 15118 V2G/PLC), CAN injection methodology, and CAN-IDS detection — 18 sections with real CLI flags and incident references (Jeep 2015, Tesla 2017, BMW, VW, UK CAN injection thefts).
• test-cases.md — Structured test cases (SocketCAN lab bring-up, passive CAN sniffing, DBC reversing, UDS enumeration, CAN-FD capture, CANToolz analysis, IVI recon, OBD-II PID readout, rolling-code capture, GNSS spoofing PoC, ISO 15118 fuzzing, CAN-IDS tuning) — 12 cases across 6 categories.
• guides/automotive-vehicle-security-playbook.md — End-to-end red team playbook: bus recon → DBC reverse → UDS enum → ECU compromise → physical-effect validation. Includes CAN architecture refresher, automotive lab build (virtual + hardware tiers), CAN bus reverse engineering methodology, key fob attack workflow (rolling code + PKES relay), real-world incident case studies, and legal/ethical considerations.
• guides/automotive-ecu-firmware-and-uds-deep-dive.md — Deep dive on ECU firmware extraction (boot mode, JTAG, NAND/eMMC desoldering, OTA package parsing, UDS 0x34/0x36 dump) and the full UDS service matrix (0x10-0x3E) with security access (0x27) seed-key analysis, routine control (0x31), ECU programming (0x34/0x36/0x37), firmware update attacks, secure boot bypass attempts, and signature verification analysis.

Summary

Automotive & vehicle security skill domain covering CAN (ISO 11898) / CAN-FD bus analysis, UDS (ISO 14229-1) diagnostic exploitation, OBD-II (ISO 15031) PID enumeration, in-vehicle infotainment (IVI) pentest of Android Automotive / QNX / automotive Linux, key fob rolling-code and PKES relay attacks, GNSS spoofing of connected navigation/ADAS, and EV charging station attacks against ISO 15118 Vehicle-to-Grid (V2G) Plug & Charge. The skill spans the full vehicle attack surface: from physical OBD-II port through internal CAN buses to telematics control units (TCU), the cloud-connected back-end, and the consumer mobile companion app.

Tools: can-utils (candump/cansend/cansniffer), python-can, cantools (DBC), Savvy-CAN, GVRET, CANToolz, Scapy automotive layer, OpenXC, CANBadger, Macchina M2, USBTin, Kaya CAN-USB, HackRF One (key fob RF)

Domain: automotive

MITRE ATT&CK: TA0001-Initial Access (OBD-II/TCU entry), TA0040-Detection (CAN-IDS evasion), T1557-Adversary-in-the-Middle (relay, GNSS spoofing), T1557.001-LLMNR/NBT-NS (vehicle V2G MiTM), T1530-Data from Information Repositories (firmware/DBC)

Description

Modern vehicles are networks on wheels. A 2025-era mid-segment car contains 70–150 Electronic Control Units (ECUs) interconnected by 3–8 CAN buses (powertrain, chassis, body, infotainment, ADAS, gateway), supplemented by LIN for low-cost body nodes, FlexRay for drive-by-wire, and MOST/FD for infotainment multimedia. The gateway ECU arbitrates inter-bus traffic; the Telematic Control Unit (TCU) provides the cellular/Wi-Fi uplink. Every rolling chassis is therefore an OT network with a routable path to the public internet through its TCU — and every ECU on it was designed for the deterministic world of CAN, not for adversarial input. This skill covers the exploitation of that stack.

The defining properties of the automotive threat model are:

1. CAN has no authentication, no encryption, and no source identifier. ISO 11898 specifies a broadcast multi-master bus: any ECU can transmit any CAN identifier (arbitration ID) at any time, and every other ECU receives every frame. There is no sender address, no signature, and no replay protection. The bus is secured by physical access to the wires — and the OBD-II port mandated since 2008 (US EPA, EU EOBD) is a standardized physical entry point. Once an attacker has bus write access — via the OBD-II port, a compromised TCU, or a telematics app vulnerability — they can inject any CAN frame and any ECU will act on it. The Jeep Cherokee hack (Miller & Valasek, DEF CON 23, 2015) demonstrated remote CAN injection through the Uconnect head unit: brakes, steering, transmission, at highway speed.

2. UDS (ISO 14229-1) is the management plane, and it's almost always enabled in production. Unified Diagnostic Services is the diagnostic protocol mechanics use for fault codes, ECU flashing, and component initialization. It runs over CAN (ISO 15765-3 / DoCAN) or K-Line (ISO 14230 / KWP2000) and exposes 26 service IDs (0x10 DiagnosticSessionControl through 0x3E TesterPresent). Service 0x27 SecurityAccess lets you unlock privileged modes — firmware upload (0x34/0x36/0x37), ECU reset (0x11), routine activation (0x31), and read-memory-by-address (0x23). Many production ECUs ship with UDS enabled and with weak or seed-only security. A successful 0x27 brute-force or seed-reuse attack leads to arbitrary memory read/write on the ECU — the canonical pre-exploitation step before CAN injection.

3. DBC files are the rosetta stone of the vehicle bus. A .dbc file maps each CAN arbitration ID to its constituent signals (e.g., ID 0x201 = EngineRPM bits 0-15, ThrottlePosition bits 16-23). The OEM's proprietary DBC is typically extracted from: leaked firmware images, ECU calibration files (WinOLS/Bosch), or by side-channel correlation (capture CAN while physically changing a known state — depress the brake pedal, decode which bits changed). Reverse a DBC and you have the write-semantics of every controllable actuator on the vehicle.

4. The IVI is an attack pivot, not just a target. Android Automotive, QNX, or MontaVista-based head units run full Linux/Android stacks with cellular modems, Wi-Fi, Bluetooth, GPS, USB, and a CAN connection to the vehicle bus. A single IVI RCE gives the attacker a remote, internet-facing foothold directly on the CAN bus. The Jeep Cherokee (2015), Tesla Model S (Tencent Keen Lab, 2017), BMW ConnectedDrive (2015), and multiple modern EVs all share this architecture. IVI pentest is web/mobile pentest with a CAN bus as the prize.

5. The TCU is the remote compromise path. The telematics unit is the only ECU with a routable internet connection, which makes it the highest-value remote target. Attack paths: cellular modem RCE, OTA update mechanism abuse, MQTT/HTTPS API compromise of the OEM's cloud, supply-chain compromise of third-party apps (Uber, Spotify, etc. running on the IVI), or — as in the 2015 Jeep — the cellular network SSH/telenet debug interface left open.

6. Keyless entry (PKES / passive keyless entry and start) is broken by relay. Modern key fobs wake when they receive a Low-Frequency (125 kHz) challenge from the vehicle, then respond on UHF (433/868 MHz). The Tesla/BMW/Audi PKES design is vulnerable to a two-thief relay attack: one stands at the fob (outside the restaurant), one stands at the car (driveway); the LF challenge is relayed from car to fob, the UHF response relayed from fob to car; vehicle unlocks and starts. Rolling-code 433 MHz remotes (older designs, garage doors, aftermarket alarms) are vulnerable to RollJam/RollBack captures with HackRF or a Flipper Zero. Both classes of attack have produced real-world vehicle thefts across the UK (2023, Khan/Sullivan), Europe, and the US.

7. GNSS spoofing is cheap and effective against connected vehicles. With a HackRF One and an external antenna, an attacker can broadcast a forged GPS L1 C/A signal that overpowers the genuine signal (the receiver locks to the strongest PRN). The result: arbitrary position/time drift, navigation redirected, and — critically for ADAS Level 2/3 — geofenced features disabled or enabled inappropriately. Tesla Autopilot, Mercedes Drive Pilot, and commercial fleet telematics all trust GNSS position to some degree.

8. ISO 15118 (Vehicle-to-Grid) is the new EV attack surface. Modern EVs and DC fast chargers (CCS / CharIN) use Power Line Communication (PLC) for the charging interface, with ISO 15118-20 mandating TLS and Plug & Charge (PnC) certificates. Vulnerabilities in certificate handling, Exi (Efficient XML Interchange) parsing, or the TLS stack itself allow billing fraud, charging disruption, or — in extreme cases — battery/BMS manipulation.

Difference from iot-pentest: IoT-pentest covers consumer/industrial smart devices (MQTT, CoAP, AWS IoT). Automotive-vehicle-security covers vehicle-specific buses (CAN/CAN-FD/LIN/FlexRay), vehicle-specific protocols (UDS, KWP2000, OBD-II, ISO 15118), and the vehicle threat model (60+ ECUs on a deterministic broadcast bus with no authentication). The overlap is the TCU's MQTT/HTTPS cloud back-end — automotive covers the vehicle side, iot-pentest covers the cloud side.

Difference from sdr-rf-attack: SDR covers the general RF signal layer (capture, demodulate, replay 433/868 MHz, ADS-B, AIS). Automotive-vehicle-security applies SDR techniques specifically to key fob rolling code, PKES relay amplification, GNSS spoofing (GPS L1, Galileo E1, BeiDou B1I), and the V2X DSRC/IEEE 802.11p spectrum.

Difference from hardware-security: Hardware-security covers generic chip-level attacks (JTAG/UART/SWD/glitching/power analysis). Automotive-vehicle-security applies those techniques to ECUs (boot mode pin strap, NAND readout, JTAG over the diagnostic connector) and adds the bus-protocol layer on top.

Difference from binary-reverse: Binary-reverse covers general disassembly/decompilation (Ghidra/IDA/BinaryNinja). Automotive-vehicle-security applies binary-reverse to ECU firmware (MPC5xxx, RH850, ARM Cortex-R), with automotive-specific concerns: calibration data (WinOLS/A2L files), DBC recovery, UDS service identification, and secure-boot bypass.

Difference from scada-ics-security: SCADA covers industrial control protocols (Modbus, DNP3, S7comm, OPC UA). Automotive covers vehicle protocols (CAN, UDS, KWP2000, LIN, FlexRay). The architectural overlap is minimal but the methodology (deterministic bus, broadcast medium, no authentication) is identical.

Difference from mobile-security: Mobile covers iOS/Android apps generally. Automotive covers Android Automotive OS (AAOS), QNX, and the in-vehicle app ecosystem with the additional surface of the CAN bus pivot.

Use Cases

• Pre-engagement vehicle security audit: Given a target vehicle (or a fleet), map its full attack surface: OBD-II diagnostic port, internal CAN bus topology, UDS-exposed services per ECU, IVI/TCU remote attack surface, key fob RF profile, and OEM cloud connectivity — before an adversary does.
• CAN bus reverse engineering: From a captured CAN trace (candump) and/or an extracted DBC, decode every signal on the bus: engine RPM, throttle, brake pressure, steering angle, gear, speed. Produce a working DBC the red team can use to craft injection frames.
• UDS enumeration and exploitation: Walk every ECU on the diagnostic bus, enumerate UDS services (0x10-0x3E), test 0x27 SecurityAccess seed/key, attempt firmware readout (0x23 ReadDataByIdentifier / 0x34-0x37 RequestDownload/Transfer/Exit), and document any ECU that accepts unauthenticated privileged services.
• IVI / head unit pentest: Treat the Android Automotive / QNX head unit as a mobile device with a cellular modem and a CAN pivot. Test: OTA update signature validation, Bluetooth/Wi-Fi pairing, USB attack surface, web browser sandboxing, and the IVI-to-CAN gateway ECU's filtering rules.
• Keyless entry attack: Capture and replay a 433 MHz rolling-code key fob (HackRF/Flipper), or perform a PKES relay attack against a Tesla / BMW / Audi / Mercedes. Document time-to-unlock, range, and detection footprint.
• GNSS spoofing PoC (lab / closed-course only): Demonstrate position drift, time drift, or geofence bypass on a target vehicle's navigation and ADAS subsystem using a HackRF-based GPS L1 spoofer.
• EV charging station (ISO 15118) assessment: Capture PLC V2G traffic between a CCS vehicle and a DC fast charger, test the TLS/Plug & Charge certificate handling, fuzz the Exi message decoder, and document billing/authentication bypass findings.
• Connected vehicle red team: Combine multiple vectors (TCU cellular RCE → IVI app pivot → CAN injection → physical effect) into a full kill-chain demonstration, following the methodology established by Miller & Valasek (Jeep, 2015) and Tencent Keen Lab (Tesla, 2017).

Core Tools

Bus Analysis & Sniffing

Tool	Purpose	Command Example
can-utils (Linux Foundation)	Reference SocketCAN userland: candump, cansend, cansniffer, cangen	candump -L can0 (timestamped capture)
python-can	Python library for SocketCAN / Kvaser / Vector / PCAN / serial	python-can.interfaces.socketcan.SocketcanBus(interface='can0')
cantools (Python)	DBC file parse, encode/decode, plot, replay	cantools decode dbc.dbc frame.data
Savvy-CAN (Collin Kidder)	Cross-platform GUI: live trace, DBC editing, frame graphing, replay, send	Savvy-CAN GUI (Qt)
GVRET / ESP32-CAN-Transceiver	Open-source CAN sniffing firmware (Comma.ai compatible)	Serial over USB, used with Savvy-CAN

Hardware Interfaces

Tool	Purpose	Command Example
CANBadger (Wolf Goats)	Purpose-built CAN attack tool (ESP32, 2x CAN, Ethernet)	CANBadger web UI / scripts
Macchina M2 / mk2	Open-source automotive dev board (Arduino-based, CAN/LIN)	Arduino sketch with CAN library
USBTin	Affordable CAN-USB adapter (~$50) for SocketCAN	slcand -o /dev/ttyACM0 -s 500000 can0
Kaya CAN-USB / Kvaser / PCAN-USB / Vector VN1630	Commercial CAN interfaces (OEM-grade)	Vendor driver → SocketCAN

Frameworks & Protocol Layers

Tool	Purpose	Command Example
CANToolz (eik00d, Black Hat EU 2016)	Black-box CAN analysis framework (fuzz, send, mine)	cantoolz -c can0 -b 500000
Scapy automotive	Scapy with UDS, ISO-TP, GMLAN, XCP layers	sr1(UDS()/UDS_DiagnosticSessionControl(...))
OpenXC (Ford)	Reference platform for vehicle data APIs (mobile/VI)	openxc-hardware + openxc-python

Methodology

Five-Phase Automotive Red Team Workflow

Phase 1           Phase 2           Phase 3            Phase 4            Phase 5
Recon & Setup  →  Bus Sniffing   →  Protocol Reversing→  ECU Compromise →  Physical Effect
(OBD-II pinout,   (candump,         (DBC decode,        (UDS enum,          (replay, injection,
 hardware bringup, cansniffer,       ISO-TP/UDS,         0x27 seed/key,      brake / steer /
 IVI surface)      python-can)       KWP2000)            firmware readout)   dashboard PoC)
   │                 │                 │                   │                   │
   ▼                 ▼                 ▼                   ▼                   ▼
 Pin 6/14 CAN-H/L,  Passive trace     DBC from leak or   UDS service map,    Replay captured
 ground, OBD-II     over test drive,  side-channel       0x27 brute/reuse,   actuator frames,
 adapter bringup,   identify ECUs,    correlation        boot mode, NAND     fuzz arbitration
 IVI recon          ISO-TP discovery  (depress pedal →   readout              IDs, safety-
                    on 0x7DF/0x7E0    signal bits                             critical PoC
                                                                            requires explicit
                                                                            authorization

Phase 1: Recon & Setup — Bring up the hardware and map the physical/IVI attack surface. Identify OBD-II pinout (CAN-H pin 6, CAN-L pin 14, GND pin 4/5, 12V pin 16). Bring up a SocketCAN interface (slcand for USBTin; kernel driver for Kvaser/PCAN; ip link set can0 type can bitrate 500000). Probe the IVI: enumerate Bluetooth (BD_ADDR, services), Wi-Fi (hidden SSIDs), USB (ECU reflash modes), and the head-unit's app catalogue (Android Automotive intents, QNX resource manager nodes).

Phase 2: Bus Sniffing — Passive capture only; never transmit on a vehicle bus without explicit authorization. Standard workflow: candump -L can0 > trace.asc (ASC format for Vector compatibility); cansniffer -c can0 (live per-arbitration-ID view showing which IDs are changing). Identify ECU tiers by arbitration ID range (SAE J1939 PGN ranges; ISO 11783 agricultural; standard 11-bit vs extended 29-bit IDs). Probe ISO-TP / UDS on the functional address 0x7DF and each physical address 0x7E0-0x7E7.

Phase 3: Protocol Reversing — Turn raw CAN IDs into named signals. Start with any leaked/extracted DBC (open-source DBCs for some Tesla/Hyundai/Kia/Nissan models on GitHub; OpenDBC project by Comma.ai). If no DBC exists, perform side-channel correlation: capture CAN while manipulating a single known state (key on, brake depressed, steering at 0°, then 90°), diff the bus to identify which bits in which arbitration IDs changed. Decode ISO-TP multi-frame messages with isotp_send/isotp_recv. Identify UDS service support per ECU via the 0x22 (ReadDataByIdentifier) calls.

Phase 4: ECU Compromise — Walk the UDS service matrix per ECU. Enumerate 0x10 DiagnosticSessionControl (default 0x01, programming 0x02, extended 0x03). Probe 0x27 SecurityAccess (request seed on subfunction 0x01, send key on 0x02). Brute-force weak seed/key implementations (often 16-bit seed, 24-bit key, deterministic XOR/LFSR). On successful 0x27, attempt 0x23 ReadMemoryByAddress, 0x34 RequestDownload, 0x36 TransferData to read out firmware. Boot-mode extraction via ECU-specific pin strap (e.g., MPC5xxx BOOTS signal, RH850 debug-mode strap). NAND readout via desoldering / JTAG (see hardware-security).

Phase 5: Physical Effect Validation — With the DBC decoded and UDS mapped, demonstrate a CAN injection that produces a measurable physical effect. Standard demo vectors (with explicit authorization, on a closed course, with a safety driver): instrument cluster spoofing (RPM, speedo), steering-wheel button injection (volume up), body control (lights, wipers), brake/steering at speed (the Miller-Valasek Jeep vector — requires a vehicle with the gateway removed or with documented debug access). Every safety-critical injection must be authorized in writing by the vehicle owner and by the OEM. CAN fuzzing: cangen can0 -g 10 -n 1000 to send random frames; CANToolz module-based fuzz for targeted arbitration ID ranges.

Quick Selection Guide

Scenario	Primary Approach	Alternative
CAN-H/CAN-L bring-up	slcand -o /dev/ttyACM0 -s 500000 can0 && ip link set up can0	kernel driver for Kvaser/PCAN
Passive trace	candump -L can0 trace.asc	cansniffer -c can0 (live delta view)
DBC decode	cantools dump dbc.dbc then cantools decode dbc.dbc 0x201#01020304	Savvy-CAN DBC editor
UDS service enum	scapy UDS DiagnosticSessionControl on 0x7E0	python-can + raw ISO-TP
UDS 0x27 brute	Scapy UDS scanner loop	CANToolz fuzz module
OBD-II PID read	cansend can0 7DF#02010F0000000000 (mode 01 PID 0x0F catalyst temp)	Savvy-CAN OBD-II pane
CAN injection	cansend can0 201#01020304	Scapy sendp(...) over SocketCAN
IVI OTA check	adb shell pm list packages + decompile APK with jadx	QNX: ls /proc + memory dump
Key fob capture (433 MHz)	HackRF hackrf_transfer -r fob.cs8 -f 433920000	Flipper Zero SubGHz record
PKES relay	Two Yagi antennas + amplifier, no SDR needed	Custom LF/UHF relay hardware
GNSS spoof	HackRF + GPS-SDR-SIM, replay forged ephemeris	bladeRF / USRP B210
EV V2G capture	PLC sniffer (HomePlug AV2) between CCS port and charger	ISO 15118 test tool from Vector

Defense Perspective

Regulatory & Compliance Layer

Defense Measure	Description
Automotive ISAC (Auto-ISAC)	Industry threat-intel sharing for OEMs and Tier-1s; the canonical clearinghouse for coordinated vulnerability disclosure and IoC sharing. automotiveisac.com
UNECE WP.29 R155 (CSMS)	Mandatory since July 2022 for new vehicle type approvals in UNECE 1958 signatory countries (EU, Japan, Korea, UK). Requires OEMs to operate a CSMS, perform TARA, detect/respond to incidents, and report critical vulnerabilities within 4 months.
UNECE WP.29 R156 (SUMS)	Companion to R155; governs OTA updates. Requires SUMS, update integrity verification, rollback capability, and per-update risk assessment.
ISO/SAE 21434	The automotive SDLC standard. Maps to R155 CSMS requirements; covers TARA, cybersecurity goals, validation, post-development monitoring. Reference framework every OEM audit committee references.
SAE J3061	Predecessor to ISO 21434; still widely cited for the TARA methodology and the vehicle V-model cybersecurity overlay.

In-Vehicle Network Layer

Defense Measure	Description
Gateway ECU filtering	The inter-bus gateway should not route safety-critical messages (brake, steer) from infotainment-side buses to powertrain-side buses. Default-deny inter-bus ACL; explicit allowlist per message ID.
CAN message authentication (AUTOSAR SecOC)	SecOC adds a truncated MAC to each CAN frame, providing freshness and integrity. Adoption slow (5–10% of 2024 production vehicles) but increasing with R155 pressure.
Hardware Security Module (HSM) per ECU	EVITA HSM (light/medium/full) or SHE (Secure Hardware Extension) on each safety-critical ECU. Stores keys, performs MAC, protects secure boot. Required for SecOC.
UDS 0x27 hardening	Per-ECU unique seed/key with strong PRNG; rate-limit 0x27; lock in default session; disable on production ECUs where possible (move to JTAG/boot-mode only).
CAN-IDS	Per-ECU or gateway-resident IDS flagging: new arbitration IDs, out-of-range signal values, message-rate anomalies, UDS anomalies. Vendors: Karamba, GuardKnox, Towersec (HP), Argus (now NXP). Forward events to OEM SOC via TCU.

External Interface Layer

Defense Measure	Description
Telematics segmentation	The TCU's cellular interface must be in a separate security domain from the CAN backbone; inter-domain traffic flows through an automotive firewall with DPI on ISO-TP/UDS/SOME-IP.
PKES relay mitigation	Time-of-flight ranging on UHF response (impossible to relay without detectable latency); motion sensors in the fob (sleep when stationary); multi-band challenges (LF + BLE + UWB ranging). Modern BMW/Audi moved to UWB (IEEE 802.15.4z) for this reason.

Practical Steps

Detailed payloads in payloads.md, complete test checklist in test-cases.md.

Exercise 1: SocketCAN + can-utils Bring-up on Linux

Goal: bring up a SocketCAN interface on Kali Linux and capture live CAN frames from a bench ECU or a vircar virtual CAN simulator.

# 1. Install can-utils (Linux Foundation reference SocketCAN userland)
sudo apt-get install -y can-utils
# verify
candump --version

# 2a. Option A: Real hardware via USBTin (~$50 USB-to-CAN adapter)
#    slcand creates a SocketCAN interface from a serial CAN adapter
sudo slcand -o /dev/ttyACM0 -s 500000 -S 500000 can0
sudo ip link set up can0
ip -details link show can0
#   can0: <NOARP,UP,LOWER_UP> mtu 16 qdisc ...

# 2b. Option B: Virtual CAN (no hardware, lab-only) — great for learning
sudo modprobe vcan
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0

# 3. Passive capture (timestamped, ASC format for Vector compatibility)
candump -L vcan0 > trace.asc &
CANDUMP_PID=$!