A Complete Guide to Setup.app and Activation LockWritten and Edited by Apple Tech 752, Security Researcher and Bypass ExpertWhat is an iCloud Bypass? How does an iCloud Bypass work?
How it Works: The mobileactivationd binary is renamed and replaced with a disassembled/patched copy, for which all instances of unactivated are changed to activated. This tricks the iOS device into thinking it has valid activation records for the purpose of skipping the setup assistant, but in reality none have been applied, so all device features that require activation records to function properly are not useable. All apps that do not require activation records are completely useable, including Safari, Music, Camera, Photos, and much more. However, since the patched binary cannot be codesigned with an Apple signature, this bypass is not persistent after a reboot.
iOS 12 mobileactivationd Bypass
Type: Indirect Setup.app mitigation
Tools: Sliver Mac
Target Devices: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Mini 2, 3, iPad Air 1, iPod Touch 6
Target Versions: iOS 12.4.5 - 12.5.1
How it Works: The mobileactivationd binary is renamed and replaced with a disassembled/patched copy, for which all instances of unactivated are changed to activated. For iOS 12, additional steps are taken to ensure the device accepts the unsigned binary, including uicache. This tricks the iOS device into thinking it has valid activation records for the purpose of skipping the setup assistant, but in reality none have been applied, so all device features that require activation records to function properly are not useable. All apps that do not require activation records are completely useable, including Safari, Music, Camera, Photos, and much more. However, since the patched binary cannot be codesigned with an authentic Apple signature, this bypass is not persistent after a reboot.
How it Works: Setup.app is renamed to Setup.app.bak to remove the presence of the Setup Assistant. Additional steps are taken to ensure that Setup.app is completely unrecognizable, including uicache and restarting the backboardd process. Because the device has no idea that Setup.app exists, this modification is persistent even after a reboot. All apps that do not require activation records are useable, including Safari, Music, Camera, Photos, and much more. Apple identified and patched this method with the release of iOS 13.3, which introduced a new systemwide detection of Setup.app that sends iOS devices into a panicked, frozen state when Setup.app is unrecognizable. As a result, the mobileactivationd bypass was discovered and introduced.
How it Works: Passcode locked or disabled devices almost always have a valid set of factory activation records (unless they were bypassed previously). When a passcode bypass is performed, those records are extracted and saved to a folder on the Desktop (specifically activation_record.plist, data_ark.plist, commcenter.plist, and IC-Info.sisv within the FairPlay folder). A system binary is then inserted into the /bin directory in the root filesystem and given an argument that instructs the device to force erase itself regardless of whether FMI (Find My iPhone) is turned on or turned off.
After the erase has completed, all user data including the passcode is gone, but the device needs a valid set of activation records to pass the setup assistant (Setup.app) and activate Phone, Messages, FaceTime, iCloud, etc. Normally Albert (Apples activation server) would provide these records, but because Find My iPhone is turned on, Albert refuses to generate a new activation_record.plist and instead shows the Activation Lock page. However, this is not a problem, because all of the activation records that we saved to the Desktop can be re-applied into the filesystem. Before the activation records are installed, they are uploaded to the user Media (Downloads) folder and permissions/flags are changed so that the device will be able to read and accept them when they are moved to their correct locations. A good passcode bypass will set permissions/flags such that all activation records are signed and persistent after a reboot, and unchanged by setting a passcode. Both Sliver 6.1 and Sliver5Windows perform this exact process.
How it Works: By now you probably understand that Albert will refuse to generate activation records for devices that have Find My iPhone turned on. That part is pretty straightforward. But consider this- activation records are also specific to the unique identifiers of every iOS device (such as Serial Number, IMEI, UDID, ECID, etc). In other words, if activation records are created for the specific unique identifiers of a device, that device will accept them and become fully functional. This is the general idea that hackers used to come up with an extremely clever method to fetch activation records directly from Albert for any target iOS device. While in reality Signal Bypass is a very sophisticated and complicated method, the overall concept is fairly simple and understandable.
It all starts with another iOS device. To start, another iPhone that has Find My iPhone turned OFF is jailbroken so that its root filesystem can be modified. Next, the unique identifiers of the Activation Locked device that has Find My iPhone turned ON (Serial Number, IMEI, UDID, etc) are fetched and assigned to the second iOS device that has Find My iPhone turned OFF. In other words, the unique identifiers of the device with Find My iPhone OFF were temporarily covered up replaced with the unique identifiers of the device with Find My iPhone ON. Now, here is the best part. Albert (albert.apple.com, Apples activation server) does not notice or care that the second device with Find My iPhone OFF has a changed set of unique identifiers. Under normal circumstances Albert might notice, but an SSL process that occurs during activation is modified (people also call this hooking or pinning) to ensure that Albert is completely oblivious to the fact that the IMEI, Serial Number, UDID, etc came from an Activation Locked device that has Find My iPhone turned ON.
Right, now we are in an absolutely perfect situation. What happens next is an activation request (AKA the process that happens when it says It may take a few minutes to activate your iPhone) is started from the device with Find My iPhone OFF. Since Albert has no clue whatsoever that the unique identifiers are different, it generates a perfectly valid set of activation records based on the unique identifiers it sees, which are of course the unique identifiers of the Activation Locked device with Find My iPhone ON. At this point, the freshly generated activation records are taken from the device with Find My iPhone OFF and the most important piece (the WildCard ticket) is applied to the filesystem of the Activation Locked Device with Find My iPhone ON in the form of activation_record.plist (just like the Passcode Bypass). Because the activation_record.plist was created for the unique identifiers of the Activation Locked device by Albert (the only process that is capable of creating activation records), everything is perfect, and the device is able to accept the activation records (also known as a baseband ticket) in the same way it would have accepted them if normal activation had occurred (which basically did).
The reason Apple has not patched this method is because to implement a process in Albert that checks the authenticity of the unique identifiers of every device that gets activated would require a complete server rework and cost an extreme amount of money. Apple has chosen not to dedicate their resources to performing such a task. Unless they change their mind, the GSM Signal Bypass will likely exist forever for checkra1n-compatible iOS devices. However, the majority of iOS devices nowadays have an MEID, which is like an extra layer of security that prevents the device from being able to accept non-authentically generated activation records. This just adds an extra step though, and hackers have already found a way to hash/sign the records to bypass it. Good news: the method was discovered, and signal bypass for both MEID and GSM devices (iPhone 5s to iPhone X) is now possible with Checkm8.Info and iRemoval Pro.
How it Works: When you restore an iOS device to the latest version of iOS normally (with iTunes or 3uTools), a series of small image files are uploaded and executed before the restore actually begins. The purpose of this process is to prepare the device for a full filesystem rewrite. These files include iBSS, iBEC, DeviceTree, Ramdisk, and Kernelcache. For a normal restore, the device would actually receive a newly-written filesystem after all these files are uploaded, which is important to understand, because all ramdisk iCloud Bypass methods work by starting a restore but not actually restoring the device or writing any contents.
The first and most important step in any ramdisk iCloud Bypass method is PWNED DFU MODE with the checkm8 exploit. What PWNED DFU allows us to do upload whatever image files we want. The regular image files for the latest version of iOS might upload properly without PWNED DFU, but that wont help us at all. We need to upload special patched versions of everything: patched iBSS to allow patched iBEC to load, patched iBEC to give the device custom boot arguments (including -v for verbose boot), and most importantly, a patched ramdisk that instructs the device to open up an SSH connection when all the pre-restore steps are complete. An exploit like checkm8 is required to upload and excecute patched and unsigned images.
Sliver has all of the necessary patched files for every device pre-bundled and loads them automatically when you click Load Ramdisk. After the last file (Kernelcache) is uploaded, the bootx command is executed, which starts the SSH connection and allows any client to SSH into the device (popular ones are TCPRelay, iproxy, Cyberduck) and view the root filesystem. Sliver uses TCPRelay when you click Relay Device Info. For A7 devices, a custom payload is then executed that instructs the device to delete Setup.app and reboot itself, so no ramdisk image is necessary, but for all A6 and A5 devices, the SSH connection is opened first through the ramdisk and then a script is executed that automatically logs into root@localhost and runs the ssh commands to mount the filesystem, delete Setup.app, and reboot. For A5 devices, when Setup.app is missing the device will simply boot straight to the home screen. For A6 and A7 devices however, the device must have been restored and put into DFU mode immediately prior to the bypass or else the black screen issue will occur.
The reason for the black screen issue is when the device has not completed the post-restore progress bar, which essentially resets the filesystem. When Setup.app is deleted and the post-restore progress bar occurs afterwards, the device understands that Setup.app never is and never was a part of the filesystem, so it can ignore it. But if the post-restore progress bar has already completed with Setup.app and then Setup.app is deleted afterwards, the filesystem will think it is missing something and refuse to boot to the home screen. This is why I always tell people to restore and enter DFU before the on-device progress bar when attempting any ramdisk method, just to be safe.
