Files
Kettenoeler/Reverse-Engineering CAN-Bus/HOW-TO-REVERSE.md
Marcel Peterkau a9053997a1
All checks were successful
CI-Build/Kettenoeler/pipeline/head This commit looks good
update of trace_signal_fitter.py and some doc
2025-08-27 23:59:57 +02:00

91 lines
4.3 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 20100 Hz, RPM 1050 Hz, TPS/APS 20100 Hz, Lenkwinkel 50100 Hz, Temperaturen 110 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 3050 km/h/s (Straße).
- **RPM**: schnelle Sprünge möglich, aber nicht teleport. 1k8k in 13 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 (~12 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
1. **Splitten** (Logs Traces).
2. **ID-Explorer/Batch**: Periodizität, Change-Density, 8/16-bit Plots.
3. **Range-Fit** mit physikalischen Ranges *und* **Slew-Limits** (Δ/Δt) + **Rate/Jitter-Constraints**.
4. **Cross-Checks**: Kandidaten gegen andere Kanäle testen (RPMSpeed, BrakePressure).
5. **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.