DID (Data Identifier)
A DID is the 16-bit identifier UDS uses to address a data record, read with 0x22 and written with 0x2E. Standard ranges from ISO 14229-1 Annex C and writable DIDs.
Updated This page as Markdown
In short
A data identifier (DID) is a two-byte value from 0x0000 to 0xFFFF that names a data record inside an ECU: the VIN is F190, the ECU serial number F18C, the active diagnostic session F186. ReadDataByIdentifier (0x22) reads it, WriteDataByIdentifier (0x2E) writes it, and 0x2A, 0x2C and 0x2F use DIDs as well. ISO 14229-1 Annex C reserves the identification block 0xF180 to 0xF19F and a few other ranges; everything else is defined by the manufacturer in ODX or CDD files.
What is a DID?
A data identifier is a 16-bit number that stands for one data record inside the ECU. Instead of addressing memory, the tester asks for a DID and the ECU returns the record with whatever length and encoding the manufacturer defined. 22 F1 90 reads the VIN and the ECU answers 62 F1 90 followed by 17 bytes; 22 F1 86 returns the active diagnostic session as one byte, 62 F1 86 03 for the extended session.
Several services work with DIDs: ReadDataByIdentifier (0x22) and WriteDataByIdentifier (0x2E), ReadScalingDataByIdentifier (0x24), ReadDataByPeriodicIdentifier (0x2A, which uses the low byte of the F2xx range), DynamicallyDefineDataIdentifier (0x2C) and InputOutputControlByIdentifier (0x2F).
Where is it defined?
ISO 14229-1:2020 Annex C lists the standard data identifiers. The identification block 0xF180 to 0xF19F carries boot and application software identification (F180 to F182), the fingerprints (F183 to F185), the active session (F186), spare part and software numbers (F187 to F189), the system supplier identifiers (F18A, F18B), the ECU serial number (F18C), the VIN (F190), the ECU hardware number (F191), the programming date (F199) and the repair shop codes (F198, F19A). Further ranges are reserved for periodic identifiers (F200 to F2FF), dynamically defined identifiers (F300 to F3FF), OBD (F400 to F8FF), tachograph, airbag and safety systems, and system supplier specific use (FD00 to FEFF). The ranges 0x0100 to 0xA5FF and others are vehicle manufacturer specific and are documented in the ECU’s ODX or CDD file.
What it means in practice
DIDs are where information leaks and where unauthorised changes happen. On the bench, the first thing a tester reads is the identification block, because it tells you software version, hardware revision and programming history and almost every ECU answers it. The second thing is a sweep of the whole identifier space per session, because the interesting DIDs are the undocumented ones: debug counters, internal states, sometimes key material or configuration bytes.
We regularly see identification DIDs that are writable in the extended session without SecurityAccess, which lets anyone rewrite the fingerprints or the serial number and destroys the audit trail of who programmed the ECU. We also see DIDs that accept any length on write and ECUs that return different data for the same DID in different sessions.
How AutoST tests it
AutoST reads the identification range 0xF180 to 0xF19F by default and can sweep the full 0x0000 to 0xFFFF space in every discovered session, over CAN or DoIP. An imported ODX, PDX or CDD file names the discovered identifiers and provides the expected lengths, and the opt-in write-probing phase checks which DIDs accept a 0x2E write, with wrong-length and write-back checks, off by default and confirmed before it runs.
Common misunderstandings
A DID is not a memory address; ReadMemoryByAddress (0x23) is a different service with a different risk profile. And a DID that answers 0x31 in the default session may well answer in the extended session, so a sweep in one session says nothing about the others.
FAQ
Frequently asked questions
How many DIDs does an ECU have?
Anything from a dozen to several thousand. The standard reserves ranges but does not force an ECU to implement a single DID; the manufacturer specification does. A full sweep of 0x0000 to 0xFFFF with ReadDataByIdentifier takes roughly ten minutes per session over CAN and is the only way to find undocumented ones.
Which DIDs are security relevant?
Those an attacker would read or change: the VIN (F190), the serial number (F18C), the fingerprints F183 to F185 and the repair shop codes F198 and F19A that record who programmed the ECU, plus manufacturer DIDs that hold calibration, keys or feature flags. Readable where needed, writable only after SecurityAccess, if at all.
Why does an ECU answer 0x31 for a DID?
requestOutOfRange means the ECU does not support that DID in the current session or at all. It is the normal answer during a DID sweep and marks the identifiers that do not exist; 0x33 securityAccessDenied marks the ones that exist but are protected.
Sources
Related pages
- GlossaryReadDataByIdentifier (0x22)UDS ReadDataByIdentifier (0x22) reads a data identifier (DID) from an ECU. The request and response bytes, which session it needs and what to validate.
- GlossaryWriteDataByIdentifier (0x2E)UDS WriteDataByIdentifier (0x2E) writes a data identifier (DID) to an ECU. The request and response bytes, which session it needs and what to validate.
- GlossaryODX (Open Diagnostic Data Exchange)ODX (ISO 22901-1, ASAM MCD-2 D) is the XML format that describes how an ECU speaks UDS: services, DIDs and routines. How it is structured and what testers do with it.
- Free toolsUDS DID Lookup: Standard Data IdentifiersLook up the data identifiers reserved by ISO 14229-1: VIN (F190), active session (F186), software and hardware numbers, fingerprints, OBD and safety ranges.
- PlatformYour ODX and CDD, turned into tests.AutoST imports ODX, PDX and Vector CDD files to name the DIDs it finds and run the right routines (0x31), with opt-in, clearly warned write-probing.
- 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.
