RequestDownload (0x34)

Was ist RequestDownload (0x34)?

RequestDownload ist der UDS-Service, mit dem ein Tester ankündigt, dass er einen Datenblock in den Speicher des Steuergeräts schreiben will, meist neue Firmware. Er eröffnet die Download-Sequenz: 34 RequestDownload, dann ein oder mehrere 36 TransferData-Blöcke, dann 37 RequestTransferExit. Das Steuergerät antwortet auf 0x34 mit der maximalen Blockgröße, die es akzeptiert, und ab dann liefert der Tester die Daten in Blöcken dieser Größe.

Der Request trägt vier Parameter: den dataFormatIdentifier (hohes Nibble Kompressionsverfahren, niedriges Nibble Verschlüsselungsverfahren, 00 heißt Rohdaten), den addressAndLengthFormatIdentifier (hohes Nibble: Anzahl Bytes von memorySize, niedriges Nibble: Anzahl Bytes von memoryAddress), die memoryAddress und die memorySize. 34 00 44 08 00 00 00 00 02 00 00 fordert einen Download von 0x20000 Byte Rohdaten an Adresse 0x08000000 an. Die positive Antwort 74 20 0F FA sagt: Der lengthFormatIdentifier 20 kündigt eine zwei Byte lange maxNumberOfBlockLength an, und 0F FA (4090) ist die maximale Länge jeder TransferData-Nachricht, inklusive SID und blockSequenceCounter-Byte.

Wo ist es definiert?

ISO 14229-1:2020, Kapitel 14 (Upload download functional unit), definiert RequestDownload (0x34) zusammen mit RequestUpload (0x35), TransferData (0x36), RequestTransferExit (0x37) und RequestFileTransfer (0x38). Die Negative Response Codes speziell für diese Sequenz sind 0x70 uploadDownloadNotAccepted, 0x71 transferDataSuspended und 0x73 wrongBlockSequenceCounter, neben den allgemeinen Codes 0x13, 0x22, 0x31, 0x33 und 0x7F. Auf CAN laufen die Blöcke über ISO 15765-2, weshalb Blocklänge und ISO-TP-Empfangspuffer des Steuergeräts zusammenhängen.

Was es in der Praxis bedeutet

Ein Tester, der 0x34, 0x36 und 0x37 durchläuft, kann die Software des Steuergeräts ersetzen. Das ist der Zweck des Service, und genau deshalb erwartet ISO 14229-1 ihn nur in der Programming Session (0x02), hinter SecurityAccess (0x27) und normalerweise mit Signaturprüfung des übertragenen Images. Drei Antworten verraten dir die Konfiguration: 7F 34 7F heißt, der Service existiert, aber nicht in dieser Session; 7F 34 33 heißt, SecurityAccess sperrt ihn; 74 ... in der Default Session heißt, dass keine der beiden Hürden existiert.

Wir sehen regelmäßig 0x34 in Default oder Extended Session erreichbar, Downloads für beliebige Adressen akzeptiert (7F 34 31 requestOutOfRange wäre die korrekte Antwort auf eine Adresse außerhalb des Flash-Bereichs) und Steuergeräte, die resetten oder hängen, wenn ein TransferData-Block länger ist als die angekündigte maxNumberOfBlockLength oder der blockSequenceCounter springt. An einem Leistungselektronik-Steuergerät war eine ohne Seed/Key akzeptierte Download-Sequenz der kürzeste Weg vom Diagnosestecker zur Firmware.

Wie AutoST es testet

Die Enumeration-Engine prüft 0x34 in jeder gefundenen Session und klassifiziert die Antwort: unterstützt, durch SecurityAccess gesperrt, nicht in dieser Session oder nicht vorhanden. Im Service-Risikokatalog ist RequestDownload als riskant markiert und trägt das höchste Gewicht (5), ein Steuergerät, das ihn außerhalb einer geschützten Session akzeptiert, wird entsprechend bewertet. Der UDS-Fuzzer kann 0x34 und 0x36 mit fehlerhaften Längen und Adressen angehen, während der TesterPresent-Liveness-Check auf Hänger oder Reset achtet. AutoST flasht das Steuergerät nicht.

Häufige Missverständnisse

Der Name ist aus Sicht des Testers gewählt: “Download” heißt, Daten fließen ins Steuergerät, während RequestUpload (0x35) Speicher ausliest. Eine positive Antwort auf 0x34 ist noch kein Schreibvorgang; nichts ändert sich, bis TransferData-Blöcke ankommen und RequestTransferExit abschließt. Für den Security-Test ist die Annahme von 0x34 das Finding, nicht die Daten, die du danach senden könntest.