Cryptiiiic/ios16_downgrading.txt

## ios16_downgrading.txt
Unfortunately I have some bad news for downgrading.
Before I explain the bad news at the end of this post, I first need to introduce a background of iOS devices.
In iOS 16, Apple introduced a new firmware component known as Cryptex1. Technically, this is a "virtual" co-processor.
It's purpose is to allow Apple to push RSRs (Rapid Security Responses) which are separate from traditional iOS updates and can be installed much faster.
Like other firmwares, it also has a signing ticket locked to a cryptographic nonce (number-used-once).
We commonly refer to the Apple signing tickets as SHSH blobs.
Meaning the firmware can't be installed without a valid signing ticket as well as a matching nonce.
The "big two" components we deal with signing/nonces are AP and SEP. AP is basically the main device chip (Application Processor).
SEP is the security chip (Secure Enclave Processor).
With regards to APNonce, Apple conveniently gave us the com.apple.System.boot-nonce NVRAM property which we use to set the APNonce generator.
On A11 and older, APNonce is hashed from that generator. When the property is not set, the generator is random.
To explain how that generator works, first I have to introduce you to "nonce-seeds".
I don't know much about them yet but upon boot the kernel's Image4 kext (kernel driver) generates a new seed randomly. The nonce is then generated based on the seed.
Starting in A12, Apple introduced nonce entanglement, which basically encrypts the seed using the device specific UID1 key as well as a constant value.
Meaning even with the boot-nonce NVRAM property, the hash will not be of the original set generator.
We got around this by first setting the generator, then extracting the encrypted value's hash (APNonce) to save a signing ticket with.
Getting back to SEP, SEP has no such NVRAM property to set nonce. Meaning we have to restore a SEP version that Apple gives us a signing ticket back for.
This introduces the issue of "SEP compatibility".
Using latest SEP with an older version may work sometimes, but Apple could all of a sudden release an update that breaks the compatibility.
OK, so we have AP and SEP that use the same signing ticket style (ApImg4Ticket), however an iOS device has many other components.
The other components are usually separate microchips/co-processors. They have their own firmwares. During a restore they are updated.
They are called FirmwareUpdaterComponents for this reason. Unfortunately these firmwares don't use ApImg4Tickets or APNonces.
Instead they have their own signing ticket and nonce derived from nonce seeds.
Luckily for us it was rare that a FirmwareUpdaterComponent update would break compatibility with an older iOS version.
This allowed us to downgrade with no issue given SEP was also compatible. This brings me to the bad news with iOS 16.
There's no known way to persist nonce-seeds. Meaning we can't reuse older FirmwareUpdaterComponents and their saved signing tickets.
Cryptex1 may be "virtual" and not a real chip but it's still considered a FirmwareUpdaterComponents, it has a signing ticket and its own nonce.
It is extremely rare that a newer Cryptex1 will be compatible with the older iOS version you are downgrading to, as it contains the dyld shared cache among other things, which contains basically all of the system's libraries.
At the time of this post, 16.3.1 Cryptex1 causes 16.0-16.1.2 to not even boot, 16.2 will boot but freeze on country selection on the setup screen.
It's really not looking good for downgrading. We now need to put research and effort into finding a way to persist nonce-seeds across multiple reboots.

TLDR;
In iOS 16, Apple introduced a new component that is almost always incompatible with older versions. This means downgrading is likely to be impossible on non-checkm8 devices except within patch versions (e.g. 16.3 and 16.3.1).
In other words A12 and later, downgrading is impossible, dead in the water, a no-go.

- Cryptic
	Unfortunately I have some bad news for downgrading.
	Before I explain the bad news at the end of this post, I first need to introduce a background of iOS devices.
	In iOS 16, Apple introduced a new firmware component known as Cryptex1. Technically, this is a "virtual" co-processor.
	It's purpose is to allow Apple to push RSRs (Rapid Security Responses) which are separate from traditional iOS updates and can be installed much faster.
	Like other firmwares, it also has a signing ticket locked to a cryptographic nonce (number-used-once).
	We commonly refer to the Apple signing tickets as SHSH blobs.
	Meaning the firmware can't be installed without a valid signing ticket as well as a matching nonce.
	The "big two" components we deal with signing/nonces are AP and SEP. AP is basically the main device chip (Application Processor).
	SEP is the security chip (Secure Enclave Processor).
	With regards to APNonce, Apple conveniently gave us the com.apple.System.boot-nonce NVRAM property which we use to set the APNonce generator.
	On A11 and older, APNonce is hashed from that generator. When the property is not set, the generator is random.
	To explain how that generator works, first I have to introduce you to "nonce-seeds".
	I don't know much about them yet but upon boot the kernel's Image4 kext (kernel driver) generates a new seed randomly. The nonce is then generated based on the seed.
	Starting in A12, Apple introduced nonce entanglement, which basically encrypts the seed using the device specific UID1 key as well as a constant value.
	Meaning even with the boot-nonce NVRAM property, the hash will not be of the original set generator.
	We got around this by first setting the generator, then extracting the encrypted value's hash (APNonce) to save a signing ticket with.
	Getting back to SEP, SEP has no such NVRAM property to set nonce. Meaning we have to restore a SEP version that Apple gives us a signing ticket back for.
	This introduces the issue of "SEP compatibility".
	Using latest SEP with an older version may work sometimes, but Apple could all of a sudden release an update that breaks the compatibility.
	OK, so we have AP and SEP that use the same signing ticket style (ApImg4Ticket), however an iOS device has many other components.
	The other components are usually separate microchips/co-processors. They have their own firmwares. During a restore they are updated.
	They are called FirmwareUpdaterComponents for this reason. Unfortunately these firmwares don't use ApImg4Tickets or APNonces.
	Instead they have their own signing ticket and nonce derived from nonce seeds.
	Luckily for us it was rare that a FirmwareUpdaterComponent update would break compatibility with an older iOS version.
	This allowed us to downgrade with no issue given SEP was also compatible. This brings me to the bad news with iOS 16.
	There's no known way to persist nonce-seeds. Meaning we can't reuse older FirmwareUpdaterComponents and their saved signing tickets.
	Cryptex1 may be "virtual" and not a real chip but it's still considered a FirmwareUpdaterComponents, it has a signing ticket and its own nonce.
	It is extremely rare that a newer Cryptex1 will be compatible with the older iOS version you are downgrading to, as it contains the dyld shared cache among other things, which contains basically all of the system's libraries.
	At the time of this post, 16.3.1 Cryptex1 causes 16.0-16.1.2 to not even boot, 16.2 will boot but freeze on country selection on the setup screen.
	It's really not looking good for downgrading. We now need to put research and effort into finding a way to persist nonce-seeds across multiple reboots.

	TLDR;
	In iOS 16, Apple introduced a new component that is almost always incompatible with older versions. This means downgrading is likely to be impossible on non-checkm8 devices except within patch versions (e.g. 16.3 and 16.3.1).
	In other words A12 and later, downgrading is impossible, dead in the water, a no-go.

	- Cryptic