[ Car Hacking — Links & Resources ]

External tools and references that pair with the scripts, guides, and
hardware on the Car Hacking parent page.
Grouped by character:

  Foundational      CLI utilities and core libraries every other
                       tool here builds on (can-utils, python-can,
                       can-isotp).
  UDS toolkits      Python libraries and frameworks for
                       diagnostic-protocol work, recon, fuzzing.
  DBC data          Signal databases and the tools that parse
                       them; how to make candump output read like a
                       dashboard instead of a hex dump.
  GUI / hardware    Cross-platform GUIs and open-source CAN
                       hardware -- the clickable + reproducible
                       counterparts to the CLI flow on the parent page.

[ Foundational — CLI + libraries ]

SocketCAN userspace toolkit — the canonical CLI for working with
SocketCAN interfaces, real or virtual. Includes:

    candump      sniff / log CAN traffic with filtering
    cansend      send one frame
    cangen       generate test traffic
    canplayer    replay a captured log (used in the Python CAN Bus Lab)
    isotpdump    sniff ISO-TP reassembled streams (see SniffingCanbus.txt)
    isotpsend    send an ISO-TP message
    cangw        gateway frames between buses
    canbusload   per-ID load / utilisation stats

Every script in the parent page's
Tools | Scripts section depends
on at least one of these. Standard install on Debian / Ubuntu / Raspberry
Pi OS:

    sudo apt install can-utils
Foundational Python library for CAN bus interaction. The transport layer
that pyJeepCan.py, udsoncan, cantools,
caringcaribou, and scapy-automotive all ride on. Supports a long list of
backends: SocketCAN (Linux), Kvaser, PEAK PCAN, Vector, IXXAT, USB2CAN,
J2534, SLCAN / serial CAN, virtual CAN, plus replay-from-log.

Same API across backends — write code once, point at vcan0 for the
bench rig, swap to socketcan/can0 for the real vehicle. Threaded reader
patterns, asyncio, kernel-level filtering (when the backend supports it),
log readers/writers for BLF, ASC, CSV, and plain candump format.

Install: pip install python-can.
In-kernel ISO-TP implementation by Oliver Hartkopp (one of the SocketCAN
authors). Provides a CAN_ISOTP protocol socket that handles framing in
the kernel instead of in userspace, which means much higher throughput
and lower latency than equivalent userspace tools when you're moving
real diagnostic payloads (ECU flashing, large DID reads, multi-frame
fuzz campaigns).

Mainlined into Linux ~5.10. Older kernels can build it as an out-of-tree
module from this repo. If you're already on a modern Debian / Ubuntu /
Raspberry Pi OS kernel, the module is likely already loadable:

    sudo modprobe can-isotp

Pair with can-isotp's Python bindings (the isotp
package on PyPI) or the python-can-isotp extension to
python-can for
high-performance ISO-TP work from Python. udsoncan plugs into the same
stack as its transport layer for high-volume diagnostic sessions.

[ UDS / security toolkits (Python) ]

Pure-Python UDS (Unified Diagnostic Services, ISO 14229) client. The
"proper" alternative to the hand-rolled cansend incantations in
3rd_brakelight.sh — instead
of building each request byte-by-byte, you instantiate a Client and call
methods like client.change_session(0x03),
client.io_control(0xD1B3, ...),
client.read_data_by_identifier(0xF190), etc.

Handles ISO-TP framing for you (single frame / first frame / consecutive
frames / flow control — see
SniffingCanbus.txt) via a pluggable
transport layer that rides on top of python-can. Same socketcan / vcan /
J2534 backend set as everything else on this page.

Where it shines: scripting any non-trivial diagnostic workflow.
Periodic-DID polling, automatic security-access seed/key exchange,
DTC enumeration with name lookup, ECU flashing sequences. Pair with the
Bus & Message Reference UDS
walkthrough for a side-by-side view of the protocol bytes the library
is generating.

Install: pip install udsoncan.
Python framework for automotive security testing. The attack-toolkit
sibling to udsoncan above — where udsoncan is the protocol library,
caringcaribou is the recon / scan / fuzz tooling built on top of it.

Modules:

    discovery   find live ECUs by probing standard diagnostic IDs
                and watching for responses
    uds         session probing, security-access seed/key dump,
                DID enumeration, ReadDataByIdentifier sweep, DTC dump
    fuzzer      random-frame fuzzing with ID / byte-position constraints
    listener    classify observed traffic by ID activity
    send        craft and send raw frames

Useful first-pass tool when you connect to an unfamiliar vehicle and want
to know what ECUs exist before reaching for udsoncan to do targeted
protocol work. Pair with the
Bus & Message Reference for
context on what the discovered IDs are likely to mean on FCA platforms.

Install: pip install caringcaribou.
scapy (with automotive extensions)
Packet manipulation framework that has grown native CAN, ISO-TP, UDS,
GMLAN, and SOMEIP support over recent releases. Heavier learning curve
than udsoncan or caringcaribou, but in return you get full packet-level
control: craft malformed UDS requests, fuzz ISO-TP fragmentation, mix
protocols in one capture, dissect layer-by-layer in an interactive shell.

Strongest use case on this page: developing or testing protocol-level
attacks against a target ECU. For "just read DID 0xF190" you'd use
udsoncan; for "send this 0x10 request with a deliberately malformed PCI
byte and see what comes back" you'd reach for scapy.

Install: pip install "scapy[basic]" or
apt install python3-scapy on Debian.

[ DBC data & tooling ]

The community-reverse-engineered DBC repository, maintained by comma.ai.
DBC files for hundreds of vehicle platforms across Toyota, Honda,
Hyundai/Kia, GM, Ford, Volkswagen, Nissan, Subaru, Tesla, plus several
Chrysler / Ram / Jeep / Dodge platforms.

A DBC file is a structured description of every signal on every broadcast
message ID — bit positions, scaling factors, units, endianness. Drop
one into SavvyCAN or feed it to cantools and your candump output starts
showing "EngineRPM: 2400, VehicleSpeed: 65, GearPosition: D" instead of
raw hex.

For FCA / JEEP work, check the chrysler_*_generated.dbc files in the
opendbc/dbc/ directory first. If your platform isn't covered,
the IDs you decode using the techniques on this page (candump diff +
Bus & Message Reference) are
exactly what upstream wants as pull requests.
Python library + CLI for DBC files. Parses DBC, generates decoder classes,
encodes messages by name, dumps signal tables. The Python-side partner to
opendbc above.

Typical workflow:

    from cantools.database import load_file
    db   = load_file('chrysler_ram_dt_generated.dbc')
    msg  = db.get_message_by_frame_id(0x322)
    data = msg.decode(payload_bytes)
    # data == {'EngineRPM': 2400.0, 'VehicleSpeed': 65.0, ...}

This replaces the hand-rolled decode helpers in pyJeepCan.py (raw8, tilt,
rpm, etc) with DBC-driven dispatch — IF you have or can write a DBC
for your platform. Without a DBC, the by-hand approach in pyJeepCan.py
remains the right move.

CLI subcommands: cantools decode (live-decode candump output),
cantools dump (human-readable DBC contents),
cantools convert (DBC ↔ KCD / SYM / other formats).

Install: pip install cantools.
Community-maintained reverse-engineering spreadsheet for the Jeep Wrangler
JL (2018+) platform. Documents observed CAN-IHS and CAN-C message IDs with
byte-level decode notes, contributed by hobbyists over the years. The
single largest source of community RE data for the JL platform —
many of the candidate IDs in the
Bus & Message
Reference candidate-IDs table originate here.

Format: Google Sheets, tabs by message ID / functional area. Some columns
more reliable than others — the most-edited cells tend to be the
most-verified; sparser entries are speculation. Treat the data the same
way the BMR's
Caveats section asks
you to treat the rest of this page: starting point, not authoritative
spec. Always confirm with candump on your own vehicle before automating
anything that writes.

Strongest pairing: import the most-confirmed sections into a DBC file
(see cantools /
opendbc above), then
verify each signal against your own captures. Finished decodes that
make the round trip "spreadsheet -> verified on real vehicle -> DBC -> PR
to opendbc" are exactly what the open-source CAN community wants more of.

Best-effort applies primarily to JL Wrangler (2018+). Limited
applicability to Grand Cherokee, Ram, Pacifica, older Wranglers, etc.
— FCA reuses some IDs across the lineup but reassigns others
aggressively (see BMR
Caveats).

[ GUI / simulation / hardware ]

Cross-platform (Linux / Windows / macOS) Qt-based GUI for CAN bus reverse-engineering
and capture. The clickable counterpart to the candump-and-diff CLI workflow described
in the Bus & Message Reference
candidate-IDs section — its "Signal Hunter" view automates the
"log baseline -> trigger event -> log again -> diff for changed bytes"
technique with a live-updating display of which bits toggled in response
to a stimulus. Saves a lot of grep / awk plumbing when you're hunting an
unknown message ID.

Capture / send on any Qt SerialBus interface: SocketCAN, PeakCAN, Vector,
J2534 passthrough, plus the Macchina M2 and Teensy 3.x boards. Multi-bus
capture is built in — one window, both CAN-C and CAN-IHS at the same
time. Plays cleanly with the vcan setup from the
Python CAN Bus Lab on the Guides page:
canplayer into vcan0 / vcan1, point SavvyCAN at those, hunt signals
against the captured drive log without a vehicle present.

Notable: DBC import/export (use the JL Wrangler RE spreadsheet or
the opendbc repo as a
starting point), JavaScript scripting for custom transforms, can-utils-compatible
log format so captures move between CLI and GUI without conversion, and
ISO-TP framing support for UDS work.
Craig Smith's CAN reverse-engineering training tool. Renders a fake
vehicle instrument cluster (speedometer, doors, turn signals, locks)
driven by simulated CAN traffic, plus a controller that lets you "drive"
the simulated vehicle. The pair runs over vcan0 with no real hardware
required.

Natural next step after the Python CAN
Bus Lab on the Guides page. The lab teaches capture and replay;
ICSim gives you a small, fully simulated vehicle to apply the
candump-diff RE technique against, with known-correct answers (the source
code reveals which IDs drive which indicators) so you can grade your own
work.

The instrument cluster's IDs are arbitrary — not based on any real
vehicle — but the WORKFLOW of discovering them is identical to
working on a real CAN log.

Build: clone the repo and follow the README. Pre-built deb / docker
images also circulate.
Open-source USB-CAN hardware + firmware from comma.ai. Three independent
CAN buses, USB-C host interface, full schematics / BOM / firmware on
GitHub. Useful as a hobbyist-priced alternative to Vector / Kvaser /
PEAK USB-CAN dongles — same socketcan / python-can compatibility
through their panda Python package, but the hardware is
genuinely open: you can build one, modify the firmware, audit what's
actually running on the wire.

For JEEP / FCA work specifically: three buses means you can sit on
CAN-C, CAN-IHS, AND the OBD-II port simultaneously in a single capture
session — useful for confirming which side of the
SGW a given message originated
on. Also has flash-protection modes ("safety models") that prevent
accidental writes to the wrong bus, which is more guardrail than most
dongles give you.

Spiritual successor to the older comma.ai pandacan-py and ChimpDriver
projects. Drivers ship with python-can —
can.interface.Bus(interface='gs_usb', ...) or
can.interface.Bus(interface='socketcan', channel='can0')
once the panda is bridged to a SocketCAN interface via their
panda daemon.

[ See Also ]