ODX-gestütztes Testen: Diagnosedaten in Tests verwandeln

ODX-gestütztes Testen heißt, die Diagnosebeschreibung zu nutzen, die du schon hast, um zu benennen, was ein Scan findet, und genau die Dienste aufzurufen, die ein ECU definiert, statt zu raten. ODX (Open Diagnostic Data Exchange, ISO 22901-1) ist das Standardformat für diese Beschreibung, und sie in einen Security-Test einzuspeisen verwandelt einen rohen Hex-Dump in etwas, das wie deine eigene Diagnose-Spezifikation liest. Hier ist, was die Daten enthalten und wie sie einen Test schärfen.

Was ODX wirklich ist

ODX ist ein XML-Datenmodell, standardisiert als ISO 22901-1, das die Diagnosekommunikation eines ECU beschreibt: die Dienste, die es unterstützt, die Data Identifier, die es offenlegt, die Routinen, die es ausführt, und wie jeder Request und jede Response aufgebaut ist. Es wird meist als PDX (Packed ODX) ausgeliefert, ein Container, im Grunde ein ZIP, der die ODX-Dateien für ein oder mehrere ECUs bündelt, damit die ganze Beschreibung als ein einziges Artefakt reist.

Der praktische Punkt ist, dass eine ODX-Datei die Grundwahrheit darüber ist, was ein ECU anbietet, geschrieben von den Leuten, die es gebaut haben. Ein Security-Test, der sie ignoriert, arbeitet blind; einer, der sie liest, startet von der echten Karte.

Der DIAG-LAYER, und wie er Dinge benennt

ODX organisiert Diagnostik in Schichten. Die für Tests wichtige ist der DIAG-LAYER (die Diagnoseschicht für eine bestimmte ECU-Variante). In ihm definieren die Daten:

• Data Identifier. Ein DID wie 0xF190 wird mit einem Kurznamen, einem Langnamen und einer Struktur beschrieben: DID 0xF190 = "VIN", 17 Bytes, ASCII. Der Scan zeigt nicht länger eine bloße Nummer, er zeigt den Namen.
• Routinen. Ein Routinen-Identifier (RID), den RoutineControl (0x31) nutzt, wird mit seinen Sub-Funktionen (start, stop, request results) und den Parametern definiert, die jede nimmt. Die Daten sagen dir, dass die Routine existiert und wie man sie korrekt aufruft.
• Request- und Response-Struktur. Die Parameter jedes Dienstes, ihre Positionen, Längen und Kodierungen, sodass eine Response in Felder statt Bytes dekodiert werden kann.
• Negative-Response-Behandlung. Die erwarteten NRCs eines Dienstes, was hilft, einen echten Fund von normalem Verhalten zu unterscheiden.

Ein konkretes Vorher und Nachher. Ohne ODX findet die Enumeration:

22 F1 A0 -> 62 F1 A0 03 1F 00 ...   DID 0xF1A0 lesbar, Wert unbekannt

Mit geladenem DIAG-LAYER liest sich dasselbe Ergebnis:

DID 0xF1A0 "Kalibrier-Datensatzversion" lesbar, Wert 3.31.0

Der Wert wurde gerade bedeutsam, und das ist der Unterschied zwischen einer Liste lesbarer Adressen und einem Verständnis dafür, was jede offenlegt.

Warum Routinen aus den Daten kommen, nicht aus Brute Force

DIDs lassen sich durchfegen, weil der Identifier-Raum endlich und eine Lesung billig ist. Routinen lassen sich nicht sinnvoll per Brute Force durchprobieren: ein RoutineControl-0x31-Start mit falschen Parametern kann einen Aktor bewegen, eine Flash-Löschung starten oder das ECU in einen seltsamen Zustand versetzen. Man feuert keine zufälligen Routinen auf ein ECU und sieht, was passiert.

ODX löst das. Weil der DIAG-LAYER jede Routine und ihre Parameter definiert, kann ein Scan genau die Routinen aufrufen, die das ECU deklariert, mit der richtigen Payload, und die Ergebnisse lesen, die das ECU zurückgibt. Das ist sicherer und gründlicher als Raten, weil es die wichtigen Routinen abdeckt, ohne solche zu berühren, die nie definiert wurden.

RID 0xFF00 "Programmier-Vorbedingungen prüfen"
tx 31 01 FF 00        startRoutine, laut DIAG-LAYER ohne Zusatzparameter
rx 71 01 FF 00 00     Routine gestartet, Ergebnis-Byte 0x00

Was das für Security-Tests bringt

ODX zu laden ändert einen Test auf vier Arten:

1. Lesbare Ergebnisse. Findings benennen DID und Routine, sodass der Bericht wie deine Spezifikation liest und ein Entwickler sofort weiß, was betroffen ist.
2. Gezielte Routinen-Abdeckung. Der Scan fährt die Routinen, die das ECU wirklich definiert, nicht eine zufällige Teilmenge, und zeichnet Request und Response für jede auf.
3. Sichereres Write-Probing. Ist Write-Probing (0x2E) aktiviert, heißt die Struktur aus ODX, dass der Test korrekt geformte Daten schreibt und Länge und Write-Back-Verhalten prüfen kann, statt blind fehlerhafte Payloads zu feuern. Write-Probing bleibt destruktiv, standardmäßig aus und vor dem Ausführen bestätigt.
4. Schnellere, sauberere Scans. Von der echten Karte zu starten überspringt die Sackgassen reinen Brute Force.

Wie AutoST es nutzt

AutoST importiert ODX, ODX-D und PDX (den ASAM-Standard) und Vector CDD (Candela XML) und normalisiert beides zu einer Liste von DIDs und Routinen je ECU. Die DID-Namen reichern die Enumeration-Ergebnisse an, sodass ein entdeckter Identifier seinen echten Namen zeigt, und die Routinen-Definitionen treiben den Routinen-Scan (0x31): AutoST ruft nur die Routinen auf, die in deiner Datei definiert sind, mit einer Payload, die du überschreiben kannst, und speichert jeden Request und jede Response. Du hängst die Datei einmal ans ECU, und jeder Scan nutzt sie. Vertrauliche Diagnosedateien bleiben auf deiner eigenen Instanz, was zählt, weil eine ODX oder CDD oft so sensibel ist wie das ECU, das sie beschreibt.