R0bf0rdSn0w proxy Write up

R0bf0rdSn0w proxy Write up R0bf0rdSn0w! Has no one actually been able to get this so far? Want to know how it works?

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 *
SHA1(README)= bfa093102ae4f219d92926d3e6f8916e4189734c
SHA1(iPhoneActivation.pem)= 925708392f87e5fc9a190e42f5d040fef7715fa1
SHA1(iPhoneActivation_private.pem)= ff809fe295db90ea9f9c44d36441b322739fa238
SHA1(iPhoneDeviceCA.pem)= 720e6e57e9a1db9c3b460118e6a923025913098d
SHA1(iPhoneDeviceCA_private.pem)= 5dafe717f05a1ea7a5ebd5266b281470d0e38b1a
SHA1(proxy)= 9264762e7c30da767161a1f12d475e9ecf3ca15d
SHA1(proxy.exe)= cdeb405308b2e443e951a8ab9bbaef469cc0c6cb
SHA1(r0bf0rdsn0w-v1.2.zip)= 5b8bcf45e0194816107e72786cacdebc6f5805ac

- 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,
kSecPaddingPKCS1SHA1,
hash,
20,
(const uint8_t *)[signature bytes],
SecKeyGetBlockSize(keyRef)
);

* 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;
_BYTE first[3];
_BYTE second[3];
char _48;
int result;
CFDataGetBytePtr();
CFDataGetLength();
CC_SHA1();
_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 )
{
save_lockdown_log((int)"create_activation_info",
"Could not sign with necessary certificate: %d",sign_activation_infos);
result = 0;
CFArrayAppendValue();
}

* When looking into the function we see that it has a 3-byte signature length, so :

SecKeyRawVerify (x,x,x,x,3,x);

* 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.