[ CAN bus — a generic introduction ]

Vendor-neutral primer for someone who's heard of CAN bus but hasn't touched one yet. Covers the physical layer, the protocol up through frame anatomy, what kinds of higher-layer protocols ride on top (UDS / OBD-II / J1939 / CANopen), the tools to actually look at traffic, and the safety practice that keeps you from bricking hardware on day one. Once this clicks, the rest of the car-hacking material on this site (JEEP-specific primer, message reference, UDS writes) reads like applied examples rather than a foreign language.

CAN stands for Controller Area Network.  Bosch published it in 1986
to replace the rat's nest of dedicated point-to-point wires that
1970s/80s cars used between control modules.  By the mid-90s it was
the de facto vehicle bus, and by the time OBD-II became mandatory in
the US (1996 model year) CAN was the protocol most manufacturers
used on top.

Today CAN shows up everywhere that needs robust real-time messaging
between embedded controllers over short distances in noisy
electrical environments:

    -- Cars, trucks, motorcycles, RVs, boats, agricultural / construction
       equipment, military vehicles
    -- Industrial automation (factory floors, PLCs, motor controllers)
    -- Medical devices (infusion pumps, MRI auxiliary controllers)
    -- Building automation (HVAC, elevators)
    -- Aerospace ground equipment

The design priorities are not "fast" or "flexible".
They're:

    1. Robust -- works through automotive electrical noise
       (alternator switching, ignition coil spikes, ground bounce).
    2. Real-time -- bounded latency for safety-critical
       traffic (brakes, airbags) via priority-based arbitration.
    3. Cheap -- $0.50 transceivers, no central hub or
       switch, runs on two wires.
    4. Multi-master -- any node can talk; no master
       election ceremony, no token passing.

Throughput is modest (1 Mbps theoretical max on classical CAN, 500
kbps in practice for most powertrain buses).  Compared to Ethernet
that's slow.  But when you only need to ship 8-byte sensor updates
hundreds of times per second across a 10-node network in a car, slow
is fine and robust matters more.

CAN is a differential 2-wire bus.  Both wires carry
the same data with opposite voltages so external electromagnetic
noise affects both equally and cancels out at the receiver.  The
wires are:

    CAN-H   "High" wire.    ~3.5 V dominant, ~2.5 V recessive.
    CAN-L   "Low"  wire.    ~1.5 V dominant, ~2.5 V recessive.

When both wires sit at ~2.5 V the bus is idle (called
"recessive" in CAN terminology, meaning 1).  When CAN-H rises and
CAN-L falls, the bus is asserting a "dominant" state (logical 0).
The receiver looks at the difference between the two wires
(CAN-H minus CAN-L), so:

    Differential > 0.9 V  => dominant (0)
    Differential < 0.5 V  => recessive (1)

This differential scheme is why CAN tolerates being run through an
engine bay with 50 amp alternator wiring six inches away.  Any noise
that couples in capacitively or inductively hits both wires equally
and is rejected at the differential receiver.

Termination: A CAN bus needs a 120-ohm resistor at
each end (not the middle, not somewhere in between -- physically at
each of the two endpoints).  These prevent signal reflections that
would otherwise smear the bit edges.  Many vehicles bake the
terminators into modules at each end of the bus; some require an
external pair.  If you tap into a bus and add terminators, you turn
a working bus into a broken one with too-low impedance.

Connector reality check:  In a car, CAN-H is usually
the green / pale-green wire (J1962 OBD-II pin 6) and CAN-L is white
(J1962 pin 14).  But the wire colours and which pins on which
connector vary by manufacturer.  Don't trust colour without
verifying.

    Bus voltages over time

    3.5V  -----.    .--.    .-----  CAN-H
              |    |  |    |
    2.5V  .....+....+--+....+.....  idle / mid-rail
              |    |  |    |
    1.5V       '----'  '----'          CAN-L
          recessive  dominant  recessive  dominant  recessive
            (1)        (0)        (1)        (0)        (1)

CAN is multi-master broadcast:

    -- Every node on the bus sees every frame.
    -- Any node can transmit at any time the bus is idle.
    -- There is no central controller, no switch, no master.
    -- Frames carry an arbitration ID, not a destination address.
       Each receiver decides individually whether the frame matters
       to it.

When two nodes start transmitting at the same instant (both saw the
bus as idle and pulled the trigger), CAN resolves the collision
losslessly via bit-by-bit arbitration:

    1. Each node transmits its arbitration ID one bit at a time,
       starting with the most significant bit.
    2. Each node simultaneously reads back what it just put on the
       bus.
    3. The dominant bit (0) always wins over the recessive bit (1).
       This is a hardware property of the CAN transceiver -- if one
       node pulls dominant while another tries to leave it
       recessive, the bus reads dominant.
    4. A node that sent recessive but read back dominant knows it
       lost arbitration on that bit.  It immediately stops
       transmitting and waits for the bus to go idle again.
    5. The node with the lowest numerical ID wins arbitration and
       keeps transmitting.  Everyone else's frame is queued for
       a retry.

The arbitration loser doesn't lose any data -- it just retries on
the next idle window.  No collision detection / random-backoff dance
like Ethernet.  The lossless property is what gives CAN its bounded
worst-case latency for high-priority traffic.

Practical consequence: a frame's ID is also its
priority.  An emergency brake actuator firing 0x040 always beats a
radio station-info broadcast firing 0x328.  Same goes for designing
your own injected traffic on a hacked bus: a higher (numerically
larger) ID will get crowded out by ordinary vehicle traffic.

A classical CAN frame has six fields, but for most analysis only two
of them matter: the arbitration ID and the
data payload.

    SOF | ID | RTR | IDE | r0 | DLC | DATA | CRC | ACK | EOF

    SOF   Start of frame (1 dominant bit, edge-triggers re-sync)
    ID    Arbitration ID (11 bits classical, 29 bits extended)
    RTR   Remote Transmission Request (1=request, 0=data frame)
    IDE   Identifier Extension (0=11-bit ID, 1=29-bit ID)
    r0    Reserved
    DLC   Data Length Code (4 bits, indicates 0-8 data bytes)
    DATA  0 to 8 bytes of payload (this is the part you read)
    CRC   15-bit CRC over the preceding fields
    ACK   Acknowledge slot (any other node pulls dominant to ACK)
    EOF   End of frame (7 recessive bits)

When you see candump output:

    can0  328   [8]  07 41 4D 61 67 69 6B 65

The fields parse as:

    can0    interface name (kernel SocketCAN device)
    328     arbitration ID (hex), 11-bit
    [8]     DLC: 8 data bytes follow
    07 ..   the 8 payload bytes

The CRC / ACK / framing bits are handled by the transceiver hardware
and never surface to userspace.  As far as a SocketCAN consumer is
concerned, a CAN frame is just (id, dlc, data_bytes).

Standard vs extended IDs:  Classical CAN was
originally 11-bit IDs (2048 possible values, range 0x000-0x7FF).
Later extended to 29-bit IDs (~537M values).  Cars use both: most
on-vehicle traffic is 11-bit, while protocols layered on top of CAN
for trucks and industrial gear (J1939, CANopen) use 29-bit.  In
candump output an extended ID is rendered with 8 hex chars and an
"X" suffix.

Payload is small:  Maximum 8 bytes per frame.  This
limit is why higher-layer protocols (ISO-TP, see below) exist -- to
fragment / reassemble longer messages across multiple frames.

Classical CAN runs at a single fixed bitrate per bus segment.
Common automotive rates:

    1000 kbps    Max theoretical for classical CAN; rarely used
                 in production vehicles.
     500 kbps    "High-speed" CAN.  Powertrain, chassis, ABS, ESP --
                 anything safety-critical.  Most "CAN-C" buses run at
                 500 kbps.
     250 kbps    J1939 standard for heavy trucks.
     125 kbps    "Low-speed" / fault-tolerant CAN.  Body, comfort,
                 infotainment.  Most "CAN-IHS" buses run here.
      33.33 kbps GMLAN single-wire CAN (vendor-specific GM use).

Two newer variants are worth knowing about because they show up
increasingly in 2020s vehicles:

    CAN-FD (Flexible Data Rate)  ISO 11898-1:2015.
      Arbitration phase still runs at classical rates (typically
      500 kbps), but the data phase ramps up to 2 Mbps or 5 Mbps
      so the larger payload (now 0-64 bytes) doesn't dominate
      bus time.  Tools and transceivers must support FD or they
      fault on the high-rate data phase.

    CAN XL  ISO 11898-1:2024.  Extends payload to
      2048 bytes and data rate to 10 Mbps.  Niche and forward-
      looking; not in any consumer vehicle as of 2026 but starting
      to appear in heavy-truck and industrial roadmaps.

For everyday vehicle work today, "classical CAN at 500 / 250 / 125
kbps" covers ~99% of what you'll see.

CAN itself is just a transport for 0-8 byte frames.  Useful traffic
is structured by higher-layer protocols stacked on top.  The ones
you'll actually encounter:

ISO-TP (ISO 15765-2) -- transport layer for multi-frame messages

  CAN frames are 8 bytes max.  Anything larger -- a 17-character
  VIN, a multi-byte diagnostic response, a firmware-update chunk --
  has to be split across multiple frames and reassembled at the
  receiver.  ISO-TP defines four frame types:

    SF (Single Frame)         payload <= 7 bytes, fits in one frame
    FF (First Frame)          start of a multi-frame message
    CF (Consecutive Frame)    continuation, sequence-numbered
    FC (Flow Control)         receiver's "go / wait / stop" signal

  Linux has a kernel module (`can-isotp`) that handles all of this
  in-kernel; userspace just sees a SOCK_DGRAM that reads / writes
  complete messages of arbitrary length.

UDS (ISO 14229) -- Unified Diagnostic Services

  The vehicle-diagnostic protocol that rides on top of ISO-TP.
  Service byte + sub-function + parameters.  Key services to know:

    0x10  DiagnosticSessionControl    (start a diagnostic session)
    0x11  ECUReset
    0x22  ReadDataByIdentifier        (read a named data item -- DID)
    0x23  ReadMemoryByAddress
    0x27  SecurityAccess              (seed/key unlock for sensitive ops)
    0x2E  WriteDataByIdentifier
    0x2F  IOControlByIdentifier       (actuate things -- horn, locks)
    0x31  RoutineControl              (run named routines on the ECU)
    0x34  RequestDownload             (firmware updates)
    0x3E  TesterPresent               (keep-alive for a session)

  Positive response convention: response byte = request byte + 0x40.
  So a request 0x22 returns 0x62, a request 0x2F returns 0x6F, etc.
  Negative response: 0x7F <requested_service> <NRC>.

OBD-II (ISO 15765-4 + SAE J1979) -- standardised emissions

  The mandatory subset every 1996+ US-market car supports.  Same
  physical CAN, same ISO-TP framing, but uses a different service
  set focused on emissions / live sensor data:

    0x01  ShowCurrentData       (read a live PID like RPM, speed)
    0x03  ShowDTCs              (read stored DTCs -- see below)
    0x04  ClearDTCs
    0x09  RequestVehicleInfo    (VIN, calibration ID)

  PIDs (Parameter IDs) for Service 0x01 are standardised by SAE
  J1979; the full list is documented on Wikipedia.

  DTCs (Diagnostic Trouble Codes) are the
  standardised fault codes ECUs store when something goes wrong —
  P0420, P0171, C0561, B1320, U0101, etc.  Format is one letter +
  four hex chars; the letter says which broad system reported the
  fault (P=Powertrain, C=Chassis, B=Body, U=Network).  Scan tools and
  the auto-parts-store free-code-read service both work by issuing
  Service 0x03 and decoding the response.  When the MIL (Malfunction
  Indicator Lamp; also called CEL or check engine light) is on,
  there's a DTC behind it.  Full byte-level encoding +
  position-by-position breakdown at
  Bus & Message
  Reference #dtc-anatomy.

SAE J1939 -- heavy trucks and buses

  Different framing entirely -- uses 29-bit extended IDs, structures
  the ID into Priority / Reserved / DataPage / PDU Format / PDU
  Specific / Source Address fields.  Standard parameter group
  numbers (PGNs) define what each frame carries.  If you see 29-bit
  IDs on a vehicle and the manufacturer is Cummins / Cat /
  PACCAR / Volvo Trucks, you're probably looking at J1939.

CANopen -- industrial automation

  Object-dictionary-based protocol used in factory automation, motor
  drives, medical devices.  Not common in vehicles, but worth
  recognising if you see CAN traffic on industrial equipment.
  Defines profiles for specific device classes (CiA 401 generic I/O,
  CiA 402 motor drives, etc.).

You need three things to start working with CAN:

  1. A way to talk to the bus electrically (hardware transceiver +
     interface to your computer).
  2. A driver / API in your OS.
  3. Software to read, write, decode, replay.

Hardware

  Pick one based on budget and use case:

    Cheap MCU + transceiver       Raspberry Pi + Waveshare 2-CH CAN
                                  HAT (~$25), ESP32 + SN65HVD230
                                  ($5), Teensy 4.0 + MCP2562 ($25).
                                  Best for DIY rigs, dev work, what
                                  the magikh0e.pl
                                  CANBus dev
                                  stack uses.

    USB-CAN adapter               PCAN-USB ($300+), Kvaser Leaf
                                  ($150+), Lawicel CANUSB ($80).
                                  Plug-and-play on Linux, robust,
                                  certified for production lab use.

    Open-source dev board         comma.ai panda ($90), CANable
                                  ($45) running candleLight firmware.
                                  Good middle ground between MCU
                                  flexibility and USB-adapter polish.

OS / driver

  On Linux, the kernel SocketCAN stack treats CAN interfaces as
  network interfaces.  Bring an interface up like an ethernet card:

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

  After that candump can0 works like tcpdump
  eth0.  Mac / Windows tooling exists but is less mature;
  most car-hacking work happens on Linux specifically for SocketCAN.

Software

  Foundational userspace -- install everything in this group first:

    can-utils       candump, cansend, canplayer, cangw, isotpsend,
                    isotprecv.  apt install can-utils.  See
                    links.html
                    for the canonical reference.

    python-can      Pythonic CAN socket library.  pip install
                    python-can.  Wraps SocketCAN plus other backends.

    can-isotp       Kernel module for ISO-TP fragmentation /
                    reassembly.  Lets you send / receive UDS messages
                    without writing your own framing state machine.

    udsoncan        Python UDS client library; speaks ISO 14229 over
                    can-isotp.

  Reverse-engineering tooling:

    cantools        DBC file parser; decodes raw frames into named
                    signals if you have a DBC for your platform.

    SavvyCAN        Cross-platform GUI for CAN inspection.  Signal
                    hunter, frame editor, scripting.  Best for
                    sit-down RE sessions.

    caringcaribou   Python toolkit for offensive CAN work --
                    discovery, fuzzing, UDS attacks.

  All of these are documented in detail on the Car Hacking
  Links & Resources page.

Hardware + software is half the picture; the other half is figuring
out where to physically connect your CAN interface to the vehicle.
Two access points cover almost every modern car-hacking workflow:

1.  The OBD-II port (J1962)

  Every car sold in the US since 1996 (1998 in Canada, 2001 EU
  petrol, 2003 EU diesel) has a standardised 16-pin diagnostic port
  required by emissions regulation.  It's usually within arm's
  reach of the driver -- under the dash near the steering column,
  in the fuse-box area, or in the centre console.  By law it must
  be reachable without tools.

  Pinout (looking AT the connector from the cable side):

      +--------------------------+
      |  1   2   3   4   5   6   7   8 |   row 1 (pins 1-8)
      |  9  10  11  12  13  14  15  16 |   row 2 (pins 9-16)
      +--------------------------+

  Standardised CAN pins (ISO 15765-4):

      Pin 6   CAN-H (high-speed CAN, typically 500 kbps)
      Pin 14  CAN-L (high-speed CAN)
      Pin 4   Chassis ground
      Pin 5   Signal ground
      Pin 16  +12V battery (always-on, even with ignition off)

  Manufacturer-specific pins (when used at all) commonly carry a
  second low-speed CAN bus, K-line for older diagnostics, or
  proprietary signalling.  On FCA / Stellantis vehicles, pins 3
  and 11 typically carry the diagnostic CAN-IHS pair (low-speed
  body bus, 125 kbps); on GM you'll find single-wire CAN on pin 1;
  on VAG group you may see K-line on pin 7.  See your platform's
  wiring diagrams.

  Building a DIY OBD-II breakout cable is the
  cheapest entry point --
  cut a $5 OBD-II Y-cable, expose pins 6 / 14 / 16 / 4-5 as
  bare wires, terminate to your CAN interface.  Total cost
  ~$10, takes 15 minutes.

  OBD-II caveat -- the SGW gating problem:  On
  2018+ FCA / Stellantis vehicles (Jeep Wrangler JL, Gladiator JT,
  Grand Cherokee, Ram, Dodge Charger, Chrysler 300, et al.) there
  is a Secure Gateway Module (SGW / SGM) physically sitting between
  the OBD-II port and the rest of the CAN bus.  The SGW transparently
  passes read traffic (Mode 01 PIDs, Service 0x03
  DTCs, Service 0x22 ReadDataByIdentifier) so emissions inspection
  still works.  But write traffic (Service 0x04
  ClearDTCs, Service 0x2F IOControl, Service 0x2E
  WriteDataByIdentifier, Service 0x31 RoutineControl, anything that
  modifies vehicle state) is blocked unless you have a session token
  from AutoAuth, a Stellantis-authorised certified scan tool, or
  you bypass the gateway entirely.

  For read-only work (live data dashboards, fault-code reading,
  VIN lookups), OBD-II is fine on every vehicle including
  post-SGW ones.  For write work on a 2018+ FCA, you need either
  AutoAuth (~$50/year subscription, certified tool required) or
  the second access point below.

2.  Behind-the-glovebox 13-way connectors (FCA / Stellantis)

  On Wrangler JL / Gladiator JT and most other 2018+ FCA platforms,
  remove the glovebox (push the sides in, drop it down) and you'll
  see two large 13-way connectors mounted on the back wall.  These
  are the body-side end of the CAN harness from the powertrain
  side.  Specifically, they expose CAN-C (high-speed
  powertrain, 500 kbps) and CAN-IHS (low-speed body,
  125 kbps) at points downstream of the SGW on the
  vehicle side -- which means traffic at these taps has already
  passed through the gateway and is unfiltered from the perspective
  of anything else on the bus.

  Practical consequence:

      OBD-II port                  =>  SGW   =>  vehicle CAN
                                       |
                                       +-->   gates writes
                                              from OBD-II

      Behind-glovebox 13-way connectors
        sit HERE, on the vehicle side  =>  unfiltered access

  Plugging a CAN interface into the behind-glovebox connectors
  gives you full read AND write access on both
  CAN-C and CAN-IHS without AutoAuth, without a certified tool,
  without any subscription.  The SGW doesn't see traffic that
  doesn't pass through it.

  The on-site
  DIY OBD-II Diagnostic
  Cable guide documents the connector-pinout layout for the
  JL / JT specifically, including which pin pairs are CAN-C
  and which are CAN-IHS, and walks through a build that gives you
  both buses on a single Pi rig.  The
  Secure Gateway Module
  guide covers the broader SGW story:  what it is, what it gates,
  AutoAuth pricing, hardware bypass cables sold by third parties,
  and the trade-offs of each access path.

  Other platforms have analogous tap points but they're located
  differently -- on the JK (2007-2018 Wrangler) the SGW doesn't
  exist and OBD-II writes work directly; on GM vehicles look for
  the BCM (Body Control Module) connector behind the dash; on VAG
  group look for the gateway module's CAN-bus pins in the foot
  well.  Service-manual wiring diagrams are the canonical source.

3.  Other tap points (vendor-specific, less common)

  -- Inline at a specific module connector.  Cut the harness,
     splice a T into the CAN-H / CAN-L pair, restore the wires.
     Useful when you want to isolate which module is sending a
     specific ID -- unplug the module, see if the ID disappears
     from candump output.

  -- Through an aftermarket diagnostic port.  Some platforms
     have a secondary "service connector" that exposes CAN
     bypassing the gateway:  Bimmer Coding, Tactrix Openport, etc.

  -- Direct probe at the wires.  Pierce-clip a CAN-H / CAN-L pair
     anywhere on the bus.  Easy on harness sections behind trim,
     near impossible mid-loom.

A few rules that separate productive CAN work from "I just bricked
my ABS module":

1.  Listen-only mode first.  Bring the interface up
    with listen-only on so the CAN controller can
    receive but cannot transmit -- not even ACK bits.  candump
    your way through a few drive cycles before you ever issue a
    cansend.  When you understand the traffic, lift listen-only
    and add real transmission.

        ip link set can0 type can bitrate 500000 listen-only on

2.  Don't fuzz random IDs.  Modern vehicles have
    safety-critical IDs (brake controller, airbag controller,
    steering assist) that respond to forged frames in real time.
    Some accept the frame at face value; some flag the impostor and
    set a DTC; a few will execute the request.  Random fuzzing is
    how you end up with a deployed airbag or a permanent ABS
    fault.  Always inject targeted frames with a hypothesis you
    can verify by candump on the response.

3.  Some frames are integrity-protected.  Modern
    CAN buses, especially CAN-C powertrain segments, increasingly
    use rolling counters (a byte that increments every frame) and
    CRC bytes to detect replay / spoof attacks.  Your forged frame
    needs to carry a correct counter and checksum or it gets
    rejected by the receiver and a DTC fires.  Identify these IDs
    by looking at byte-level deltas between consecutive frames in
    candump output -- ones with steadily-incrementing bytes are
    counters, ones where a byte changes with no pattern when nothing
    else changes are usually checksums.

4.  The CAN bus is broadcast -- so is your evidence.
    Every frame you transmit is seen by every node.  If you fire a
    diagnostic write at the wrong module, the right module saw it
    too and may have logged the attempt.  This isn't a forensic
    deterrent (the logs aren't usually crash-survivable), but it
    does mean "I'll just try it and undo if it doesn't work" is a
    fragile recovery plan.

5.  Have a hardware kill switch.  The dev-stack on
    this site uses Zero2Go Omni supercaps that survive crank
    brown-outs but ALSO can be manually cut -- pulling the Pi off
    the bus is the fastest way to stop a misbehaving script
    mid-transmission.  Soft kills via Ctrl+C are best-effort; a
    physical switch is guaranteed.

6.  Brick recovery is real, not theoretical.  UDS
    Service 0x34 RequestDownload and Service 0x31 RoutineControl
    can re-flash module firmware.  Targets vary, but the cost of
    bricking an ECU ranges from "buy a new module, $300-1500" to
    "the dealer is the only place that can recover it, $400 + tow."
    Don't run untrusted firmware-update flows against real
    vehicles unless you're prepared to backstop the worst case.

From here, the rest of the car-hacking material on this site is
applied examples of the protocol pieces above.  Reasonable reading
order:

  1.  Jeep CAN bus primer
      -- first-time-user walkthrough specifically on the JEEP JL /
      JT platform.  Same protocol-level material as this page but
      with concrete IDs, byte sequences, and a working hardware
      stack documented end-to-end.

  2.  Bus & Message Reference
      -- decoded message-ID catalog with byte-level evidence,
      worked OBD-II + UDS examples, JEEP live-data message map,
      DTC anatomy.  This is the reference you keep open while
      working.

  3.  Python CAN Bus Lab Guide
      -- spin up a virtual CAN environment without a real vehicle,
      replay captured drive logs, watch the traffic in a dashboard.
      Practice the tooling above without the brick-recovery risk.

  4.  UDS Write Operations
      -- Services 0x2E / 0x2F / 0x31 / 0x27, cleanup patterns,
      verified writable targets, SGW interaction.  The "actually
      change something on the vehicle" reference.

  5.  Secure Gateway Module
      -- the 2018+ FCA / Stellantis gating story.  Not strictly
      protocol-level material but you'll hit it the first time you
      try to do anything write-y from the OBD-II port on a modern
      Chrysler / Dodge / Jeep / Ram.

  6.  Reverse Engineering UDS with JScan
      -- use a known-good scan tool (JScan) as a stimulus, capture
      what it sends, decode the protocol byte-by-byte.  Cheaper
      than buying a $5000 dealer scan tool to learn what the
      vehicle's UDS surface actually looks like.

  7.  Links & Resources
      -- external references: can-utils, python-can, SavvyCAN,
      ICSim simulator, the JL Wrangler RE spreadsheet, opendbc.

External references worth bookmarking outside this site:

  -- Vector CAN training (free e-learning)
     -- the canonical industry training set; thorough on the
     physical layer and bit-timing topics this page glosses over.
  -- CSS Electronics CAN bus intro
     -- visual reference for the wire-level signalling material.
  -- Wikipedia: CAN bus
     -- decent for terminology and standards references.