Skip to content

The reports

The recovered detail lives in reports/ in the repository, one file per subsystem. These are working notes, not polished documentation -- they carry hypotheses that died, retractions, and corrections to earlier entries in the same file, because that record is the useful part.

Two conventions to know before reading one:

  • Read the whole file before appending to it. The head very often already answers the question the tail is about to dig into. A tail read is not reading the notes.
  • Superseded sections are kept, marked superseded, rather than deleted. Several conclusions in this project were reversed by later measurement, and the reversal is worth more than a clean file.

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

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

Boot, security and protected content bootrom_crypto.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.