Difference between revisions of "Bootrom"
(→DFU mode) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
== Introduction == | == Introduction == | ||
| − | The iPod | + | The iPod bootrom is different from the iBoot/SecureROM bootrom present on iOS-based devices. This is true even for iOS/non-iOS devices that share the same SoC, eg. the iPod touch 2G and Nano 4G (both of which are based around an S5L8720). |
| − | The reverse engineering efforts below have been based on a ROM extract from a Nano | + | The reverse engineering efforts below have been based on a ROM extract from a Nano 4G with the following SHA256 sum: 9cc05fb83024c9d51fd31c97a137447ce5ea87fe7cefba7b9aa6d54609bfbafb . |
== BootROM functionality == | == BootROM functionality == | ||
| Line 31: | Line 31: | ||
The difference between the Nano and SecureROM bootrom codebases seem to be the main cause of none of the SecureROM USB exploits working (steaks4uce, usb_control_msg(0xa1, 1), checkm8, etc. However, a full pass over the USB codepaths is still yet to be performed, other vulnerabilities are likely to exist. | The difference between the Nano and SecureROM bootrom codebases seem to be the main cause of none of the SecureROM USB exploits working (steaks4uce, usb_control_msg(0xa1, 1), checkm8, etc. However, a full pass over the USB codepaths is still yet to be performed, other vulnerabilities are likely to exist. | ||
| + | |||
| + | The USB codebase of the DFU is where the [[WInd3x|wInd3x]] bug lives. | ||
Latest revision as of 18:24, 9 January 2023
Introduction
The iPod bootrom is different from the iBoot/SecureROM bootrom present on iOS-based devices. This is true even for iOS/non-iOS devices that share the same SoC, eg. the iPod touch 2G and Nano 4G (both of which are based around an S5L8720).
The reverse engineering efforts below have been based on a ROM extract from a Nano 4G with the following SHA256 sum: 9cc05fb83024c9d51fd31c97a137447ce5ea87fe7cefba7b9aa6d54609bfbafb .
BootROM functionality
The BootROM can perform the following actions:
- Boot from NAND flash (via built-in flash translation layer implementation)
- Boot from some other unknown storage (NOR? Although NOR is not present on the N4G...)
- Boot from USB DFU mode.
The mode is selected based on straps, pressed buttons and mode priorities (first NAND or 'NOR' is performed, then DFU).
All three boot paths end up performing the same image verification steps:
- Load image into memory at beginning of SRAM.
- Verify image header (IMG1 2.0): perform SHA1 then AES of first 0x40 bytes, compare against stored sum.
- Parse footer certificates and verify footer signature against body (undocumented).
- Decrypt and jump into body.
Certificate parsing
The certificate parsing code is subject to Pwnage 2.0. This is one of the few codebases shared with iBoot/SecureROM, and is why the bug was portable to the Nano bootroms.
DFU mode
The DFU mode codebase seems to be different from the iBoot/SecureROM codebase, with very little code shared (perhaps apart from low-level DesignWare HS OTG register access code). There are no iBoot-like tasks present, the heap is very minimalistic (bitmap based, so no unlink/house of $x heap attacks), and the entire data transfer is effectively performed in poll/synchronous mode (with all transfers initiated via USB DMA directly into temporary receive buffers).
The difference between the Nano and SecureROM bootrom codebases seem to be the main cause of none of the SecureROM USB exploits working (steaks4uce, usb_control_msg(0xa1, 1), checkm8, etc. However, a full pass over the USB codepaths is still yet to be performed, other vulnerabilities are likely to exist.
The USB codebase of the DFU is where the wInd3x bug lives.
