ktncodes.
6 min read

AI Can Help Reverse Engineer a CAN Bus, as One Stage in a Pipeline

AI-assisted CAN bus reverse engineering works when the model sits inside a pipeline of deterministic decoding and validation. It fails when the model is asked to guess signals from raw frames.

embeddedaiai-agentsclaude-code

My day job is C++ and Qt for agricultural guidance displays, and CAN is the kind of network that vehicles and heavy machines run on. So when CSS Electronics published a demonstration of reverse engineering a CAN bus with Claude Code, it landed close to home.

I have not reverse engineered a CAN bus myself. I have debugged vehicle defects from CAN logs, but with the manufacturer's own decoding tools, which is the opposite situation. What follows is my reading of one worked demonstration and the notes I took on it.

The short version: the demonstration is convincing, and the reason is that the model does very little of the measuring.

CAN for a web developer

A CAN bus is a shared pair of wires. Every controller on it broadcasts small frames, and every other controller sees them. A frame is an ID plus a handful of data bytes, eight at most on classic CAN. There are no field names and no JSON.

A signal such as vehicle speed is a slice of bits somewhere in one of those frames. To read it you need the frame ID, where the bits start, how many there are, the byte order, whether the value is signed, and a scale and offset to turn the raw integer into a physical unit. Those rules live in a DBC file. If you come from the web, think of the DBC as the schema for a packed binary protocol, the way a .proto file is for protobuf.

Here is a made-up example, not one from the video:

raw frame:   ID 0x1A0   data 00 00 2E E0 00 00 00 00
DBC rule:    Speed = bytes 2-3, big-endian, unsigned, scale 0.01, offset 0
decoded:     0x2EE0 = 12000, and 12000 * 0.01 = 120.00 km/h

Manufacturers rarely publish their DBC files. The video notes two partial exceptions, the J1939 standard and a limited set of OBD2 data. For everything else, reverse engineering means recovering that rule from captured traffic. Done by hand, you watch which bits move while you press the accelerator. The presenter puts that at hours per signal.

Why asking the model to guess fails

A capture is millions of frames. Pasting that into a context window has two problems. The cost grows with the size of the trace, and nothing in the bytes says which ones are speed, so the model has no ground truth. It can only produce a plausible story.

The video argues this without showing a failed attempt, so I am taking it on reasoning. The presenter does reject the magic reading himself: without a clean reference signal, he says, raw CAN data alone is not enough.

The pipeline around the model

What the video demonstrates is a Claude Code skill that packages a procedure, some domain reference material, and a set of Python scripts. The sequence, as my notes record it:

  1. Capture the bus traffic together with a synchronized reference for the signal you want.
  2. Survey the trace: which IDs and bytes change, and which fields are counters or checksums to exclude.
  3. Rank candidate fields by how well they correlate with the reference.
  4. Search exhaustively over bit start, length, byte order, and sign.
  5. Fit the scale, then the offset.
  6. Write the DBC and a set of diagnostic plots.
  7. Verify against a separate capture and in a live decoder.

Steps two to six are scripts. The model's job is to carry the procedure, pick the next tool, read a compact result, and react when a check fails.

The reference in step one is the real requirement. It turns "find speed somewhere in here" into a search that can be proven wrong. The video ranks three kinds. A second digital measurement such as OBD2 is best. A dashboard filmed on video and read by OCR is next. A human moving a slider in time with a physical gauge is the fallback, and it needs fixed-value anchors to compensate for shaky hands.

The intermediate evidence is what I find persuasive. In the dashboard example the tool reports an OCR read rate of 88.3 percent and a mean confidence of 0.77, and rejects outliers before any correlation is run. The gauge example ends with hold and sweep checks that report Spearman correlations of 0.971 and 0.996. Each stage produces something a person can inspect, so a wrong answer has several places to get caught.

What I do not take at face value

CSS Electronics sells the interface hardware used throughout the video. The presenter built the skill. His estimate is that a signal drops from two to six hours of manual work to five or ten minutes once the reference data is recorded, and that figure comes from his own test set. I found no independent benchmark. In the project's favor, the code is open source and sample data for the first two demonstrations is public, so the claim can be checked.

My notes also list what the video passes over lightly: clock drift between the reference and the bus, a reference channel that lags, gateways or encryption hiding the traffic you need, multiplexed signals, and high correlations that are coincidence.

That list is why step seven matters. A generated DBC is a hypothesis until it passes a capture it was not fitted on and a check that the values are physically plausible.

The same shape as my own tooling

My research pipeline uses the same division of labor in a different domain. The skill I built for research notes has the model write claims with timestamp anchors, then runs a deterministic check on those anchors and refuses to finish until they verify. The model drafts, and a check it cannot argue with decides whether the work is done.

The CAN workflow generalizes the same way: find a measurable proxy, search coarsely, search exhaustively within bounds, fit the parameters, and verify on data held back. The agent tracks the procedure. The tools do the arithmetic.

Key Takeaways

  • Raw CAN frames carry IDs and bytes but no meaning. Recovering the decoding rule for each signal is the reverse engineering task.
  • Asking a model to find signals in raw frames runs into cost and a lack of ground truth.
  • The approach that works puts the model in charge of a procedure while scripts do the survey, correlation, bit search, and fitting.
  • A synchronized reference signal is the hard requirement, and its quality sets the ceiling on the result.
  • The time savings are vendor-reported. Treat any generated DBC as a hypothesis until it passes a held-out capture.

Sources

The sample data for the first two demonstrations is public, so my next step is to run it and read the intermediate plots for myself.