[ Car Hacking — Guides & Tutorials ]

Long-form material for the car-hacking section. Two flavours:

  Tutorials      hands-on walkthroughs where you DO something
                 (set up a virtual CAN lab, sniff UDS traffic from a
                 known-good scan tool, etc.). Run-along format.

  Reference Guides  read-once material that explains a protocol,
                 a module, or an architectural pattern. Look-up format.

For the scripts these guides are built around, the hardware reference,
and the curated link list, see the Car Hacking parent page.

Vendor-neutral primer on the CAN protocol -- physical layer
(differential 2-wire signalling, CAN-H / CAN-L voltages, terminator
placement), multi-master arbitration (lossless bit-by-bit collision
resolution, lower-ID-wins priority), frame anatomy (11-bit vs
29-bit IDs, SOF / DLC / DATA / CRC / ACK fields, the 8-byte payload
ceiling that motivates ISO-TP), bitrates and variants (classical
CAN at 125 / 250 / 500 kbps, CAN-FD, CAN XL), what rides on top
(ISO-TP transport layer, UDS diagnostic services, OBD-II, SAE
J1939 for heavy trucks, CANopen for industrial automation),
tooling (SocketCAN, can-utils, python-can, SavvyCAN, hardware
adapter shortlist), and safety practice (listen-only first,
integrity-protected IDs with rolling counters + CRC, brick-recovery
realities).

Designed as the prerequisite for the JEEP-specific
primer and the rest of the
applied material on the parent page.  Read this first if you've
heard of CAN but never touched one; skip if you already know the
difference between SF / FF / CF / FC framing.

Hands-on primer for new CAN-bus hackers working on the JEEP platform.
Covers proven Waveshare 2-channel CAN HAT config.txt
parameters and ip link / ifconfig initialization, the
can0-vs-can1 naming gotcha, terminating resistors (you don't need to
add any), CAN-C vs CAN-IHS payload-size discrimination on duplicate
IDs ($12B is 1-byte on IHS, 8-byte on C), sleep / wake
behavior (including the $2D3 empty-bitmap wake fallback
that several on-site scripts use), what to expect from time-driven vs
event-driven messages, partially-offline sensor sentinels, and a worked
hexadecimal-to-decimal printf pattern that all the bash
scripts use.

The TTCAN section is what makes this primer specifically JEEP-shaped:
the Wrangler's CAN-C and CAN-IHS aren't ordinary CAN but a time-
triggered variant where most slots are pre-reserved for specific
message IDs. Includes a textual matrix-cycle rendering and a pointer at
the Leen &
Heffernan 2002 paper that originally formalised the scheduling
model. The $400 TTCAN controller ID is flagged for further
discovery work.

Closes with safety: airbag-deployment likelihood (low but not zero,
treatments to make it lower), short-circuit consequences (engine code
+ a stern look from the dash, not permanent damage absent cut wires),
and the always-relevant "don't fuzz random IDs at your own car"
advisory. Originally written by jmccorm; page polish and cross-links
by magikh0e.

Hands-on lab for learning CAN bus reverse-engineering WITHOUT a real vehicle.
Install py-can +
can-utils, bring up a pair
of virtual CAN interfaces (vcan0 / vcan1 to mirror CAN-IHS / CAN-C), replay
a captured drive log via canplayer, and watch the traffic in tkcan.py or the
newer pyJeepCan.py curses dashboard. Includes
candump format walkthrough, a worked $12B decode example, a verifiable
"what you should observe" checklist, cross-links to the
Bus & Message Reference for ID
lookups, and teardown commands.

Download: tkcan.py (Tk viewer) |
pyJeepCan.py (curses viewer) |
CANBus Log Files

Hands-on intro to UDS reverse-engineering, using JScan as a known-good
stimulus tool. Connect JScan, click a Live-Data field or an Activation,
sniff what JScan sends with isotpdump and candump,
decode the protocol byte-by-byte. The walkthrough covers Service 0x22
(ReadDataByIdentifier — reading battery voltage via DID $D020 on the
HVAC module's $783/$503 ID pair) and Service 0x2F (IOControlByIdentifier
— honking the horn via DID $D0AD on the BCM's $620/$504 pair).

Also walks through the "request_service + 0x40 = positive response" rule
and the 0x7F negative-response form, both of which carry across every
other UDS service. Includes pointers to the
Bus & Message Reference,
horn.sh, and
3rd_brakelight.sh as natural
follow-ons.

Original walkthrough by jmccorm; page polish by magikh0e. Same technique
applies to any UDS-speaking diagnostic tool (wiTECH, Autel, Launch X431,
Topdon) — JScan is just the example.

CAN-C vs CAN-IHS topology, TIPM/TIPMCGW gateway behavior, and decoded message
IDs with byte-level evidence lifted from the scripts above — $1C0 RKE
payloads, $122 ignition state, $25D radio mute, $291 lights / turn signals,
$328 EVIC text, $350 RTC layout, $2D3 NM wake and the UDS service path used by
3rd_brakelight.sh ($620 / DID $D1B3), plus the full JEEP live-data message
map extracted from pyJeepCan.py.  Worked Service 0x2F (write) and Service 0x22
(read) examples for direct module interaction.  Includes candidate IDs for
unverified next-additions (fuel level, throttle, TPMS, ambient temp,
sway-bar / locker requests on JL Wrangler) and caveats on model/year
variance.

Read-side counterpart to UDS Write Operations below.  Covers Service 0x22
ReadDataByIdentifier — the on-wire protocol, positive / negative response
codes, the FCA module catalog (BCM / SCCM / Radio / IPCM / HVAC arbitration-ID
pairs and which CAN bus each sits on), DID discovery patterns (ISO-standardised
F1xx identification range, observed manufacturer-specific clustering, scan-tool
capture as a discovery shortcut), ISO-TP framing for multi-frame responses
(VIN spans three CAN frames), and the SGW pass-through rules that explain why
0x22 reads work from the OBD-II port without AutoAuth on 2018+ FCA vehicles
while 0x2F / 0x2E / 0x31 writes don't.  Includes the rid.sh / ridscan.sh /
read_vin_uds.py scripts that implement the pattern.

The shared pattern behind every actuator-control script on the parent page
(3rd_brakelight, horn / 3honk, 2k). Covers UDS Services 0x2F (IOControl),
0x2E (WriteDataByIdentifier), 0x31 (RoutineControl), and 0x27 (SecurityAccess);
the two cleanup patterns (toggle-and-release vs hold-via-TesterPresent);
known writable targets with verified DIDs and routine IDs; SGW interaction
(what passes through the OBD-II port vs what requires direct CAN access);
and the safety discipline that separates a useful demo from a bricked
module.

Reference guide to the FCA / Stellantis Secure Gateway Module on 2018+ vehicles —
what it is, why it sits between the OBD-II port and the rest of the CAN bus, what
it gates (writes blocked, reads allowed), how AutoAuth authentication works,
hardware bypass options and their trade-offs, and how the SGW relates to the
Uconnect head unit. Written from the perspective of someone working on these
cars rather than someone selling a $5,000 scan tool.

The shared architectural pattern behind every state-change automation
script on the parent page (Blackbox_monitor, autocollect, Remote_WiFi, backlight).
Covers the candump + state-machine loop structure, edge vs level triggering,
three rate-limiting strategies, three cleanup disciplines (explicit reset,
deliberate non-reset, restore-to-safe), hardware lifecycle integration
(crank brown-out, vehicle sleep, SD card flush), bus-quiet reconnect handling,
and a worked example for adding your own handler for a new message ID.

Bridge between raw candump sniffing and UDS diagnostics work. Covers the
CAN vs ISO-TP mental model, ISO-TP frame types (SF / FF / CF / FC) with byte
layouts, isotpdump invocation and argument walkthrough, how to discover
tester/ECU ID pairs on a target platform, and a worked Single Frame example
matching the 3rd_brakelight.sh UDS request.