# Programming Session (0x10 0x02)

> Die Programming Session ist die UDS-Diagnose-Session zum Neuprogrammieren eines Steuergeräts, betreten mit DiagnosticSessionControl 10 02 und bestätigt mit 50 02. Darin nimmt das Steuergerät, oft sein Bootloader, die Download-Services RequestDownload (0x34), TransferData (0x36) und RequestTransferExit (0x37) an, dazu Routinen zum Löschen des Speichers und zum Prüfen der neuen Software. Weil am Ende neuer Code im Steuergerät steht, gehört sie hinter Vorbedingungen, SecurityAccess und Signaturprüfung.

Die UDS Programming Session (10 02) ist der Diagnosemodus zum Flashen eines Steuergeräts. Wie man hineinkommt, welche Services sie freischaltet, warum sie heikel ist.

Source: https://auto-st.com/de/glossar/programming-session · Updated: 2026-10-07

## Was ist die Programming Session?

Die Programming Session ist eine der Diagnose-Sessions von DiagnosticSessionControl (`0x10`). Der Request ist `10 02`, die positive Antwort `50 02`, gefolgt von den Timing-Werten P2 und P2*, die das Steuergerät verwenden wird. In dieser Session schaltet das Steuergerät die Services frei, die zum Austausch seiner Software nötig sind: RequestDownload (`0x34`), TransferData (`0x36`), RequestTransferExit (`0x37`) und RoutineControl (`0x31`) für Routinen wie Speicher löschen und Programmierabhängigkeiten prüfen.

Bei vielen Steuergeräten wechselt der Eintritt von der Applikation in einen separaten Bootloader. Eine typische Flash-Sequenz ist: Extended Session, ControlDTCSetting aus, CommunicationControl zum Abschalten des Normalverkehrs, Programming Session, SecurityAccess, Löschroutine, RequestDownload, eine Reihe von TransferData-Blöcken, RequestTransferExit, Prüfroutine, ECUReset.

## Wo ist es definiert?

ISO 14229-1 definiert den Session-Typ `0x02` programmingSession im Service DiagnosticSessionControl und die Funktionsgruppe Upload/Download (`0x34` bis `0x38`). Den Schutz überlässt die Norm dem Hersteller: welche Session-Wechsel erlaubt sind, welche Vorbedingungen gelten und welcher SecurityAccess-Level das Programmieren freischaltet. UN R156 ergänzt die regulatorische Sicht: Fahrzeughersteller brauchen ein Software-Update-Managementsystem und müssen Integrität und Authentizität von Updates schützen, was am Steuergerät meist signierte Images bedeutet, die der Bootloader prüft.

## Was es in der Praxis bedeutet

Die Programming Session ist der heikelste Zustand eines Steuergeräts, denn was darin passiert, entscheidet, welcher Code als Nächstes läuft. Am Prüfstand sehen wir regelmäßig Programming Sessions, die sich ohne Vorbedingungen aus der Default Session betreten lassen, SecurityAccess-Level fürs Programmieren mit demselben schwachen Seed/Key-Verfahren wie für die Diagnose und TesterPresent, das die Programming Session mit entsperrtem SecurityAccess beliebig lange offen hält. Seltener, aber mit großer Wirkung: Bootloader, die Images ohne Signaturprüfung oder ältere Softwarestände annehmen.

Die Session macht auch beim Testen Probleme. Manche Steuergeräte bleiben nach einem fehlerhaften Request im Bootloader hängen und brauchen einen Power Cycle. Diese Session zuletzt und mit Wiederherstellungsweg zu testen, ist gute Praxis.

## Wie AutoST es testet

Die Session-Erkennung von AutoST prüft, ob die Programming Session erreichbar ist und aus welcher Session, und der Service-Sweep probiert danach jeden SID darin, sodass Download-Services, die ohne SecurityAccess erreichbar sind, als Findings auftauchen. Weil manche Steuergeräte darin hängen bleiben, testet AutoST die Programming Session zuletzt, und du kannst sie auslassen. Die SecurityAccess-Engine prüft die Seed/Key-Level, die sie schützen.

## Häufige Missverständnisse

Die Programming Session zu erreichen heißt noch nicht, flashen zu können: Die Signaturprüfung im Bootloader ist die letzte Verteidigungslinie. Ein Steuergerät, das sich allein darauf verlässt, gibt einem Angreifer aber beliebig viele Versuche dagegen.

## FAQ

**Kommt man direkt aus der Default Session in die Programming Session?**

ISO 14229-1 überlässt das dem Hersteller. Viele Steuergeräte akzeptieren 10 02 nur aus der Extended Session und nach Prüfung von Vorbedingungen wie Geschwindigkeit null, sonst antworten sie 7F 10 22 (conditionsNotCorrect). Ein Steuergerät, das den Wechsel aus der Default Session ohne jede Prüfung annimmt, ist ein meldenswertes Finding.

**Warum verschwindet das Steuergerät manchmal nach 10 02?**

Viele Steuergeräte springen zum Programmieren in einen separaten Bootloader. Der kann eine andere Baudrate, andere CAN-IDs oder ein anderes Timing nutzen und auf den Session-Request erst mit 7F 10 78 (Response Pending) und dann mit 50 02 antworten. Ein Tester, der das nicht erwartet, verliert das Steuergerät.

**Ist es sicher, die Programming Session zu testen?**

Das Betreten meist schon, Herunterladen und Löschen nicht. Manche Steuergeräte bleiben im Bootloader, bis sie gültige Software oder einen harten Reset bekommen. Deshalb hältst du einen Wiederherstellungsweg bereit und testest diese Session zuletzt.

## Sources

- [ISO 14229-1:2020 Straßenfahrzeuge, Unified diagnostic services (UDS), Teil 1: Anwendungsschicht (DiagnosticSessionControl 0x10, Upload/Download 0x34 bis 0x38)](https://www.iso.org/standard/72439.html)
- [UN-Regelung Nr. 156, Software-Update und Software-Update-Managementsystem](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update)

## Related

- [Diagnose-Session (DiagnosticSessionControl 0x10)](https://auto-st.com/de/glossar/diagnose-session)
- [RequestDownload (0x34)](https://auto-st.com/de/glossar/request-download-0x34)
- [TesterPresent (0x3E)](https://auto-st.com/de/glossar/tester-present-0x3e)
- [Kenne jede Tür ins ECU.](https://auto-st.com/de/uds-enumeration)
- [ECU-Reset- und Session-Handling-Fehler, und wie du sie testest](https://auto-st.com/de/insights/ecu-reset-und-session-handling-fehler)
- [Hält dein Seed/Key wirklich?](https://auto-st.com/de/security-access-test)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/glossar/programming-session