Jailbreak (S5L8720x) - Revision history

Gjest: /* Unsigned Code (at iBoot level) */ removed duplicate word

2017-05-28T18:42:12Z

‎Unsigned Code (at iBoot level): removed duplicate word

Spydar007 at 12:33, 23 March 2017

2017-03-23T12:33:56Z

IAdam1n: Updating

2015-10-12T08:28:40Z

Updating

IAdam1n: Adding Category:Jailbreaking

2015-08-26T19:11:13Z

Adding Category:Jailbreaking

IAdam1n: /* Firmware Encryption */

2014-10-19T18:01:32Z

‎Firmware Encryption

IAdam1n: Consistency please.

2014-10-19T10:19:18Z

Consistency please.

Aker: /* Firmware Parsing Flaw */

2014-08-11T13:57:25Z

‎Firmware Parsing Flaw

Aker: /* Firmware Encryption */

2014-08-11T13:54:21Z

‎Firmware Encryption

IAdam1n: Only the iPod touch 2G used this.

2014-08-11T11:04:41Z

Only the iPod touch 2G used this.

Http: /* Small Things */ link update

2013-08-04T08:12:15Z

‎Small Things: link update

@@ Line 55: / Line 55: @@
 * '''Decrypting firmware files''': We can recycle the code geohotz wrote in the summer of 2008  that called iBoot's AES function to decrypt [[KBAG]]s. This way, we could examine iBoot for any other vulnerabilities, the kernel, as there is maybe a 1% chance that there could possibly be a flaw in the codesign mechanism, [[DeviceTree]], so we can make more sense of stuff going on in iBoot because we know the proper hardware addresses, and more.
 * '''Testing hax''': Since the end goal is to find an exploit that will trick the bootrom into saying the LLB signature is valid, when it is not, then having the ability to run unsigned code is a great advantage. This is because we could write code to call different internal functions for the signature / cert / etc checking routines, and to use 'printf' and such that is built into iBoot to report status messages, which would be great for exploit development. Hell, I believe there is even code already in iBoot to dump the stack frame, so there is another useful thing already there for us.
-* '''Dumping the "true" [[bootrom]]''': I have personally resorted to just examining WTF 2.0, since that is technically what the new bootrom is. But there is a catch. Unless every worker in the factory is Superman, I strongly doubt that Apple was able to get 2.1 iBoot code into the bootrom. As MuscleNerd said when I was talking to him a few months ago, it is not cheap to replace the bootrom like this, so if we are lucky it may have some exploitable stuff that Apple fixed for [[WTF]] 2.0 and [[iBoot]], but did not fix in the bootrom, since they would have to be insane to replace the bootrom with new code a second time because of one exploit that they probably would not expect people to see in the first place, since dumping the bootrom is not something that can be done without running unsigned code. Something that can somewhat boost the validity of my theory is that in the 1.2 (2.0 beta 1) lockdownd and higher, there was a check to see if the device model was "iPhone1,2" or "iPod2,1". If true, then the device would automatically activate. Knowing this, it is probably safe to assume that this is when the testing period for the iPod touch (2nd generation) was. Now, to actually say something directly  about this topic, I think Apple made a weak attempt to disallow this. The bootrom is mapped to 0x22000000 now, instead of 0x20000000. And before you ask, iBoot no longer uses it as a library for PKE stuff, it now has that stuff built in, so that is no longer a problem either. Anyway, LLB also maps itself to 0x22000000, therefore mapping itself over where the bootrom code was, and if you used mdb or mr to read what is at that location, LLB would be there. Luckily, iBoot maps itself to 0x18000000, so a solution to this issue would be to just restore to an IPSW with an invalid LLB (so that we can 100% confirm that we are in real, true, bootrom DFU, and not the stupid pseudo-DFU that LLB has built in), and then send simply send it iBoot with iRecovery. iBoot will map itself to 0x18000000, and we can use whatever unsigned code exploit is found to strap an iBoot with permissions/sigcheck/rangecheck patched, thereby allowing us to read what is at 0x22000000.
+* '''Dumping the "true" [[bootrom]]''': I have personally resorted to just examining WTF 2.0, since that is technically what the new bootrom is. But there is a catch. Unless every worker in the factory is Superman, I strongly doubt that Apple was able to get 2.1 iBoot code into the bootrom. As MuscleNerd said when I was talking to him a few months ago, it is not cheap to replace the bootrom like this, so if we are lucky it may have some exploitable stuff that Apple fixed for [[WTF]] 2.0 and [[iBoot]], but did not fix in the bootrom, since they would have to be insane to replace the bootrom with new code a second time because of one exploit that they probably would not expect people to see in the first place, since dumping the bootrom is not something that can be done without running unsigned code. Something that can somewhat boost the validity of my theory is that in the 1.2 (2.0 beta 1) lockdownd and higher, there was a check to see if the device model was "iPhone1,2" or "iPod2,1". If true, then the device would automatically activate. Knowing this, it is probably safe to assume that this is when the testing period for the iPod touch (2nd generation) was. Now, to actually say something directly  about this topic, I think Apple made a weak attempt to disallow this. The bootrom is mapped to 0x22000000 now, instead of 0x20000000. And before you ask, iBoot no longer uses it as a library for PKE stuff, it now has that stuff built in, so that is no longer a problem either. Anyway, LLB also maps itself to 0x22000000, therefore mapping itself over where the bootrom code was, and if you used mdb or mr to read what is at that location, LLB would be there. Luckily, iBoot maps itself to 0x18000000, so a solution to this issue would be to just restore to an IPSW with an invalid LLB (so that we can 100% confirm that we are in real, true, bootrom DFU, and not the stupid pseudo-DFU that LLB has built in), and then simply send it iBoot with iRecovery. iBoot will map itself to 0x18000000, and we can use whatever unsigned code exploit is found to strap an iBoot with permissions/sigcheck/rangecheck patched, thereby allowing us to read what is at 0x22000000.
 * '''OpeniBoot''': Not that it a priority in the jailbreak, but it would definitely help out the iPhone Linux folks, since they can decrypt iBoot and spot the differences, as well as DeviceTree for any new hardware / GPIO addresses. On a plus side for the jailbreak, it would be much easier to have a working OpeniBoot to use for experimentation versus needing to write ARM code to call different iBoot functions.

@@ Line 1: / Line 1: @@
-The '''iPod touch 2G''' is the only device that uses a new processor, the [[S5L8720]]x. Here is a mini "manifesto" to get you caught up to speed. Please use the "Discussion" page for any type of brainstorming or ideas, and limit this page itself to actual, solid, information.
+The '''iPod touch (2nd generation)''' is the only device that uses a new processor, the [[S5L8720]]x. Here is a mini "manifesto" to get you caught up to speed. Please use the "Discussion" page for any type of brainstorming or ideas, and limit this page itself to actual, solid, information.
 ==Summary==
@@ Line 11: / Line 11: @@
 ===DFU 2.0===
-Unlike the iPhone, iPhone 3G and iPod touch, the iPod touch 2G has a new [[bootrom]]. It is based off of WTF 2.0, and is much more secure than the previous bootrom. It boils down to 3 things:
+Unlike the iPhone, iPhone 3G and iPod touch, the iPod touch (2nd generation) has a new [[bootrom]]. It is based off of WTF 2.0, and is much more secure than the previous bootrom. It boils down to 3 things:
-* '''Pwnage 2.0''': It should go without saying, but the iPod touch 2G is no longer vulnerable to the stack overflow that Pwnage 2.0 relied on.
+* '''Pwnage 2.0''': It should go without saying, but the iPod touch (2nd generation) is no longer vulnerable to the stack overflow that Pwnage 2.0 relied on.
 * '''No 8900 Support''': It does not have support for 8900 files any longer. So you cannot just cheat by sending a 1.1.4 iBoot and then using the diags exploit to strap a patched one ;-)
-* '''[[LLB]] Signature Check''': This is the biggest of them all. Now, when firmware images are flashed to NOR, they are left entirely intact in their containers. This gives Apple the upper hand at making things much more secure, for a few reasons. First and foremost, they can properly signature check LLB, so the classic "[[Pwnage]]" exploit in which the device would happily run any LLB in NOR without first signature checking it, so if anyone found a hack to flash the NOR with custom files, then they would be able to "Pwn". No longer is that true though, since the images are intact in NOR, the new bootrom can do proper signature checking. The second reason that this gives Apple the upper hand on things is because they do not really have to have any code in the kernel to utilize the GID key for anything, and I have not personally looked into if they have done this or not, because the iPod Touch 2G kernel is encrypted (I will get into this in the next section), but theoretically they could just remove the code for it, thereby making it so the only way to decrypt KBAGs is by using openiboot, code that calls the AES_Decrypt(); function in iBoot, or something similar. Even worse, they now have less to worry about, because even if there was a bug in the AppleImage3NORAccess routine in the kernel, or an iBoot hack, or something like that, to reflash the NOR, it would be no use because the signature check that the bootrom performs on LLB will just fail.
+* '''[[LLB]] Signature Check''': This is the biggest of them all. Now, when firmware images are flashed to NOR, they are left entirely intact in their containers. This gives Apple the upper hand at making things much more secure, for a few reasons. First and foremost, they can properly signature check LLB, so the classic "[[Pwnage]]" exploit in which the device would happily run any LLB in NOR without first signature checking it, so if anyone found a hack to flash the NOR with custom files, then they would be able to "Pwn". No longer is that true though, since the images are intact in NOR, the new bootrom can do proper signature checking. The second reason that this gives Apple the upper hand on things is because they do not really have to have any code in the kernel to utilize the GID key for anything, and I have not personally looked into if they have done this or not, because the iPod Touch (2nd generation) kernel is encrypted (I will get into this in the next section), but theoretically they could just remove the code for it, thereby making it so the only way to decrypt KBAGs is by using openiboot, code that calls the AES_Decrypt(); function in iBoot, or something similar. Even worse, they now have less to worry about, because even if there was a bug in the AppleImage3NORAccess routine in the kernel, or an iBoot hack, or something like that, to reflash the NOR, it would be no use because the signature check that the bootrom performs on LLB will just fail.
 ===Firmware Encryption===
-Apple did not even want people having the chance to reverse any of the code on the iPod touch 2G, so they did the following:
+Apple did not even want people having the chance to reverse any of the code on the iPod touch (2nd generation), so they did the following:
-* '''Gave iPod touch 2G firmwares a different build number''': Something interesting I have found is that all builds, as long as they are the same number, share the same ASR key, even if one is an iPod build and the other is for iPhone 3G. Apple obviously knew hackers would be sneaky enough to notice this, so now the iPod touch 2G firmwares are one ahead of the previous devices. For example, on 2.2, other devices build number was 5G77, while iPod touch 2G build number was 5G77a. This could just be a coincidence, but whatever it is, the fact remains that it has a completely different ASR key than the [[M68AP|iPhone]], [[N82AP|iPhone 3G]], and [[N45AP|iPod touch]] firmwares now.
+* '''Gave iPod touch (2nd generation) firmwares a different build number''': Something interesting I have found is that all builds, as long as they are the same number, share the same ASR key, even if one is an iPod build and the other is for iPhone 3G. Apple obviously knew hackers would be sneaky enough to notice this, so now the iPod touch (2nd generation) firmwares are one ahead of the previous devices. For example, on 2.2, other devices build number was 5G77, while iPod touch (2nd generation) build number was 5G77a. This could just be a coincidence, but whatever it is, the fact remains that it has a completely different ASR key than the [[M68AP|iPhone]], [[N82AP|iPhone 3G]], and [[N45AP|iPod touch]] firmwares now.
-* '''New [[GID Key]]''': There is now a new group ID key in the device, so unlike with previous devices, you cannot just decrypt the [[KBAG]] of the iPod touch 2G firmware files on a Pwned iPhone or something. It must be decrypted on the device itself, and that cannot happen unless someone finds a way to run unsigned code.
+* '''New [[GID Key]]''': There is now a new group ID key in the device, so unlike with previous devices, you cannot just decrypt the [[KBAG]] of the iPod touch (2nd generation) firmware files on a Pwned iPhone or something. It must be decrypted on the device itself, and that cannot happen unless someone finds a way to run unsigned code.
 ===Small Things===
@@ Line 55: / Line 55: @@
 * '''Decrypting firmware files''': We can recycle the code geohotz wrote in the summer of 2008  that called iBoot's AES function to decrypt [[KBAG]]s. This way, we could examine iBoot for any other vulnerabilities, the kernel, as there is maybe a 1% chance that there could possibly be a flaw in the codesign mechanism, [[DeviceTree]], so we can make more sense of stuff going on in iBoot because we know the proper hardware addresses, and more.
 * '''Testing hax''': Since the end goal is to find an exploit that will trick the bootrom into saying the LLB signature is valid, when it is not, then having the ability to run unsigned code is a great advantage. This is because we could write code to call different internal functions for the signature / cert / etc checking routines, and to use 'printf' and such that is built into iBoot to report status messages, which would be great for exploit development. Hell, I believe there is even code already in iBoot to dump the stack frame, so there is another useful thing already there for us.
-* '''Dumping the "true" [[bootrom]]''': I have personally resorted to just examining WTF 2.0, since that is technically what the new bootrom is. But there is a catch. Unless every worker in the factory is Superman, I strongly doubt that Apple was able to get 2.1 iBoot code into the bootrom. As MuscleNerd said when I was talking to him a few months ago, it is not cheap to replace the bootrom like this, so if we are lucky it may have some exploitable stuff that Apple fixed for [[WTF]] 2.0 and [[iBoot]], but did not fix in the bootrom, since they would have to be insane to replace the bootrom with new code a second time because of one exploit that they probably would not expect people to see in the first place, since dumping the bootrom is not something that can be done without running unsigned code. Something that can somewhat boost the validity of my theory is that in the 1.2 (2.0 beta 1) lockdownd and higher, there was a check to see if the device model was "iPhone1,2" or "iPod2,1". If true, then the device would automatically activate. Knowing this, it is probably safe to assume that this is when the testing period for the iPod touch 2G was. Now, to actually say something directly  about this topic, I think Apple made a weak attempt to disallow this. The bootrom is mapped to 0x22000000 now, instead of 0x20000000. And before you ask, iBoot no longer uses it as a library for PKE stuff, it now has that stuff built in, so that is no longer a problem either. Anyway, LLB also maps itself to 0x22000000, therefore mapping itself over where the bootrom code was, and if you used mdb or mr to read what is at that location, LLB would be there. Luckily, iBoot maps itself to 0x18000000, so a solution to this issue would be to just restore to an IPSW with an invalid LLB (so that we can 100% confirm that we are in real, true, bootrom DFU, and not the stupid pseudo-DFU that LLB has built in), and then send simply send it iBoot with iRecovery. iBoot will map itself to 0x18000000, and we can use whatever unsigned code exploit is found to strap an iBoot with permissions/sigcheck/rangecheck patched, thereby allowing us to read what is at 0x22000000.
+* '''Dumping the "true" [[bootrom]]''': I have personally resorted to just examining WTF 2.0, since that is technically what the new bootrom is. But there is a catch. Unless every worker in the factory is Superman, I strongly doubt that Apple was able to get 2.1 iBoot code into the bootrom. As MuscleNerd said when I was talking to him a few months ago, it is not cheap to replace the bootrom like this, so if we are lucky it may have some exploitable stuff that Apple fixed for [[WTF]] 2.0 and [[iBoot]], but did not fix in the bootrom, since they would have to be insane to replace the bootrom with new code a second time because of one exploit that they probably would not expect people to see in the first place, since dumping the bootrom is not something that can be done without running unsigned code. Something that can somewhat boost the validity of my theory is that in the 1.2 (2.0 beta 1) lockdownd and higher, there was a check to see if the device model was "iPhone1,2" or "iPod2,1". If true, then the device would automatically activate. Knowing this, it is probably safe to assume that this is when the testing period for the iPod touch (2nd generation) was. Now, to actually say something directly  about this topic, I think Apple made a weak attempt to disallow this. The bootrom is mapped to 0x22000000 now, instead of 0x20000000. And before you ask, iBoot no longer uses it as a library for PKE stuff, it now has that stuff built in, so that is no longer a problem either. Anyway, LLB also maps itself to 0x22000000, therefore mapping itself over where the bootrom code was, and if you used mdb or mr to read what is at that location, LLB would be there. Luckily, iBoot maps itself to 0x18000000, so a solution to this issue would be to just restore to an IPSW with an invalid LLB (so that we can 100% confirm that we are in real, true, bootrom DFU, and not the stupid pseudo-DFU that LLB has built in), and then send simply send it iBoot with iRecovery. iBoot will map itself to 0x18000000, and we can use whatever unsigned code exploit is found to strap an iBoot with permissions/sigcheck/rangecheck patched, thereby allowing us to read what is at 0x22000000.
 * '''OpeniBoot''': Not that it a priority in the jailbreak, but it would definitely help out the iPhone Linux folks, since they can decrypt iBoot and spot the differences, as well as DeviceTree for any new hardware / GPIO addresses. On a plus side for the jailbreak, it would be much easier to have a working OpeniBoot to use for experimentation versus needing to write ARM code to call different iBoot functions.
@@ Line 66: / Line 66: @@
 ==Chronic's Notes==
-I have a weird way of keeping things in order. One of them is, when I take notes / document iPod Touch 2G stuff, I do it in TextEdit then commit it via SVN to the chronicdev google code page. If you are interested in any specific topics, such as how the iBoot flags work, you can read about it all [http://code.google.com/p/chronicdev/w/list here]
+I have a weird way of keeping things in order. One of them is, when I take notes / document iPod Touch (2nd generation) stuff, I do it in TextEdit then commit it via SVN to the chronicdev google code page. If you are interested in any specific topics, such as how the iBoot flags work, you can read about it all [http://code.google.com/p/chronicdev/w/list here]
 ==Anything else?==

@@ Line 19: / Line 19: @@
 ===Firmware Encryption===
 Apple did not even want people having the chance to reverse any of the code on the iPod touch 2G, so they did the following:
-* '''Gave iPod touch 2G firmwares a different build number''': Something interesting I have found is that all builds, as long as they are the same number, share the same ASR key, even if one is an iPod build and the other is for iPhone 3G. Apple obviously knew hackers would be sneaky enough to notice this, so now the iPod touch 2G firmwares are one ahead of the previous devices. For example, on 2.2, other devices build number was 5G77, while iPod touch 2G build number was 5G77a. This could just be a coincidence, but whatever it is, the fact remains that it has a completely different ASR key than the [[M68ap|iPhone]], [[N82ap|iPhone 3G]], and [[N45ap|iPod touch]] firmwares now.
+* '''Gave iPod touch 2G firmwares a different build number''': Something interesting I have found is that all builds, as long as they are the same number, share the same ASR key, even if one is an iPod build and the other is for iPhone 3G. Apple obviously knew hackers would be sneaky enough to notice this, so now the iPod touch 2G firmwares are one ahead of the previous devices. For example, on 2.2, other devices build number was 5G77, while iPod touch 2G build number was 5G77a. This could just be a coincidence, but whatever it is, the fact remains that it has a completely different ASR key than the [[M68AP|iPhone]], [[N82AP|iPhone 3G]], and [[N45AP|iPod touch]] firmwares now.
 * '''New [[GID Key]]''': There is now a new group ID key in the device, so unlike with previous devices, you cannot just decrypt the [[KBAG]] of the iPod touch 2G firmware files on a Pwned iPhone or something. It must be decrypted on the device itself, and that cannot happen unless someone finds a way to run unsigned code.

← Older revision		Revision as of 19:11, 26 August 2015
Line 72:		Line 72:

	-chronic		-chronic
		+
		+	[[Category:Jailbreaking]]

@@ Line 19: / Line 19: @@
 ===Firmware Encryption===
 Apple did not even want people having the chance to reverse any of the code on the iPod touch 2G, so they did the following:
-* '''Gave iPod touch 2G firmwares a different build number''': Something interesting I have found is that all builds, as long as they are the same number, share the same ASR key, even if one is an iPod build and the other is for iPhone 3G. Apple obviously knew hackers would be sneaky enough to notice this, so now the iPod touch 2G firmwares are one ahead of the previous devices. For example, on 2.2, other devices build number was 5G77, while iPod Touch 2G build number was 5G77a. This could just be a coincidence, but whatever it is, the fact remains that it has a completely different ASR key than the [[M68ap|iPhone]], [[N82ap|iPhone 3G]], and [[N45ap|iPod touch 1G]] firmwares now.
+* '''Gave iPod touch 2G firmwares a different build number''': Something interesting I have found is that all builds, as long as they are the same number, share the same ASR key, even if one is an iPod build and the other is for iPhone 3G. Apple obviously knew hackers would be sneaky enough to notice this, so now the iPod touch 2G firmwares are one ahead of the previous devices. For example, on 2.2, other devices build number was 5G77, while iPod touch 2G build number was 5G77a. This could just be a coincidence, but whatever it is, the fact remains that it has a completely different ASR key than the [[M68ap|iPhone]], [[N82ap|iPhone 3G]], and [[N45ap|iPod touch]] firmwares now.
 * '''New [[GID Key]]''': There is now a new group ID key in the device, so unlike with previous devices, you cannot just decrypt the [[KBAG]] of the iPod touch 2G firmware files on a Pwned iPhone or something. It must be decrypted on the device itself, and that cannot happen unless someone finds a way to run unsigned code.

@@ Line 59: / Line 59: @@
 ===Firmware Parsing Flaw===
-This is the end goal. Just running unsigned code is not enough, because the bootrom will signature check LLB at every boot. We need an exploit that will trick the bootrom into thinking a patched LLB is a valid, Apple-signed LLB. This does sound like something very hard, but it is a flexible for requirement. For example, if the bootrom was still vulnerable to the Pwnage2 exploit, it would work in this case. At every boot, the bootrom would start parsing LLB, it would get to the place where it copies the entire cert to the stack, then the exploit itself tacked onto LLB would make the routine return 1 (success). Unfortunately, that explit is gone. But my point is the flexibility of it; The exploit would not specifically have to actually trick the bootrom into thinking it is valid, but rather, it could force it into saying it is valid via the forced return(1);
+This is the end goal. Just running unsigned code is not enough, because the bootrom will signature check LLB at every boot. We need an exploit that will trick the bootrom into thinking a patched LLB is a valid, Apple-signed LLB. This does sound like something very hard, but it is a flexible for requirement. For example, if the bootrom was still vulnerable to the Pwnage2 exploit, it would work in this case. At every boot, the bootrom would start parsing LLB, it would get to the place where it copies the entire cert to the stack, then the exploit itself tacked onto LLB would make the routine return 1 (success). Unfortunately, that exploit is gone. But my point is the flexibility of it; The exploit would not specifically have to actually trick the bootrom into thinking it is valid, but rather, it could force it into saying it is valid via the forced return(1);
 ==Alternative Attack Vectors==

← Older revision		Revision as of 11:04, 11 August 2014
Line 1:		Line 1:
−	The '''iPod touch 2G''' is the ~~first~~ of ~~the~~ ~~[[M68ap\|iPhone]]/[[N82ap\|iPhone 3G]]/[[N45ap\|iPod touch]] family to use~~ a new processor, the ~~S5L8720x. It is possible that future devices will also use this but for now it is just the iPod Touch 2G~~. Here is a mini "manifesto" to get you caught up to speed. Please use the "Discussion" page for any type of brainstorming or ideas, and limit this page itself to actual, solid, information.	+	The '''iPod touch 2G''' is the only device that uses a new processor, the [[S5L8720]]x. Here is a mini "manifesto" to get you caught up to speed. Please use the "Discussion" page for any type of brainstorming or ideas, and limit this page itself to actual, solid, information.

	==Summary==		==Summary==

@@ Line 25: / Line 25: @@
 In the 1.1.x days, we can all agree that Apple probably did not expect people to be pulling off things such as [[Pwnage]]. Now that they have seen the possibilities though, they have implemented all kinds of small extra things to be more secure. One example of this is that now [[iBoot]]/[[iBEC]]/[[iBSS]] now does not jump to the secure bootloader to perform access the RSA accelerator, but now has all the logic coded in (as it probably should have been in the first place). In essence this does not really do much, but, for example, if there was an exploit in the PKE logic and Apple realized it something like a few days before release, then they can just fix it in [[iBoot]]/[[iBEC]]/[[iBSS]] instead of having to reball a new [[bootrom]]. People would not really be able to find out that the exploit even exists, either, since they need to be able to run unsigned code in the first place to dump the bootrom.
-Another example of a small thing they have done is keeping the [[IMG3 File Format|IMG3]] containers intact when flashed to [[NOR]], not only for the obvious reason of allowing a bootrom signature check, but also because during a restore, the kernel technically will not require access to the [[GID-key|GID key]] to decrypt the firmware file and flash it to the NOR, since again, all of the container remains intact, and the file is flashed as it is.
+Another example of a small thing they have done is keeping the [[IMG3 File Format|IMG3]] containers intact when flashed to [[NOR]], not only for the obvious reason of allowing a bootrom signature check, but also because during a restore, the kernel technically will not require access to the [[GID Key]] to decrypt the firmware file and flash it to the NOR, since again, all of the container remains intact, and the file is flashed as it is.
 ==What will not work==