But there are two ways to bypass this verification.
Doulci server verification#
Is this method still working? Yes, but? Apple finally opted to use Signature Verification to verify if the request has a valid signature or not. Because iOS needed to be patched for correct verification process, too. When Apple allowed us to control our sent data by modifying some simple info like IMEI, SN, UUID, etc., like on the old leaked version of doulCi Server files, the request is accepted on Apple side and gives a half broken Activaton Ticket, that worked even so. and my servers was using CertifyMe first to prevent the need of the SIM Hook for supported devices.
Doulci server code#
The only downside of this second exploit is that it required a trick to make it work for devices that have cellular network, by using a SIM with a PIN Code for the processed devices. Since the first one was not working on all devices but only on iPhone 4 and below for iPhones, iPad 2 and below for iPads and all wifi devices including all iPod Touches. Merruk iCloud Bypass "doulCi" was modified to use both exploits. He discovered it along the way, but used it and wasted and burned the exploit. This exploit was used first by minacriss. What was the other exploit used? Again and as I said before, the CertifyMe exploit led to the discovery that Apple does not verify the data sent to Albert by the on-device generated signature, so you can modify the request to your convenience. Is this process still working now? Unfortunately not. By merely changing some words like "certificate-info" to "activation-info", iCloud could be easily bypassed. Trying it on an iCloud locked device as an ActivationTicket also works!?!?! The SpringBoard is showing up. So after playing with CertifyMe and a little bit of debugging, I discovered that the request is almost the same as the activation itself. Hmmmm? So, could we MITM on that? Of course we can, with an activated device and a trusted certificate on it. The worst thing is Apple developers did not even use a security check mechanism existing from the onset on their platform servers, namely "Data Signature Verification", leading to the discovery of the second exploit, which will talk about later.Īnother security flaw is that Apple iDevices leaked some very important information during the boot process "certifyme request with a visible link on the boot log". The problem with this second method is, Apple uses the same info as the Activation Request, with only minimal changes. The second method is a simple CertifyMe request generated on the device and is sent to the Apple server, a.k.a., "Albert". Following is an example of the activation process and how Apple verification takes place. The first one is in the Activation itself. What was the first CertifyMe exploit? Apple used two methods for the certification of its iDevices.
So the old doulCi that i have decided to rename again because of scammers to "Merruk iCloud Bypass" is still working, with some exceptions, because Apple added some security patches on both the server side and in its iOS. To be fully patched it would require Data Migration, which would be very time and labor consuming for Apple and would require a great deal of effort. The first one is a "CertifyMe" exploit and the second is based on a security flaw on Apple servers that was actually a beginner?s mistake.
0 kommentar(er)
