Top News & Events
Website Company
Don't Miss Any Merruk !
Be social, Follow US.

DTN - DOS : doulCi Team News | doulCi Open Source (OpenSourced Technicals about doulCi Kitchen, Merruk iCloud Bypass.).

OpenSourced Technicals about doulCi Kitchen, Merruk iCloud Bypass. : doulCi Open Source.
| |

OpenSourced Technicals about doulCi Kitchen, Merruk iCloud Bypass.
iCloud bypass is no longer called doulCi, it goes Open Source with the name merruk iCloud bypass

Merruk iCloud bypass detailed technical instructions: From the beginning.

Is "Merruk iCloud bypass" real? Is it still working? So, how can I be sure?

doulCi kitchen, a.k.a 2.0, was an improved version of the old magic line way method of bypassing Apple's iCloud Activation lock. It had the simple name "doulCi", a reverse spelling of iCloud. It was discovered, developed and demoed by Yahya Lmallas @MerrukTechnolog during the first months of 2014. After that, someone else going by the name of minacriss discovered one of the two exploits used by this bypass. 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. 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. 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.

What was the first CertifyMe exploit?

Apple used two methods for the certification of its iDevices. The first one is in the Activation itself. Following is an example of the activation process and how Apple verification takes place.
example of the activation process and how Apple verification takes place
The second method is a simple CertifyMe request generated on the device and is sent to the Apple server, a.k.a., "Albert". The problem with this second method is, Apple uses the same info as the Activation Request, with only minimal changes. 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.

Another 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". Hmmmm? So, could we MITM on that? Of course we can, with an activated device and a trusted certificate on it.

So after playing with CertifyMe and a little bit of debugging, I discovered that the request is almost the same as the activation itself. The surprise wasn't that. It was the response to this request. It gives about 90% the same. Trying it on an iCloud locked device as an ActivationTicket also works!?!?! The SpringBoard is showing up. That was quite a big discovery. By merely changing some words like "certificate-info" to "activation-info", iCloud could be easily bypassed.

Is this process still working now? Unfortunately not.

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. This exploit was used first by minacriss. He discovered it along the way, but used it and wasted and burned the exploit. So, no need to hide it anymore. Merruk iCloud Bypass "doulCi" was modified to use both exploits. 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.

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. and my servers was using CertifyMe first to prevent the need of the SIM Hook for supported devices.

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. Because iOS needed to be patched for correct verification process, too.

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. But there are two ways to bypass this verification.
Verification Of DATA Signature Part, was it a Back-Door For NSA and Brothers? Who Knows This is Maybe the must interesting asked question that i couldn't find an answer for.

Technical for everybody easy to understood even for beginners.

The first is to learn the signature on the device and replicate it. This is not the subject concerning us right now.

The second is to teach the iDevice to think differently. Targeting and hacking into the most powerful and useful libraries on this device can allow you to do the impossible.

Apple uses property list "plist", to parse almost 90% of its data as serialized dictionary objects format. NeXTSTEP is the original format and first developed property list. GNUStep is an improved implementation a little closer to XMLPlist, Apple's own developed version.

Having access to this library gives you full control of every single bit of data communicated by the iOS/OS-X Operating Systems. So "On the Fly" searching for keys and replacing values will make the device see the results you want. I had the idea of doing this on-device. Changing the necessary info will make the iDevice generate a very nice FairPlayDataSignature, which is a signature of a modified version of ActivationInfoXML, just like the example before Apple added signature verification.

minacriss pointed me to a Cydia MobileSubstrate tweak used to hook up "lockdown_copy_value". This wasn't helpful but gave me an idea about MobileSubstrate. I was very new to iOS and never developed anything for it. As I said before, Merruk iCloud Bypass "doulCi" was my first contact with Apple and iOS.

So I created a basic concept of the things that needed to be done and started looking for the most powerful things used by the iOS. That's how I started this kitchen and found what I was looking for.

I published an old write-up on the subject. 3 months passed and no one was able to bypass. I released proofs on twitter and again, no one was quite there. It was not until a full 7 months from the first article that a single person succeeded.

This is a list of the steps needed for a complete bypass and the very basic tools for success.

  • - 1 ) an iDevice with iOS version 7.1.2 or lower.
  • - 2 ) ideviceactivate from github repo (or any activation proxy that you can control)
  • - 3 ) start an activation for the locked device with a custom server that will read the locked device info, and send them to the kitchen then await a reply (see step 5)
  • - 4 ) a way to make doulCi kitchen device accept a request containing the locked iDevice info from step 3 and store them somewhere (python or php may be the easiest methods for parts 3 and 4)
  • - 5 ) a MobileSubstrate tweak to check for existence of previously-stored info and hooking up the necessary internal libraries functions with our desired data "search for..., replace with...".
  • - 6 ) invoke activation request for the kitchen itself (requiring our device target info) and redirect the result to our iDevice. (custom link to the local server that will save the results in a file, step 3 will read when such file exists.) Doing this achieves the bypass.

* This basic Concept will allow many of you to draw inspiration, because it can be very useful and I think it's a whole new method for iOS hacking.

Remember i don't have no other website then merruk and the original doulCi iCloud Bypass

In my next article, I will include some very basic code examples, in case no one else understands the concept or if someone tries to use it to scam others.

[ VIA : ] Merruk.
[ SOURCE : ] doulCi.


// //