Today i’m going to be answering a few questions that i’ve received (more than a few times) from members of the community around the subject of iPhone Activation.
To fully understand how the ‘Activation’ process works, we must first understand a few wider concepts - heres a few:
- Asymmetric Encryption
- Tether & Untether
Asymmetric Encryption is arguably the most common type of Encryption utilised within modern mobile platforms and is very effective. It works using two elements:
The Remote Server (Apple) hold the private key. The private key is held securely by the server and never disclosed to the device/user. The private key can decrypt the information contained within data packets - where these packets are sent from devices holding the public key.
We as consumers hold the public key. The public key is limited purely to encrypting information. So we can encrypt our information, but not decrypt it. This is to enable secure transmissions where the only device that can decrypt the data is the server.
The above applies to network transmissions - but the same principle applies to the signing of binaries, although subtly different in the process.
In the case of signing, the ‘owner’ of said binary uses their private key to digitally ‘sign’ the binary.
Apple implements this in iOS by generating a cryptographic ‘hash’ of every executable ‘page’ of memory, and encrypting the hash using the private key, which only the owner (Apple) holds.
When ‘said binary’ arrives at the mobile device, the authenticity of the hashes are checked by first decrypting them using the public key supplied to the user by the owner, and secondly verifying the hashes match the binary recieved. This process is also known as code-signing, and goes much more indepth than what we’re talking about today - In fact, I have a section covering codesigning in my new book, iOS Research & Exploration Volume I! (https://duffy.app/book)
This leads us very nicely to the subject of ‘tether’ and ‘untether’.
At each stage of the iDevice boot process, each boot component is integrity checked - This involves all system and user binaries, too.
As many of you will know, members of the community such as ‘AppleTech752’ release free activation tools that feature a patched version of ‘mobileactivationd’ which is a background process in iOS that handles the activation state of the device.
The problem here is that this ‘patched’ binary will not match the code-signing information attached to the binary and will fail to load - right? You’re absolutely right!
Checkra1n ‘patches’ the codesigning process, meaning patched binaries can load succesfully. This limits our device to booting with checkra1n, making our device ‘tethered’ meaning an external device must be connected to your iPhone to execute checkra1n and patch code-signing upon boot.
So, what’s ‘untether’? Untether simply means the device doesn’t require any sort of external device to boot succesfully. This also means the integrity checks performed by iOS complete succesfully... how could that be possible?
A leaked private key - that’s how!
Rumour has it that an Apple Employee working on the public-facing server that handles iDevice Activations, inadvertently (or purposely) leaked an Apple private key to a small set of individuals. This allows those individuals holding the private key to allow activation requests made from an iPhone to be sent to an illegitimate server, and the result would be ‘signed’ as if it were from Apple - ‘bypassing’ the problem codesigning introduces.
So, if the private key is in the hands of a few individuals, we can safely assume we’re not going to have access to that key anytime soon. - the key will naturally not be exposed to the end users of their ‘activation products’.
We’re left with a few options.
I was a little hesistant in talking about this specifically due to the ethical grey area, although I feel that now is a good time to talk about this openly - as Apple have (to my knowledge) implemented a different Activation Process in iOS 14.
There are, however, a few developer-implemented restrictions to their ‘tools’. First, you have to pay the developer or said tool, and secondly, your device’s serial number must be registered on their server - providing a form of ‘authorisation’ to use their services.
At the end of the day - there will have to be some sort of reverse engineering involved on our side if we’re going to achieve an activation without paying the malicious actor. We won’t be able to execute the entire process locally without the private key, and so we have no option but to attempt interface with the malicious actors services.
I’ve spent a good amount of time in the previous weeks researching the operations of the applications in question - attacking from different angles, including the use of Burp Suite, ProcessMonitor and others (I highly reccomend you experiment with these utilities, as they’ll prove invaluable when attempting to understand and manipulate the execution flow of said application).
To reverse engineer such an application, we must understand which specific values are used to actually ‘authenticate’ to the malicious activator application. I began by using ProcessMonitor to see if any calls were made to particular processes, which could point to the values in use - (no luck - the application must be implementing some obfuscation to prevent our monitoring.)
Upon opening Burp Suite and other proxy applications, the activator automatically force-closed. This could possibly be bypassed, but we’re looping around in circles right now...
My second attempt was to simply go in blind, and take a guess at the value most likely to be authenticating the activation - probably the serial number. So I changed my device’s serial number to one that was known to be registered and marked as ‘paid’ on the remote server...
Executed the tool - boom, fully activated!
So, now we know the tool is using a very simple ‘check’ of the serial number, and this is likely to be one of the only values sent as a form of authentication (other than the activation request itself of course).
But... how? Well, what a wonderful question. The most likely answer is using ideviceinfo. This fufills al.... 5 hours later
In the past couple of weeks, i’ve been learning new skills every day, and so rather than jumping to a rather simple answer, I wanted to investigate further so I can share with you how the tool is executing, using some rather new skills!
Using Frida-Trace, we are able to log calls to ‘functions’ and functions within libraries, and visually see what’s getting passed to those functions as the execution completes. But this leads to another question of what do we actually want to look for/monitor?
Well, luckily for us, macOS produces a really pretty crash log, presenting the loaded libraries when the crash occured. By causing a crash, and checking out the crash log, I could see the ‘NMSSH’ library was loaded - If we can see what’s getting executed on the iOS Device, we can begin to understand how the tool works.
By monitoring the Frida-Generated handlers a little (for the most interesting-looking functions(we talk about this in the book too!)) - we can visualise the commands being executed on the device, at runtime.
Here’s a screenshot of the frida-trace output:
Using this, we could use the knowledge to begin constructing our own application to call to the servers with modified serial number data (to trick the remote server into generating signed records). If you look closely, you’ll see the SSH commands being sent to the device!
Thanks for reading this (longer than usual) article!
I hope you’ve enjoyed the read, and maybe learnt something - or driven you to check out frida-trace and start experimenting yourself!
I could definitely follow this up with a pt.2 if there’s interest!