The application processor of an iOS device generates a single use number at restore time: the AP Nonce.
As iOS update replay attacks have increased in complexity, so has security on the device. This article briefly delves into the history of how this number is generated, used, and exploited to allow devices to upgrade / restore / downgrade after Apple no longer signs a particular firmware version.
When an iOS device updates, it will make a request to Apple for a digital signature to personalize the firmware components in the restore. Then, the update will be installed.
An SHSH “blob” signature is the response to this signature request, coming from Apple’s Tatsu signing server (TSS). TSS decides whether to sign a request based on the input parameters or whether to deny it. These blobs can’t be forged since Apple’s signing keys are private.
You can request a signature from Apple by simply making a request to their servers. You will need the following information:
When you save a SHSH “blob”, you are requesting a SHSH signature from Apple and storing it. But how can we use this later in the presence of an AP Nonce? Let’s delve into what exactly an AP Nonce is and how we can manipulate it.
At restore time, a device generates arbitrary* data to be signed to prevent replay attacks. This is the AP Nonce. An example of an AP Nonce is 3cc4e7b5dce6ffaba306d37879292e4abc721121e833285f698125703e6a4bc3.
Remember, a Tatsu signature / SHSH blob is only valid for this particular set of inputs — board ID, chip ID, etc. including AP Nonce. If the device cancels the restore, the next time it tries to restore, the AP Nonce will be different, and thus will reject the signature.
An iOS device needs to keep its AP Nonce the same after a reboot: OTA updates from the device need to get the signature and communicate with the Tatsu server before the restore process, as restore mode cannot connect to the internet on its own. Thus, it must retain the same AP Nonce between user mode and restore mode, if temporarily. How is this achieved?
In a device’s NVRAM, a ‘generator’ (key = com.system.Apple.boot-nonce) can be set. This generator defines what the AP Nonce will be. An example of a generator could be 0x1111111111111111 or 0xb6d96a54d2a8fc37. This NVRAM generator can only be set to a custom value when jailbroken.
To get the AP Nonce from this generator, on ≤A11, we simply hash the generator, and it turns into an AP Nonce. There’s nothing more to it—the AP Nonce is just the generator, but hashed.
On A10 and A11 devices, the process is as follows (using generator 0xb6d96a54d2a8fc37 as an example):
0xb6d96a54d2a8fc37 into 0x37fca8d2546ad9b6.f17a809ef94fcfab8c6d8245a6287c12f172e9edc7170cc5712453509e4f50a7.On A9 and lower devices (with AP nonces), the process is as follows:
0xb6d96a54d2a8fc37 into 0x37fca8d2546ad9b6.0x37fca8d2546ad9b6 into a0d0280e91dba467250d54cf43d80db7b7cf7110. Every single A9 and lower device (that uses AP Nonces) will get this exact AP Nonce from this generator.To save blobs on A11 or older devices, you do not need a jailbroken device. Why? Because our device-specific info, like the ECID, can be read from a computer. We also know an AP Nonce for any generator by simply hashing it (you can do this with any website online). So when the time comes to set your generator, you already have a blob saved with a nonce that you know the generator for.
For A10 and A11, you can use 0x1111111111111111 as your generator (that’s 16 “1"s) with the AP Nonce being 27325c8258be46e69d9ee57fa9a8fbc28b873df434e5e702a8b27999551138ae. You can save blobs with this pair as long as your know your ECID.
For A9 and lower, you can use 0x1111111111111111 as your generator with the AP Nonce being 3a88b7c3802f2f0510abc432104a15ebd8bd7154. You can save blobs with this pair as long as your know your ECID.
A12 or later devices introduce nonce entanglement.
If a nonce is entangled, it means that its generator is encrypted together with some device-specific keys, and then hashed to get an AP Nonce. This means that your AP Nonce will be specific to that generator on your device only—nobody else’s. You cannot read these device-specific keys without being jailbroken.
This introduces a bit more complexity — to save valid, reusable blobs, we must have a valid generator–AP Nonce pair for our specific device.
You can read a device’s current AP Nonce from a computer when it is in recovery mode. Saving blobs with this random AP Nonce with an unknown, randomized generator will be useless. We cannot recreate the state to enable a replay attack.
We could* set a persistent boot-nonce in NVRAM using mobilegestalt (through ideviceinfo or iTunes) by requesting an
ApNoncein normal mode. We could then find the generator that creates this AP Nonce by rebooting and requestingBootNoncethrough mobilegestalt. This has been patched as of iOS 17.0—see my future blog post.
But with a jailbroken device, we can set the generator. This means we can save blobs with any generator → AP Nonce pair, and as long as we remember the generator, we can recreate the AP Nonce and perform a replay attack.
It is also possible to read our device’s specific AES keys (device specific keys) so that we can save blobs with whatever generator whenever we want, even when not jailbroken. (Note: Since you cannot set generator without a jailbreak, you cannot use these blobs until you are able to set the generator again.)
On ≥A12 devices, the process is as follows:
0x568241656551e0cdf56ff84cc11a79ef (a device-wide constant) through the UID Key.