Encrypting and Decrypting RSA messages in theory:

We assume for the moment that someone (an ``oracle'') gives us a modulus N and two numbers p (the public key) and s (the secret key) with the information that in m is any (invertible) element in $ \mathbb {Z}$/N$ \mathbb {Z}$, then mps = m in $ \mathbb {Z}$/N$ \mathbb {Z}$. In order to send a message, the message is broken into chunks m of size N - 1 and each block is encrypted as c = mp (we will see shortly why we do not expect a problem from non-invertibility of m). This is then sent over the public channel. At the receiving end the operation m = cs recovers the original message blocks. Thus, the algorithms of the earlier subsection (especially the one about taking powers) can usefully be applied in implementing this encryption/decryption process.

One question is how the triple (N, p, s) is chosen. Clearly, if M is the order of the group of units in $ \mathbb {Z}$/N$ \mathbb {Z}$, then one way to recover s given p is by the relation ps = 1(mod M). Thus, one consideration is that given only N and p it should not be easy to determine M (or else s is not secret at all!). Clearly, if a complete factorisation of N is known then this M can be easily determined. However, note that if k is the exponent of the group of units in $ \mathbb {Z}$/N$ \mathbb {Z}$ (i. e. the least common multiple of the order of all elements) then it is enough to know k rather than M, since solving ps = 1(mod k) is adequate.

A related consideration is that there should not be too many elements in $ \mathbb {Z}$/N$ \mathbb {Z}$ which are not units. The encrypter/decrypter should not have to worry about checking for this while constructing messages.

Both these considerations lead us to take for N = ab a product of two large primes a and b (we will see some additional constraints on the pair (a, b) as we go along). It is generally expected (and in the next section we will see some evidence of this) that factoring a number which has all factors of size (in terms of ``log'') r or more is much harder than checking that a number of size r is prime. Thus, it should be easier to construct key triples than it is to ``break'' keys (by determining s given N and p). Note that M = (p - 1)(q - 1) in this case and in general there does not seem to be a way to determine M (or the exponent k for that matter) without determining a factoring of N. The only elements m in $ \mathbb {Z}$/N$ \mathbb {Z}$ that are not units are p and q, thus this choice is also good from this point of view.

Originally Posted by Pada

isnt weird that geohotz hasnt post anything in days?

Erm... No

C'mon it could take weeks and why not months to come up with a viable BF method. This is something that is firmware irrelevant to some extent and would permanently unlock your phone, don't expect it to be a 1.1.2 unlock method.

RSA demo:
http://islab.oregonstate.edu/koc/ece575/02Project/Mor/

Guys how can I change or modify my iphone imei ? please help

thanks

The real question nobody is asking is:

Is it POSSIBLE to extract the ltoken needed by the bf-method from bootloader-4.6 phones ? (trough software, of course)

If so, HOW ?

Originally Posted by duwde

The real question nobody is asking is:

Is it POSSIBLE to extract the ltoken needed by the bf-method from bootloader-4.6 phones ? (trough software, of course)

If so, HOW ?

Well... Here is a pointer:

http://www.hackint0sh.org/forum/show...0&postcount=27

Where MuscleNerd says the following in my exact same question:

For 4.6 BL iPhones, that way still requires a secpack beyond 112 to come out of Apple (unless you are good at reballing BGAs)

So nope, we can't extract it yet, but hopefully we can once there is a new secpack.

I haven't looked at the code too closely, and I don't know if this is possible or not, but once the program creates the TEA key, can the validity be checked without decrypting the WHOLE ltoken?

Otherwise put, is it possible to rule-in/rule-out a given TEA key by only processing A PART of the ltoken (such at the first block only)? This might save CPU cycles and increase our throughput if it can be done.

Comments anyone?

Unless there's some overlooked flaw.. there's no way we can attack the encryption system. I'll try to explain what I understand from it and other guys can jump in with any other info.

Using Geohot's info (which seems to be the right one since he could make a test ltoken) the process is:

RSA(TEA(someinfofromiphone, SHA(NCK+NORID+CHIPID)),rsa_key2)

That means:

You start with your NCK and NORID and CHIPID, you use those three combined to encrypt using the SHA algorithm. You'll get some encrypted info. Then you get that info, mix that with some information (seczone 0x400) and encrypt it once again, using the TEA algorithm. You'll get a second encrypted message. Then you get that message and encryp that with RSA using your message and a "public" rsa key from Apple.

So it would be something like this:

encryptedmsg1 = sha(nck+norid+chipid)

encryptedmsg2 = tea(seczone400 + encryptedmsg1)

encryptedmsg3 = rsa(encryptedmsg2 + apple_rsa_key)

What you have in your phone is encryptedmsg3.

Geohot could extract that from his phone (I have no clue how so don't ask me)

If you take a look at RSA: http://en.wikipedia.org/wiki/RSA

You'lll see that RSA uses two keys, one public and one private. Basically it would take forever to bruteforce their RSA key. SO no approach is possible there. (Unless Apple monkeys were stupid and used a silly key)

Then let's say you get to Apple's RSA key.. you'll have to break TEA next. (which is "easier" but still isn't taking candy off some retarded kid's hand.

TEA information: http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

Then.. let's say you have TEA broken.. you'll still have to do all the hashes for SHA.

Information about SHA: http://en.wikipedia.org/wiki/SHA_hash_functions

AS you can now see, any type of attack through their encryption system is most likely to get you more important things than an unlocked iPhone.. if you manage to find a flaw in that thing you're closer to a Nobel prize than to wanting an iPhone.

So you ask me, what's with the BruteForce thing then?

The thing is, we know their encryption process and we know the encrypted message. So a bruteforce would be encrypting all the possible NCKs to get all the possible encrypted messages and then having all the messages we would compare with the one in our iPhone and (obviously) we would find the right one.

Once we found the right one we would input the NCK in our iPhone and it would be truly unlocked.

As everyone knows we have 15 digits (as far as we know) in the NCK. As it was stated here before, that's a monstruous number and it would take a lot of time (for each iPhone) to find the key. (by a lot of time I mean 30 years in your computer, and a couple years in the computer of all your friends together)

Maybe with optmization and a LOT of people with a LOT of computers (I'm talking hundreds to thousands) we could get close to an acceptable rate.

So bruteforce has no finesse and we (as intelligente beings) are trying to find a clever way around this.

Right now the main idea is to have a lot of NCK-IMEI pairs. Why?

Because we assume (yes, assume) that there is a connection between those numbers and believe it or not we try to guess the connection or using analysis we try to infer what it could be and then try to get parameters. Something like this:

nck/imei
1/2
2/3
3/4
.
.
.
1001/1002

As you can see in this case we would guess that nck = imei - 1.

It's more complex because NCK has 15 digits and no sane person would use such a simple algorithm since who's doing all the math is a computer and boy he's good at it.

Geohot's guess is something like IMEI^D mod N...

information about mod math: http://en.wikipedia.org/wiki/Modular_exponentiation

Which could be the right thing all we need is to find the expoent and N.

But it also could be wrong. It could be any other rule. That's why I am trying to get NCK-IMEI pairs on my own, to try a different rule than Geohot's and to bee able to test it instead of just sitting around thinking how many computers I can use to bruteforce.

Now the problem with that is this: Apple can tell who's the owner of the phone by it's IMEI (in the worst scenario) and send a block code or sue the owner or whatever *insert evil thing here* they want to do.

So we can't have people posting their NCK-IMEI pairs so everyone can attempt to find the right rule.

The thing is: Encryption and patterns aren't direct things. Some grandmother could be sitting having lunch and see a NCK-IMEI pair over Geohot's shoulder and find the relation. The second thing is that since we know a guy like Geohot knows so much about computer stuff, it's most likely he doesn't know the same about mathmatics and encryption (just guessing, of course.. but he has only 24 hours in a day same as us) so maybe our chances of succeeding would need us to take some risk and spread the NCK-IMEI pairs around.

But that's a decision for the NCK-IMEI pairs owners.

What I'm personally doing is trying to get those pairs from the owners and start doing my own research. So far I have one owner who sent me his a.plist and I'm still working to extract the info out of that file. IF anyone wants to help me get more a.plist what I can promise is that I will keep posting information so you guys can at leeast know what's going on.. like I did today.

So far th count is:
Geohot 6 NCKs : No Pattern
Deco 0 (Attempting to extract the first one out of the file CELL20 sent me THANKS CELL!) : No Pattern

Enjoy!

anyone have experience using the Playstation 3 for BF???

I was thinking about patterns too. The best way I know of is by using artificial neural networks, but with 6 or so pairs - forget about it, you need hundreds of them...

Other idea is maybe, propably not, but maybe there is a flaw in the encryption method made by apple. Here what i was thinking of:

message = RSA((TEA(Token, SHA(X))))
Token = TEA-decr(RSA-pk(message), SHA(X))

Now, message is a constant value for a particular iphone, so is the RSA-pk(message). You can say that the token is a function of X (NCK, in our case) for a particular iphone, or token = f(NCK). We would like to know f^-1(token) = NCK. Size of the token is +- 10kB, size of the NCK is +-8B. You can see the NCK as sort of a hash function of the token. The question is how secure is this "hash". It is less secure than SHA, but propably it uses full strength of the NCK.

To know for sure, we could use different private key for RSA (just as with the proposed bf attack) and generate few hundred pairs. I am not good enough with analysis of this kind (perhaps artificial neural networks), so I can't do it. Besides the chanses are low that there is some redundancy in the token. Some chanse exist, since both TEA and SHA use shift, xor and + only, but it is a very long shot.

Also the "key" for the "hash" function is different for each iphone, since the message and the NORID and the CPUID are different, and so not constant over different iphones. So, no great news from my side, I just wanted to share some thoughts.