Revision as of 19:24, 9 January 2023 by Q3k (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


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:

  1. Boot from NAND flash (via built-in flash translation layer implementation)
  2. Boot from some other unknown storage (NOR? Although NOR is not present on the N4G...)
  3. 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:

  1. Load image into memory at beginning of SRAM.
  2. Verify image header (IMG1 2.0): perform SHA1 then AES of first 0x40 bytes, compare against stored sum.
  3. Parse footer certificates and verify footer signature against body (undocumented).
  4. 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.