Following is our exploit write up?
What is R0bf0rdSn0w? What files are used? How does it work?
What is R0bf0rdSn0w?
- R0bf0rdSn0w is an iCloud bypass proxy developed by iH8Sn0w that was not made public, as you know. You need a code to unpack it :) Getting the code requires an A5+ exploit, (if you have one, you have no need for R0bf0rdSn0w!).
- This is first two useless AES GID keys used for the decryption process of R0bf0rdSn0w.
What files are used?
- The main files are in the ZIP:
-rwxr-xr-x@ 1 iH8sn0w staff 895 Mar 31 14:41 iPhoneDeviceCA_private.pem
-rwxr-xr-x@ 1 iH8sn0w staff 148512 Mar 31 14:45 proxy
-rwxr-xr-x@ 1 iH8sn0w staff 3990 Mar 31 14:46 iPhoneDeviceCA.pem
-rwxr-xr-x@ 1 iH8sn0w staff 3960 Mar 31 14:47 iPhoneActivation.pem
-rwxr-xr-x@ 1 iH8sn0w staff 932256 Mar 31 17:27 proxy.exe
-rwxr-xr-x@ 1 iH8sn0w staff 891 Apr 1 13:25 iPhoneActivation_private.pem
-rwxr-xr-x@ 1 iH8sn0w staff 21 Apr 1 14:11 README
-rw-r--r-- 1 iH8sn0w staff 1091905 Apr 3 16:38 r0bf0rdsn0w-v1.2.ziP
iH8sn0ws-MacBook-Pro:r0bf0rdsn0w-v1.2 iH8sn0w$ openssl sha1 *
- As we can see, the files are two tricky Certificates and their private keys :), along with two proxy files for win/mac platforms, and finally a Read-me file.
How does it work?
- Let's first focus on the proxy files. They are generically named and this means that they merely serve as an intermediate between the iDevices and the computer. No default Albert server is used here :).
- And how I do know this? Simple. We don't need Apple Albert activation server because the necessary certificates are already here. What we do need is the FairPlayKeyData and the same certificate that Apple sends for all idevices :) These are known and can very well be static. See data below:
FairPlayKeyData = Static.
AccountTokenCertificate = Static.
DeviceCertificate = Dynamic from Certificates. (Doesn't matter. Can be static too)
AccountTokenSignature = Dynamic from Certificates. (This is the hack)
AccountToken = Dynamic from iDevice informations. (Here's where you cannot get carrier signal until you use a method of generating the correct WildcardTicket, tea key etc.)
- Okay, so what we need to do now is find the exploit :) So, if this iCloud bypass does not use Albert default activation server, how does the process work?
- Through extensive research and a lot of debugging (starting with the lockdownd/fairplayd and other binaries for iOS8 like MobileActivation), I came across something quite interesting, reminding me of a well-known exploit of validating SSL signatures, created via certificates that use PKCS1SHA1 and signature bytes length "3".
* This is an example from the web of the way apple verifies signatures.
CC_SHA1((const void *)[data bytes], [data length], (unsigned char *)hash);
status = SecKeyRawVerify (keyRef,
(const uint8_t *)[signature bytes],
* And this is how apple does it (signing) from an old decompiled lockdownd (iOS 3.4.1), in function create_activation_info();
signed int _4MB;
signed int _256;
_4MB = 4096;
_256 = 256;
_48 = 48;
memcpy(&v41, &v42, 20u);
sign_activaton_infos = sign_activation_infos_func((int)&_48, 35,
(signed int)first, &_256, (int)second, $amp;_4MB);
if ( sign_activaton_infos )
"Could not sign with necessary certificate: %d",sign_activation_infos);
result = 0;
* When looking into the function we see that it has a 3-byte signature length, so :
* By simply Googling similar exploits, such as the Mozilla NSS Library exploit, we find that they are identical :) and maybe apple is facing the same issue :) When we see how r0bf0rdsn0w does it, we could infer that it's the same :) Apple was using a vulnerable version of OpenSSL that allowed bypassing the signature check.
So, how could this be accomplished?
- Using a tricky certificate created to match the above information is the key :), There are a lot of explanations for this subject on the web. Do the research.
Has r0bf0rdsn0w been patched? It's up to you to find out for yourself.
- I apologize for my grammar and the way I wrote this, but English is not my mother tongue.
Yahya Lmallas (Maroc-OS), @MerrukTechnolog from doulCi Team.
[ COMMENTS : ]