SID (Service Identifier)

Was ist ein SID?

Der Service Identifier ist das eine Byte am Anfang jeder UDS-Nachricht, das sagt, welchen Service der Tester will. 10 ist DiagnosticSessionControl, 11 ECUReset, 22 ReadDataByIdentifier, 27 SecurityAccess, 2E WriteDataByIdentifier, 31 RoutineControl, 34 RequestDownload, 3E TesterPresent. Alles nach dem SID gehört zu diesem Service: ein Sub-Funktions-Byte bei Services, die eines haben, dann die Parameter.

Die Antwortregel ist einfach. Eine positive Antwort beginnt mit dem Request-SID plus 0x40: auf 10 03 kommt 50 03 ..., auf 27 01 kommt 67 01 <seed>. Eine negative Antwort hat immer drei Bytes, 7F, den abgelehnten SID und einen Negative Response Code (NRC), zum Beispiel 7F 27 36.

Wo ist es definiert?

ISO 14229-1:2020 listet die Service Identifier und ihre Bereiche in Kapitel 8 und Tabelle 2. Request-SIDs für UDS belegen 0x10 bis 0x3E und 0x83 bis 0x88; 0x00 bis 0x0F und 0x40 bis 0x4F bleiben den alten OBD-Services der ISO 15031-5 vorbehalten. Positive Antworten liegen bei 0x50 bis 0x7E und 0xC3 bis 0xC8, 0x7F ist der Negative-Response-Identifier, und 0xBA bis 0xBE (Antworten 0xFA bis 0xFE) sind für lieferantenspezifische Services reserviert. Die übrigen Werte reserviert ISO. Jedes Service-Kapitel definiert, welche Sub-Funktionen es gibt und welche NRCs das Steuergerät zurückgeben darf.

Was es in der Praxis bedeutet

Weil der SID das erste Byte ist, kann ein Tester jeden möglichen Wert senden und die Reaktion des Steuergeräts klassifizieren. Ein unbenutzter SID bekommt 7F xx 11 serviceNotSupported. Ein SID, der existiert, aber eine andere Session braucht, bekommt 7F xx 7F serviceNotSupportedInActiveSession. Ein SID hinter SecurityAccess bekommt 7F xx 33. Ein SID, der sich über die falsche Länge beschwert, 7F xx 13, existiert und ist jetzt gerade erreichbar. Wiederholst du diesen Sweep in Default, Extended und Programming Session, hast du in wenigen Minuten eine Landkarte der Diagnoseoberfläche.

Wir sehen in solchen Sweeps regelmäßig drei Arten von Findings: Services, die in der Default Session antworten, obwohl sie die Extended Session bräuchten (typisch 0x2E, 0x31 oder 0x11), lieferantenspezifische Services im Bereich 0xBA bis 0xBE, die niemand dokumentiert hat, und Steuergeräte, die auf alles Unbekannte 7F xx 10 generalReject antworten, was die Struktur versteckt, aber trotzdem verrät, welche SIDs sich anders verhalten.

Wie AutoST es testet

Die Enumerations-Engine von AutoST probiert in jeder gefundenen Session jeden SID von 0x00 bis 0xFE und klassifiziert die Antwort als supported, security access denied, not supported in this session, conditions not correct oder not supported. Riskante Services wie 0x11, 0x31, 0x34 und die Speicher-Services werden markiert und gewichtet in den Risiko-Score aufgenommen; die Fuzzing-Engine kann anschließend ausgewählte oder nicht standardisierte SIDs mit fehlerhaften Payloads angehen.

Häufige Missverständnisse

Ein SID ist keine Session und keine Berechtigung. 0x27 existiert auf fast jedem Steuergerät, aber Existieren ist nicht dasselbe wie Entsperrt-Sein. Außerdem erklärt die Regel SID + 0x40, warum 0x7F nie ein Request sein kann: ein Request 0x3F würde mit dem Negative-Response-Identifier kollidieren, deshalb reserviert ISO ihn.