Libimobiledevice: Wireless charge failed after reflash iOS 14

[ducquyenkmt09]

Hi team,

Have anyone help me to fix the issue iDevice failed wireless charge after reflash to iOS 14 official?

Thank so much !

[a-gunter]

Experiencing the same thing here with iPhone XSM, I will try to test more models in some time to get a bigger picture.

Device flashed via iTunes to iOS 14.0 will charge wirelessly; same device flashed via idevicerestore will not.

EDIT: Factory reset does NOT fix the issue after flashing via idevicerestore. 100% reproduce-able

[nikias]

@ducquyenkmt09 what device? Was it an erase restore or did you keep the user data?

[pekn]

This happens at least with iPhone XR, iPhone XS, iPhone XS Max and iPhone 11. Devices do charge wirelessly, but the battery charging indicator doesn't update.

[pekn]

Forgot to mention: iPhone 8 and iPhone X work OK

[nicolassan]

Same problem with the lastest libimobiledevice on Windows, wireless charge not working with IOS 14.

@nikias : Its a full erase restore

Even after "Erase content settings" , the problem is the same.

It's not a display problem, there is no charge.

The only solution is to restore it with itunes.

[nikias]

Is there any chance you can do another restore with -d and post the full output? Maybe we can see something. It sounds like the personalization of the wireless charging component failed. Back when faceid was introduced we had a successful restore but faceid wasn't working due to a bad component personalization. However in iOS 13.7 wireless charging definitely works after a restore, so 🤷‍♂️

[Orbif]

I noticed the same problem with iPhone Xr, Xs, 11, 11 pro and latest idevicerestore on Windows.
A factory reset doesn't solve the problem.

Here the output of idevicerestore with -d on iPhone 11 : iphone 11 restore full output

[ducquyenkmt09]

@ducquyenkmt09 what device? Was it an erase restore or did you keep the user data?

all models have Wireless charge.

[mexmer]

@ducquyenkmt09 what device? Was it an erase restore or did you keep the user data?

all models have Wireless charge.

no, wireless charge has been added to iphone starting with iphone 8 while ios 14 is supported on iphone6s and newer, and ipads don't have wireless charge at all.

[nikias]

I wonder if this has to do with the fact this is a Windows build...

[a-gunter]

I see the same results on Ubuntu 20.04 and Mac OS 10.14.6. Can't provide a debug log currently but I can edit tomorrow with a debug log from Ubuntu

EDIT: Ubuntu debug log below, erase restore with iPhone XSM on iOS 14.0,
restore_log_14.0.txt

[a-gunter]

Looks like the issue isn't affecting iPhone 8, iPhone 8+, and iPhone X (from what I'm seeing). But from every other model I've tested, I have not been able to wirelessly charge the model afterwards.

Is there anything we can learn from the personalized components for iPhone 8 / 8+ / X? At first I was confused as to why iPhone 7 wasn't wirelessly charging if iPhone 8 works, and then I realized iPhone 7 doesn't support it...

EDIT: Also should mention that iOS 14.0.1 is exhibiting the same issues. The only current solution seems to be performing an iTunes restore

[a-gunter]

I guess looking at iPhone 8 / 8p / X may be a dead end since there's no WirelessPower.im4p component in those .ipsws...

Any thoughts here? I don't suppose there's a way to compare the WCHFirmwareUpdater components on 13.7 vs on 14.0+?

[nikias]

The components work with iTunes so something must go wrong when stitching the img4. I didn't see any unimplemented request or similar in the logs. Maybe it's some bug in the code. If idevicerestore is ran with -k it will write the personalized components to a file. Then we can take a look.

[a-gunter]

I've got an example of the components for XSM on 14.0, but I don't have anything from 13.7. I took out some of the bigger files but left in WCHFirmwareUpdater

Personalized_XSM_14.0.zip

[Orbif]

I tried to compare idevicerestore (-k option) personalized components with components present on ipsw. They are very similar, but idevicerestore components have a different header and more data at the end. Is this normal ?

For example, for WCHFirmwareUpdater, the component present on ipsw is smaller than the file I got with -k option.

@nikias Do you see something unusual between those two files ?

[nikias]

The overhead is normal. The IM4P will be embedded into an "IMG4 sequence" (ASN.1 format) followed by the ApImg4Ticket. The ticket also includes the digest (DGST) for the wireless charging component:

56338:d=8  hl=2 l= 127 cons: SEQUENCE
56340:d=9  hl=2 l=   4 prim: IA5STRING         :wchf
56346:d=9  hl=2 l= 119 cons: SET
56348:d=10 hl=7 l=  58 cons: priv [ 1145525076 ]
56355:d=11 hl=2 l=  56 cons: SEQUENCE
56357:d=12 hl=2 l=   4 prim: IA5STRING         :DGST
56363:d=12 hl=2 l=  48 prim: OCTET STRING      [HEX DUMP]:7A0A294F476D6CA79F36E1274931FDDF8C3EEA8079010285FFEE312561A5ABBF77D99B0DD19E0C285654E8A8809196AF
56413:d=10 hl=7 l=  11 cons: priv [ 1162560857 ]
56420:d=11 hl=2 l=   9 cons: SEQUENCE
56422:d=12 hl=2 l=   4 prim: IA5STRING         :EKEY
56428:d=12 hl=2 l=   1 prim: BOOLEAN           :255
56431:d=10 hl=7 l=  11 cons: priv [ 1162891855 ]
56438:d=11 hl=2 l=   9 cons: SEQUENCE
56440:d=12 hl=2 l=   4 prim: IA5STRING         :EPRO
56446:d=12 hl=2 l=   1 prim: BOOLEAN           :255
56449:d=10 hl=7 l=  11 cons: priv [ 1163085123 ]
56456:d=11 hl=2 l=   9 cons: SEQUENCE
56458:d=12 hl=2 l=   4 prim: IA5STRING         :ESEC
56464:d=12 hl=2 l=   1 prim: BOOLEAN           :255

This looks totally normal to me so I don't know what would be wrong...

[demhademha]

Question, are all your utils built from source and up to date, maybe idevicerestore is linking against an old library?

[a-gunter]

idevicerestore and its dependencies are all built from their up-to-date repositories for me.

There's no equivalent for a device syslog during the restore process, is there?

[nikias]

Unfortunately not...

[ducquyenkmt09]

Have any solution for this issue?

[Chasewhip8]

Could you use a DCSD cable tp give you a restore log?

[ducquyenkmt09]

Could you use a DCSD cable tp give you a restore log?

Here is it,
iphone11_iq_pb_restore.txt

[nikias]

@ducquyenkmt09 that's the same log @Orbif posted above. I don't think DCSD wouldn't help to get a serial log as you can't get serial output without modifying boot arguments when starting the kernel (unless the restore kernel enables it by default which I highly doubt). On production devices this only works with a bootrom/iBoot exploit.

[Chasewhip8]

Ye I assumed they would have it enabled on the restore

[a-gunter]

So the wchf component looks like it's stitched correctly, and as far as the rest of the img4 components are concerned, they weren't affected by 14.0, right? Would it be possible for the rules / requirements for stitching a specific img4 file to get changed?

Everything seems to point towards the wchf component since wireless charging is only affected on IPSWs that include the component... Is it possible to sniff out anything useful from an iTunes restore?

[Orbif]

I started to compare iTunes and idevicerestore data sent to an iPhone 11, but I don't see significant difference for the wchf component.
So far, the most visible difference seems to be the baseband data sent to the device.

If I understood well, the baseband data is extracted from ICE19-2.00.01.Release.bbfw. Maybe wrong data is extracted from this file ?

We also see on idevicerestore logs the message "WARNING: size mismatch when parsing MBN file" and "DEBUG: Unknown file format passed to mbn_parse".
Is this warning normal ?

[nikias]

@Orbif thanks for the feedback. The warning should be ok, it was an error before until we realized the format changed slightly, and it would still work if you ignore the value in the header vs. the actual file size. However, the baseband will report an error if it failed to update (and report success if it was successful) and if it should really be broken you wouldn't get any signal... also hard to imagine that the baseband has anything to do with wireless charging.

[a-gunter]

I pulled the personalized WCHF component from an iTunes restore, and like @Orbif mentioned, there's a small difference when compared to idevicerestore (this is an XR on 14.0.1). Would this difference be enough to cause the issue?

Here are the two personalized files, and here's a diff between the two files

[nikias]

@a-gunter the only difference is inside the APIMG4Ticket that was stitched into the personalized files. This is what we receive from Apple, so the only way something could be wrong is if there is something missing in the TSS request, but all the properties (like ESEC, EPRO, etc.) are matching. All the differences are nonces and the rsa signature bytes that change with every ticket...

[a-gunter]

Ah ok, that makes sense. Is there any other direction you'd go in to troubleshoot this? Maybe somehow the issue isn't rooted in the img4 stitching after all?

[nikias]

I have been digging through MobileDevice framework but couldn't find anything in particular. Maybe there's something in the TSS request that is different; we need to compare what is sent by iTunes and what is sent by idevicerestore. I mean it doesn't look like something is missing really but who knows...

[Jame-sudo]

Hi all,

I captured all data restore of iTunes and I found the package incorrect on libimobileidevice.
We need to append more data before restoring iOS 14 to iDevice to fix the wireless charge issue.
I tested and it works on all model iPhone 8 -> iPhone 11 Pro Max. The wireless charge works normally after restoring.
Contact with me if you want to get more detail.
Jame-sudo from Israel ([email protected])

[nikias]

@Jame-sudo can you just post the details here so we can fix it properly? We don't need the full dump, just the part that is different. Thanks.

[Jame-sudo]

Hi Nikias,
 I supporting for a big project with our libmobileidevice on linux and this issue is very important to me. I asked many forums to find a way to fix this issue but didn't get anything. When I post this issue on under Apple forum, have a worker at Apple inbox to me. He said "have some data of WLC data was encrypt on the package restore" and he sells the key to decrypt this data. We need the key to decrypt data and append WLC data into iOS package to restore. But I have not enough money to buy this. Can we buy this key together to fix this issue?

Thanks,Jame-sudo

On Monday, October 5, 2020, 9:59:45 PM GMT+7, Nikias Bassen <[email protected]> wrote:

@Jame-sudo can you just post the details here so we can fix it properly? We don't need the full dump, just the part that is different. Thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[pekn]

@Jame-sudo - that sounds like a scam. How much money does he ask?

[nikias]

@Jame-sudo I find it kind of hard to believe that someone at Apple would "sell some key". You said you found some differences in the dump, then what are the differences? Is it with the wireless charging component? Is it something else?

[a-gunter]

Sorry @nikias I've been away from this issue for a couple of days... I've got the TSS request and response from the same iTunes restore that I provided the wchf component for (iPhone XR on 14.0.1).

This is the debug folder pulled from the iTunes restore

Let me know if I can provide anything else

[Jame-sudo]

Hi Nikias,
 Yes, it's so hard to believe.. but I don't have other choices. This issue is very important to me, I have been fixed this issue 2 weeks but don't find solution.
 He said "he's an under Apple" and unlock the iPhone and jaibreak iDevice is his job.. oh my god... I think he is a hacker :(

"You said you found some differences in the dump, then what are the differences? Is it with the wireless charging component?"-> He asked me about that and this data encrypted and he will sell the key to decrypt ... it's so bad :(

Thanks,Quyen Tran
On Tuesday, October 6, 2020, 8:58:41 PM GMT+7, Nikias Bassen [e-mail] wrote:

@Jame-sudo I find it kind of hard to believe that someone at Apple would "sell some key". You said you found some differences in the dump, then what are the differences? Is it with the wireless charging component? Is it something else?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[ducquyenkmt09]

@Jame-sudo How much for 1 key.. Can we buy this code and use it together. But you have to make sure it woks well.
How to verify the key ?

[nikias]

Guys, don't think about buying any sort of key before we understand the actual problem. We need a full USB dump of the restore procedure. I just don't have a matching device here on iOS 14 that I could test with. Also the MobileDevice framework on macOS doesn't seem to do anything weird that it didn't do before... I mean it's quite big and I might have missed something, but at least I didn't see anything really obvious of that sort.

[a-gunter]

How can we get a full usb dump from an iTunes restore? Is something like Wireshark sufficient?

[Orbif]

I can provide USB dump from usbpcap for both iTunes and idevicerestore, but this is +5GB dump file for each

[nikias]

@Orbif great... yes that's the issue with that. The thing is we don't know exactly what we're looking for so we could narrow it down....
@a-gunter btw. the TSS request and reply look pretty normal, and matches with what idevicerestore is sending (judging from your other log you posted before).

[a-gunter]

@Orbif do you have a google drive or dropbox or something that you can host the files on?

[a-gunter]

I have a capture log from wireshark uploaded to this google drive if you want to look at it. It's from iTunes on a Mac restoring an iPhone XR to 14.0.1. Lot of data... (5GB). I'm not sure if I should have filtered anything out, so I just captured everything I could coming from that specific USB port. Let me know if I need to filter anything or provide timestamps for certain parts of the process, I guess it could help narrow down where to look.

I don't have the equivalent from idevicerestore yet, the Mac I used doesn't have libimobiledevice set up on it. I can get it if needed, though.

[nikias]

@a-gunter Amazing, I will have a look.

[Orbif]

I uploaded usbpcap usb full dump of the same iPhone 11 on both itunes and idevicerestore, if anyone want to do the comparison.

[Orbif]

I just found out the element Firmwarevinyl_05.vnlfw is present only on ipsw of iPhones that have the wireless charge problem.
I saw there is vinyl parameter on tss request but the vinyl_05.vnlfw file doesn't seem to be used on idevicerestore.

Maybe this is the cause of this issue ?

Can this plist be useful to add this component support on idevicerestore ?

[nikias]

@Orbif good observation. The weird thing is that the device is requesting whatever it needs for the restore, so maybe it's inside one of the known requests and we have to add the image somewhere...

[nikias]

I think the vinyl stuff is for the embedded eSIM card though...

[nikias]

While I didn't go through the whole restore yet, one thing I noticed is that the RestoreOptions has a new entry

        <key>iBootEANNuke</key>
        <true/>

Now out of experience most of the restore options are ignored during a release version restore, but we had other missing entries in the past. So worth a shot IMO.
This can be tested by adding a line

plist_dict_set_item(opts, "iBootEANNuke", plist_new_bool(1));

here:
https://github.com/libimobiledevice/idevicerestore/blob/master/src/restore.c#L2882

I will keep looking...

[a-gunter]

No luck unfortunately with that patch; restore is successful but no wireless charging capability.

It looks like the vinyl_fw pieces were also present in 13.7, where wireless charging worked with idevicerestore, but I'm not sure if the tss request parameters changed between 13.7 and 14+

[hiepnh0]

BuildManifest.plist has 2 new keys:

<key>IsiBootEANFirmware</key>
<false/>
<key>IsiBootNonEssentialFirmware</key>
<false/>

Is that the root cause of the issue?

[nikias]

@a-gunter well, I kinda expected that it wouldn't be that easy.
@hiepnh0 currently idevicerestore is only checking for IsLoadedByiBoot for these components to decide wether it should send them over at a specific stage of the restore. I am currently writing a script that allows me to extract the packet payloads from the wireshark dumps so I don't have to do that manually, so I can see what it actually transfers.

[nikias]

Ok I got something. Apparently the NORData data request expects the WCHFirmwareUpdater image as part of the NorImageData images. Currently, idevicerestore picks these components based on the IsFirmwarePayload: true entry and if it has a Path property. From @a-gunter's dump, I see the following images being sent back:

• AppleLogo (IsFirmwarePayload: true)
• BatteryCharging0 (IsFirmwarePayload: true)
• BatteryCharging1 (IsFirmwarePayload: true)
• BatteryFull (IsFirmwarePayload: true)
• BatteryLow0 (IsFirmwarePayload: true)
• BatteryLow1 (IsFirmwarePayload: true)
• BatteryPlugin (IsFirmwarePayload: true)
• DeviceTree (IsFirmwarePayload: true)
• LowPowerWallet0 (IsFirmwarePayload: true)
• RecoveryMode (IsFirmwarePayload: true)
• WCHFirmwareUpdater (IsSecondaryFirmwarePayload: true && IsLoadedByiBoot: true)
• iBoot (IsFirmwarePayload: true)

I added in parenthesis the flags from the BuildIdentity (BuildManifest) that would match the selection; The only component I found that has IsLoadedByiBoot: true and is sent back in the NorImageData array is WCHFirmwareUpdater, and so I found it's the only component that has IsSecondaryFirmwarePayload set to true (so both flags have to be set).

So basically the decision to pick the components seems to be this:

if (IsFirmwarePayload || (IsSecondaryFirmwarePayload && IsLoadedByiBoot)) {
    // add to list
}

Here a patch that will add this to restore.c:

diff --git a/src/restore.c b/src/restore.c
index 3e84689..ba2d420 100644
--- a/src/restore.c
+++ b/src/restore.c
@@ -1059,11 +1059,26 @@ int restore_send_nor(restored_client_t restore, struct idevicerestore_client_t*
                plist_dict_next_item(build_id_manifest, iter, &component, &manifest_entry);
                if (component && manifest_entry && plist_get_node_type(manifest_entry) == PLIST_DICT) {
                    uint8_t is_fw = 0;
-                   plist_t is_fw_node = plist_access_path(manifest_entry, 2, "Info", "IsFirmwarePayload");
-                   if (is_fw_node && plist_get_node_type(is_fw_node) == PLIST_BOOLEAN) {
-                       plist_get_bool_val(is_fw_node, &is_fw);
+                   uint8_t is_secondary_fw = 0;
+                   uint8_t loaded_by_iboot = 0;
+                   plist_t fw_node;
+
+                   fw_node = plist_access_path(manifest_entry, 2, "Info", "IsFirmwarePayload");
+                   if (fw_node && plist_get_node_type(fw_node) == PLIST_BOOLEAN) {
+                       plist_get_bool_val(fw_node, &is_fw);
+                   }
+
+                   fw_node = plist_access_path(manifest_entry, 2, "Info", "IsLoadedByiBoot");
+                   if (fw_node && plist_get_node_type(fw_node) == PLIST_BOOLEAN) {
+                       plist_get_bool_val(fw_node, &loaded_by_iboot);
                    }
-                   if (is_fw) {
+
+                   fw_node = plist_access_path(manifest_entry, 2, "Info", "IsSecondaryFirmwarePayload");
+                   if (fw_node && plist_get_node_type(fw_node) == PLIST_BOOLEAN) {
+                       plist_get_bool_val(fw_node, &is_secondary_fw);
+                   }
+
+                   if (is_fw || (is_secondary_fw && loaded_by_iboot)) {
                        plist_t comp_path = plist_access_path(manifest_entry, 2, "Info", "Path");
                        if (comp_path) {
                            plist_dict_set_item(firmware_files, component, plist_copy(comp_path));

Let me know if this makes it work and I'll push this to master.

[nikias]

Also if you added anything about the iBootEANNuke I mentioned above, please undo it. I need to understand the logic behind that first.

[a-gunter]

You're the MAN!

Looks promising; I tested an iPhone XSM on 14.0.1 and was able to wirelessly charge the device afterwards. I'll try to get around to testing the rest of the affected models sometime today & I'll update this comment

EDIT: Verified on all affected models 👍

[Orbif]

@nikias I just tested, It also worked on iPhone 11, I think the problem is solved. Thank you !

[nikias]

See commit https://github.com/libimobiledevice/idevicerestore/commit/18ba27c74305100146dd9599336dbdcd5e794ad1.

[nicolassan]

Great job Nikias, you're a genius !

Many thanks

[ducquyenkmt09]

Very good job Nikas,
I tested on all iPhone devices and it works well.

Many thanks,