Skip to content

The reports

The recovered detail lives in reports/, one file per subsystem. They are working notes rather than documentation: retractions, corrections and dead ends stay in, because knowing what was already tried is most of their value.

Two conventions:

  • Read a whole file before appending to it. The head usually answers what the tail is about to go and dig up again.
  • Superseded sections are marked, not deleted. A conclusion that later measurement reversed is more useful than a tidy file.

Querying the archive instead of guessing at it

Much of what a report would otherwise have to assert can be asked, and chikuma/build/archwalk is the whole query surface. It is built from the same readers the device runs, so what it prints is what the firmware would read:

./build/archwalk sections                    # the 27 fourcc sections
./build/archwalk screen 0x0DAD0CE6           # a screen's slots, geometry and records
./build/archwalk item 0x48 | str <id> | name <text> | lists | find <id>
./build/archwalk colours | ids <FOURCC> | refs <id> | bmap <id> | sorc <n>
ARCHIVE_BLOB=../firmware/extracted/osos-dec.dfu ./build/archwalk ...   # the whole image

It replaced a Python tool that reimplemented part of the parsing, so there is now one reader: the device's.

Where to start

File What it is
session_state.md where the last session stopped and what is next (read this first)
fs_worklist.md every filesystem function, with its state
ui_menu_worklist.md every menu target: registered, generic, unserved, unresolved
qemu_vs_unicorn.md the device-by-device diff between the two emulators
address_space_hygiene.md the address conversions, at length

By subsystem

Filesystem and data fs_layer.md, hfs_driver_worklist.md, itunesdb_reader.md, itunesdb_signature.md, artwork_reader.md, media_model.md, genius_re_report.md, genius_constraints.md, photos_re.md

UI: the largest group, and the one to read before touching a screen ui_view_base.md, ui_view_records.md, ui_menu_wiring.md, ui_split_view.md, ui_media_lists.md, ui_text_views.md, ui_image_views.md, ui_progress_view.md, ui_battery_statusbar.md, ui_battery_preview.md, ui_preview_panes.md, ui_pane_ownership.md, ui_property_context.md, ui_transitions.md, ui_transform.md, ui_archive_survey.md, ui_nowplaying_content.md, ui_settings_actions.md, wheel_scroll_rows.md

Audio and video sm1_spec.md (the specification), sm1_audio_engine.md (the investigation log), audio_hardware.md, audio_path.md, playback_path.md, m4a_decoder.md, video_path.md, video_player_re.md

Platform memory_map_rework.md, mmu_map.md, power_idle_state_machine.md, i2c_async_design.md, input_hold_gate.md, piezo_clicker.md, accessories.md, accessory_board.md, usb_disk_mode.md, retailos_panel_path.md, emu_display_and_time.md

Click-wheel games (see the games section) games_sandbox.md, eapp_format.md, eapp_api.md, eapp_slot_table.txt

Graphics stack gl_vincent.md, gl_binary_shaders.md, gl_port_plan.md, third_party_versions.md

Boot, security and protected content boot_chain.md, nor_contents.md (the ONB, module by module), onb_port_log.md (the C port's log), bootrom_crypto.md, bootrom_wtf_symbols.md, bootloader_target.md, onb_boot_screens.md, aupd_updater.md, ipod_debug_access.md, and the FairPlay series

Unsorted unknown_blocks.md: regions not yet attributed to anything, kept explicitly rather than ignored

Third-party components

third_party_versions.md records which parts of the image are somebody else's published work and at what version, because that decides what gets recovered and what gets vendored.

The OpenGL ES implementation is the worked example. The strings identify it as Vincent, and the advertised extension list is the stock fixed-point set, except for GL_APPLE_binary_shader, with its glRegisterBinaryShaderAPPLE and glUnregisterBinaryShaderAPPLE. So Vincent comes from upstream at the advertised version, and the Apple extension is recovered, because Apple wrote it and it could have been different.

Vendoring a library does not vendor the parts Apple grew onto it, and a file that takes one has to say which half it is.

Debug facilities on a real device

ipod_debug_access.md decodes about 37 firmware options, gated behind two empty files in iPod_Control/Device/: a master gate and a per-feature flag. With logging enabled the firmware writes an event log and a usage report to the device. Others include memory, FPS and voltage displays. This is Apple's own instrumentation, present in shipped firmware, and it needs no modification to switch on.