SID (Service Identifier)
The SID is the first byte of every UDS message and names the service, from 0x10 DiagnosticSessionControl to 0x3E TesterPresent. Ranges, response rule, SID sweeps.
Updated This page as Markdown
In short
The service identifier (SID) is the first byte of every UDS request and tells the ECU which service is being called: 0x10 DiagnosticSessionControl, 0x22 ReadDataByIdentifier, 0x27 SecurityAccess, 0x31 RoutineControl and so on. ISO 14229-1 assigns requests the ranges 0x10 to 0x3E and 0x83 to 0x88; a positive response uses SID + 0x40, a negative response starts with 0x7F followed by the rejected SID. Probing every SID in every session is how a tester maps the diagnostic surface of an ECU.
What is a SID?
The service identifier is the one byte at the start of every UDS message that says which service the tester wants. 10 is DiagnosticSessionControl, 11 ECUReset, 22 ReadDataByIdentifier, 27 SecurityAccess, 2E WriteDataByIdentifier, 31 RoutineControl, 34 RequestDownload, 3E TesterPresent. Everything after the SID belongs to that service: a sub-function byte for services that have one, then the parameters.
The response rule is simple. A positive response starts with the request SID plus 0x40: 10 03 is answered with 50 03 ..., 27 01 with 67 01 <seed>. A negative response is always three bytes, 7F, the rejected SID and a negative response code (NRC), for example 7F 27 36.
Where is it defined?
ISO 14229-1:2020 lists the service identifiers and their ranges in clause 8 and Table 2. Request SIDs for UDS occupy 0x10 to 0x3E and 0x83 to 0x88; 0x00 to 0x0F and 0x40 to 0x4F are left to the legacy OBD services of ISO 15031-5. Positive responses live at 0x50 to 0x7E and 0xC3 to 0xC8, 0x7F is the negative response identifier, and 0xBA to 0xBE (responses 0xFA to 0xFE) are reserved for system supplier specific services. The remaining values are reserved by ISO. Each service clause defines which sub-functions exist and which NRCs the ECU may return.
What it means in practice
Because the SID is the first byte, a tester can send every possible value and classify the ECU’s reaction. An unused SID gets 7F xx 11 serviceNotSupported. A SID that exists but needs another session gets 7F xx 7F serviceNotSupportedInActiveSession. A SID behind SecurityAccess gets 7F xx 33. A SID that answers with a wrong-length complaint, 7F xx 13, exists and is reachable right now. Repeating this sweep in the default, extended and programming session produces a map of the diagnostic surface in a few minutes.
We regularly see three kinds of findings in such a sweep: services that answer in the default session although they should need the extended session (typically 0x2E, 0x31 or 0x11), supplier specific services in the 0xBA to 0xBE range that nobody documented, and ECUs that answer 7F xx 10 generalReject to everything unknown, which hides the structure but still tells you which SIDs behave differently.
How AutoST tests it
The AutoST enumeration engine probes every SID from 0x00 to 0xFE in each discovered session and classifies the response as supported, security access denied, not supported in this session, conditions not correct or not supported. Risky services such as 0x11, 0x31, 0x34 and the memory services are flagged and weighted into the risk score; the fuzzing engine can then target selected or non-standard SIDs with malformed payloads.
Common misunderstandings
A SID is not a session and not a permission. 0x27 exists on almost every ECU, but existing is not the same as being unlocked. Also, the response SID + 0x40 rule is why 0x7F can never be a request: a request 0x3F would collide with the negative response identifier, so ISO reserves it.
FAQ
Frequently asked questions
How do I recognise a positive response?
Its first byte is the request SID plus 0x40. A request 10 03 is answered with 50 03, a request 22 F1 90 with 62 F1 90 and data. If the first byte is 0x7F instead, the response is negative and the second byte repeats the rejected SID.
What is the sub-function byte?
Services such as 0x10, 0x11, 0x27 and 0x31 carry a second byte that selects a variant, for example 10 03 for the extended session. Bit 7 of that byte (0x80) is the suppressPosRspMsgIndicationBit: 10 83 switches session without a positive response.
Are SIDs above 0x3E used?
Yes. 0x83 AccessTimingParameter, 0x84 SecuredDataTransmission, 0x85 ControlDTCSetting, 0x86 ResponseOnEvent and 0x87 LinkControl are standard services; 0xBA to 0xBE are reserved for system supplier specific services, and their responses sit at 0xFA to 0xFE.
Sources
Related pages
- GlossaryUDS (Unified Diagnostic Services)UDS (ISO 14229) is the diagnostic protocol of most automotive ECUs: sessions, services, DIDs and SecurityAccess. What it defines and why it is the first attack surface.
- GlossaryNRC (Negative Response Code)A UDS negative response is 7F, the rejected SID and a negative response code (NRC) such as 0x11, 0x33 or 0x7F. What the codes in ISO 14229-1 Annex A mean on the bench.
- GlossaryDiagnostic session (DiagnosticSessionControl 0x10)UDS DiagnosticSessionControl (0x10) switches an ECU between default, extended and programming session. Bytes, timing parameters and what to validate.
- Free toolsUDS Message DecoderPaste UDS bytes from a trace and see what they mean: service, sub-function, session, DIDs, routine identifier, SecurityAccess level or NRC, per ISO 14229-1.
- InsightsUDS enumeration explained: how to map an ECU safelyWhat UDS enumeration finds on an automotive ECU, why sessions and services matter, and how a non-destructive scan maps the diagnostic surface without breaking anything.
- PlatformKnow every door into the ECU.AutoST enumerates an ECU over UDS: diagnostic endpoints, sessions, all 255 services and readable DIDs, plus XCP/CCP discovery. Risky services are flagged automatically.
