Diagnosetester vs. Security-Tester: Warum dein ODX-Tool kein Security-Test ist

Was ist der Unterschied?

Ein Diagnosetester ist gebaut, um eine Spezifikation zu bestätigen. Du lädst die ODX oder CDD, er kennt jeden Service, jede DID, jede Routine und deren Parameter und lässt dich diese ausführen: VIN lesen, Routine starten, Image flashen, DTCs löschen. Zum Testen eingesetzt beantwortet er die Frage “Tut das Steuergerät, was die Datei sagt?” Sein Bild vom Steuergerät ist die Datei. Eine DID, die nicht in der ODX steht, existiert für ihn nicht, und ein Service, der in der Default Session antwortet, obwohl die Datei Extended sagt, fällt ihm nicht auf, weil er wie befohlen zuerst die Extended Session öffnet.

Ein Security-Tester ist gebaut, um zu finden, was die Spezifikation nicht sagt. Er geht jede Session durch, schickt jeden Service Identifier und klassifiziert die Negative Response Codes, durchläuft den DID-Raum, den die Datei nicht erwähnt, zählt, wie viele falsche Keys SecurityAccess annimmt, probiert einen Key ohne Seed-Anforderung, prüft, ob eine Identifikations-DID schreibbar ist, und schickt dem Steuergerät dann fehlerhafte Eingaben und beobachtet, ob es überlebt. Sein Bild vom Steuergerät ist das, was das Steuergerät tatsächlich antwortet. Die ODX nützt ihm für Namen und zum Aufruf echter Routinen, nicht als Grenze des Tests.

Die beiden sind nicht austauschbar, und der Diagnosetester ist nicht schlechter. Konformitätstests sind nötig, und ein Security-Tool ist darin schlecht. Der Fehler ist, ein Konformitätstool zu benutzen und zu glauben, ein Security-Test habe stattgefunden.

Nebeneinander

	Diagnosetester	Security-Tester
Findet	Abweichungen von ODX oder CDD: falsche Antwortlängen, fehlende DIDs, Routinen, die fehlschlagen, Flash-Fehler, Timing-Verletzungen	Undokumentierte Services und DIDs, Services in der falschen Session, schreibbare Identifikations-DIDs, schwache oder konstante Seeds, fehlende Versuchszähler, Keys, die ohne Seed angenommen werden, Resets und Hänger beim Fuzzing, offenes XCP/CCP, DoIP-Routing und SOME/IP-Exposition
Übersieht	Alles, was nicht in der Datei steht: undokumentierte Oberfläche, Exposition in der falschen Session, SecurityAccess-Schwächen, Robustheit; er schickt nie absichtlich fehlerhafte Eingaben	Konformitätsdetails: Er prüft nicht, ob eine dokumentierte DID die richtige Länge oder Skalierung hat; Logik und verkettete Angriffe bleiben Sache des Pentesters
Wer macht es	Diagnose- und Absicherungs-Engineers	Dieselben Engineers aus einem Dashboard, oder ein Security-Team
Prüfstandszeit	Sekunden pro Sequenz; ein voller Konformitätslauf hängt von der Testspezifikation ab	Minuten für die Enumeration, Stunden für Fuzzing, unbeaufsichtigt
Kosten	Lizenzen kommerzieller Diagnosetools, oft schon im Haus	AutoST lizenziert pro getesteter Komponente, Preis auf Anfrage; freie Open-Source-Tools decken Teile davon ab
Passt in den Release-Zyklus	Ja, Konformitätssequenzen sind meist schon automatisiert	Ja, über API-Tokens und das Bamboo-Plugin, mit SARIF in den Tracker
Verlangt von	Diagnose-Konformitätsanforderungen des OEM; typgenehmigungsrelevante Diagnose bei Emissions-Steuergeräten	ISO/SAE 21434 Clause 10.4.2 [RC-10-12] Komponententests mit Fuzzing und Schwachstellen-Scans; UN R155 Tests der Sicherheitsmaßnahmen
Ergebnis	Pass oder Fail pro Testschritt, Trace-Logs	Karte der Oberfläche mit Risiko-Flags, Score von 0 bis 10, PDF-Bericht, SARIF, Fix Plan

Nimm den Diagnosetester, wenn

• die Frage Konformität ist: Verhält sich jeder dokumentierte Service über Varianten und Firmware-Releases wie spezifiziert. Dafür ist das Tool da, und es macht das besser als jedes Security-Tool.
• du das Steuergerät für andere Tests ansteuern musst: Flashen, Bandende-Routinen, Variantencodierung, DTC-Behandlung.
• du eine Hypothese schnell prüfen willst. “Funktioniert 2E F1 8C in der Default Session?” ist ein einzelner Request, und der Diagnosetester schickt ihn problemlos.
• niemand einen Security-Test verlangt hat und das Steuergerät keine Security-Ziele hat. Dann braucht auch niemand einen Security-Tester.

Nimm den Security-Tester, wenn

• jemand beantworten muss “Was kann ein Angreifer am Bus oder am OBD-Port mit diesem Steuergerät tun”, nicht “Erfüllt das Steuergerät die Spezifikation”. Die Findings, die wir am häufigsten sehen, Services in der Default Session erreichbar, schreibbare Fingerprints, Seeds ohne Zufälligkeit, kein Versuchszähler, sind für einen Konformitätslauf alle unsichtbar.
• das Steuergerät CAL 2 oder höher hat oder ein Assessor nach Fuzzing- und Schwachstellenscan-Nachweisen gemäß [RC-10-12] fragen wird.
• du das Ergebnis als Nachweis willst: einen datierten Bericht pro Firmware-Release, einen Score zum Vergleich der Releases, SARIF in den Tracker, einen Fix Plan mit Status.
• du den vollen DID- und Service-Raum abgedeckt haben willst, nicht die dokumentierte Teilmenge. Etwa zehn Minuten pro Session decken 0x0000 bis 0xFFFF ab; von Hand macht das kein Engineer.

Beides zusammen

Die beiden ergänzen sich und teilen eine Datei. Lade dieselbe ODX oder CDD in beide: Der Diagnosetester beweist, dass das Dokumentierte funktioniert, der Security-Tester beweist, dass nichts Undokumentiertes offen liegt und die dokumentierten Tore (Sessions, SecurityAccess) tatsächlich halten. Die Differenz zwischen beiden Bildern ist selbst ein Finding: Jede DID, die der Security-Tester liest und die in der Datei fehlt, ist eine Frage an den Zulieferer.

AutoST ist das zweite Tool in diesem Paar. Es importiert ODX-, PDX- und CDD-Dateien, um zu benennen, was die Enumeration findet, und um die darin definierten Routinen aufzurufen, und es überlässt Konformitätstests dem Tool, das du schon hast. Keines von beiden findet einen Seed/Key-Algorithmus, der durch sein Design schwach ist, oder eine Angriffskette über den Update-Pfad; dafür brauchst du einen Penetrationstester, der die Firmware liest.