4 min read

Modern iOS Activation Patching Utilities. Secure? Yes & No

Modern iOS Activation Patching Utilities. Secure? Yes & No

An insight…

So i’d like to first give you all a little insight into the tools I use during my research and how I use them. In this article, Tool 1 is referring to the activation bypass utility we will be inspecting.

My initial thoughts when I come to research the functionality of an application like this is ‘What are we really looking to gain here’. In this case, we could say our aim is to bypass the protections of Tool 1 and use Tool 1 with any iOS Device, wether it’s registered on Tool 1 server or not...

With our aim in place, let’s think about how the ‘device check’ would take place. To gain a little insight, I plugged in a device which was not activated on Tool 1 services, and attempted to run the tool. I was of course met with an error message letting me know to register my device serial number on their website for a fee.

As the tool requires an internet connection, it’s very likely there’s a Database somewhere holding a list of serial numbers where the tool is ready for use. Following a successful purchase, the users serial gets added to the Database and the ‘check’ which is run while the device is connected, will give the go-ahead!

It’s Proxy Time!

So, lets see what get’s sent to the Tool 1 Server when we execute the tool. Let’s launch Burp Web Proxy so we can intercept the web request made to the Tool 1 Server.

As we can establish from observing the contents of this request, we can see a POST request was made to the Tool 1 server, where a PHP script will execute based on the submitted data.

As part of our request was a block of encoded data named ‘activation_info’.

GCHQ CyberChef

CyberChef Setup w/Magic Module

Using GCHQ CyberChef, I attempted to figure out which encoding algorithm was being used to send this unidentified block of data so we can determine what exactly is being sent to the server. CyberChef has a very nice ‘Magic’ module which attempts to decode the data using various common encoding methods.

The great part of this is we can enter a ‘crib’, or in other words, a part of the plaintext data we already know. In this example, i’m certain that our serial number is being sent in this block of data, so I can enter my plaintext serial as the ‘crib’. If CyberChef has an output where this plaintext string is found, it will be highlighted and presented as the presumed decoded data.

Unfortunately, in this case our serial number was not found in any of the combinations of decoded data CyberChef has generated. It could possibly be due to ‘layered’ encoding where there is more than one encoding method being used ontop of another in an attempt to ‘obfuscate’ or prevent researchers like ourselves from understanding what data exactly is being sent.

I also tried intercepting the request using a device which *was* registered using Tool 1, and did not notice any similarities in the submitted data.

What’s Tool 1 Doing?

I decided to attempt monitoring the Tool 1 process during execution to understand what it’s executing and wether it would give us any pointers to the encoding methods in use. For this task I used the amazing ProcessMonitor utility developed by Objective-See. ProcessMonitor monitors activity of a specific process so we can learn a little more about it’s actions during execution. Unfourtunately, Tool 1 detected the attempted observation of it’s process and force-closed. Another attempt at obfuscation.

The developer was not quick-to-assume any of us would see the code-signing information of Tool 1. This kindly includes the developers Apple ID email address connected to an Apple Developer Account. We can look at this another time, I suppose.

Let’s think a little more local to the machine. HOW is it actually fetching the serial number from the device to be used within the software? No matter how the value is encoded, if we can modify the serial number fetched by the application, we can effectively bypass all of these protections. libimobiledevice, which is used to interface with iPhones over USB, is used to retrieve the information from the device, for example the Serial Number, UDID etc. This is the case for the majority of these tools.


I figured two methods to succesfully bypassing these protections. The first is to actually modify the serial number of the iDevice to a serial number which is legitimately permitted access to the service. This appears to completely bypass the protections from each service and the device succesfully activates with cellular connectivity.

The second method is to actually figure a normal output of ideviceinfo, which would contain the info used by Tool 1 to deduce the information about the device, and write out own ideviceinfo to return exactly the data we like, which Tool 1 will interpret as it was being recieved from the real ideviceinfo binary.

This will only work if the developer is calling directly to the binary at it's usual location, although a lot of developers still use this basic implementation which we can in turn bypass.