ECU-Reset- und Session-Handling-Fehler, und wie du sie testest

Session- und Reset-Verhalten ist die Stelle, an der Steuergeräte Privilegien verlieren. Die Regeln in ISO 14229 sind einfach: ein Reset bringt das Steuergerät zurück in die Default-Session mit gesperrter Security, eine Session fällt nach dem S3-Timeout auf Default zurück, sofern kein Tester sie am Leben hält, und ein entsperrtes Security-Level überlebt die Session nicht, in der es gewährt wurde. Steuergeräte brechen diese Regeln in kleinen Weisen, die leicht zu übersehen und leicht zu testen sind: ein Security-Level, das nach einem Reset noch entsperrt ist, eine Programming-Session, die nie abläuft, ein Reset, der den Zustand gar nicht löscht. Jedes davon macht aus einem einmaligen Entsperren einen dauerhaften Zugriff, und genau das sollte das Tor verhindern.

Die Regeln und die beteiligten Services

Vier Services tragen dieses Verhalten: DiagnosticSessionControl (0x10), ECUReset (0x11), SecurityAccess (0x27) und TesterPresent (0x3E). Das erwartete Verhalten:

• Eine Session außer Default bleibt nur aktiv, solange ein Tester innerhalb des S3-Timeouts (typisch 5 s) TesterPresent sendet. Ohne das fällt das Steuergerät in die Default-Session zurück.
• Ein Reset (11 01 hart, 11 02 Key-off-on, 11 03 soft) bringt das Steuergerät zurück in die Default-Session mit gesperrter Security.
• Ein gewährtes Security-Level ist an die Session gebunden. Die Session zu verlassen oder zu resetten lässt es fallen.

Die Tests

Session-Rückfall beim S3-Timeout

Geh in die Extended-Session, stoppe dann das Senden von TesterPresent und warte über das S3-Timeout hinaus. Sende dann einen Service, den nur die Extended-Session erlaubt, und bestätige, dass das Steuergerät ihn jetzt ablehnt.

10 03 -> 50 03 ...            Extended-Session betreten
(TesterPresent stoppen, > 5 s warten)
22 F1 90 -> 7F 22 7F          serviceNotSupportedInActiveSession  (zurückgefallen, korrekt)
22 F1 90 -> 62 F1 90 ...      antwortet weiter  -> Session lief nicht ab

Ein Steuergerät, das lange nach dem letzten TesterPresent noch Extended-Session-Requests bedient, hat eine Session, die nicht abläuft, und hält ein privilegiertes Fenster länger offen als beabsichtigt.

Security-Zustand nach einem Reset

Entsperre ein Security-Level, bestätige, dass du einen abgesicherten Service erreichst, resette dann und probiere ohne neuen Seed-und-Key-Austausch den abgesicherten Service erneut.

27 01 / 27 02 ...             Level entsperrt
2E F1 90 ... -> 6E F1 90      abgesichertes Schreiben geht im entsperrten Zustand
11 01 -> 51 01                Reset
2E F1 90 ... -> 6E F1 90      geht weiter  -> Security hat den Reset überlebt (Fehler)
erwartet: 7F 2E 33            securityAccessDenied nach dem Reset

Ein Security-Level, das einen Reset übersteht oder ohne den Seed-und-Key-Austausch wieder aktiv ist, ist ein ernstes Finding: ein Entsperren hält über Neustarts hinweg.

Reset, der den Zustand nicht löscht

Manche Steuergeräte beantworten den Reset-Request, initialisieren sich aber nicht vollständig neu: eine Session bleibt aktiv, eine Routine läuft weiter, ein Zähler wird nicht gelöscht. Lies nach einem Reset Session- und Security-Zustand erneut und prüfe, dass das Steuergerät wirklich auf Default zurückgekommen ist. Vergleiche das Verhalten der drei Reset-Typen, denn ein Soft-Reset (11 03) löscht manchmal weniger als ein Hard-Reset (11 01).

Privilegierte Session unbegrenzt offengehalten

Geh in eine privilegierte Session, sende weiter TesterPresent und beobachte, ob das Steuergerät das Fenster je von selbst schließt. Eine Programming-Session, die sich so lange offenhalten lässt, wie ein Tester 3E 00 sendet, ohne andere Zeitgrenze oder Re-Authentifizierung, ist ein Fenster, das weit länger offen bleibt, als ein Flash braucht.

Vorbedingungen beim Session-Eintritt

Prüfe, dass privilegierte Sessions ihre Vorbedingungen durchsetzen. Eine Programming-Session, die in einem Zustand betreten wird, der sie verbieten sollte, beantwortet mit 50 02 statt 7F 10 22 (conditionsNotCorrect), ist eine fehlende Absicherung.

Was die Ergebnisse bedeuten

Beobachtung	Was es bedeutet
Extended-Session antwortet nach S3 ohne TesterPresent	Session läuft nicht ab
Abgesicherter Service geht nach Reset ohne erneutes Entsperren	Security-Zustand übersteht den Reset
Session oder Routine nach Reset noch aktiv	Reset löscht den Zustand nicht
Programming-Session bleibt unbegrenzt offen	Keine Zeitgrenze für ein privilegiertes Fenster
Privilegierte Session in verbotenem Zustand betreten	Fehlende Vorbedingungsprüfung

Das sind Design- und Konfigurations-Findings, und die meisten haben einen klaren Fix: Security an die Session binden, den S3-Rückfall durchsetzen, den Zustand beim Reset löschen und das privilegierte Fenster begrenzen. Der Wert des Testens liegt darin, dass sie einem statischen Review unsichtbar und mit wenigen gezielten Requests offensichtlich sind.

Wie AutoST das testet

Die Enumeration von AutoST behandelt Sessions sorgfältig, inklusive robustem Eintritt und sicherem Umgang mit Steuergeräten, die in einer Programming-Session hängen bleiben, und die SecurityAccess-Engine enthält eine optionale, bestätigungspflichtige ECU-Reset-Probe, die prüft, ob der Seed, und der entsperrte Zustand, über einen Neustart vorhersagbar sind oder fortbestehen. Session-Rückfall, Timeout und Reset-Verhalten werden im Rahmen dieser Läufe beobachtet und landen im selben Risiko-Score und Fix Plan. Die Reset-basierten Prüfungen sind hinter einer Bestätigung abgesichert, weil sie das Steuergerät neu starten, und sie gehören an einen Prüfstand, nie an ein Fahrzeug im Betrieb.