Versteckte Diagnosedienste auf einem Steuergerät finden

Versteckte Diagnosedienste sind die Services, Sub-Funktionen, Sessions und Data Identifier, die ein Steuergerät beantwortet, die aber nicht in der ODX oder CDD stehen, die du bekommen hast. Du findest sie genauso wie die dokumentierten: sende jeden Request über den gültigen Bereich und lies den Response-Code. Der Unterschied ist, dass du das Ergebnis mit der Dokumentation vergleichst, und alles, was das Steuergerät beantwortet, aber die Dokumentation nicht erwähnt, ist ein Kandidat. Solche Dienste zählen, weil sie in keinem Bedrohungsmodell standen, also auch nicht geschützt wurden, und eine Routine oder ein DID, den niemand aufgeschrieben hat, ist genau die Art Sache, die einen Aktor bewegt oder ein Geheimnis preisgibt, ohne eine SecurityAccess-Prüfung davor.

Warum es sie gibt

Undokumentierte Services sind selten böswillig. Es sind Überbleibsel aus Entwicklung und Produktion:

• Werks- und End-of-Line-Routinen (RID), die das Steuergerät am Band konfigurieren oder testen.
• Kalibrier- und Messzugriff, der aus dem Entwicklungs-Build aktiv geblieben ist.
• Debug-DIDs, die internen Zustand, Speicherinhalte oder Build-Informationen zurückgeben.
• Eine herstellerspezifische Session (zum Beispiel 10 4F), die einen Satz Services freischaltet, den die Standard-Sessions nicht zeigen.
• Services, die in einer Session antworten, die niemand dokumentiert hat, weil die Dokumentation nur die Sessions des Diagnosetesters beschrieb.

Vor dem Produktionsstart waren sie nützlich. Die Security-Frage ist, ob sie entfernt, hinter SecurityAccess abgesichert oder einfach erreichbar gelassen wurden.

Prüfe den ganzen Raum, nicht den dokumentierten Teil

Die Methode ist erschöpfendes Probing mit Klassifikation nach Response-Code. Ein Spezifikations-Review sieht immer nur die dokumentierte Oberfläche, also muss das Probing mehr abdecken, als die ODX auflistet.

Sessions

Fordere jede Session 10 01 bis 10 7F an und halte fest, welche mit 50 (positiv) antworten statt mit 7F 10 12 (subFunctionNotSupported). Eine Session, die antwortet, aber nicht dokumentiert ist, ist die erste Stelle zum Nachsehen, weil sie oft die versteckten Services absichert.

10 01 -> 50 01            Default, dokumentiert
10 03 -> 50 03            Extended, dokumentiert
10 4F -> 50 4F            antwortet, nicht in der ODX  <- untersuchen

Services

Sende in jeder antwortenden Session jeden Service Identifier 0x00 bis 0xFE und klassifiziere die Antwort:

Antwort	Bedeutung
positiv (SID + 0x40)	Service unterstützt und beantwortet
7F xx 11	serviceNotSupported, nicht implementiert
7F xx 7F	serviceNotSupportedInActiveSession, existiert anderswo
7F xx 33	securityAccessDenied, existiert und ist abgesichert
7F xx 22	conditionsNotCorrect, existiert, Vorbedingungen fehlen

Die nützliche Erkenntnis ist, dass 0x11, 0x7F, 0x33 und 0x22 alle bestätigen, dass der Service existiert; nur 0x11 heißt, er fehlt wirklich. Ein Service, der 0x33 antwortet, ist durch seine eigene Ablehnung dokumentiert, auch wenn kein Papier ihn erwähnt.

Sub-Funktionen und DIDs

Für einen Service mit Sub-Funktionen, etwa RoutineControl (0x31) oder IOControl (0x2F), tastest du die Sub-Funktions- und Identifier-Bereiche ab und klassifizierst genauso. Bei DIDs liest du den vollen Raum 0x0000 bis 0xFFFF, nicht nur den Identifikationsblock 0xF1xx, denn Debug- und interne DIDs liegen meist außerhalb des dokumentierten Bereichs. Ein positives Lesen eines DID, der nicht in der ODX steht, ist ein versteckter lesbarer Wert; sieh dir an, was er zurückgibt.

Was ein versteckter Service bedeutet

Ein gefundener Service ist nicht automatisch ein Finding. Klassifiziere ihn danach, was er tun kann:

• Lesbarer undokumentierter DID: eine Offenlegungsfrage. Gibt er ein Geheimnis, einen Key, Speicher oder personenbezogene Daten preis?
• Undokumentierte Routine: die größte Sorge. Eine Routine kann Aktoren bewegen, Speicher löschen oder Konfiguration ändern. Ob sie hinter SecurityAccess abgesichert ist, entscheidet über den Ernst.
• Undokumentierte Session: ein Sprungbrett, gefährlich wegen dessen, was sie freischaltet, also prüfe, welche Services erreichbar werden, sobald sie aktiv ist.
• Service in der falschen Session erreichbar: ein Service für das Produktionsband, der noch in einer Feld-Session antwortet, ist eine Oberfläche, die hätte geschlossen sein müssen.

Die entscheidende Frage ist bei jedem das Tor davor. Eine Werksroutine, die noch funktioniert, in einer erreichbaren Session, ohne SecurityAccess, ist die Art Finding, die einen Fix vor dem Produktionsstart rechtfertigt.

Wie AutoST sie findet

Die Enumeration-Engine von AutoST erledigt den erschöpfenden Teil automatisch: sie tastet Sessions, jeden Service Identifier je Session, Sub-Funktionen und den vollen DID-Bereich ab und klassifiziert jeden Response-Code. Ist eine ODX- oder CDD-Datei geladen, benennt sie die bekannten Services und DIDs, sodass alles, was antwortet, aber nicht in der Datei steht, als undokumentiert heraussticht. So gefundene Routinen und schreibbare Identifier fließen in den ODX- und CDD-gestützten Scan mit vorsichtigem, bestätigungspflichtigem Schreib-Probing. Es geht darum, die Oberfläche sichtbar zu machen, die niemand dokumentiert hat, und dann einen Tester entscheiden zu lassen, was jeder Punkt bedeutet.