3 min read

Demystifying iCloud/FRP Activation Process Patching Utilities

Demystifying iCloud/FRP  Activation Process Patching Utilities

During the development of one of my recent WIP projects, I had to order a device to test with (an iPhone 6S) to ensure full functionality of said project. The device arrived 'activation-locked'.. After a few quick Google searches it became apparent that most options for using the device while in this state were provided via third parties offering their unlocking ‘services’ for a price.

This article will explore a part of my research process aiming to understand how these activation process patching utilities function.

This article isn’t about ethics, but I don't think that’s right to be charging for such a service. I was curious how the process worked, and if I could recreate this process of ‘patching activation’ on a device myself.

I started by analysing a few of the major tools to understand how they function and attempting to recreate some of the functionality.

I began by dragging a popular tool, we’ll refer to it as Tool 1, into Hopper Disassembler to see if there were some plaintext strings to execute stored inside the text region of the binary.

The binary appeared to be well obfuscated, using many common methods such as including an extremely high number of functions that aren’t critical to the software functionality in order to ‘overload’ the disassembler, making it less attractive target for a researcher to inspect.

I shifted my attention to determining wether most of the process was server side, or if all the functionality could run locally on the Mac.

Network Monitoring

Using Burp Suite Proxy, I attempted to intercept all the network requests Tool 1 was generating in order to learn a little more about what was happening at each stage of execution. The binary was somehow bypassing the proxy set locally on my Mac, probably by design to help prevent this sort of inspection.

To overcome this, I used Proxifier, which creates a virtual network card on your Mac, where all the traffic that passes through the card is processed by the proxy we set, Burp Suite, and then to the Tool 1’s central server.

After analysing the very few requests made by Tool 1, I found there to be two mechanisms in place to prevent unauthorised users from using the tool.

The first is a request made to Apple’s activation server to grab a legitimate activation ticket. Tool 1 duplicates the content of this outgoing request, and forwards it to the Tool 1 Central Server in order to determine the identity of the device making the request.

The second request Tool 1 makes is to it’s central server again, this time submitting the serial number of the connected device, which appeared to be sent as an BASE64 encoded string of the device serial number. The device in Request 1 and 2 must first match each other, and the details will then be checked against a database of authorised serial number's Tool 1 Developer owns and maintains internally.

The responses from Tool 1’s server were very short, containing minimal information other than essentially an encoded ‘OK’ message. This allowed the locally running program to proceed and execute the rest of the forged activation process.

If an invalid serial was submitted, the server would reject the request, and Tool 1 would stop executing.

My goal was to understand how exactly these activation bypasses work - not to simply bypass the tool’s checking mechanism.

Following the information we gained, and Tool 1 executing it’s process successfully, we now need to work out what it’s executing in the background.

I used Process Monitor for this task.

It was incredibly interesting seeing the output, as it turns out Tool 1 actually operates in a very simple way internally.

The software, once authenticated, follows roughly this flow...

- Initialise a connection to the iDevice over USB using iProxy

- Execute curl on-device to download a few files from a remote server to an unusual folder on the device (A certificate, multiple DYLIBS and a few PLISTS)

- The files were downloaded as pretty obscure random names, probably to avoid easy detection. Another few calls to exec moved the files to their relevant, correct  directories.

- The original downloaded files were quickly removed, and the new plists were loaded on the iOS device.

- Springboard and mobileactivationd processes are restarted and the device then appears as activated without any need to patch the mobile activation daemon.

I wrote a simple C Program and compiled it on the iPhone in order to grab the files that were created. As they were deleted very quickly, they were difficult to retrieve. But, we got there eventually, knowing all possible directories for the files from the tracing using ProcessMonitor, and our output files were copied back to my Mac.

With a little C programming, I could replay the whole process very quickly without any interaction with the server.

So, thats the story. If anyone has any questions please feel free to get in contact via Twitter, etc.