Difference between revisions of "Bootrom"
(Stub.) |
|||
| Line 1: | Line 1: | ||
| + | == Introduction == | ||
| + | |||
The iPod Nano 4G bootrom is different from the iBoot/SecureROM bootrom present on iOS-based S5L8720 devices, like the iPod Touch 2G. | The iPod Nano 4G bootrom is different from the iBoot/SecureROM bootrom present on iOS-based S5L8720 devices, like the iPod Touch 2G. | ||
| + | |||
| + | 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: | ||
| + | |||
| + | # Verify image header (IMG1/DFU v2.0, '87202.0' header): perform SHA1 then AES of first 0x40 bytes, compare against stored sum, decrypt rest of image with AES. | ||
| + | # Parse footer certificates and verify footer signature against 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 DWC2 OTG register access code). There are no iBoot-like tasks present, the heap is very minimalistic (bitmap based), and the entire data transfer is effectively performed in poll/synchronous mode. | ||
| + | |||
| + | 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. | ||
Revision as of 22:47, 9 December 2021
Introduction
The iPod Nano 4G bootrom is different from the iBoot/SecureROM bootrom present on iOS-based S5L8720 devices, like the iPod Touch 2G.
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:
- Verify image header (IMG1/DFU v2.0, '87202.0' header): perform SHA1 then AES of first 0x40 bytes, compare against stored sum, decrypt rest of image with AES.
- Parse footer certificates and verify footer signature against 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 DWC2 OTG register access code). There are no iBoot-like tasks present, the heap is very minimalistic (bitmap based), and the entire data transfer is effectively performed in poll/synchronous mode.
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.
