idevicerestore fails to restore iPhone 16 from normal mode.

[rekyagis]

Hello.

idevicerestore (the latest from GitHub) succeed to restore iPhone 16 from restore mode, but fails to restore from normal mode.
iPhone is disconnected suddenly after "Done sending NORData" and turn to restore mode if restore starts from normal mode.

The success log (from restore mode) is
recovery_success.txt

The fail log (from normal mode) is
normal_fail.txt

I found that SepNonce from normal mode is all-0xFF.
The log says "Getting SepNonce in normal mode... ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ".

$ ideviceinfo -x -k SEPNonce
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<data>
//////////////////////////8=
</data>
</plist>

We can retrieve SepNonce from ApParameters like this. (Apple Devices app on Windows seems to do this way.)

$ ideviceinfo -x -k ApParameters
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ApNonce</key>
	<data>
	NDUmc4xMMNtlK4HSt0WZLgrP36pki606W5OfG0ydGn8=
	</data>
	<key>ApNonceSlotID</key>
	<integer>1</integer>
	<key>ApSikaFuse</key>
	<integer>0</integer>
	<key>SepNonce</key>
	<data>
	DbiGJQ2TLDmF6nj04BSHy1rbtZg=
	</data>
	<key>SepNonceSlotID</key>
	<integer>3</integer>
</dict>
</plist>

I've modified idevicerestore to use SepNonce from ApParameters, but it still fails.
Its log is
normal_fail2.txt

I think we should use the value of ApNonceSlotID, ApSikaFuse and SepNonceSlotID in ApParameters, but I haven't find how for now.

I also should check TSS requests, but I can't capture TSS requests created by Apple's software since recent version of Apple's software seems to reject mitmproxy's certificate.

Could someone give me some help?
Thanks in advance.

[nikias]

Hi, I observed the same thing, and noticed that the img4 stitching has some extra entries. This has all to do with the new ApNonceSlotID and SepNonceID.
This patch will allow you to get past that and actually in my case it restores completely now, even from normal mode, but when it's done from normal mode it will end up in a boot loop currently. Feel free to test. To get out of the boot loop, press and hold the side button until the device goes back to recovery mode, then you can restore again.

Patch: https://gist.github.com/nikias/18aea0129e6029f4f6a5183a74929606

[nikias]

Updated the patch with latest changes. Still boot looping when restoring from normal mode...

[irainbw]

iPhone14 also fails in normal mode, but returns 168 error,recovery mode success.
iphone14_18b1.txt

[nikias]

Can you run ideviceinfo -k ApParameters when the device is in normal mode?

[irainbw]

ideviceinfo -x -k ApParameters

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict/>

nothing there

[nikias]

ok, then it must be something else

[d235j]

I'm told that HomePod (AudioAccessory1,1) restore fails with the following:

Getting SepNonce in dfu mode... db 70 5e b2 fb 29 1b 6a 6f 24 28 42 5e 33 d2 95 63 22 f8 5b 
ERROR: Unable to find UniqueBuildID node

[nikias]

I'm told that HomePod (AudioAccessory1,1) restore fails with the following:

Getting SepNonce in dfu mode... db 70 5e b2 fb 29 1b 6a 6f 24 28 42 5e 33 d2 95 63 22 f8 5b 
ERROR: Unable to find UniqueBuildID node

Well, the error says the build identity doesn't contain UniqueBuildID. Now curious to see where the one telling got the .ipsw file from...

[rekyagis]

Hi, I observed the same thing, and noticed that the img4 stitching has some extra entries. This has all to do with the new ApNonceSlotID and SepNonceID. This patch will allow you to get past that and actually in my case it restores completely now, even from normal mode, but when it's done from normal mode it will end up in a boot loop currently. Feel free to test.

Thank you for your continuous support.

I'm checking the USB packet log by Apple Device app.
It sends APNonceSlotID and SEPNonceSlotID in RestoreOptions of StartRestore request, and "-restore" option is appended to RestoreBootArgs.
start_restore_plist.txt

I've modified RestoreOptions (just hard-coded to be the same as Apple Device app) and also append "-restore" to client->restore_boot_args, but no effect. Still boot-logo-loop after restore.

[d235j]

Well, the error says the build identity doesn't contain UniqueBuildID. Now curious to see where the one telling got the .ipsw file from...

The .ipsw file is built from the OTA and an Apple TV HD IPSW using the script that can be found here: https://github.com/tihmstar/homepodstuff
It needs to be applied to a HomePod (AudioAccessory1,1) in pwned dfu mode.

It is possible that we need to be adding some properties to the .ipsw that we currently aren't.

[nikias]

Well, the error says the build identity doesn't contain UniqueBuildID. Now curious to see where the one telling got the .ipsw file from...

The .ipsw file is built from the OTA and an Apple TV HD IPSW using the script that can be found here: https://github.com/tihmstar/homepodstuff It needs to be applied to a HomePod (AudioAccessory1,1) in pwned dfu mode.

It is possible that we need to be adding some properties to the .ipsw that we currently aren't.

UniqueBuildID is "just" a GUID, just add something random there.

[nikias]

Hi, I observed the same thing, and noticed that the img4 stitching has some extra entries. This has all to do with the new ApNonceSlotID and SepNonceID. This patch will allow you to get past that and actually in my case it restores completely now, even from normal mode, but when it's done from normal mode it will end up in a boot loop currently. Feel free to test.

Thank you for your continuous support.

I'm checking the USB packet log by Apple Device app. It sends APNonceSlotID and SEPNonceSlotID in RestoreOptions of StartRestore request, and "-restore" option is appended to RestoreBootArgs. start_restore_plist.txt

I've modified RestoreOptions (just hard-coded to be the same as Apple Device app) and also append "-restore" to client->restore_boot_args, but no effect. Still boot-logo-loop after restore.

If you manage to capture a full restore (and upload this somewhere...) I am happy to take a look.
Just to recap:

• With the current code without my patch, the restore will fail after sending NORData (checkpoint load_sep_os)
• With my patch it will /not/ fail at NORData/load_sep_os stage which tells us that the personalization with APNonceSlotID and SEPNonceSlotID is working as expected
• Booting fails which means that one of the images that is sent to the device seems incorrectly personalized
• Restoring from recovery mode WITHOUT the APNonceSlotID and SEPNonceSlotID for the personalization works fine

I feel like somehow the personalized images have to be sent again somehow, but I don't see this in a restore process on macOS, so no idea how this would work...

[rekyagis]

If you manage to capture a full restore (and upload this somewhere...) I am happy to take a look.

Yes, I have full USB capture of restore by Apple Device app on windows. It's captured by WIreshark/USBPcap.
But it's too large (more than 8Gbytes) to upload.

I'll try to pick up and upload the part you are interested if you give me instructions, keyword for search.

[nikias]

Can you find out how many times you can locate the SEP image, it is na IMG4 image so IMG4 will be in the first 16 bytes, but more specifically it contains the bytes 49 4D 34 50 16 04 73 65 70 69 at offset 0x12 (IM4P and sepi with 0x16 0x04 inbetween). Then try to extract these images, we want to know if it it transferred again after the initial transfer (actually two transfers, once in recovery, and once in restore mode). Thanks :)

[rekyagis]

Can you find out how many times you can locate the SEP image, it is na IMG4 image so IMG4 will be in the first 16 bytes, but more specifically it contains the bytes 49 4D 34 50 16 04 73 65 70 69 at offset 0x12 (IM4P and sepi with 0x16 0x04 inbetween). Then try to extract these images, we want to know if it it transferred again after the initial transfer (actually two transfers, once in recovery, and once in restore mode). Thanks :)

I found 49 4D 34 50 16 04 73 65 70 69 in packet log twice.
22049.txt
95018.txt

Did it help?

[nikias]

OK, so the first one is when it is booted from recovery mode to restore mode, and the second one is during restore mode as a response for the NORData request. So there is no further upload of the SEP image; there must be something else that is happening and we are not aware of...

[rekyagis]

Hi,

The result of finding 49 4D 34 50 16 04 in USB dump is follows:
(the first column is the packet number, the second is 4 letters following to 49 4D 34 50 16 04)

4304 ibec
4472 rans
4560 ibdt
4572 rdcp
4702 rlgo
4714 mtpf
4938 rxcl
7038 aopf
7330 rsm3
7344 rtrx
7362 rtsc
7373 aop2
7546 anef
7644 ispf
9196 wchf
9220 gf1f
9608 pmcf
9620 siof
9700 gfxf
10102 avef
10214 rspt
10234 pmpf
10282 rdsk
19316 rdtr
19330 rsep
19778 rkrn
(reconnect)
21331 rsep
22047 stg1
22049 sepi
22769 dtre
22775 ansf
22895 ibot
23047 ilib
23857 wchf
23889 recm
23991 liqd
24187 dcpf
24403 alpm
24505 logo
24543 aubt
24661 wchf
24701 recm
24797 liqd
24917 dcpf
25121 alpm
25227 logo
25262 aubt
25367 mtpf
25725 hpas
25745 mtfw
25847 msys
28717 exvl
28737 aopf
29211 exic
29281 aop2
29518 excl
34159 anef
34321 ispf
36807 rtsc
36827 trst
36851 gf1f
37473 pmcf
37495 ibdt
37517 lphp
37553 extc
37573 trxm
37605 rans
37737 isys
37757 sm3f
37781 avef
37963 siof
38093 gfxf
38739 pmpf
38819 sptm
86737 msys
90649 rtsc
91245 rans
91959 isys
95018 sepi
883576 cssy
883588 trcs
884583 casy
884595 trca
884631 krnl
886500 dtre
886540 isys
886776 msys
889584 isys

I hope I hope this helps.

[nikias]

Looks all good... but still something must be happening differently. I would need to compare the full restore process; essentially we would need to compare all the images that are transferred (except I guess the large filesystem images) and see if there are any new additional requests or parameters shared. You already checked the RestoreOptions so I wouldn't know what else could be the issue...

[nikias]

I realized that I didn't update the snid for the SepStage1 image. I moved the patch to this gist: https://gist.github.com/nikias/18aea0129e6029f4f6a5183a74929606 and have updated it just now to add the SepNonceSlotID from parameters when stitching SepStage1. Not sure if it would fix it though, I can't currently test myself unfortunately.

[rekyagis]

I moved the patch to this gist: https://gist.github.com/nikias/18aea0129e6029f4f6a5183a74929606 and have updated it just now to add the SepNonceSlotID from parameters when stitching SepStage1.

This patch works well.
idevicerestore can be restore my iPhone 16 from normal mode with this patch.

Thank you so much.

[nikias]

Oh wow so I guess I just forgot that one piece of code then. Thanks for confirming! I will merge this.

[nikias]

@rekyagis I updated the patch once more, would you be able to run another restore from normal mode? If not I will just commit the changes and just hope it works fine :)

[rekyagis]

@rekyagis I updated the patch once more, would you be able to run another restore from normal mode? If not I will just commit the changes and just hope it works fine :)

The updated patch also works well.
It can restore my iPhone 16 from normal mode.

Thank you so much for your great work.