HOW-TO_REVERSE – Praxisleitfaden fürs CAN-Reverse-Engineering

Dieses How-To ist dein Werkzeugkasten, um aus nackten Frames echte Signale zu destillieren. Es ist kein Orakel, sondern ein Experimentier-Protokoll: miss, verifiziere, falsifiziere. Nutze es zusammen mit der GUI/CLI (Splitter, Explorer, Batch-Analyzer, Range-/Unsupervised-Fit).

0) Vorbereitungen (Daten sammeln wie ein Ingenieur)

Zustände trennen: Zündung an, Motor aus, Motor an Leerlauf, Schieben, aufgebockt Hinterrad drehen, kurze Fahrt.
Aktoren toggeln: Blinker, Bremse, Licht, Lüfter → generiere Ground-Truth für Bits/Flags.
Nur RX analysieren, wenn deine Hardware parallel TX sendet (Störmuster vermeiden).

1) Frame- & ID-Ebene zuerst

Repetition Rate (Hz): Zyklische Sensor-IDs senden stabil.
- Daumenwerte: WheelSpeed 20–100 Hz, RPM 10–50 Hz, TPS/APS 20–100 Hz, Lenkwinkel 50–100 Hz, Temperaturen 1–10 Hz.
Jitter der Periodizität: Streuung der Inter-Arrival-Times. Niedrig = sauberer Zyklus.
DLC-Stabilität: schwankende Payload-Länge → ggf. ISO-TP / Multiplex.
Change-Density: Anteil Frames mit Payload-Änderung. Zu hoch → Counter/Checksumme, zu niedrig → Status/Träge.

2) Byte/Bit-Signaturen

Bit-Flip-Rate pro Bit: ~50% → Flag/Event; sehr regelmäßig → Pattern/Timer.
Rolling Counter: 4/8-bit Sequenzen (0..15/255), oft konstant steigend.
Checksumme: Byte hängt deterministisch von anderen Bytes ab; häufig letzte Position.
Endianness: 16-bit LE/BE testen. Monotone Trends/kleine Deltas weisen auf richtige Byteordnung.
Quantisierung: typische Schrittweiten (z. B. 0.5 °C, 0.25 km/h).

3) Physik als Filter (Slew-Rate & Grenzen)

Miss ΔWert/Δt robust (95-Perzentil, nicht Max):

Temperaturen: sehr träge → ΔT/s ≪ 1 °C/s.
Fahrgeschwindigkeit: 0→100 km/h < 1 s unrealistisch; grob ≤ 30–50 km/h/s (Straße).
RPM: schnelle Sprünge möglich, aber nicht teleport. 1k→8k in 1–3 s plausibel.
Lenkwinkel: schnell, aber begrenzt; Jerk (ΔΔ/Δt) nicht absurd.

Alles, was diese Checks bricht, ist selten dein gesuchtes physikalisches Signal (oder deine Skalierung ist falsch).

4) Korrelation & Kausalität

Cross-Korrelation: RPM ↔ WheelSpeed (Gang drin), Brake-Bit ↔ Pressure, Blinker-Bit ↔ Blinkfrequenz (~1–2 Hz).
Gang aus Ratio (RPM/Speed) ableiten und Kandidaten validieren.
Event-Marker setzen und zeitgleichen Byte-Kipp suchen.

5) Protokoll & Multiplex

ISO-TP: Muster 0x10 len … (First Frame), 0x21… (Consecutive). Enthält selten einzelne Sensorkanäle.
Multiplexer: Ein Byte schaltet die „Seite“ der Payload um. Erkennbar am Sprungverhalten.

6) Statistik-Fingerabdrücke

Unique-Ratio = |unique|/n. Zu klein → Flag/Konstante; moderat → analog.
Entropy pro Byte → Daten/Checksumme vs. Status.
Plateaus/Hysterese: aktualisiert nur bei Δ≥Schwelle.

7) Scale/Offset systematisch schätzen

Scale-Raster: Dekaden + praxisnahe Werte (0.0625, 0.1, 0.25, 0.5, 0.75, 1, 2, 5, 10 …).
Offset via Intervall-Überdeckung: wähle das Offset, das die meisten Samples in [rmin, rmax] bringt.
Vorzeichen prüfen: signed/unsigned, ggf. negative Scales zulassen.

8) Workflow-Cookbook

Splitten (Logs → Traces).
ID-Explorer/Batch: Periodizität, Change-Density, 8/16-bit Plots.
Range-Fit mit physikalischen Ranges und Slew-Limits (Δ/Δt) + Rate/Jitter-Constraints.
Cross-Checks: Kandidaten gegen andere Kanäle testen (RPM↔Speed, Brake↔Pressure).
Iterieren: Range/Constraints verfeinern, Plots sichten, Hypothesen anpassen.

9) Typische Fallen

Falsche Endianness → Teleports.
Counter/Checksumme im selben 16-bit-Wort → zuerst trennen.
DLC<8 → 16-bit-Kombis fehlen; keine Dummies einstreuen.
×10/×100-Skalierung: Δ/Δt wirkt absurd groß.
BCD/ASCII in Diag/Odometer – nicht physikalisch.

10) Ziel: Berichte statt Bauchgefühl

Automatisiere Tests & Schwellen. Lass Skripts einen Analysebericht schreiben: „PASS (smooth, low jitter, rate ok)“ vs. „FAIL (jitter, slope99 zu hoch, hit-ratio zu klein)“.
Das minimiert Confirmation Bias – und macht Ergebnisse reproduzierbar.

4.3 KiB Raw Blame History Unescape Escape