UDS enumeration explained: how to map an ECU safely

Before you can secure an electronic control unit, you have to know what it exposes. UDS (Unified Diagnostic Services, ISO 14229) is the language most ECUs speak for diagnostics, and enumeration is the act of mapping everything it offers: which diagnostic sessions exist, which services answer in each one, and which data identifiers can be read.

Why enumeration comes first

An ECU is not one flat interface. A service that is silent in the default session may answer in an extended or programming session. A data identifier that looks harmless may return a serial number, a calibration value or a secret. Until you have walked the whole surface, session by session, you are guessing at the attack surface.

What a good scan covers

A thorough enumeration walks four layers:

• Endpoints. The ISO-TP address pairs the ECU responds on, across both the 11-bit and 29-bit ranges.
• Sessions. Default, extended and, carefully, programming. Entry has to be robust, because some gateways get stuck.
• Services. Every service ID, probed in each session and classified: supported, denied for security reasons, not supported in this session, or conditions not correct.
• Data identifiers. The readable DIDs, either the identification range or the full identifier space.

Keeping it non-destructive

Enumeration should read, not write. It discovers what is there and flags the risky services (ECU reset, routine control, memory access) without triggering them. That is the difference between understanding an ECU and disturbing it, and it is why enumeration is the safe first step before any fuzzing or write testing.

This is exactly what the enumeration engine in AutoST does, automatically, in minutes, and it scores the risky services it finds so you know where to look next.