# TesterPresent (0x3E)

> TesterPresent (0x3E) is the UDS keep-alive: the tester sends it periodically so the ECU knows a tester is still connected and stays in the extended or programming session. The request is 3E 00, the response 7E 00, and 3E 80 suppresses the response. Without it the S3 server timer expires and the ECU falls back to the default session and locks SecurityAccess. ECUs that never time out, or that let TesterPresent hold a programming session for hours, are findings.

UDS TesterPresent (0x3E) keeps a non-default session alive. Request and response bytes, the suppress bit, the S3 server timer, and the session bugs it exposes.

Source: https://auto-st.com/glossary/tester-present-0x3e · Updated: 2026-10-07

## What is TesterPresent (0x3E)?

TesterPresent is the UDS keep-alive. A tester sends it periodically to tell the ECU that it is still there, so the ECU stays in the session the tester selected instead of falling back to the default session. The request is two bytes, `3E 00` (sub-function zeroSubFunction), the positive response is `7E 00`. With the suppressPosRspMsgIndicationBit set, `3E 80`, the ECU does not answer at all, which is how most testers send it.

The service carries no data and triggers nothing in the ECU. Its only job is to reset the session timer.

## Where is it defined?

ISO 14229-1:2020 defines TesterPresent (0x3E) in clause 9 (Diagnostic and communication management functional unit), together with DiagnosticSessionControl (0x10), ECUReset (0x11), SecurityAccess (0x27) and the other session-level services. The timing it keeps alive is the S3 server timer defined by the session layer (ISO 14229-2 for the generic timing, with a common default of 5000 ms). When S3 expires in a non-default session, the ECU must return to the default session, which also ends any SecurityAccess unlock and resets ControlDTCSetting and CommunicationControl to their defaults.

On CAN, TesterPresent is typically sent functionally to all ECUs on the bus, for example on the 11-bit ID `0x7DF`, as a single ISO 15765-2 frame `02 3E 80 00 00 00 00 00`, every two to four seconds.

## What it means in practice

Every automated UDS test depends on this service. During enumeration of the extended session, during a SecurityAccess seed/key run or during fuzzing, a missing TesterPresent silently drops the ECU back into default session, and from then on every probe answers `7F xx 7F` serviceNotSupportedInActiveSession. Testers that forget the keep-alive produce results that look like a locked-down ECU.

On the bench the interesting part is the other direction. We regularly see ECUs where TesterPresent keeps the programming session alive indefinitely, with SecurityAccess unlocked, so the one-time unlock of a flash tool becomes a permanent state as long as someone keeps sending `3E 80`. We also see ECUs that do not implement S3 at all: the tester disconnects and the ECU stays in the extended session, with CommunicationControl still disabling normal traffic. And some ECUs answer `7E 00` to TesterPresent during a reset or a crash, which fools naive crash detection. A liveness check needs a service that actually exercises the application, or at least a check that the session is still the expected one.

## How AutoST tests it

AutoST sends TesterPresent as the configurable keep-alive of every scan, so sessions do not drop during enumeration, DID scanning and SecurityAccess checks. In the fuzzing engine a TesterPresent liveness check runs after every iteration and is always on; an ECU that stops answering it is recorded as a crash with the exact payload that preceded it. Enumeration also records whether a non-default session survives without keep-alive, which exposes ECUs with a missing or far too long S3 timer.

## Common misunderstandings

TesterPresent does not unlock anything, does not extend SecurityAccess on its own and does not count as activity for the P2 timers; those belong to individual requests. It only keeps the session. And `3E 80` getting no answer is not an error: the response is suppressed by design. If you want to know whether the ECU is alive, send `3E 00` and expect `7E 00`.

## FAQ

**Why is TesterPresent usually sent with 0x80?**

The sub-function byte 0x80 sets the suppressPosRspMsgIndicationBit, so the ECU does not answer. On a functionally addressed request (CAN ID 0x7DF) this avoids every ECU on the bus replying at once every few seconds.

**What happens when TesterPresent stops?**

The S3 server timer in the ECU expires, typically after 5 seconds, and the ECU returns to the default session. Any SecurityAccess unlock is dropped at that point. An ECU that stays in the extended session after the tester is gone has a session-handling bug.

**Is TesterPresent itself a security risk?**

Not by itself; it carries no data and changes no state. The risk is what it keeps open. If an attacker can hold a programming session with SecurityAccess unlocked indefinitely, the ECU has no mechanism to end a diagnostic session that nobody is using legitimately.

## Sources

- [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer, clause 9 Diagnostic and communication management functional unit](https://www.iso.org/standard/72439.html)
- [ISO 15765-2 Road vehicles, Diagnostic communication over CAN (DoCAN), Part 2: Transport protocol and network layer services](https://www.iso.org/standard/84211.html)

## Related

- [Diagnostic session (DiagnosticSessionControl 0x10)](https://auto-st.com/glossary/diagnostic-session)
- [Programming Session (0x10 0x02)](https://auto-st.com/glossary/programming-session)
- [Break it on the bench, not in the field.](https://auto-st.com/ecu-fuzzing)
- [Know every door into the ECU.](https://auto-st.com/uds-enumeration)
- [ECU reset and session handling bugs, and how to test them](https://auto-st.com/insights/ecu-reset-and-session-handling-bugs)
- [Does your seed/key actually hold?](https://auto-st.com/security-access-testing)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/tester-present-0x3e