Apple tech 752 bypass tool windows

Apple tech 752 bypass tool windows

The iPad 2 / A5 Bypass (sliverPHP) works by applying generic activation certificates to the device via iDeviceActivation (in reality, this is an iOS 7.x.x bug that Apple patched on every other device but forgot to patch only on the iPad 2). However, due to the properties of the certificates that are applied, they do not persist after a reboot, meaning the bypass is tethered (re-locks after rebooting).

A few years ago, iOS 6.1.3 was signed by Apple. This allowed iPad 2 users to downgrade to iOS 6.1.3, bypass with the iPad 2 server, then update OTA (in the settings application) to iOS 8.4.1. This resulted in an untethered iCloud Bypass, because iOS 8.4.1 is a firmware that supports sideloading 3rd party applications on unactivated devices, so it was super easy to install EtasonJB and delete Setup.app with iFile or Filza. However, Apple is no longer signing iOS 6.1.3, so this method is outdated. If you have an Apple Developer Program Account, you can bypass with the iPad 2 server on 9.3.5 and install the Phoenix jailbreak to delete Setup.app, but this is not a good solution since it is extremely expensive.

Overall, the iPad 2 Bypass Server is a temporary solution. Those wanting a permanent solution should invest in an OEM Arduino Uno and USB Host Shield (when you get any other A5 device in the future, you will be glad you did).

Why does my device show the apple logo/black screen after deleting Setup.app with Sliver?

The reason for the black screen issue is when the device has not completed the post-restore progress bar, which 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 mode immediately before attempting any ramdisk method, just to be safe.

Why does Sliver say Move to Trash and refuse to open?

On newer MacOS versions, all applications are thoroughly scanned, and Sliver is incorrectly labeled by Apple as incompliant software. The quick fix is to open a Terminal window and type sudo xattr -rd com.apple.quarantine /Applications/Sliver.app/. Another solution is to open Sliver until you get the Move To Trash popup, then 2-finger click on Sliver in your Applications folder, click Get Info, Override Malware Protection. This is usually a small checkbox in the Get Info pane.

Why does checkm8-a5 fail to upload to my Arduino when the USB Host Shield is attached?

There are multiple reasons why this can occur. The most likely and most common issue is that your Arduino Uno is a CLONE. If yours is a blue board that says UNO in big letters, thats an immediate red flag that you bought a fake device. You need an OEM Arduino Uno with the +/- logo and Made In Italy printed on the back (usually OEM boards are green rather than blue). The second most common issue is that 3 essential pins on your usb host shield are not connected to each other. This can easily be fixed by soldering the 3 pins so they make contact. If you google search this topic, you will find plenty of forums on the official arduino website with more details on the exact solution. Lastly, its possible that your LED is connected to the wrong pins, or if you are using an old printer cable, maybe it does not have all the wires attached. I recommend buying brand new LEDS and cables so that wear and tear is never a concern.

My arduino successfully put my A5 device into pwned DFU mode, why is Sliver not loading the ramdisk?

Use SYNACKUK checkm8-a5 (NOT a1exdandy), and the latest release of Sliver or SliverM1. Make sure to delete all old versions of Sliver from your Applications folder BEFORE installing the latest version. It is extremely important to only have one copy of Sliver in /Applications! Also, SliverM1 users can access the Arduino Setup Tutorial (included in the app) which explains more details about Arduino-USB patching.

What if the ramdisk is still not loading?

If you are using Sliver 6.1 and still have issues, check out the pinned guide on reddit.com/r/setupapp for ramdisk troubleshooting. It has detailed instructions and explanations for every possible issue that could prevent the ramdisk from loading on A5/A6 devices. You can also comment on the post with any further questions.

Why are some files missing from my activation folder? (Sliver Passcode Bypass)

Check to see which files are missing. If the activation_record.plist is missing, or if the FairPlay folder is missing entirely, it means your device was probably iCloud Bypassed by someone else who set a passcode, and it does not have any activation records to back up. If the Activation folder is blank (does not contain any files), then your device is likely USB restricted. Use checkra1nRG to jailbreak. You can also try to reboot or reinstall MacOS. If for some reason these steps still produce a blank activation folder, I recommend trying the FMI OFF method. You can contact IFPDZ on Telegram to order FMI OFF for your passcode locked/disabled device at t.me/ifpdz.

How can I fix Unable to Access Resources on Sliver?

Follow this tutorial to install Homebrew, then open a new Terminal window and type brew install libusb. Close and relaunch Sliver, the issue should be fixed.

Why does the iPad 2,1 fail to connect to MagicCFG in Purple Mode?

The iPad 2,1 has a bug that makes it unrecognizeable after loading a diagnostics image. Although the exact cause is unknown, it could be a hardware disconnect in the 30-pin DCSD cable. The iRepairBox is now updated and works with the iPad 2,1. Visit AliExpress to purchase the iRepair P10.

Can I jailbreak iOS 10.3.3 or 10.3.4 after deleting Setup.app with Sliver?

Apple patched standard sideloading on bypassed devices for all versions higher than iOS 9, so there is no free method to install H3lix on iOS 10.3.3 / iOS 10.3.4. If you have an Apple Developer Program Account, use Sliver A6 FactoryActivation and install the iPA with Cydia Impactor. Otherwise, you can downgrade to iOS 8.4.1, install H3lix, and update back to iOS 10.3.3 / iOS 10.3.4 to jailbreak, but the downside is the H3lix app will get revoked after 7 days, and you would have to downgrade and upgrade again to re-install it. This method theoretically supports the iPhone 5 and the iPad 4, but it does NOT support the iPhone 5c, since it has no 8.4.1 OTA blobs.

If I restore or OTA update my iCloud Bypassed device, will Activation Lock come back?

iPhone iCloud Bypass (GSM/MEID Signal Activation) does NOT remove iCloud from Apples servers, only your device. Read my Blog to understand why your iPhone will become locked again if it is restored or updated. Older iPads (WiFi not cellular) can be unlocked forever with purpleSliver. See the iCloud Bypass page for more details.

Will there ever be a bypass for the iPhone XR/XS/11/12?

All Activation Lock Bypass methods require the checkm8 bootrom exploit, which was patched by Apple with the release of the A12 processor. This means that all devices higher than the iPhone X are unsupported, and there is no way to bypass Activation Lock on the iPhone XR, XS, XS Max, 11, 12, or 13 until a new bootrom exploit is discovered.

Will there ever be a bypass for A5 devices that does NOT require arduino?

Most likely not, unless someone decides to port checkm8-a5 to Mac. If this ever does happen, I will immediately add support to Sliver, but given how long it took a1exdandy and synackuk to make checkm8-a5 for arduino, we cannot expect anything too soon.

Источник

Apple tech 752 bypass tool windows

A bypass is the process of removing or mitigating the effects of activation on iOS devices. Depending on the device model and iOS version, an iCloud Bypass can be accomplished either directly by deleting the Setup.app directory from the root filesystem, or indirectly by either modifying existing activation executables or injecting spoofed Activation Records. All modern-day bypass methods are possible because of the extremely powerful and unpatchable checkm8 bootrom exploit that allows us to modify the root filesystem of iOS devices through SSH. The most well known platforms that make use of this exploit include checkra1n, ipwndfu, and checkm8-a5 (arduino).

The goal of direct methods is to create a situation where the device has no Setup and therefore has no choice but to load the SpringBoard, the next highest process after the Setup Assistant (Setup.app). The goal of indirect methods is slightly different- rather than removing Setup.app by deletion, they trick the device into thinking that it has valid activation records. Therefore, even though Setup.app still exists, the device believes that it was activated normally, so it no longer views Activation Lock as a necessary step in the Setup Assistant. Most indirect methods allow you to complete the setup assistant normally after passing the activation screen, since it is nearly impossible to differentiate spoofed activation records from legitimately generated activation records (more on this later).

What causes Activation Lock?

In simplest terms, Activation Lock occurs when an iOS device does not have valid Activation Records and Find My iPhone (FMI) is turned on. There are multiple ways to cause Activation Lock. The first and most common is by restoring or erasing an iOS device that has Find My iPhone turned on (typically with iTunes or 3uTools). Activation Records are Setup.app repellents, they are what prevent the Setup screen from appearing (so long as they exist), and when you restore an iOS device without retaining user data, everything is erased, including Activation Records. Without Activation Records, iOS will by default load the Setup Assistant (Setup.app).

Activation Records are required to a) pass the setup screen legitimately and b) be able to use the most important parts of your iOS device (cellular data, calls, notifications, FaceTime, iMessage, Siri, iCloud, etc). As it turns out, the ONLY way to get activation records is from Apple (yes thats right, Apple controls your ability to use YOUR device). After a restore, all iOS devices attempt to make themselves useable by connecting to Albert, (the name of Apples activation server- the ultimate dictator of every iPhone, iPad, and iPod Touch on the planet). Albert then gets to decide whether he wants you to be able to use your device or not. His decision is based entirely on a single fact- whether or not Find My iPhone is turned on. Using the Unique Identifiers of your device, he makes his choice. If FMI is on, he says YOU SHALL NOT PASS and throws an HTML page we all know as Activation Lock. If FMI is off, he says We can be friends, have a nice day, and hands your a cryptic golden ticket that a) tells Setup.app to finish up and get lost and b) tells all the essential functions of your device (including the Phone itself) they can start working.

Which brings me to the second most common cause of Activation Lock: remote activation of Lost Mode or Remote Erase. When anyone uses their Apple ID to log into an iOS device, which the Setup Assistant (Setup.app) tells you to do, Apple will make sure that Find My iPhone is enabled on that device by default. This allows the owner of that Apple ID to log into iCloud.com (or the Find My app on another iOS device) anytime they want and remotely make the device that has FMI turned on obsolete by telling it to either enter Lost Mode or erase all its data (the difference between lost mode and remote erase is that lost mode keeps your data while remote erase obviously does not. Lost mode also allows you to set a custom message). However, the main purpose of both methods is simple and straightforward; to get rid of the devices activation records and make the device obsolete, so it must see Albert again. When either method is executed, because there are no Activation Records AND Find My iPhone is turned on, it is the perfect situation for Activation Lock. Albert will say YOU SHALL NOT PASS and throw you an Activation Lock page. Of course, anyone can force Albert to change his mind by entering the correct Apple ID and password, but this situation rarely occurs for many reasons, which I explain in the next section.

The third, most rare, and most strange cause of Activation Lock is nothing. Thats right, Activation Lock can occur completely randomly for no specific reason. If you have owned an iOS device for long enough, you probably had the experience of waking up one morning and finding your device on the Setup Assistant. Or you were browsing in Safari and all of the sudden you saw the apple logo and the Hello screen. You then slid to unlock or pressed home to open and immediately found the Activation Lock screen. If you had entered your Apple ID and Password, the page might freeze for 10 seconds or so and then immediately crash to the Home Screen, with no Data and Privacy, no Touch ID setup, no Welcome to iPhone get started, nothing. However, if you did not remember your Apple ID (lets say you set it up when you bought the device and its been 5 years and you never used it since, I dont blame you) then you are locked out, for absolutely no reason at all. This happened to someone I knew very well- they lived overseas in a small country and it took me nearly 5 months to ship them an iPhone. They were so excited to have the device and set it up with their own Apple ID, but a few days later it randomly crashed and showed Activation Lock. Unfortunately they did not know their password, and they did not have a computer to use for bypassing, so in one split second everything they knew and loved about their iPhone was gone forever. I use an iPhone 6s and this strange phenomena has happened multiple times on my personal device, even in a jailbroken state. However, the strange thing about this type of Activation Lock is that it can actually save your activation records. So if you do manage to delete Setup.app, sometimes you can still continue to use your device like normal, which is the weirdest part. For example, some people have deleted Setup.app on an iPhone 4s using my arduino method and they got calls and data (who knew!). Their device was most likely once affected by this rare occurrence of Activation Lock, and was never Restored, Remote Erased, or put into Lost Mode.

Why Bypass Activation Lock?

You might think that people who bypass activation lock are iPhone thieves or criminals, but this is rarely true. Think back to Find My iPhone. As I mentioned in the last section, Apple makes sure that all new iPhone users have Find My iPhone enabled by default. However, I can assure you that many people would rather have it turned off if they were reading this post. Human memory is far from perfect, and oftentimes passwords can be tricky to remember, especially among older generations. I have met many people over the years who have come to me with Activation Lock who had absolutely no idea what it was, why it existed, or how Find My iPhone was turned on in the first place. An Apple store employee probably helped them create an Apple ID when they purchased their device, and they simply never used it since. How would you expect someone in this situation to remember their Apple ID, let alone know their password?

There is also Lost Mode. People who use Lost Mode most likely lost or misplaced their iPhone, iPad, or iPod Touch, and for obvious reasons they do not want anyone else using their phone. Makes sense, I wouldnt either. But consider this. If you lost an iOS device, you are not going to simply live without a phone or a tablet. In our highly technological modern world, digital technology has evolved into a necessity for work, communication, recreation, and much more. So that person who lost their phone on the beach one summer is not going to wait until its found to move on with their life, they will most likely take a trip to the local Apple store or cell service provider and buy a new device to use as their daily driver. Maybe a year passes, or even 5 years, and by then they have several new phones and totally forgot about the device they lost ages ago. Then one day someone creative enters the scene, discovers the lost treasure, and finds that it miraculously accepts charge and comes back to life. They notice there is a message from the old owner on the screen with a phone number, so they call that number, but of course the owner has no idea who they are and immediately hangs up the phone (I have found multiple phones in lost mode with valid phone numbers, and this is usually what happens). So, there you have it. A perfectly good iPhone that the original owner does not want or need, and the new discoverer is stuck with Activation Lock. Who wouldnt want to bypass in this situation?

Thats all assuming Lost Mode actually does its job and displays the owners message. If the device is a WiFi only iPad or iPod Touch, then Lost Mode is completely useless, because unless the device moves into close proximity of a known WiFi network, it will never show the owners message. So, whoever might find a Wifi-only device will simply see a Passcode or iPad/iPod is Disabled. You would hope they would go on YouTube and search up passcode bypass until they found Sliver, but unfortunately the first videos that popup for how to remove iPad passcode are tutorials for how to erase a device with 3utools. Thats just great. Now they have successfully deleted all the Activation Records and its time for a talk with good old Albert, who of course will not let them pass. Eventually they do come across Apple Tech 752 and see the video they wish they watched originally, and are probably slapping themselves for it, but the good news is that its still possible to bypass the Hello screen (Setup.app). And I genuinely dont see who wouldnt want to in this situation, nor why it would be a bad thing to do!

And of course the biggest reason of all why so many people bypass is because of unfortunate or uninformed sales! Thieves who steal iOS devices want to get rid of them quick, and make some fast cash. The most common way this is done is through Craigslist or eBay. Thieves will do a quick restore to get the device on the setup screen, then sell it to some uninformed buyer who doesnt know any better and thinks its a brand new device. The victim of the scam sets it up, and of course they are stuck with Activation Lock, but its not their fault at all, its the thiefs fault, and unfortunately iDevice thieves are rarely caught. Apple could have been really smart about this and chosen to display the FULL email address of the owners account to whom the device is linked, but instead they only show the first letter! What good does that do? If the victim of the scam had a way to reach out to the victim of the robbery, then they could settle and make the device useable again, but Apple would rather sacrifice the usability of iOS devices than display full emails on the setup screen. Not a good choice. Luckily for the victim, since there is no way to reach out to the original owner, they get to have some fun with bypassing. And when it comes down to it, in this situation its not the fault of the user for trying to make a device useable that they paid for, its the fault of Apple for making it nearly impossible for victims of scams to return their devices to the original owners. No matter what, the device will be obsolete unless the user chooses to bring it back to life with a bypass. My philosophy is to always to bring iOS devices back to life whenever possible so that someone, rather than no one, will benefit!

How does an iCloud Bypass work?

• iOS 13 mobileactivationd Bypass
  • Type: Indirect Setup.app mitigation
  • Tools: Sliver Mac, Sliver Windows
  • Target Devices: iPhone 6s — iPhone X, pre-A11 iPads, iPod Touch 7
  • Target Versions: iOS 13.3 — 13.7
  • 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, Sliver Windows
  • 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.

• iOS 12 / iOS 13 Setup.app Removal
  • Type: Direct Setup.app deletion
  • Tools: iCloudBypassCA
  • Target Devices: iPhone 5s — iPhone X, pre-A11 iPads, iPod Touch 6, 7.
  • Target Versions: iOS 12.0 — 12.4.4, iOS 13.0 — 13.2.3
  • 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.

• iOS 12 / 13 / 14 Passcode Bypass
  • Type: Backup & Restore Data
  • Tools: Sliver Mac, Sliver Windows, F3arra1n
  • Target Devices: iPhone 5s — iPhone X, pre-A11 iPads, iPod Touch 6, 7.
  • Target Versions: iOS 12.0 — 12.5.1, iOS 13.x.x, iOS 14.0 — 14.2
  • 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.

• iOS 12 / 13 / 14 GSM Signal Bypass
  • Type: Indirect Setup mitigation
  • Tools: Checkm8.info, iRemoval PRO, SoNiCk14, F3arra1n
  • Target Devices: iPhone 7 — iPhone X (GSM only)
  • Target Versions: iOS 13.x.x, iOS 14.x.x
  • 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 the GSM 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, so we may see a method for MEID devices fairly soon. If one does surface, Apple will once again likely choose not to patch it.

• A4, A5, A6, A7 Setup.app Removal via SSH Ramdisk
  • Type: Direct Setup.app deletion
  • Tools: Sliver Mac
  • Target Devices: iPhone 4, 4s, 5, 5c, 5s, iPod Touch 5, iPad Air 1, iPad Mini 1, 2, iPad 2, 3, 4.
  • Target Versions: iOS 10.3.3 (A7), iOS 10.3.3/10.3.4 (A6), iOS 9.3.5/9.3.6 (A5), iOS 7.1.2 (A4).
  • 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.

That’s all! Hope you enjoyed my blog. If you have any comments or questions, please make a post on Reddit and use the Blog Follow-Up post flair.
I look forward to reading your responses!

Источник