UDS (Unified Diagnostic Services)
UDS, Unified Diagnostic Services per ISO 14229, is the diagnostic protocol of nearly every ECU. Which services exist, how access control works and what to test.
Updated This page as Markdown
In short
UDS (Unified Diagnostic Services) is the diagnostic protocol defined in ISO 14229 that a tester uses to read data, clear fault codes, run routines and flash software on an ECU. It runs over CAN (via ISO-TP) and Ethernet (via DoIP). Because UDS can write memory and reprogram the ECU, its access control, SecurityAccess (0x27) and Authentication (0x29), is one of the most important security boundaries in a vehicle.
What is UDS?
UDS is the diagnostic protocol with which a diagnostic tester (client) controls functions in an electronic control unit (server). ISO 14229-1 defines the services independently of the bus: every service has a service identifier, a request with optional sub-functions and parameters, a positive response (service identifier plus 0x40) and a negative response (0x7F, service identifier, negative response code).
The most important services: DiagnosticSessionControl (0x10) switches between the default, extended and programming sessions; ECUReset (0x11); ReadDataByIdentifier (0x22) and WriteDataByIdentifier (0x2E) read and write data addressed by 16-bit data identifiers (DIDs); ReadDTCInformation (0x19) reads the fault memory; RoutineControl (0x31) starts manufacturer-specific routines; RequestDownload (0x34), TransferData (0x36) and RequestTransferExit (0x37) flash software; TesterPresent (0x3E) keeps a session alive. SecurityAccess (0x27) and Authentication (0x29) protect the sensitive services.
Where is it defined?
The ISO 14229 series has several parts: Part 1 defines the application layer, Part 2 the session layer services, Part 3 UDS on CAN (UDSonCAN), Part 5 UDS on IP (UDSonIP), and further parts cover FlexRay, K-Line and LIN. On CAN, ISO 15765-2 (ISO-TP) segments messages of up to 4095 bytes; on Ethernet, ISO 13400 (DoIP) carries diagnostic messages over TCP/IP. The actual assignment of DIDs and routines is not in the standard but in the manufacturer’s diagnostic specification, often as an ODX or CDD file.
ISO/SAE 21434 names fuzz testing and penetration testing as verification methods in clause 10, and UN R155 requires in Annex 5 measures against the misuse of diagnostic functions. In practice both land on the UDS interface.
What it means in practice
UDS is present in every ECU and reachable through the OBD port, through telematics units with remote diagnostics and through DoIP on the vehicle network. The diagnostic interface is therefore in focus in nearly every ECU penetration test we do, from power-electronics ECUs such as DC/DC converters and on-board chargers to infotainment systems. The assessment follows three questions:
- What is reachable, and in which session? We enumerate all offered services, DIDs and routines and compare with the specification. Deviations are common: forgotten production-line routines, DIDs holding calibration data or key material, write services that do not require a session change.
- How good is the access control? A solid SecurityAccess implementation uses random seeds of sufficient length, a cryptographically strong key algorithm with an ECU-specific key, failed-attempt counters and delays. If one of these is missing we rate it as a finding and demonstrate it on the device.
- Does the implementation withstand invalid input? Wrong lengths, unknown sub-functions, aborted transfers and manipulated ISO-TP segmentation must not crash or reset the ECU. Fuzzing answers that; detection works through TesterPresent heartbeats, reset observation and the ECU’s negative responses.
Our product AutoST automates exactly these steps: enumeration of sessions, services, DIDs and routines, comparison with ODX or CDD databases, assessment of the access control and protocol-aware fuzzing with reset detection.
Common misunderstandings
“UDS is only for the workshop” underestimates that the interface can be reachable remotely through telematics and DoIP, and that diagnostic testers are cheap to buy. “SecurityAccess is enabled, so the flash is protected” says nothing about the quality of the algorithm and the key management. And a flawless diagnostic specification does not guarantee that the firmware implements it flawlessly; only the test on the device shows that.
FAQ
Frequently asked questions
Is UDS a security protocol?
No. UDS is a diagnostic protocol with two access control services attached. SecurityAccess (0x27) is a seed-and-key exchange whose algorithm the manufacturer chooses; the standard says nothing about its strength. Authentication (0x29), new in ISO 14229-1:2020, brings certificate-based authentication, but most ECUs in production still rely on 0x27.
How do you test UDS in an ECU penetration test?
We record which sessions, services, data identifiers and routines the ECU offers, compare that with the diagnostic specification and check that access control applies everywhere the specification says it should. Then we assess the SecurityAccess implementation and fuzz the parsers behind the services. AutoST automates the enumeration and the fuzzing.
Does UN R155 say anything about UDS?
Not by name. Annex 5 of UN R155 lists threats that include the misuse of diagnostic functions and unauthorised access to vehicle data and software, and requires the manufacturer to mitigate them. UDS is in practice the path through which those threats arrive, and the evidence comes from testing the diagnostic interface.
Sources
Related pages
- GlossaryCAN BusThe CAN bus is the serial network that connects ECUs in vehicles and machines. How frames and arbitration work, why CAN has no built-in security, and what protects it.
- GlossaryFuzzingFuzzing feeds a program or device large numbers of malformed inputs to find crashes and security bugs. The methods, where standards ask for it, and how it works on ECUs.
- InsightsECU Fuzzing Explained: Finding Bugs in UDS, DoIP and SOME/IPHow fuzz testing works for automotive ECUs, which protocols to target, how to detect crashes on real hardware and how fuzzing supports ISO/SAE 21434.
- GlossaryISO/SAE 21434ISO/SAE 21434:2021 is the standard for cybersecurity engineering of road vehicles. Its clauses, how it relates to UN R155, and what it asks from OEMs and suppliers.
- ServicesAutomotive Security Testing, automated.AutoST automates ECU fuzzing, security tests and vulnerability scanning over UDS, CAN FD, DoIP and SOME/IP, producing evidence for UN R155 and ISO/SAE 21434.
- ServicesFind the vulnerabilities in your vehicle before attackers do.ECU and vehicle penetration testing, fuzzing, TARA and ISO/SAE 21434 consulting to meet UN R155/R156. Hands-on automotive security experts from Germany.
