Page 14 of 20 FirstFirst ... 4567891011121314151617181920 LastLast
Results 131 to 140 of 196
Discuss [NCK] validation algorithm public at the iPhone "2G" (Rev. 1) - Hackint0sh.org; Encrypting and Decrypting RSA messages in theory: We assume for the moment that someone (an ...
  1. #131
    Professional Array ReVan's Avatar

    Join Date
    Sep 2007
    Posts
    56
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    9

    Default

    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.
    ░▒▓█ Working iPhone v1.1.3
    ░▒▓█ Call In/Out ► Yes/Yes
    ░▒▓█ SMS In/Out ► Yes/Yes
    ░▒▓█ WiFi/EDGE ► Yes
    ░▒▓█ YouTube App ► Yes
    ░▒▓█ Voicemail ► Yes
    ░▒▓█ [MOD] iVolume v2.0 beta ► Yes


  2. #132
    Senior Professional Array

    Join Date
    Nov 2007
    Posts
    155
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    15

    Default

    Quote Originally Posted by Pada View Post
    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.
    iPhone 3G 16GB white. Official on contract. Used to have a w48 iPhone (OTB 1.1.2) all the way to 2.0.1 when I went legit.

    Current FW: 2.0.2
    Carrier: EMT (Estonia)
    All functions working

  3. #133
    Professional Array ReVan's Avatar

    Join Date
    Sep 2007
    Posts
    56
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    9
    ░▒▓█ Working iPhone v1.1.3
    ░▒▓█ Call In/Out ► Yes/Yes
    ░▒▓█ SMS In/Out ► Yes/Yes
    ░▒▓█ WiFi/EDGE ► Yes
    ░▒▓█ YouTube App ► Yes
    ░▒▓█ Voicemail ► Yes
    ░▒▓█ [MOD] iVolume v2.0 beta ► Yes

  4. #134
    Newbie Array

    Join Date
    Sep 2007
    Posts
    3
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    0

    Default imei modify-change

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

    thanks

  5. #135
    Senior Professional Array duwde's Avatar

    Join Date
    Oct 2007
    Location
    Tatooine
    Posts
    164
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    15

    Default

    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 ?


  6. #136
    Senior Professional Array

    Join Date
    Nov 2007
    Posts
    155
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    15

    Default

    Quote Originally Posted by duwde View Post
    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.
    iPhone 3G 16GB white. Official on contract. Used to have a w48 iPhone (OTB 1.1.2) all the way to 2.0.1 when I went legit.

    Current FW: 2.0.2
    Carrier: EMT (Estonia)
    All functions working

  7. #137
    drg
    drg is offline
    Senior Professional Array

    Join Date
    Oct 2007
    Location
    Canada
    Posts
    479
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    34

    Post Only decrypt PART of the lotken?

    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?

  8. #138
    iPhone Moderator Array

    Join Date
    Dec 2007
    Posts
    153
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    14

    Default

    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!

  9. #139
    Jedi Admin Array

    Join Date
    Sep 2007
    Location
    sao paulo, brasil
    Posts
    1,242
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    10

    Default

    anyone have experience using the Playstation 3 for BF???
    MSN/AIM? PM me
    If you want to become a Hackint0sh supporter click here.
    I DO READ PM's

    "Just because I'm losing
    Doesn't mean I'm lost
    Doesn't mean I'll stop
    Doesn't mean I will cross

    Just because I'm hurting
    Doesn't mean I'm hurt
    Doesn't mean I didn't get what I deserve
    No better and no worse "

  10. #140
    Advanced Array FryTheSolid's Avatar

    Join Date
    Dec 2007
    Posts
    38
    Post Thanks / Like
    Downloads
    0
    Uploads
    0
    Rep Power
    0

    Default

    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.


 

 

Similar Threads

  1. Looking for Volunteers for Product Validation
    By mafili in forum iPhone Developer Exchange
    Replies: 0
    Last Post: 06-01-2011, 04:39 AM
  2. Help with Multiple Text Field Validation
    By zacharyrs in forum iPhone Developer Exchange
    Replies: 0
    Last Post: 01-12-2010, 08:02 PM
  3. MacNN: Cheetah3D 5.1 intros new automatic skinning algorithm
    By hackint0sh in forum Latest Headlines
    Replies: 0
    Last Post: 12-01-2009, 07:50 PM
  4. MacNN: AKVIS Sketch 9.0 provides new conversion algorithm
    By hackint0sh in forum Latest Headlines
    Replies: 0
    Last Post: 08-17-2009, 09:20 PM
  5. [Update] iPod touch $20 validation on reload
    By juliangall in forum iPod Touch 1G
    Replies: 8
    Last Post: 01-21-2008, 03:53 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Powered by vBulletin®
Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.
Search Engine Friendly URLs by vBSEO
(c) 2006-2012 Hackint0sh.org
All times are GMT +2. The time now is 01:06 PM.
twitter, follow us!