UDS (Unified Diagnostic Services)

What is UDS?

UDS is the diagnostic application protocol that almost every automotive ECU speaks. A tester (the client) sends a request, the ECU (the server) answers. The first byte of a request is the service identifier (SID), followed by an optional sub-function byte and the parameters of that service. A positive response repeats the SID plus 0x40; a negative response is always 7F <SID> <NRC>.

A single exchange looks like this: 22 F1 90 asks for data identifier F190 (the VIN) with ReadDataByIdentifier, and the ECU answers 62 F1 90 57 56 57 ... with the 17 ASCII bytes of the VIN. If the ECU refuses, it answers for example 7F 22 33, securityAccessDenied.

ISO 14229-1 groups its 26 services into six functional units: diagnostic and communication management (0x10 DiagnosticSessionControl, 0x11 ECUReset, 0x27 SecurityAccess, 0x28 CommunicationControl, 0x29 Authentication, 0x3E TesterPresent, 0x85 ControlDTCSetting and others), data transmission (0x22, 0x23, 0x2E, 0x3D and others), stored data (0x14, 0x19), input/output control (0x2F), routines (0x31) and upload/download (0x34 to 0x38).

Where is it defined?

ISO 14229-1:2020 defines the application layer: services, sub-functions, parameters, the negative response codes in Annex A, the standard data identifiers in Annex C and the routine identifiers in Annex F. ISO 14229-2 defines the session layer and the timing parameters P2, P2* and S3. The transport is separate: ISO 15765-2 (ISO-TP) for CAN and CAN FD, ISO 13400-2 for DoIP over Ethernet. ISO 14229-3 to -8 map UDS onto each transport.

What it means in practice

UDS is the largest attack surface an ECU exposes without physical disassembly. Everything a workshop tester can do, an attacker on the bus can attempt as well: switch into the extended session, read identification and calibration data, write data identifiers, start routines, erase memory and download new firmware. The protocol itself carries no encryption and no authentication; the ECU has to add protection through sessions and SecurityAccess, and that is where implementations differ.

We regularly see services that answer in the default session although the manufacturer specification restricts them to the extended session, data identifiers that leak more than they should and SecurityAccess implementations that can be bypassed in a few requests. A trace of UDS requests and responses is therefore the fastest way to judge how well an ECU is protected.

How AutoST tests it

AutoST speaks UDS over CAN, CAN FD and DoIP. The enumeration engine discovers ISO-TP endpoints and diagnostic sessions, probes every SID from 0x00 to 0xFE in each session, classifies the response and reads the data identifiers; the diagnostics engine adds DID names and routines from ODX or CDD files; the SecurityAccess engine tests 0x27; the fuzzing engine sends malformed UDS payloads and watches for crashes. The results feed a risk score, a PDF report and a Fix Plan.

Common misunderstandings

UDS is not a security protocol and was never meant to be one. It is also not limited to CAN: the same requests travel over DoIP, and an ECU that is well protected on CAN is not automatically protected when a gateway routes DoIP traffic to it. Finally, a tester that gets 7F xx 11 (serviceNotSupported) has learned something, not nothing: the service does not exist on this ECU, in contrast to 7F xx 7F, which means it exists in another session.