# RequestDownload (0x34) > RequestDownload (0x34) is the UDS service that starts a data transfer from the tester into ECU memory, typically a firmware download. The request names format, address and size; the positive response 0x74 returns the maximum block length for the following TransferData (0x36) messages. ISO 14229-1 expects it in the programming session behind SecurityAccess. Reachable anywhere else, it is one of the most serious findings on an ECU. 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. Source: https://auto-st.com/glossary/request-download-0x34 ยท Updated: 2026-10-07 ## What is RequestDownload (0x34)? RequestDownload is the UDS service a tester uses to announce that it wants to write a block of data into the memory of the ECU, usually new firmware. It opens the download sequence: `34` RequestDownload, then one or more `36` TransferData blocks, then `37` RequestTransferExit. The ECU answers 0x34 with the maximum block size it accepts, and from then on the tester feeds data in blocks of that size. The request carries four parameters: the dataFormatIdentifier (high nibble compression method, low nibble encryption method, `00` means plain data), the addressAndLengthFormatIdentifier (high nibble: number of bytes in memorySize, low nibble: number of bytes in memoryAddress), the memoryAddress and the memorySize. `34 00 44 08 00 00 00 00 02 00 00` asks to download 0x20000 bytes of plain data to address 0x08000000. The positive response `74 20 0F FA` says: the lengthFormatIdentifier `20` announces a two-byte maxNumberOfBlockLength, and `0F FA` (4090) is the maximum length of each TransferData message, including the SID and the blockSequenceCounter byte. ## Where is it defined? ISO 14229-1:2020, clause 14 (Upload download functional unit), defines RequestDownload (0x34) together with RequestUpload (0x35), TransferData (0x36), RequestTransferExit (0x37) and RequestFileTransfer (0x38). The negative response codes specific to the sequence are 0x70 uploadDownloadNotAccepted, 0x71 transferDataSuspended and 0x73 wrongBlockSequenceCounter, next to the general codes 0x13, 0x22, 0x31, 0x33 and 0x7F. On CAN the blocks travel over ISO 15765-2, which is why the block length and the ISO-TP receive buffer of the ECU are related. ## What it means in practice A tester that can complete 0x34, 0x36 and 0x37 can replace the software of the ECU. That is the purpose of the service, and also why ISO 14229-1 expects it only in the programming session (0x02), behind SecurityAccess (0x27) and normally with a signature check on the transferred image. Three answers tell you how the ECU is set up: `7F 34 7F` means the service exists but not in this session, `7F 34 33` means it is locked by SecurityAccess, and `74 ...` in the default session means neither gate is in place. We regularly see 0x34 reachable in the default or extended session, downloads accepted for arbitrary addresses (`7F 34 31` requestOutOfRange is the correct answer to an address outside the flash area), and ECUs that reset or hang when a TransferData block is longer than the announced maxNumberOfBlockLength or when the blockSequenceCounter jumps. On a power-electronics ECU, a download sequence accepted without any seed/key exchange was the shortest path from the diagnostic connector to the firmware. ## How AutoST tests it The enumeration engine probes 0x34 in every discovered session and classifies the answer: supported, locked by SecurityAccess, not in this session, or absent. In the service risk catalogue RequestDownload is flagged risky with the highest weight (5), so an ECU that accepts it outside a protected session scores accordingly. The UDS fuzzer can target 0x34 and 0x36 with malformed lengths and addresses while the TesterPresent liveness check watches for a hang or reset. AutoST does not flash the ECU. ## Common misunderstandings The name is from the tester's point of view: "download" means data flows into the ECU, while RequestUpload (0x35) reads memory out. A positive response to 0x34 is not yet a write; nothing changes until TransferData blocks arrive and RequestTransferExit completes. For a security test, the acceptance of 0x34 is the finding, not the data you could send after it. ## FAQ **Why does maxNumberOfBlockLength include the SID and the counter byte?** ISO 14229-1 defines it as the length of the complete TransferData message. A value of 0x0FFA (4090) therefore leaves 4088 bytes of payload per block. Testers that forget the two bytes send oversized blocks and get 0x13 incorrectMessageLengthOrInvalidFormat, or they crash a careless ECU. **Should 0x34 ever answer in the default session?** No. ISO 14229-1 places reprogramming in the programming session, and a secure implementation also requires SecurityAccess. A 0x74 positive response in the default session means anyone with bus access can start a flash download. **Does AutoST flash the ECU?** No. AutoST checks whether and in which session 0x34 is reachable, how the ECU handles malformed download requests, and scores the exposure. The flashing itself stays with your flash tool. ## Sources - [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer, clause 14 Upload download 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 - [Programming Session (0x10 0x02)](https://auto-st.com/glossary/programming-session) - [Diagnostic session (DiagnosticSessionControl 0x10)](https://auto-st.com/glossary/diagnostic-session) - [ISO-TP (ISO 15765-2)](https://auto-st.com/glossary/iso-tp) - [Know every door into the ECU.](https://auto-st.com/uds-enumeration) - [Break it on the bench, not in the field.](https://auto-st.com/ecu-fuzzing) - [Does your seed/key actually hold?](https://auto-st.com/security-access-testing) --- AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/request-download-0x34