Finding hidden diagnostic services on an ECU

Hidden diagnostic services are the services, sub-functions, sessions and data identifiers an ECU answers but that are not in the ODX or CDD you were given. You find them the same way you find the documented ones: send every request across the valid range and read the response code. The difference is that you compare the result with the documentation, and anything the ECU answers that the documentation does not mention is a candidate. They matter because they were not in anyone’s threat model, so they were not protected, and a routine or a DID nobody wrote down is exactly the kind of thing that moves an actuator or leaks a secret without a SecurityAccess check in front of it.

Why they are there

Undocumented services are rarely malicious. They are leftovers from development and production:

• Factory and end-of-line routines (RID) that configure or test the ECU on the assembly line.
• Calibration and measurement access left enabled from the development build.
• Debug DIDs that return internal state, memory contents or build information.
• A manufacturer-specific session (for example 10 4F) that unlocks a set of services the standard sessions do not show.
• Services that answer in a session nobody documented, because the documentation only described the sessions the diagnostic tester uses.

They were useful before start of production. The security question is whether they were removed, gated behind SecurityAccess, or simply left reachable.

Probe the whole space, not the documented part

The method is exhaustive probing with classification by response code. A specification review only ever sees the documented surface, so the probing has to cover more than the ODX lists.

Sessions

Request every session 10 01 through 10 7F and record which ones answer 50 (positive) rather than 7F 10 12 (subFunctionNotSupported). A session that answers but is not documented is the first place to look, because it often gates the hidden services.

10 01 -> 50 01            default, documented
10 03 -> 50 03            extended, documented
10 4F -> 50 4F            answers, not in the ODX  <- investigate

Services

In each session that answers, send every service identifier 0x00 to 0xFE and classify the response:

Response	Meaning
positive (SID + 0x40)	Service supported and answered
7F xx 11	serviceNotSupported, not implemented
7F xx 7F	serviceNotSupportedInActiveSession, exists elsewhere
7F xx 33	securityAccessDenied, exists and is gated
7F xx 22	conditionsNotCorrect, exists but preconditions unmet

The useful insight is that 0x11, 0x7F, 0x33 and 0x22 all confirm the service exists; only 0x11 means it is genuinely absent. A service that answers 0x33 is documented by its own refusal, even if no paper mentions it.

Sub-functions and DIDs

For a service that takes sub-functions, such as RoutineControl (0x31) or IOControl (0x2F), sweep the sub-function and identifier ranges and classify the same way. For DIDs, read the full 0x0000 to 0xFFFF space, not just the 0xF1xx identification block, because debug and internal DIDs are usually placed outside the documented range. A positive read of a DID that is not in the ODX is a hidden readable value; inspect what it returns.

What a hidden service means

A found service is not automatically a finding. Classify it by what it can do:

• Readable undocumented DID: a disclosure question. Does it leak a secret, a key, memory, or personal data?
• Undocumented routine: the highest concern. A routine can move actuators, erase memory or change configuration. Whether it is gated behind SecurityAccess decides how serious it is.
• Undocumented session: a pivot. It is dangerous because of what it unlocks, so test which services become reachable once it is active.
• Service reachable in the wrong session: a service meant for the production line that still answers in a field session is a surface that should have been closed.

The decisive question for each is the gate in front of it. A factory routine that still works, in a reachable session, without SecurityAccess, is the kind of finding that justifies a fix before start of production.

How AutoST finds them

AutoST’s enumeration engine does the exhaustive part automatically: it sweeps sessions, every service identifier in each session, sub-functions and the full DID range, and classifies each response code. When an ODX or CDD file is loaded it names the known services and DIDs, so whatever answers but is not in the file stands out as undocumented. Routines and writable identifiers found this way feed the ODX- and CDD-driven scan with careful, confirmation-gated write probing. The point is to surface the surface nobody documented, then let a tester decide what each item means.