Hello frieds of hackint0sh...
I was following this thread and the following question came to the mind:
Why instead of BF the code for one single iphone at the time, we don't use the distributed effort to BF the code for the crypto-key to alow creating a new bootloader version 4.7 or 5.9 perhaps. This will fix every OTB 1.1.2 iPhone in the planet.
We just have to find 1 key...
So, mine is running to with:
92495756 keys done, 00270085 k/s, 00:00:27 left
Thanks for the compiler options, this is a improvement!
Looking forward to a source with the full 15 characters in ;)
If I get it right:
RSA(TEA(token, SHA(NCK+stuff))) = message
so: token=TEA_decrypt(RSA_private_key(message), SHA(NCK+stuff))
So it is no problem to make own token based on own NCK - when you know the private key for the RSA. In other words, the algorithm's strength comes from RSA... It is way harder to crack 1024 bit RSA key then approx. 54 bit NCK.
Also the strength of the TEA is the full length of the key (128 bit?), because when you have three equivalent keys, only one of the keys corresponds to the SHA of the NCK+stuff = it is impossible (as good as) to find three different NCK's that when combined with the stuff (CPUID and NORID) and hashed give three equivalent keys for the TEA. Again - it is easier to bf the NCK than TEA in this case.
SHA is secure hash - hard to find message that corresponds to the hash, so even if you find the key of the TEA, it is to hard to revers it to the message=NCK+stuff (at least 62 bit strength - stronger then the NCK itself).
As I see it, the NCK is the weakest part of whole thing. Forget the token, RSA, TEA and SHA. Think how to optimize the algorithm, not decrypt something. Only hope is that the NCK's are not secure random numbers, or at least some part of it. Or that apple will release the private key :D
If you can replace the token AND the public key for the RSA by your own, then you can choose your own NCK.
Could somebody explain me in Spanish what exactly you are trying to do with George program?
Let's see if I understand this properly.
Obviously a brute force of the NCK and trying to validate the NCKs on the iPhone would not work because of the limit.
But what is being done here, is a brute force of the NCK, and then running it through the NCK validation algorithm (without the iPhone) to see if it's correct?
I've already got an unlocked iPhone (anySIM) but I'd be willing to help out with this (with my Core 2 Duo iMac). A "real" unlock is better than the anySIM unlock, of course :-)
sorry if this question have allready been answered, but even if somebody manages to find hin exacn NCK with this algorithm, do we allready have a way to spoof the unlock message provided by itunes to unlock the phone?
€: its been a while since i had math, but do i see it right that the number of possible combination for the NCK is 10^15, or 1.000.000.000.000.000 and we got to check them all out? How long would this take on lets say an C2D with 2,2ghz? Also would be great if somebody could explain how exactly the algorithm improvements work for the ones of us not studying informatics ;)
Hi guys. Sorry for offtopic.
Dont know how it happened but.
After manipulation with
launchctl unload -w /System/Library/LaunchDaemons/com.apple.CommCenter.plist
appeared icon EDGE on 1.1.2 OOTB.
Is it bug or something else ?
After reboot of phone Icon diappeared. And i cant to repeat this situation.
linker....if you knew it was offtopic why did you posted it in here? 1.1.2 with 4.6bl can't be unlocked. please do a search.
I was thinking: I saw on other post, that for the official unlock procedure apple/orange needs the IMEI of the iphone. Is it the only thing that is needed? If it is so, not all 15 digits of the EMEI are unique, only 6 of them are. This would mean that there are only 1000000 possible NCK's, easy to crack if you know the key space. So even if it is so, that only EMEI is needed, it doesn't help the bf attack (we don't know the key space...). I was just wondering.