Comment by teruakohatu

> Any diagnostic and recovery tools available at boot time are going to be designed to be non-privileged, so there are a number of things (such as validating the integrity of the encrypted user data partition) that just aren't going to be possible. That locks you down to basically rudimentary hardware validation.

Eh, sort of. Remember that most users have an iCloud Recovery Key enabled. Meaning that Apple could design a non-tethered restore process for iOS that looks like:

1. The device boots into recovery mode; asks the user to configure a wi-fi connection (if none of the ones it has persisted in NVRAM are available.)

2. The device reaches out to Apple, hitting an "I'm a broken device; help me!" endpoint, referencing the iCloud account the device is signed into, and signing the request with the device's root TPM key.

3. Apple validates that the message is from a device that is registered to the given user's iCloud account.

4. Apple sends back a signed payload containing: a device-root-TPM-key-encrypted copy of the device's own disk encryption key (the iCloud Recovery Key), and some amount of "privileged restore" logic (at minimum, just an XPC daemon for the restore image to load and run as root, with a code-signed capabilities manifest that grants the device-shipped client-side of that XPC connection the authority to make changes through it; or, at maximum, a whole second-stage recovery firmware for the restore image to reboot into.)

5. The resulting boot would have the same privileges to modify the on-disk system that an OS firmware update does. But, unlike an OS update, the boot that results by combining this Apple-delivered privileged payload, with the existing restore image, would be interactive. Just like macOS's Remote Recovery image, it would give the user access to some of the same management functionality that Apple would use to repair the filesystem, forensically archive + wipe the disk, repair user permission databases, etc.

6. However, this privileged recovery experience, would still ultimately be a DRMed kiosk experience. (The tool would have full power to access or modify your on-disk system, but the tool wouldn't give you any way to modify the running tool itself. Within the OS of the recovery experience, you're still an unprivileged user. Like running VM software on ChromeOS, where you have root in the VM but not on the host.) Especially, since the disk is decrypted enough to get at the keychain, regular authentication methods could be used to enforce that the device's owner is present and consenting to the repair — i.e. the device could require a "sign-in" with iCloud password + TouchID/FaceID/etc. — just like when first making a purchase on the App Store on a new device. (If the disk is so corrupted that this info is unavailable, then the device could fall back to "authorize with another device on your iCloud account" auth; and if that too wouldn't work, then it'd probably tell you to stop what you're doing and go to an Apple Store so they can identity-verify you.)

7. At the same time, Apple could add special handling into the Secure Enclave for a sort of PKI latch storage type: "anyone with the pubkey can set latch k to a value v; but only a message signed by the associated privkey can modify/delete the latch k once set." Apple could then make this privileged recovery experience do two things once booted:

- Tell the Apple servers "consider me de-activated for now; and require an extended activation — with full remote attestation — to reactivate!" Boot would not proceed until the Apple servers confirm the de-activation.

- Set an on-device TPM latch, using an Apple-provided pubkey.

(These two actions can be atomic, as a "start non-tethered repair session" endpoint, that both marks the device as de-activated, and returns the pubkey for a new dynamically-generated keypair associated with that repair session in Apple's backend.)

8. The latch means that the regular on-disk OS won't be allowed to boot again until this recovery process "considers itself complete" — so you can't break out of it mid-job by hard-resetting the device. And the remote de-activation means that, if you were trying to use non-tethered repair on "some random grey-market iPhone" to wipe it and/or scrap it for parts, the device and/or parts would still be considered stolen.

9. And "extended activation with full remote attestation" means that, when you do finish the recovery process, you wouldn't boot into the regular on-disk OS, but into a special "remote attester" mode (essentially, another type of small-ish factory-shipped recovery volume, that the repair system either has no right to modify, or always puts back after a reformat) that carefully examines and validates the OS to ensure everything is as it should be to enforce security (no rootkits, no jailbreaks) — sending that info to Apple, who then send back activation only if they're happy with what they see. (And if you somehow trick the device into booting into the on-disk OS instead of the remote attester, the on-disk OS will find that it can't activate with Apple; will notice the latch; and will just reboot back to the remote attester to try extended activation.)

Under this tight set of constraints, you can do whatever you need to do during recovery — you have root on the phone! But you're also forced to put everything back into a valid state, before Apple will be willing to "release" you from that mode back into regular use of the phone.

(Amusingly enough, Apple could even let this repair image totally break the "paradigm" that iOS normally operates under. The repair image could expose Terminal.app. The repair image could display a desktop when connected to HDMI. Heck, for the iPhone 16, the repair image could be a somewhat-neutered copy of macOS [similar to macOS Recovery] running on the M-series processor, where you're expected to connect a keyboard/mouse/display to it using a USB-C dock! As long as that sort of stuff is only available in this repair experience — and this repair experience is in turn useless as a phone [or as a general-purpose computer] — then exposing these capabilities during repair wouldn't be sales-cannibalizing.)

Also, if you think about it, this is in spirit basically the same "workflow" as Apple's Self Service [Hardware] Repair process — but without the series of phone calls being required to validate that you're actually someone who was asked to repair that device (instead of some rando who bought the phone on the grey market) and to sign off on your repair "session" as completed at the end.

In this case, you're repairing your own device that Apple knows you own because it's listed on your iCloud account, so Apple already has all the info they need to auto-authorize the "repair"; and you're purely doing a firmware/OS repair, not a hardware repair, so the device itself can do the "signing off" at the end.