Understanding CAN Network (CAN bus): Protocol, Fields, and Fuzzing with Penzzer

Why the CAN bus Matters

The Controller Area Network (CAN) is a communication backbone for modern vehicles and a variety of industrial and embedded systems. You interact with CAN daily - whether you're driving a car, using an elevator, or operating heavy machinery. As vehicles become smarter and machines more interconnected, understanding, testing, and securing the CAN bus becomes a critical requirement.

‍

Why Care About CAN Security?

• Attackers can leverage vulnerabilities in CAN-connected devices to alter or disrupt safety-critical functions.
• Security researchers and engineers need robust tools to test CAN implementations, and fuzzing has become a best-practice for finding weaknesses at scale.

In this post we will demystify the technical underpinnings of CAN - down to the fields and values of each message - then show how Penzzer's fuzzing platform elevates CAN security and testing to the next level.

‍

The Origin and Purpose of CAN

What is the CAN bus?

The CAN bus (Controller Area Network) is a serial communication protocol that allows multiple microcontrollers (or "nodes") to talk to each other without the need for a central computer. Developed in the 1980s by Bosch, its primary aim was to enable reliable, real-time communication among components in cars. Before CAN, wiring harnesses were a tangled, heavy mess; with CAN, two wires can carry all necessary messages.

‍

Key Goals of CAN:

• Reliability in Harsh Environments: Automotive and industrial settings demand robust error handling and fault tolerance.
• Real-time Communication: Some data (e.g., braking signals) must arrive in milliseconds.
• Decentralization: Any node (ECU) can initiate messages - no single point of failure.

‍

Typical Applications

• Automotive: Connecting ECUs for engine, brakes, airbags, climate control, infotainment, etc.
• Industrial Automation: Robotics, conveyor belts, process control.
• Aerospace: Critical systems in aircraft and spacecraft.
• Medical Devices, Elevators, Agricultural Equipment: Any embedded environment requiring robust networking.

‍

Standards and Specifications: What Defines CAN?

The CAN protocol has a well-defined set of specifications and standards, maintained over decades:

Key RFCs, ISO, and SAE Standards:

• ISO 11898: The core international standard for CAN, specifying the data link and physical layer.
  • ISO 11898-1: Data Link Layer and Physical Signaling
  • ISO 11898-2: High-Speed Medium Access Unit
  • ISO 11898-3: Low-Speed, Fault-Tolerant CAN
  • ISO 11898-4: Time-Triggered CAN (TTCAN)
  • ISO 11898-5: High-Speed, Low Power
  • ISO 11898-6: Selective Wake-Up functionality
• SAE J1939: Widely used in trucks, buses, and off-road vehicles; builds on CAN and adds higher-layer protocol features.
• CANopen (CiA 301): A higher-layer protocol used in industrial automation, based on CAN.
• DeviceNet: Industrial communications protocol built on CAN.
• ISO 16845: Conformance test specification for CAN.

Note: RFCs are rarely used for CAN—the ISO standards and SAE/CiA documentation are canonical.

‍

CAN FD and CAN XL Extensions

• CAN FD (Flexible Data-rate): ISO 11898-7, increases data payload (up to 64 bytes), higher bit rates.
• CAN XL: Under development, targeting even higher speeds and longer data fields.

‍

How CAN Works: A Deep Dive into the Protocol

Network Architecture

• Nodes: Each ECU or device is a "node" on the CAN network.
• Bus Topology: Nodes connect via a twisted-pair (CAN High and CAN Low) to form a single logical bus.

Decentralized, Multi-Master System

• No central controller.
• Any node can start transmission.
• Bus arbitration determines which message gets through in case of simultaneous transmission - based on message priority.

Message-Based Communication

• No direct node-to-node addressing.
• Broadcast model: Messages are sent to all nodes; each node filters and reacts to messages of interest.
• Priority: Determined by the arbitration field (lower value = higher priority).

‍

CAN bus Message Structure: Fields and Values

Classical CAN Frame Format

Key Fields in a CAN Frame

‍

Field Details

1. Start of Frame (SOF)
   • Value: Always dominant (logical 0)
   • Purpose: Synchronizes all nodes.
2. Arbitration ID
   • Standard Frame: 11 bits (0 - 0x7FF)
   • Extended Frame: 29 bits (0 - 0x1FFFFFFF)
   • Purpose: Uniquely identifies message type and priority.
   • Note: Lower IDs have higher priority during arbitration.
3. Remote Transmission Request (RTR) Bit
   • 0: Data frame
   • 1: Remote frame (requests data from other node)
4. IDE (Identifier Extension) Bit
   • 0: Standard format
   • 1: Extended format
5. Control Field
   • DLC (Data Length Code): 4 bits (0 - 8 for classic CAN; 0 - 15 for CAN FD)
     • Indicates how many data bytes follow
   • Other control bits: Reserved
6. Data Field
   • 0 - 8 bytes: Classic CAN
   • 0 - 64 bytes: CAN FD
7. CRC Field
   • 15 bits (Classic), error checking
8. ACK Field
   • 1 bit sent by receiving nodes if message received with correct CRC
9. End of Frame
   • 7 bits, always recessive (logical 1)

Example CAN Message (Classic 11-bit Frame)

‍

CAN bus Physical and Logical Topology

Physical Layer

• Two-wire bus: Twisted pair: CAN_H (High), CAN_L (Low)
  • Idle State: Both wires at ~2.5V
  • Dominant Bit: CAN_H > CAN_L (logical 0)
  • Recessive Bit: Both wires at ~2.5V (logical 1)
• Baud Rates:
  • Standard CAN: up to 1 Mbps (usually 500 Kbps or 250 Kbps)
  • CAN FD: Up to 8 Mbps (data phase)
• Termination:
  • 120 Ω resistor at each end of the bus to prevent signal reflection

Connectors

• No universal connector
  • Automotive: OBD-II, proprietary
  • Industrial: DB9 (D-sub9), M12, terminal blocks

‍

Real-world Use Cases: Automotive, Industrial, Aerospace

Automotive Example

• ECUs: Engine, transmission, airbags, climate control, instrument cluster
• Scenario: When you press the brake pedal, the brake ECU transmits a CAN message (ID 0x2F4, for instance) with data indicating brake force. The engine ECU, ABS, and dashboard instrument cluster all listen for this message and react accordingly - reducing throttle, activating ABS, turning on a dashboard light, etc.

Industrial Automation

• Robots, conveyors, sensors, actuators - all communicating via CAN for real-time coordination.

Aerospace

• Redundancy and reliability: CAN is sometimes used in spacecraft for non-mission-critical systems or as a backup protocol.

‍

Security Risks and Attack Surface in CAN

Why is CAN Security-Critical?

• Lack of Built-in Authentication: Any node can transmit messages; the protocol trusts all participants.
• Broadcast Model: All messages are visible to all nodes.
• No Encryption: Messages are transmitted in plaintext.

Common Attack Vectors

• Injection Attacks: Attacker sends spoofed messages (e.g., disable brakes, spoof speedometer).
• Fuzzing: Sending malformed or unexpected messages to find vulnerabilities.
• Denial-of-Service: Flooding the bus to prevent normal communication.

Notable Incidents

• 2015 Jeep Cherokee Hack: Attackers remotely manipulated vehicle controls via CAN bus after compromising the infotainment system.
• Ongoing research: Demonstrates feasibility of manipulating locks, brakes, steering, and more via CAN attacks.

‍

How Penzzer Tests and Secures CAN Network-able Devices

Introducing Penzzer: Modern Fuzzing for Embedded Protocols

Penzzer is a next-generation fuzzing platform purpose-built for protocol security - including complex, embedded protocols like CAN bus. Its focus: automation, scalability, and depth in security testing.

How Does Penzzer Approach CAN Testing?

1. Protocol-Aware Fuzzing
   • Penzzer includes support for CAN message formats, understanding field boundaries and legal/illegal values for each field (Arbitration ID, DLC, Data, etc).
   • Fuzzes both syntactic (structure) and semantic (meaningful stateful flows) layers of CAN communication.
2. Stateful and Stateless Modes
   • Can replay or generate valid CAN traffic for "stateful" scenarios (e.g., sequences needed to unlock a function).
   • Also sends fully random or malformed frames to trigger edge-case bugs.
3. Harnessing Physical Interfaces
   • Integrates with common CAN hardware adapters (USB-CAN, OBD-II dongles, virtual CAN interfaces).
   • Can target real cars, test benches, simulators, or hardware-in-the-loop setups.
4. Automated Test Case Generation
   • Penzzer mutates all CAN fields:
     • Arbitration ID: Randomizes, duplicates, collides IDs to test arbitration.
     • DLC: Sends over- and under-sized payloads.
     • Data Field: Mutates each byte, injects edge-case values (0x00, 0xFF, ASCII, boundary conditions).
     • Bit-level errors: Introduces bit-flips, malformed SOF, CRC, etc.
   • Automatically tracks system responses: crashes, reboots, improper ACKs, or protocol violations.
5. Fault Injection and Error Testing
   • Simulates electrical faults: bus-off conditions, frame errors, loss-of-ACK, and more.
   • Monitors error counters and node isolation responses as per ISO 11898.
6. Custom and Smart Fuzzing
   • For known application protocols (J1939, CANopen, proprietary OEM frames), Penzzer can generate smart fuzzing campaigns targeting application-level logic.
   • Learns from observed message flows to craft context-aware payloads.
7. Result Analysis and Reporting
   • Real-time dashboard with message timing, error logs, bus state.
   • Identifies exploitable vulnerabilities: code execution, denial-of-service, unsafe state changes.
   • Replays minimal crash cases for developer triage.
8. Scalability and Repeatability
   • Supports distributed fuzzing across multiple nodes or test environments.
   • Stores and replays successful exploits for regression testing.

‍

Sample Use Case: Fuzzing a Vehicle ECU

Let’s walk through a typical engagement:

• Step 1: Connect Penzzer to a vehicle’s CAN bus via OBD-II or direct DB9 interface.
• Step 2: Begin with passive sniffing to learn existing traffic patterns and identify active Arbitration IDs.
• Step 3: Launch a fuzzing campaign targeting the braking ECU:
  • Randomizes data fields for all observed braking-related messages.
  • Gradually increases payload length, mutates every bit, and tests for out-of-range DLC values.
  • Logs any abnormal responses (ECU resets, error frames, bus-off events).
• Step 4: Penzzer’s results indicate that a specific malformed message (arbitration ID 0x2F4, DLC=9) causes the brake ECU to reboot—a clear, exploitable vulnerability.

‍

Why Penzzer?

• Protocol intelligence: Unlike generic fuzzers, Penzzer knows how CAN works - down to field sizes, encoding, and error management.
• Speed: Can test millions of variations in hours.
• Depth: Finds bugs not just in message parsing, but also state machines, timing logic, and error handling—areas often missed by manual testing.
• Safety: Includes guardrails to avoid unsafe test conditions on real vehicles (e.g., throttling attack payloads, operator alerts).

‍

Compliance and Standards

• Penzzer’s test strategies align with ISO 21434 (Automotive Cybersecurity) and UNECE WP.29, supporting regulatory requirements for security validation in modern vehicles.

‍

Advanced: Variants of CAN (CAN FD, CAN XL, etc.)

Low-Speed and High-Speed CAN

• Low-Speed Fault-Tolerant CAN: Up to 125 Kbps, higher resistance to line faults (e.g., open/short circuits).
• High-Speed CAN (Classical): Up to 1 Mbps, used in most automotive systems.

CAN FD (Flexible Data-Rate)

• Introduced to overcome classic CAN’s 8-byte payload limitation.
• Data field: Up to 64 bytes.
• Higher data rates: Up to 8 Mbps.
• Field changes: DLC extended to support longer payloads.

CAN XL

• Still in development; targets 10 Mbps+ speeds and 2048-byte payloads.
• Aims to bridge gap between CAN and automotive Ethernet.

Physical Layer Variants

• CAN with Flexible Data-Rate (CAN FD): ISO 11898-7
• CAN with Partial Networking: Enables parts of the network to sleep for power savings.

‍

Future of CAN and Secure Communications

• CAN is not going away: Despite new automotive Ethernet technologies, CAN remains crucial for many time-sensitive and safety-critical systems.
• Growing attack surface: As more vehicles become connected (telematics, V2X), attack surfaces grow.
• Need for ongoing testing: Security researchers, OEMs, and Tier-1 suppliers must continuously test CAN implementations for emerging threats.
• Layered security: The future is not just about protocol hardening, but adding cryptography, authentication, intrusion detection, and robust fuzz testing at all layers.