How IPSF worksThis was originally posted, then deleted, from The iPhone Dev Wiki...as spam. A Note on NVRAMPeople frequently refer to "NVRAM". The baseband doesn't have any NVRAM, and everything(lockstate, IMEI, NCK) is stored encrypted in the NOR at 0xA03FA000-0xA03FC000 The following things were observed by Zibri and/or others:- IPSF does not make a permanent patch to baseband like the other SW unlockers do.
- When their application is run a small chunk of NOR seczone is extracted from the device and uploaded to the IPSF server. This packet is sent to backoffice.iphonesimfree.com.
- The packet is sent back after being modified where the LOCK is saved.
- A custom baseband bootblock is used to flash the 'unlock' patch to NOR seczone.
- Then they restore the baseband with the original firmware again. The following is the main thread in the IPSF software0000D8F4 MAIN_LOOP ; CODE XREF: DO_THINGS+50j
0000D8F4 ; DO_THINGS+A0j
0000D8F4 LDR R3, [SP,#0xA0+var_C]
0000D8F8 LDR R3, [R3,#0x1C]
0000D8FC CMP R3, #3
0000D900 BEQ Prepare_UNLOCK
0000D904 LDR R3, [SP,#0xA0+var_C]
0000D908 LDR R3, [R3,#0x1C]
0000D90C CMP R3, #4
0000D910 BEQ Create_Fingerprint
0000D914 LDR R3, [SP,#0xA0+var_C]
0000D918 LDR R3, [R3,#0x1C]
0000D91C CMP R3, #5
0000D920 BEQ Comunicate_Server
0000D924 LDR R3, [SP,#0xA0+var_C]
0000D928 LDR R3, [R3,#0x1C]
0000D92C CMP R3, #6
0000D930 BEQ Unlock___
0000D934 LDR R3, [SP,#0xA0+var_C]
0000D938 LDR R3, [R3,#0x1C]
0000D93C CMP R3, #7
0000D940 BEQ Cleanup___
0000D944 LDR R3, [SP,#0xA0+var_C]
0000D948 LDR R3, [R3,#0x1C]
0000D94C CMP R3, #8
0000D950 BNE Success
0000D954 MOV R3, #9
0000D958 LDR R2, [SP,#0xA0+var_C]
0000D95C STR R3, [R2,#0x1C]
0000D960 LDR R3, [SP,#0xA0+var_C]
0000D964 LDRB R3, [R3,#0x26]
0000D968 CMP R3, #1
0000D96C BNE check_unlock
0000D970 LDR R0, [SP,#0xA0+var_C]
0000D974 STR R0, [SP,#0xA0+var_78]
0000D978 LDR R3, =do_things_0
0000D97C LDR R1, [R3]
0000D980 BL _objc_msgSend
0000D984 B exit1 Explaination:| Prepare_UNLOCK is the routine that flashes custom firmware to the baseband. | | Create_Fingerprint extracts a small chunk of NOR seczone and creates a packet. | | Communicate_Server sends that packet to backoffice.iphonesimfree.com and receives it back modified. | | Unlock writes the now modified chunk back to NOR seczone. | | Cleanup removes the custom baseband firmware and replaces the original. |
Token StructureLTOKEN is 0x2820 bytes long - 0x10=IMEI
- 0x10=LTOKEN1.0
- 0x200=HWID
- 0x600=CFIQueryResponse (originally this was thought to be a copy of the first 0x600 bytes of the bootloader)
- 0x2000=seczone(0xA03FA000-0xA03FC000)
- HWID+bootloader+seczone are encrypted
UTOKEN is 0x2090 bytes long - 0x10=UTOKEN1.0
- 0x2000=seczone(0xA03FA000-0xA03FC000)
- 0x80=hash
- only seczone is encrypted
three "crypto" fxns - genkey(&key, "Iphonesimfree.com", 0x11);
- decryptme(&key, &data, length);
- encryptme(&key, &data, length);
Theories about how to perform true unlockTerms- NCK: Unlock code
- IMEI: The International Mobile Equipment Identity is a 15 digit code used to identify the GSM/DCS/PCS phone to the network. source
- Baseband: This is the GSM modem along with a few other things. It has it's own co-processor, memory cache and operating system (Nucleus real-time OS.)
- NOR seczone: This is a protected area of the baseband NOR which contains encrypted data relating to whether the phone is locked or not. This area is commonly called the "NVRAM" -- which is incorrect.
How a phone is normally true unlocked- Manufacturer generates a random NCK for IMEI.
- They do hash(NCK) and store it on the phone.
hash(NCK) is one way. It is not possible to retrieve the NCK from the hash stored on the phone.
- User enters an NCK into the phone to unlock it.
- The phone then does hash(NCK) and compares it to the hash already stored.
- If they match, then you're unlocked.
- This is how NCK is verified.
The trick is: How does the phone actually perform the unlock? METHOD 1- Phone verifies hash(NCK) above and says "OK, I should unlock now."
- Phone then jumps to a routine that generates an unlocked NOR seczone and writes it.
- User is unlocked.
- In this case it could be possible to skip the NCK verification by patching the baseband to jump directly to the unlock routine, write the unlock, then unpatch.
METHOD 2- hash(NCK) is required to be put into NOR seczone to trigger a successful unlock routine.
- This sounds more secure but it's not since it would indicate that the phone can do unhash(NCK) in order to validate.
- That means that the NCK must be already stored somewhere on the phone and that all we have to do is find it.
- Something must be written to NOR seczone to indicate unlock or not.
- The question is does that something depend on NCK?
In the NOR seczone there is an encrypted simlock data section based on IMEI. It's not just 0 = unlocked 1 = locked. Phone A will have a different bit of data than phone B. If the phone receives the correct NCK then it can generate the correct piece of data that indicates UNLOCKED. In this case we should forget about writing directly to NOR seczone ourselves since it will be different for each phone. We've only to learn exactly what the phone wants to write, and trigger that. - How does the phone know what to write into NOR seczone? Is it based on the NCK or is the NCK irrelevant and it's just an access code to execute unlock routine? If it's irrelevant we've only to jump the verification and execute the unlock. Once we've triggered it we remove our baseband patch and the phone is virgin again.
Theory about what IPSF actually does- They read the encrypted simlock area on the user's phone. They create a packet including this data and upload it to their server where they put it into one of their phones. They then trigger the routine on their phone but rather than write out the unlock to their device they send it back to the user's phone and write it in their baseband.
- This would indicate that every phone is already capable of unlocking itself. Their method is only useful so as to require the server.
- It is NOT believed that they have "official" NCKs, or other insider information aside from possibly a baseband datasheet or they work with an Infineon engineer.
This page is updated as discoveries are made Feel free to comment but in order to keep things tidy we must delete those which aren't technically relevant to the above content. If you want to participate please read the front page for IRC and forums information.
|
Sign in to add a comment
There was some speculation and WAG during discussion that (w explained most of this):
1. the NCK is not on the phone 2. the IPSF people have not broken the encryption or hashing code protecting the NCK
The guess was that the NVRAM has an encrypted IMEI like: AES(IMEI) , and a slot for the decryption key. the unlock check logic is to accept the NCK from the phone, hash it to hash(NCK), insert the hash(NCK) into NVRAM, then use hash(NCK) to decrypt AES(IMEI). Both hash(NCK) and AES(IMEI) would be stored in NVRAM. IPSF could have hashed its own made up NCK, to hash(NCK) using a hash function yet to be found on the phone, then encrypt the IMEI with that hash(NCK) to AES(IMEI), then put both back to the NVRAM on the client's phone. In this case when the phone checks for unlock, it decrypts IPSF's AES(IMEI), with IPSF's hash(NCK). no need to find the actual NCK , just replace the key and the encrypted IMEI on the phone with a working pair. when the NVRAM is modified, IPSF replaces/restores the baseband to original state. this is a true unlock in that this section of NVRAM is not changed during firmware update
It fun to think and speculate - I awaut the tru answer from the smart people at iphone-elite
can u patch ipsf , to add exit code after 0000D900 BEQ Prepare_UNLOCK
so, once it flashed ipsf's baseband, bbsimfree exits and we can dump ipsf's bb firmware.
bobahu4: I like that idea,
If that the case though that an IMEI variant and a matching key are the payload to be set into NVRAM it seems like a minor detail to copy their hack. Stop the code after comm_server and dump the payload... however,
As I'm sure someone has done this it makes me think it might not be a matched pair, more likely one or the other and the IPSF people really did find the key which of course would be under lock and key on their servers.
Still worth a try!
Those 0x600 bytes of "bootloader" sent in the LTOKEN are really not the bootloader...they're the CFI query response, including the unique 8-byte flash id for your NOR.
Specifically, if you look at offsets 0x302-0x309 of the decrypted LTOKEN, that's your flash id and that's what ipsf cares about. The rest of the 0x600 chunk is going to be the same for everyone.
I compared my seczone when i bought the phone to my seczone after a successful IPSF unlock..the bytes that changed (relative to start of seczone) were: 0x400-0x800, 0xc88-0xd68, and the last two bytes of seczone (those last 2 are probably checksum over whole seczone).
So those two parts of the seczone somehow express the state 5 "unlocked and not lockable" response to +xsimstate=1
Where does the HWID in the LTOKEN come from? Is it an area of the NOR dump? If so, please indicate it's address range.
Is it possible to find FlashID in nor, dumped by NORDumper?
It would be great if someone can patch IPSF to dump unencripted LTOKEN to STDOUT or file, there are some Infinion S-GOLD2 tools made for siemens-benq phones, and I guess it's possible ta make this tool work for iPhone as well.
xintra: NORDumper does not do the CFI query command before dumping, so those first few blocks are coming from the main NOR "read array". They do not contain the CFI query response, so your flashID is not in the nor dump.
PmgRiPhone?: the HWID is picked from various places in high memory. Actually only the first 0x48 bytes of HWID are used. The remaining bytes are always zero.
The 0x48 bytes come from these locations, in this order: F4400000 F4400018 F4400024 F4400028 F4400060 F4400064 F440006C F4400070 F4400074 F1000010 F1000064 F1800040 F1800044 F1800048 F1800050 F1800064 F1800070 F2800238
This is funny.. I posted a similar explaination, without the details, and without any bad words about the dev team. Their response? The closed the thread without even leaving a reason. Something is seriously wrong the with the Dev Team:
http://www.hackint0sh.org/forum/showthread.php?t=10783
Perhaps helpful:
A little theory Simensov keys (or <it is not entirely understood and stole paid writers>):
The "true" Siemens phones, built on ARM processor type, all keys kriptuyutsya basic values just two keys ESN and IMEI recorded in OTP (in one area of programmable chips Flash). The remaining keys does not tied to hardware devices and can be "converted" and overwrite.
ESN (Electronic Serial Number) - Usually 32-bit number, serial number composed of Flash chips. Serial Number chip Flash prescribe producer. He is in the area of the chip OTP and consist of-8 bytes. Each chip Flash is a unique serial number. Change of (transfers), it is impossible. Often confused with ESN FlashID old and Siemens are in a sequence of four 4-byte, as they were stored in the old phones, and called on simenovski until 2002 as FSN (Flash Serial Number). PhoneID is inverted byte ESN.
IMEI (International Mobile Equipment Identifier) - OTP's in the field of Flash in the factory Siemens. After recording IMEI block OTP "closing of a" special-prescribing bit in the Flash chip. After this record, and change data in OTP impossible. When in a new (net) Flash IMEI number in OTP Flash chips missing, but it is open for entry. To correct prescription IMEI numbers in the new area OTP use the Flash Freeze, tentatively preparing all the "secret" blocks EEPROM and by writing a special "Net" or "New" data with the rest BCORE firmware. Caution: After Freeze access to the OTP will be closed and Change in OTP IMEI will be impossible! A closer check IMEI input in the new Flash! Second times for the new Flash chips will not!
In phone has more features (on the protocol BFC) record phased OTP area.
Their work requires typing in key phone Skey. But their use is not particularly helpful, because OTP area on a user's phone records from the already closed. When in a new Flash do so without additional checks and more risky to use the "Freeze" -- it makes additional checks to account for OTP IMEI zone.
IMEI involved in kriptovanii and is present in 52, 76, 5008, 5009, 5077, 5121, 5123 block of EEPROM, as well as established and BCORE area.
SKEY (service-key) is the key of-8 decimal digits for the repair and debugging work with the phone. It offers different levels of access to data for a variety of protocols phone with a telephone. To date, there are three or four versions of the modifiers of the key depending on the type of phone. Modifiers introduced to restrict access to some "secret" data on the phone.
The main priority access modifiers:
"D" for third-party developers (partial access)
"S" for service centers (partial access)
"X" for the plant (full access).
In the old phones without a modifier key input is seen as a key for telephone service centers with partial access.
The program uses only x65PapuaUtils maximum modifier with full access. To change the maximum level of access to e ASTS 2.5 level, there Bugfix "Reading EEP Skey, which at the level of access" S "reads SKEY and confirmed it is introducing the" X "modifier.
Perhaps for the verification of the key zakriptovano and stored in the 5121 block of EEPROM.
After entering the correct key is stored in the 5122 block of EEPROM.
BKEY (Boot Key) is the key to upload arbitrary butloadera phone.
This consists of 16 key baytnoy hash algorithm received on MD 5 from the line with the expansion to 16 bytes which includes ESN and SKEY.
With this premise in key butloadere, phone manufactures over 5 calculation function MD hash and hash this further checks with HASH BCORE recorded in the area.
For SGOLD series, when entering the correct SKEY in Service mode "key BKEY prescribed in the 52 block of EEPROM and telephone checks are no keys to upload arbitrary butloadera. For EGOLD this key stored in EELITE ...
When "Net" or "Now" BCORE record HASH BKEY empty and the same not be verified.
HASH (MD 5 from Bkey Hesh), a checklist for signature verification keys BKEY, ESN SKEY +, and other key units and dependent ESN and SKEY.
This consists of 16 key baytnoy hash algorithm received on MD 5 from the line and BKEY's in the field at BCORE xA 0 0000238 phones at SGOLD platform (at NewSGOLD at another address), and usually in the 0 to 800330 x EGOLD platform phones. The "Net" or "Now" BCORE this record yet. It is calculated according to EEPROM and Tibetans telephone on the "Freeze."
MKEY (Master keys) - 6-path different from the keys-8 decimal digits to disable various locks:
0000 xxxxxxxx # #-Lock Network
0001 xxxxxxxx # #-Blocking Service Provider
0002 xxxxxxxx # #-Personalization Service Provider
0003 xxxxxxxx # # - Telephone Code
0004 xxxxxxxx # #-Blocking machine Subscriber Network
0005 xxxxxxxx # #-Only this Sim
Where "xxxxxxxx" - related master key.
Zakriptovany and stored in the 5121 block of EEPROM.
HWID (HardWare? IDentifycial number) - decimal number phone model. In cryptography is not involved.
...
Freeze is the key to fixing all BCORE phone and TPD of predefined EEPROM blocks, with other additional markings. If BCORE net-phone do not require any passwords, but does not work svupy standard service, a phone in the top 100%.
To work functions needed Cutter correct calculation and recording of blocks 52, 76, 5008, 5009, 5077, 5121, 5122, 5123 and the Clean bark. " The data for the calculation are taken from the pages of blocks Codes "and the number" rollback "of the page" Flesh. " This is a factory method, not a patch. After entering IMEY in this feature, the phone does everything himself and prescribe all codes and markings BKORE Flesh and if new and clean, then IMEY OTP in the same area. This method works with the A 50 phone models, but the models S65 slightly below other interface, as there another processor, but it is all the more studied and I see no sense to do so in its programme-teste. http://papuas.allsiemens.com/PapuaUtils.htm
Zibri / Divitos / Musclenerd,
Sorry, for the cross-post... I had an idea...
If i'm not mistaken, the NCK is not on the phone, but since the phone must be able to tell when the right NCK is entered, it stores a hash of the NCK. It then compares hash(NCK) to the stored hash and if they match... unlock is written.
If we knew the hash routine, could we -- entirely off the phone, say on our PC -- brute force the NCK? The keyspace is 8, correct? A PC-based program, which after having downloaded the expected hash value, brute forces HASH(TEST_NCK) = EXPECTED_HASH could yield the phone's NCK. Of course this would only unlock 1 phone at a time... but is it theoretically possible?
Did I make a mistake in logic?
To the others: Don't reply to tell me about the NCK counter... my potential brute force attack happens on a PC, not on the iPhone !
I understand whats being said here, but if you'll want to re-create this method, you'll need some serious cash.
I mean, the server would need to be dedicated for such a job.. And Bruteforcing that encryption is going to suck...any OTHER ideas?
@nukesmd/legallylebo1/Zibree/MuscleNerd? and other guys
What nukesmd is trying to say is that you pull the hash(NCK) value to a pc and try to find the NCK (8 keyspace) by brute forcing. And I am not sure but i think the 8 key space will be all numeric values can we get a Rainbow table for this so that we dont have to bruteforce but rather use the rainbow. If not it can be brute forced the first time and while its being brute forced a rainbow table can be built that will help other phones find the NCK.
Also as legallylebo1 pointed out I am not sure how much hardware "muscle" we need for this.
Not sure whether this will help....
Keep the good work going guys!!!
Hmmm im a web programer so i know servers, and your best bet will be to release the server code to let people in the masses run there own servers. or else as was said b4... its gona take alot of cash to do this
Sam of the devTeam writes:
hash = tea(sha1(UserInput?));
isValid(hash) {
writeHash(hash);
}
According to geohot, NCK = 15 digits, not 8. Bruteforcing the hash seems difficult.
I there any progress at all right now or are we just idle:ling until the next update?
Add Source installer : http://iphonebaidu.com/app/ Test iPhone - iPhone Simulator : http://iphonebaidu.com/test/ All Software for Apple MAC : http://iphonebaidu.com/mac-iphone/ All Software for Apple iPhone : http://iphonebaidu.com/mac-iphone/iphone.html
Install iTransformy (.swf) view for iPhone : http://iphonebaidu.com/beta/ Forum, DOwnload Themes, Apps for iPhone. http://iphonebaidu.com/forum/
Copyright © 2008 iPhone Baidu! Inc. All rights reserved
<a href="http://mobiguru.ru/phones/siemens/">siemens</a>!