# Versteckte Diagnosedienste auf einem Steuergerät finden Wie undokumentierte UDS-Services, Sessions und DIDs durch Probing und Response-Codes gefunden werden, warum es sie gibt, und was ein versteckter Service bedeutet. Source: https://auto-st.com/de/insights/versteckte-diagnosedienste-finden · Updated: 2026-10-07 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. ## FAQ **Was ist ein versteckter Diagnosedienst?** Ein Service, eine Sub-Funktion, eine Session oder ein Data Identifier, den das Steuergerät beantwortet, der aber nicht in der ODX oder CDD steht, die der Zulieferer übergeben hat. Versteckt ist er nicht vor dem Steuergerät, nur vor der Dokumentation, und deshalb findet Probing ihn und ein Spezifikations-Review nicht. **Warum gibt es undokumentierte Services?** Es sind meist Überbleibsel aus Entwicklung und Produktion: Werksroutinen, Kalibrierzugriff, Debug-DIDs, eine Hersteller-Session, die zusätzliche Services freischaltet. Vor dem Produktionsstart waren sie nützlich und wurden nie entfernt oder abgesichert. **Ist das Suchen danach sicher?** Lesen und Discovery sind nicht-destruktiv. Das Risiko liegt in dem, was ein versteckter Service tut, sobald er gefunden ist, etwa eine Routine, die einen Aktor bewegt. Ein neu gefundener Service wird deshalb vorsichtig geprüft, und die, die handeln könnten, bleiben einem kontrollierten Test vorbehalten. ## Sources - [ISO 14229-1:2020 Straßenfahrzeuge, Unified diagnostic services (UDS), Teil 1: Anwendungsschicht](https://www.iso.org/standard/72439.html) - [ISO 15765-2:2024 Straßenfahrzeuge, Diagnosekommunikation über CAN (DoCAN), Teil 2: Transportprotokoll](https://www.iso.org/standard/84211.html) - [ISO/SAE 21434:2021 Straßenfahrzeuge, Cybersecurity-Engineering](https://www.iso.org/standard/70918.html) ## Related - [UDS (Unified Diagnostic Services)](https://auto-st.com/de/glossar/uds) - [NRC (Negative Response Code)](https://auto-st.com/de/glossar/nrc) - [Diagnose-Session (DiagnosticSessionControl 0x10)](https://auto-st.com/de/glossar/diagnose-session) - [UDS Enumeration erklärt: wie man ein ECU sicher abbildet](https://auto-st.com/de/insights/uds-enumeration-explained) - [UDS Negative Response Codes erklärt für Tester](https://auto-st.com/de/insights/uds-negative-response-codes-erklaert) - [Kenne jede Tür ins ECU.](https://auto-st.com/de/uds-enumeration) --- AutoST by Zyberum. Canonical page: https://auto-st.com/de/insights/versteckte-diagnosedienste-finden