The boot chain, in C¶

The iPod classic does not boot in one step. Power reaches a small mask ROM burned into the chip; that ROM loads a bootloader from the device's NOR flash; the bootloader brings the machine up and loads the operating system from the disk's firmware partition. Chikuma reproduces the whole of that sequence in C, and the strongest evidence it is right is that the same reproduced chain boots Apple's own unmodified firmware to a working interface, not only Chikuma's.

The three stages¶

The mask boot ROM. The first code the processor runs. It sets up the earliest clocks, reads a pair of pins to decide where to boot from, and on a normal cold boot loads and verifies the NOR bootloader before jumping to it. If there is nothing valid to load, it falls through to a USB device firmware upgrade (DFU) loop and waits for a host to send it an image. Chikuma's reproduction lives in chikuma/bootrom/, built from source.

The NOR bootloader. Apple's EFI-style bootloader, reproduced as roughly forty modules in chikuma/onb/. It is an EFI firmware in miniature - the familiar phases (security, pre-EFI initialisation, driver execution, boot device selection, and the hand-off) are all present. It reads the NOR image directory, verifies and decrypts the next stage, brings up main memory and the rest of the clocks, and reaches the operating system on the disk's firmware partition. It is the stage that draws the early boot screens.

The operating system. The retail OS itself, which is what the rest of this documentation is about.

There is also a recovery path. Instead of the cold-boot sequence, a host can push a small recovery image to the ROM's USB DFU loop; that image (Apple calls it the WTF) brings up the clocks and memory and then runs its own DFU loop to receive whatever the host sends next. From the host's point of view the ROM's DFU loop and the recovery image's DFU loop look the same, which is worth knowing when driving either.

In one line each:

cold boot   ROM  ->  NOR bootloader  ->  the OS from the disk's firmware partition
recovery    ROM  ->  USB DFU  ->  recovery image  ->  USB DFU  ->  whatever the host sends

Reproduced, not patched¶

Every stage is a from-source C reproduction, not a modified copy of Apple's binary. The chain is signed with Chikuma's own certificate chain rather than Apple's keys, and the whole sequence - NOR read, signature verify, decrypt, the EFI phases, the hand-off - runs on the emulated machine. The control that keeps the reproduction honest is that booting Apple's unmodified firmware through the very same chain reaches a working UI: if a stage were subtly wrong, the original would fail where Chikuma happened to tolerate it.

What is deliberately not written here¶

This page describes the architecture of the boot chain. It does not document Apple's cryptography, key material, or any exploit of the boot ROM - those are out of scope for this project and this site. The reverse-engineering section covers the recoverable, checkable behaviour of the chain at the level the project works at; the security internals of a shipping product are not part of a clean-room reimplementation.

Installing the chain on a device¶

The boot chain being reproduced end to end is what makes an on-device install conceivable, but it is developer plumbing and not a product: it touches flash on a device that is no longer manufactured. Read On the device before going anywhere near real hardware.