SW:Boot
Apple Silicon devices seem to follow a boot flow very similar to modern iOS devices.
This stage is located in the boot ROM. Among others, it verifies, loads and executes normal stage 1 from NOR. If this fails, it falls back to DFU and wait for an iBSS loader to be sent, before continuing with the DFU flow at stage 1.
This stage is the primary early loader, located in the on-board NOR. This boot stage very roughly goes as follows:
-
Read the
boot-volume
variable from NVRAM: its format is<gpt-partition-type-uuid>:<gpt-partition-uuid>:<volume-group-uuid>
. Other related variables seem to beupdate-volume
andupgrade-boot-volume
, possibly selected by metadata inside theboot-info-payload
variable; -
Get the local policy hash:
-
Read the local boot policy, located on the iSCPreboot partition at
/<volume-group-uuid>/LocalPolicy/<policy-hash>.img4
. This boot policy has the following specific metadata keys:vuid
: UUID: Volume group UUID - same as abovekuid
: UUID: KEK group UUIDlpnh
: SHA384: Local policy nonce hashrpnh
: SHA384: Remote policy nonce hashnsih
: SHA384: Next-stage IMG4 hashcoih
: SHA384: fuOS (custom kernelcache) IMG4 hashauxp
: SHA384: Auxiliary user-authorized kernel extensions hashauxi
: SHA384: Auxiliary kernel cache IMG4 hashauxr
: SHA384: Auxiliary kernel extension recept hashprot
: SHA384: Paired Recovery manifest hashlobo
: bool: Local boot policysmb0
: bool: Reduced security enabledsmb1
: bool: Permissive security enabledsmb2
: bool: Third-party kernel extensions enabledsmb3
: bool: Manual mobile device management (MDM) enrollmentsmb4
: bool?: MDM device enrollment program disabledsip0
: u16: SIP customizedsip1
: bool: Signed system volume (csrutil authenticated-boot
) disabledsip2
: bool: CTRR (configurable text region read-only) disabledsip3
: bool:boot-args
filtering disabled
And optionally the following linked manifests, each located at
/<volume-group-uuid>/LocalPolicy/<policy-hash>.<id>.im4m
auxk
: AuxKC (third party kext) manifestfuos
: fuOS (custom kernelcache) manifest
-
If loading the next stage:
- The boot directory is located at the target partition Preboot subvolume, at path
/<volume-uuid>/boot/<local-policy.metadata.nsih>
; - Decrypt, verify and execute
<boot-dir>/usr/standalone/firmware/iBoot.img4
with the device tree and other firmware files in the same directory. No evidence towards other metadata descriptors yet.
- The boot directory is located at the target partition Preboot subvolume, at path
-
If loading a custom stage (fuOS):
- …
If it fails at any point during this, it will either error out or fall back to DFU, waiting for an iBEC loader to be sent, before continuing with the DFU flow at stage 2.
This stage is the OS-level loader, located inside the OS partition and shipped as part of macOS. It loads the rest of the system.
DFU flow
This stage is sent to the device by the “reviving” host. It bootstraps, verifies and runs the second stage, iBEC.
Once booted, the AP can be in one of several boot modes, as confirmed by the SEP:
ID | Name |
---|---|
0 | macOS |
1 | 1TR (“one true” recoveryOS) |
2 | recoveryOS (“ordinary” recoveryOS) |
3 | kcOS |
4 | restoreOS |
255 | unknown |
The SEP only allows execution of certain commands (such as editing the boot policy) in 1TR, or it will fail with error 11, “AP boot mode”.