# 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
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 (RPM↔Speed, Brake↔Pressure).  
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.