So basically my situation is as follows:
Recently a family member gave me a used iPhone XR they received third hand, and asked me to unlock it for them. The phone is stuck in iCloud Activation Lock purgatory, and they do not know the original owner (again, third hand purchase), so turning to Apple for help is simply not an option.
I decided to try a process I heard about a while back to bypass this, specifically modifying an IPSW file to remove the
Setup.app from the main filesystem, so that on first boot the user would be dropped to the home screen rather than forced to go through the activation process.
While I have managed to get fairly far along in this process I am encountering a hard-stop issue. I have successfully extracted the target IPSW (
iOS Ver: 14.4.2, Buildtrain: AzulD, Build Number: 18D70, Device Class: n104ap). Two important factors to note are:
1.) That this particular IPSW is a Research/CustomerUpgrade build, so the DFU, Firmware, InstalledKernelCache, RestoreSEP, and SEP packages are marked as Research builds. The rest of the components are production/release versions.
2.) This IPSW package has an unencrypted Filesystem Ramdisk by default, and uses hash/checksum verification during restore, rather than decryption keys, as it’s main method of tamper-protection.
With these in mind, I have managed to mount and modify the Filesystem Ramdisk (
038-96459-065.dmg) using a shadow copy via
hdiutil. I then merged the shadow copy into the original using
hdiutil, and recompressed the IPSW using macOS’s built in Archive Utility.
This process yields an IPSW package that successfully passes iTunes/Finder Nonce verification and begins to install, however though it installs the first two Ramdisks and the firmwares successfully, when it attempts to install the Filesystem Ramdisk (modified 038-96459-065.dmg) it fails a checksum verification and aborts install halfway through, yielding this error:
The iPhone “iPhone” could not be restored. An unknown error occurred (14). 065B.000E
The iPhone then becomes stuck on the Apple screen with the progress bar showing 1/3rd full. Attempting to enter Recovery mode fails and will not allow restoring of the phone. The error code 14 represents an unspecified interruption part way through the install, and placing the phone in DFU mode and restoring from an unmodified IPSW works fine. This is what has me convinced it is failing a checksum verification on the modified Ramdisk.
My question: is there a known (or theoretical) way to bypass the checksum verification on the System image? Perhaps by modification of the
BuildManifest.plist? Replacing the contents of
Firmware/038.96459-065.dmg.root_hash with an accurate hash for the modified Ramdisk (Assuming the hashing method for these files is known and publicly available)? Spoofing the CRC-32 checksum on the
.dmg itself? Replacing the contents of the relevant
.mtree file for the
.dmg with a newly generated string?
NOTE: All suggestions are welcome, but please do not respond if you have no relevant/specific information to share.
A message to the moderators: I apologize if this question is, technically speaking, not on the correct forum, however I am unaware of another one which would be more relevant to the project at hand. If you feel this question does not belong here, please simply refer me to a place that would better suit this question, and I will migrate it myself. There is no need to lock or migrate this thread on my behalf, I am not that stubborn.