UDS (Unified Diagnostic Services)

Was ist UDS?

UDS ist das Diagnoseprotokoll auf Anwendungsebene, das fast jedes Steuergerät im Fahrzeug spricht. Ein Tester (der Client) schickt einen Request, das Steuergerät (der Server) antwortet. Das erste Byte eines Requests ist der Service Identifier (SID), danach folgen ein optionales Sub-Funktions-Byte und die Parameter des Services. Eine positive Antwort wiederholt den SID plus 0x40; eine negative Antwort ist immer 7F <SID> <NRC>.

Ein einzelner Austausch sieht so aus: 22 F1 90 fragt mit ReadDataByIdentifier nach dem Data Identifier F190 (die VIN), und das Steuergerät antwortet 62 F1 90 57 56 57 ... mit den 17 ASCII-Bytes der VIN. Lehnt das Steuergerät ab, antwortet es zum Beispiel 7F 22 33, securityAccessDenied.

ISO 14229-1 teilt die 26 Services in sechs Funktionsgruppen: Diagnose- und Kommunikationsmanagement (0x10 DiagnosticSessionControl, 0x11 ECUReset, 0x27 SecurityAccess, 0x28 CommunicationControl, 0x29 Authentication, 0x3E TesterPresent, 0x85 ControlDTCSetting und weitere), Datenübertragung (0x22, 0x23, 0x2E, 0x3D und weitere), gespeicherte Daten (0x14, 0x19), Ein-/Ausgabesteuerung (0x2F), Routinen (0x31) und Upload/Download (0x34 bis 0x38).

Wo ist es definiert?

ISO 14229-1:2020 definiert die Anwendungsschicht: Services, Sub-Funktionen, Parameter, die Negative Response Codes in Anhang A, die Standard-Data-Identifier in Anhang C und die Routine Identifier in Anhang F. ISO 14229-2 definiert die Session-Schicht und die Timing-Parameter P2, P2* und S3. Der Transport ist getrennt geregelt: ISO 15765-2 (ISO-TP) für CAN und CAN FD, ISO 13400-2 für DoIP über Ethernet. ISO 14229-3 bis -8 bilden UDS auf die einzelnen Transporte ab.

Was es in der Praxis bedeutet

UDS ist die größte Angriffsfläche, die ein Steuergerät ohne Zerlegen preisgibt. Alles, was ein Werkstatttester kann, kann ein Angreifer am Bus ebenfalls versuchen: in die Extended Session wechseln, Identifikations- und Kalibrierdaten lesen, Data Identifier schreiben, Routinen starten, Speicher löschen und neue Firmware herunterladen. Das Protokoll selbst bringt weder Verschlüsselung noch Authentifizierung mit; der Schutz muss im Steuergerät über Sessions und SecurityAccess kommen, und genau dort unterscheiden sich die Implementierungen.

Wir sehen regelmäßig Services, die in der Default Session antworten, obwohl die Herstellerspezifikation sie auf die Extended Session beschränkt, Data Identifier, die mehr preisgeben als nötig, und SecurityAccess-Implementierungen, die sich mit wenigen Requests umgehen lassen. Ein Trace aus UDS-Requests und -Antworten ist deshalb der schnellste Weg, den Schutz eines Steuergeräts einzuschätzen.

Wie AutoST es testet

AutoST spricht UDS über CAN, CAN FD und DoIP. Die Enumerations-Engine findet ISO-TP-Endpunkte und Diagnose-Sessions, probiert in jeder Session jeden SID von 0x00 bis 0xFE, klassifiziert die Antwort und liest die Data Identifier; die Diagnose-Engine ergänzt DID-Namen und Routinen aus ODX- oder CDD-Dateien; die SecurityAccess-Engine testet 0x27; die Fuzzing-Engine schickt fehlerhafte UDS-Payloads und achtet auf Abstürze. Die Ergebnisse fließen in einen Risiko-Score, einen PDF-Bericht und einen Fix Plan.

Häufige Missverständnisse

UDS ist kein Sicherheitsprotokoll und sollte nie eines sein. Es ist auch nicht auf CAN beschränkt: dieselben Requests laufen über DoIP, und ein Steuergerät, das am CAN gut geschützt ist, ist es nicht automatisch, wenn ein Gateway DoIP-Verkehr dorthin weiterleitet. Und ein Tester, der 7F xx 11 (serviceNotSupported) bekommt, hat etwas gelernt, nicht nichts: der Service existiert auf diesem Steuergerät nicht, anders als bei 7F xx 7F, das heißt, er existiert in einer anderen Session.