ECU reset and session handling bugs, and how to test them
How to test UDS session and reset handling: session fallback, S3 timeout, security state after reset, TesterPresent keeping a session alive, and what each result means.
Tom Zaubermann · Published · 7 min read
Session and reset handling is where ECUs leak privilege. The rules in ISO 14229 are simple: a reset returns the ECU to the default session with security locked, a session falls back to default after the S3 timeout unless a tester keeps it alive, and an unlocked security level does not outlive the session it was granted in. ECUs break these rules in small ways that are easy to miss and easy to test: a security level that is still unlocked after a reset, a programming session that never times out, a reset that does not actually clear state. Each of these turns a one-time unlock into lasting access, which is exactly what the gate was supposed to prevent.
The rules, and the services involved
Four services carry this behaviour: DiagnosticSessionControl (0x10), ECUReset (0x11), SecurityAccess (0x27) and TesterPresent (0x3E). The expected behaviour:
- A session other than default stays active only while a tester sends TesterPresent within the S3 timeout (typically 5 s). Without it, the ECU falls back to the default session.
- A reset (
11 01hard,11 02key-off-on,11 03soft) returns the ECU to the default session with security locked. - A granted security level is bound to the session. Leaving the session or resetting drops it.
The tests
Session fallback on S3 timeout
Enter the extended session, then stop sending TesterPresent and wait past the S3 timeout. Then send a service that only the extended session allows and confirm the ECU now refuses it.
10 03 -> 50 03 ... extended session entered
(stop TesterPresent, wait > 5 s)
22 F1 90 -> 7F 22 7F serviceNotSupportedInActiveSession (fell back, correct)
22 F1 90 -> 62 F1 90 ... still answering -> session did not time outAn ECU that still serves extended-session requests long after the last TesterPresent has a session that does not time out, which keeps a privileged window open longer than intended.
Security state after a reset
Unlock a security level, confirm you can reach a gated service, then reset and, without a new seed and key exchange, try the gated service again.
27 01 / 27 02 ... level unlocked
2E F1 90 ... -> 6E F1 90 gated write works while unlocked
11 01 -> 51 01 reset
2E F1 90 ... -> 6E F1 90 still works -> security survived the reset (bug)
expected: 7F 2E 33 securityAccessDenied after resetA security level that survives a reset, or returns active without the seed and key exchange, is a serious finding: one unlock lasts across reboots.
Reset that does not clear state
Some ECUs answer the reset request but do not fully re-initialise: a session stays active, a routine keeps running, a counter does not clear. After a reset, re-read the session and security state and check that the ECU really came back to default. Compare the behaviour of the three reset types, because a soft reset (11 03) sometimes clears less than a hard reset (11 01).
Privileged session held open indefinitely
Enter a privileged session, then keep sending TesterPresent and watch whether the ECU ever closes the window on its own. A programming session that can be held open for as long as a tester keeps sending 3E 00, with no other time limit or re-authentication, is a window that stays open far longer than a flash needs.
Session entry preconditions
Check that privileged sessions enforce their preconditions. A programming session entered while the vehicle is in a state that should forbid it, answered with 50 02 instead of 7F 10 22 (conditionsNotCorrect), is a missing guard.
What the results mean
| Observation | What it means |
|---|---|
| Extended session answers after S3 with no TesterPresent | Session does not time out |
| Gated service works after reset without re-unlock | Security state survives reset |
| Session or routine still active after reset | Reset does not clear state |
| Programming session stays open indefinitely | No time bound on a privileged window |
| Privileged session entered in a forbidden state | Missing precondition check |
These are design and configuration findings, and most have a clear fix: bind security to the session, enforce the S3 fallback, clear state on reset, and bound the privileged window. The value of testing them is that they are invisible to a static review and obvious to a few targeted requests.
How AutoST tests this
AutoST’s enumeration handles sessions carefully, including robust entry and safe handling of ECUs that get stuck in a programming session, and its SecurityAccess engine includes an opt-in, confirmation-gated ECU-reset probe that checks whether the seed, and the unlocked state, are predictable or persist across a reboot. Session fallback, timeout and reset behaviour are observed as part of these runs and land in the same risk score and Fix Plan. The reset-based checks are gated behind a confirmation because they restart the ECU, and they belong on a bench, never on a vehicle in use.
FAQ
Frequently asked questions
Why does the security state after a reset matter?
Because an unlocked security level that survives a reset, or returns without a fresh seed and key exchange, means an attacker who gets one unlock keeps it across reboots. ISO 14229 expects a reset to drop the ECU back to the default session with security locked.
Is it a bug if TesterPresent keeps a session open forever?
Keeping a session alive with TesterPresent is the intended mechanism. It becomes a weakness when a privileged session, such as programming, can be held open indefinitely with no other control, so a window that should be short stays open as long as the tester keeps sending 3E.
Are these tests destructive?
Session and timeout checks are non-destructive. The reset-based checks restart the ECU, which can interrupt its function, so they are scheduled deliberately and run with confirmation on a bench, never on a vehicle in use.