Programming Session (0x10 0x02)
The UDS programming session (10 02) is the diagnostic mode for reflashing an ECU. How it is entered, which services it unlocks and why it is the most sensitive one.
Updated This page as Markdown
In short
The programming session is the UDS diagnostic session for reflashing an ECU, entered with DiagnosticSessionControl 10 02 and confirmed with 50 02. In it the ECU, often its bootloader, accepts the download services RequestDownload (0x34), TransferData (0x36) and RequestTransferExit (0x37) and routines for erasing memory and checking the new software. Because it ends in new code on the ECU, it should be protected by preconditions, SecurityAccess and signature checks.
What is the programming session?
The programming session is one of the diagnostic sessions defined for DiagnosticSessionControl (0x10). The request is 10 02, the positive response 50 02 followed by the P2 and P2* timing values the ECU will use. In this session the ECU enables the services needed to replace its software: RequestDownload (0x34), TransferData (0x36), RequestTransferExit (0x37) and RoutineControl (0x31) for routines such as erase memory and check programming dependencies.
On many ECUs entering the session switches from the application to a separate bootloader. A typical flash sequence is: extended session, ControlDTCSetting off, CommunicationControl to silence normal traffic, programming session, SecurityAccess, erase routine, RequestDownload, a series of TransferData blocks, RequestTransferExit, check routine, ECUReset.
Where is it defined?
ISO 14229-1 defines the session type 0x02 programmingSession in the DiagnosticSessionControl service and the upload/download functional unit (0x34 to 0x38). It leaves the protection to the manufacturer: which session transitions are allowed, which preconditions apply and which SecurityAccess level unlocks programming. UN R156 adds the regulatory view: vehicle manufacturers need a software update management system and must protect the integrity and authenticity of updates, which on the ECU usually means signed images checked by the bootloader.
What it means in practice
The programming session is the most sensitive state of an ECU, because what happens in it decides which code runs next. On the bench we regularly see programming sessions that can be entered from default session without preconditions, SecurityAccess levels for programming with the same weak seed/key scheme as diagnostics, and TesterPresent keeping the programming session alive indefinitely with SecurityAccess unlocked. Less often, but with high impact, bootloaders accept images without verifying the signature, or accept older software versions.
The session also causes test problems. Some ECUs get stuck in the bootloader after a malformed request and need a power cycle. Testing it last, with a recovery path, is good practice.
How AutoST tests it
AutoST’s session discovery checks whether the programming session can be entered and from which session, and the service sweep then probes every SID in it, so download services reachable without SecurityAccess show up as findings. Because some ECUs get stuck there, the programming session is tested last and can be skipped. The SecurityAccess engine checks the seed/key levels that guard it.
Common misunderstandings
Reaching the programming session is not the same as being able to flash: signature checks in the bootloader are the last line of defence. But an ECU that relies on that line alone gives an attacker unlimited attempts against it.
FAQ
Frequently asked questions
Can the programming session be entered directly from the default session?
ISO 14229-1 allows the manufacturer to decide. Many ECUs only accept 10 02 from the extended session and after checking preconditions such as vehicle speed zero, answering 7F 10 22 (conditionsNotCorrect) otherwise. An ECU that accepts it from default session without any check is a finding worth reporting.
Why does the ECU sometimes disappear after 10 02?
Many ECUs jump to a separate bootloader for programming. The bootloader may use a different baud rate, different CAN IDs or different timing, and it may answer the session request with a pending response 7F 10 78 before 50 02. A tester that does not expect this loses the ECU.
Is it safe to test the programming session?
Entering it is usually safe; downloading and erasing are not. Some ECUs stay in the bootloader until they get valid software or a hard reset, so testers keep a recovery path and test this session last.
Sources
Related pages
- GlossaryDiagnostic session (DiagnosticSessionControl 0x10)UDS DiagnosticSessionControl (0x10) switches an ECU between default, extended and programming session. Bytes, timing parameters and what to validate.
- GlossaryRequestDownload (0x34)UDS RequestDownload (0x34) opens a download into ECU memory. Request bytes, maxNumberOfBlockLength, typical NRCs and why 0x34 outside a locked session is a top finding.
- GlossaryTesterPresent (0x3E)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.
- 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.
- InsightsECU reset and session handling bugs, and how to test themHow 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.
- PlatformDoes your seed/key actually hold?AutoST probes UDS SecurityAccess: seed randomness, weak seed-to-key algorithms, default keys, brute-force lockout and sequence enforcement. Bounded and non-destructive.
