# SID (Service Identifier)

> Der Service Identifier (SID) ist das erste Byte jedes UDS-Requests und sagt dem Steuergerät, welcher Service gemeint ist: 0x10 DiagnosticSessionControl, 0x22 ReadDataByIdentifier, 0x27 SecurityAccess, 0x31 RoutineControl und so weiter. ISO 14229-1 weist Requests die Bereiche 0x10 bis 0x3E und 0x83 bis 0x88 zu; eine positive Antwort nutzt SID + 0x40, eine negative beginnt mit 0x7F gefolgt vom abgelehnten SID. Jeden SID in jeder Session zu probieren ist der Weg, die Diagnoseoberfläche eines Steuergeräts zu kartieren.

Der SID ist das erste Byte jeder UDS-Nachricht und benennt den Service, von 0x10 DiagnosticSessionControl bis 0x3E TesterPresent. Bereiche, Antwortregel, SID-Sweep.

Source: https://auto-st.com/de/glossar/sid · Updated: 2026-10-07

## 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.

## FAQ

**Woran erkenne ich eine positive Antwort?**

Das erste Byte der Antwort ist der Request-SID plus 0x40. Auf 10 03 kommt 50 03, auf 22 F1 90 kommt 62 F1 90 mit Daten. Steht stattdessen 0x7F vorn, ist die Antwort negativ und das zweite Byte wiederholt den abgelehnten SID.

**Was ist das Sub-Funktions-Byte?**

Services wie 0x10, 0x11, 0x27 und 0x31 tragen ein zweites Byte, das eine Variante auswählt, zum Beispiel 10 03 für die Extended Session. Bit 7 dieses Bytes (0x80) ist das suppressPosRspMsgIndicationBit: 10 83 wechselt die Session ohne positive Antwort.

**Werden SIDs über 0x3E genutzt?**

Ja. 0x83 AccessTimingParameter, 0x84 SecuredDataTransmission, 0x85 ControlDTCSetting, 0x86 ResponseOnEvent und 0x87 LinkControl sind Standard-Services; 0xBA bis 0xBE sind für lieferantenspezifische Services reserviert, ihre Antworten liegen bei 0xFA bis 0xFE.

## Sources

- [ISO 14229-1:2020 Straßenfahrzeuge, Unified diagnostic services (UDS), Teil 1: Anwendungsschicht, Kapitel 8 und Tabelle 2 (Service-Identifier-Bereiche)](https://www.iso.org/standard/72439.html)
- [ISO 15765-2:2024 Straßenfahrzeuge, Diagnosekommunikation über CAN (DoCAN), Teil 2](https://www.iso.org/standard/84211.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-Nachrichten-Decoder](https://auto-st.com/de/tools/uds-nachrichten-decoder)
- [UDS Enumeration erklärt: wie man ein ECU sicher abbildet](https://auto-st.com/de/insights/uds-enumeration-explained)
- [Kenne jede Tür ins ECU.](https://auto-st.com/de/uds-enumeration)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/glossar/sid