Bootrom
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:
- 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.
