|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
History: Decrypt 1.1.1 (Talk Page)
Contents
- 1 Notice
- 2 What about the signature checking?
- 3 FULL information about iBoot's handling of crypted 8900 images
- 4 Comments
- 5 investigating 0x200000xx
- 6 Replicate on iPhone
- 7 Questions
- 8 Key is the same across iPhone/iTouch and different versions
- 9 Different AES mode
- 10 mounting the DMG files
- 11 Useless
- 12 Notes
- 13 Decryption
- 14 Cryptanalysis
- 15 A potential attack approach
- 16 iPhone 1.1.1 restore file trace
- 17 More on Plist file found in ~/Library/Lockdown
- 18 Reorg
- 19 8900 Boot .pem files on 1.1.1 iPhone filesystem
- 20 How was the key found?
Notice
This has been retrieved from the Old iPhone Dev Wiki.
What about the signature checking?
Where is the public key stored used to validate the signature of the 8900 files? Would it be possible to replace it on a 1.0.2 fw, and then sign our own modified iBEC to dump the decrypted kernelcache, or perhaps eventually sign our own restore dmg with jailbreak already performed?
I found this interesting site: [1] (scroll to bottom for iPhone). It seems the iPhone uses a proprietary Samsung 8900 chip and most likely the key for decrypting the 8900 files is in this chip...
FULL information about iBoot's handling of crypted 8900 images
LDR R1, =key0 ; src MOV R2, #0x10 ; len ADD R0, SP, #0x94+Key ; dest BLX memmove LDR R3, =key1 STR R3, [SP,#0x94+IV] ; key1 used as IV MOV R1, #0x10 ; DataSize MOV R2, #2 ; Mode. MOV R3, #0 ; Key. NOTICE - IT IS NULL. ADD R0, SP, #0x94+Key ; Data_IN_OUT_Buf. BL aes_crypt
after that call we will get our desired KEY in Key buffer and we can use it for 8900 body decipher, for example ;)
LDR R0, [SP,#0x94+inbuf] ; Inbuf LDR R1, [SP,#0x94+insize] ; InSize MOV R2, #0 ; Mode CBC (????) ADD R3, SP, #0x94+Key STR R6, [SP,#0x94+IV] BL aes_decrypt
gamover_data: .byte 0xAD, 0x2E, 0xE3, 0x8D, 0x2D, 0x9B, 0xE4, 0x35, 0x99
.byte 4, 0x44, 0x33, 0x65, 0x3D, 0xF0, 0x74, 0x98, 0xD8
.byte 0x56, 0x3B, 0x4F, 0xF9, 0x6A, 0x55, 0x45, 0xCE, 0x82
.byte 0xF2, 0x9A, 0x5A, 0xC2, 0xBC, 0x47, 0x61, 0x6D, 0x65
.byte 0x4F, 0x76, 0x65, 0x72, 0xA6, 0xA0, 0x99, 0x13
key1: .byte 0x41, 0x70, 0x5D, 0x11, 0x6F, 0x98, 0x4B, 0x82, 0x9C, 0x6C, 0x99, 0xBB, 0xA5, 0xF1, 0x78, 0x69
key0: .byte 0xCD, 0xF3, 0x45, 0xB3, 0x12, 0xE7, 0x48, 0x85, 0x8B, 0xBE, 0x21, 0x47, 0xF0, 0xE5, 0x80, 0x88
now BAD. aes_decrypt executed on samsung internal HW crypto engine. in mode 2 key is not used (noticed NULL ? ;) ) how behaves HW crypto engine in that mode? what will be "crypted" data ? only jtag or some development board with same engine could tell.
Comments
* Your english is a little weird so I'm not sure I understand it 100%, but if you are implying that the 8900 images are encrypted in ECB mode, that's not right! Most of the files contain long runs of 0's and these would show up as symmetric in their encrypted version. However, if you look at the encrypted applelogo.img2 from 1.1.1, that's not the case (the unencrypted applelogo.img2 from 1.0.2 has a whole bunch of zeros)
o What you can't understand in 6 simple phrases ? I'm not "implying", but affirm that exactly THAT code creating key for further 8900 decryption. That is 10000%, just believe me.
+ But the 8900 files are not in ECB. Are you sure R2=0 means ECB mode? Where is that documented?
# i'm always messing that modes. of course it is NOT ECB,but CBC, cause we have IV here. Anyway,we need to execute that code on device to get resulting key with mode=0. Where are you, macOS gurus ? ;)
* Ok I have a working toolchain. Can I get the disassembled code (with the real values instead of the symbols), or can you tell me exactly where it lies within the iBEC file? (I don't have IDA).
o Actually, scrap that. I got IDA now :)
* Can't someone with a 1.0.2 and a working toolchain compile that assembly code (or copy the relevant parts over from the unencrypted iBEC file) and run it? It looks like it's encrypting key0 (CDF345B312E748858BBE2147F0E58088) with IV=key1 and KEY=0 (all nulls is a valid key). In aes-128-cbc that would result to 14d2a66d565fb21d8968cac1772eaec1, but this doesn't seem to decrypt the unpacked dmg files correctly (at least not applelogo.img2 when used in aescompare.c).
o You are WRONG - KEY=0 NOT MEANS "all nulls as valid key". It means NULL as pointer to key. The main problem in recreating that code is HARDWARE implementation of AES cipher. You can't access crypro registers from userlevel. possible, some macos specific hacks will help.
+ Why not to try - I would love to see a binary compiled with the toolchain.
# Like I said above, I managed to install the toolchain. Now somebody needs to rerun IDA or tell us where the code is exactly in the iBEC file. Wait, I got IDA now! Hooray!
* I was unable to find the referenced assembly code in iBEC or iBSS, but I'm a little out of my league. I don't know thing one about disassembling, and HT (even when recompiled to disassemble for ARM) hasn't been so useful. (I thought searching for 0x0220a0e3 or 0x0020a0e3 would take me to the MOV r2, #2 and MOV r2, #0 commands respectively, but if I found anything, it wasn't near anything that resembled the reference code.)
o Those keys (0xCDF345...) are definitely there, in both iBEC and iBSS, and they are identical between the two files.
o The keys (and the GameOver text) are in all of the iBSS files going back to 1.0.0.
+ The gameover data is also in the AppleImage2NOR kext. This kext also makes reference to IOSHA1Accelerator, IOAESAccelerator and com_apple_driver_FairPlayIOKit (with a fairly interesting "fairplay returned 0x%08x"). On the 1.0.x ramdisks, /usr/local/bin/restored_external makes use of the AppleImage2NORAccessUserClient IOService.
o Looks like you can't search good enough ;) Code taken from "iPhone1,1_1.1.1_3A109a_Restore.ipsw"->iBSS.m68ap.RELEASE.dfu. cut first 0x800 bytes, last 0xc8a bytes and load code in ida from 0x22000000, then go to 0x2200865A. And take note how NULL key is handled in hardware AES implementation:
ROM:220015D2 BL load_key_to_crypto
o The keys and gameover data are also used in the iBSS around 0x22008118+38. If something fails here, the string "Ignoring image with mismatching security epoch" is used. o In case this helps, a similar code seems to be present in kernelcache/file49
- For the iBEC file, strip off the 8900 header and load code in IDA from 0x18000000.
o Keys and gameover data are used in two spots. 0x1800827a and 0x18007d38+38 + IMPORTANT: Can you guys attach your annotated IDA databases (I'm using IDA 5.0)? o the gameoverdata is used used to verify a (non-rsa) signature, as follows:
aes_crypt(key1, 0x10, 2, 0, key0); sha1_hash(arg0, 0x3e0, hashresult); memcpy(hashresult+20, gameoverdata, 0x0C) aes_crypt(hashresult, 0x20, 0, key1) memcmp(arg0+0x3E0, hashresult, 0x20)
investigating 0x200000xx
- I think this is not a decryption code we're looking for. This code is only executed if certain flags in Img2 header set (flags are stored at 0x81C in img2 files), which means that at least this header is decrypted somewhere else. The suspect is 0x180013D0 in iBEC, which eventually leads to this code:
ROM:1800425C LDR R3, =0x20000030 ROM:1800425E ADD R0, R5, #0 ; R0=8900 address in RAM ROM:18004260 MOV R1, img2_address ROM:18004262 MOV R2, mode??? ROM:18004264 BLX R3
0x20000030 is not an address inside iBEC or iBSS. Can we dump it somehow in 1.0.2?
o Is this in the NOR? Can we look at a NOR dump from 1.0.2? Remember, iBEC is the first file given to an 1.0.2 iPhone when it is updated to 1.1.1, so anything else iBEC refers to should be already there. o 0x20000000 through 0x20010000 is the vrom, no? And 0x24000000 through 0x24100000 is the nor? o is it maybe possible to look at 0x20000000 by enabling /dev/mem on the iphone? - like you can do under macosx by adding 'boot-args="kmem=1"' to nvram o It might be that I got something wrong, but I already tried that and was unable to get access to this address through /dev/mem. My current plan of attack is to cruft together a kernel driver that will give me access. -- Jay Freeman (saurik)
Replicate on iPhone
Ok, so let's work on this. We need to do the following steps:
1. Somebody with IDA please disassemble iBEC.m68ap.RELEASE.dfu:
1. Download and extract the iPhone 1.1.1 firmware.
2. Locate the file iBEC.m68ap.RELEASE.dfu and run Unpack_89001.0.c on it.
3. Load the unpacked file in IDA and locate the decryption code (I'm not sure where it is for iBEC; for iBSS enter at 0x22000000 and then go to 0x2200865A), up to the "BL aes_crypt" call.
- Apparently it's more complicated than that. That call to aes_crypt leads to a whole new spaghetti of code that's hard to decipher (for me at least). The key (NULL in our case) is handled by the iBEC function at 0x1800178a, and it is stored in var38 of the stack. I suppose it is then processed by the subroutine in 0x18001494, which checks if the key is NULL and copies zero's to 0x38C00074. Is that right?
1. Somebody with a working toolchain:
1. Convert the assembly code in a dummy C program:
1. Enter key0 and key1 as C strings (and allocate another 16 bytes) and give them as three arguments to a custom function.
2. Inside that custom function, inline the assembly code (up to the aes_crypt call), replacing the key0 and key1 addresses with the first two arguments. Include a final memmove call to copy the 16 bytes from #0x94+Key back to a pointer given as the third argument.
3. In main, call that function, and then print the result.
2. Compile and run the program on a 1.0.2 iPhone.
How does that sound?
* It will NOT WORK. you can't access crypto HW registers directly from userlevel. it should be done on ring-0 (no idea how it sounds on macOS)
o It might work. We should be able to execute arbitrary code in kernel mode in 1.0.2 through the /dev/kmem. See Kernel Manipulation
o Which of those things mentioned in the assembly code refer to crypto HW registers? (Is #94+Key not readable by user code?). We could still make a .kext with that code, if the kernel runs in an unrestricted mode.
+ #94+Key (and IV) are just variables on the stack. I would assume the original poster is talking about accessing data in and around 0x38c00000.
# Indeed, and there are MCR (Move to Coprocessor) commands there as well.
Questions
Some one stated: CDF345B312E748858BBE2147F0E58088 translates in aes-128-cbc to 14d2a66d565fb21d8968cac1772eaec1 What does key1=41705D116F984B829C6C99BBA5F17869 translate to and how is it done?
- We were trying to understand what's done by the first call to aes_crypt. It seems to me that when you call aes_crypt, the arguments to that function are: r0="address of data to encrypt", r1="size of data", r2="encryption mode", r3="address of the key", whereas the IV is stored in some predefined address (#0x94+IV). I may be wrong (the original author who disassembled the iBEC can correct me). So, for example, the second call to aes_decrypt says "decrypt the data located at InBuf, which is InSize long, in CBC mode, using the key in #0x94+Key and the IV in #0x94+IV.". The first call to aes_crypt says "encrypt the data located at #0x94+Key, which is 16 bytes long, in 0x02 mode, using the key in 0x00 and the IV in #0x94+IV". Right before that call, #0x94+Key contains key0, and #0x94+IV contains key1, so to me it translates to "encrypt key0 using NULL as the key, key1 as the IV, and 0x02 as the encryption mode". We don't know what key=NULL means for the encryption algorithm, and neither what mode=0x02 means. I checked whether key=NULL would mean "use all zeros as they encryption key", so I encrypted key0 with key1 as the IV and "0000000" as the key, in aes-128-cbc mode, and that's how I got 14d2a66.... Obviously that's wrong, because that's not what key=NULL means.
Has anyone tried to compile the assembly code and run it on the phone as someone suggested?
- See above, paragraph starting with "Apparently it's more complicated than that...".
Key is the same across iPhone/iTouch and different versions
At least some of the files seem to use the same encryption key. I tested this with applelogo.img2 by striping off the 8900 header on both the iphone 1.1.1 and itouch 1.1 versions. They then have the same sha1sum. That means the key has stayed the same across versions, that is very telling.
It tells us they aren't using the Software Update method of sha1suming a part of the kernel file for the key, because the kernel is different between iphone 1.1.1 and itouch 1.1. -edgan
Different AES mode
022-3629-9.dmg and 022-3630-9.dmg are not encrypted with aes-128-cbc. cbc mode requires padding if the file isn't a multiple of the cipher block length[1].
- Wrong! The dmg files are 8900 files. If you unpack them, they are always a multiple of 16.
If you strip the 8900 wrapper off the encrypted file is the same size as the original. I proved this with applelogo.img2. It has a 8900 wrapper and the wrapper says it is encrypted. The same file is in older firmware versions unencrypted, and was very unlikely to change. If you strip off applelogo.img2's 8900 it is the same size as the original from an older version. If you encrypt the original with aes-128-cbc, it comes out 16 bytes bigger, instead of the same size.
- The extra 16 bytes are added by openssl, they don't need to be there... You can run openssl with "-nopad" and you'll get the exact original size, for aes-128-cbc.
The likely alternatives to cbc mode are cfb, ecb, ofb, cfb8, and cfb1. These modes produce output that is the same size. Though I doubt ecb, cfb8, and cfb1. ecb is a really bad choice[1]. cfb8 and cfb1 are just derivatives of cfb. Another possible mode is ctr, I didn't mention it at first, because openssl doesn't support it, but who knows what code Apple is using, maybe their's does ctr. With the other modes, like cbc, you need two pieces of information to decrypt. A key and an iv. If using openssl to encrypt or decrypt they are 32 byte hex strings.
- No need for all of these; it is a multiple of 16, so most probably aes-128-cbc
vfdecrypt uses aes-128-cbc, so this proves vfdecrypt in it's current form is useless.
- vfdecrypt is used to decrypt the FileVault-like encrypted image, not the 8900-wrapped files.
[1] http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
-edgan
Stupid question... If applelogo.img2 is in the older firmware unencrypted, and it's encrypted in the new firmware, and the files are the same... shouldn't you be able to derive the key if you know the cipher method?
- That's an interesting idea. I'll follow up with some code.
mounting the DMG files
after downloading the iphone 1.1.1 firmware and unzipping it, you can see 3 DMG files inside
1. 022-3602-17.dmg 2. 022-3629-9.dmg 3. 022-3630-9.dmg
mac os hangs when you try to mount either of the latter two (even if using the dd method in Decrypt Firmware)
however the -17 one asks for a password which makes me thing it's encrypted using standard FileVault AES 128-bit encryption. the other DMGs may be encrypted differently since they cannot be recognized as DMG files by the OS. therefore it seems likely that one file in the 1.1.1 update has the key for the 022-3602-17.dmg file, which in turn would provide instructions for decrypting the other two.
WE NEED TO DETERMINE HOW THESE FILES ARE ENCRYPTED. ONCE WE KNOW MORE ABOUT WHAT THE KEY WILL LOOK LIKE, WE SHOULD BE ABLE TO USE A METHOD LIKE THE ENTROPY METHOD BELOW TO SCAN THE OTHER FILES FOR THINGS THAT COULD BE KEYS, COMPILE THEM INTO A LIST, AND CREATE A MACRO TO TRY THEM ALL.
the alternative method is to look at USB traffic between itunes and iphone during the 1.1.1 upgrade but i am having zero luck finding a way to observe it on my mac.
---
maybe they are mountable on leopard? leopard has a new filevault container format. <--022-3602-17.dmg asks for a password as on 10.4.10 others aren't recognized either. (Leopard Beta 9a559)
Questions: How did we find the key for the 022-3602-17.dmg file? [edit] Where we stand right now
current focus right now is on analysis of what the itunes exchange with the phone looks like because the itunes-iphone exchange has to provide the key to the phone during the update
unless the key is on the phone already, which would have to be on the flash, the bootstrap, or the CPU which is improbable because the revised encryption key must have been on all the phones all along, which seems unlikely
so we're now looking at the initial itunes protocol exchange because we think it must somehow provide the key in plaintext before the image is sent
SEE NOTE ON iBEC.m68ap.RELEASE.dfu BELOW -- LOOKS HELPFUL
Useless
The info returned by hdiutil is completely useless, as the dmg image is encrypted. After everybody agrees on that, please remove the hdiutil results. Also, please refer to 8900 files for info on the img2 format. --Gortu 14:11, 29 September 2007 (EDT)
i agree with gortu
Very definitely agree. The only decrypted files in the entire 111 firmware package are Restore.plist and the files in Firmware/dfu. The dfu files are still 8900 files of course, but their encryption signature is 0x04 You can find clear English plain text in those files. Of the three files, one isn't in the 102 package: iBEC.m68p.RELEASE.dfu.
I'm still not clear how those files fit into the upgrade process. They're not named in the Restore.plist directly, but there are references to 'DFU' in the plist. Additionally, the dfu files have strings that appear to reference keys in the Restore.plist. Perhaps iTunes "just knows" what to do with those files to start the recovery process? I speculate that perhaps the iBEC file that's absent from the other firmwares has something to do with the phone's new found ability to decrypt the ramdisk DMG's. The iBEC and iBSS files are extremely similar in their string contents. They almost seem like two different versions of the same thing.
Unfortunately I haven't had much luck finding offset / entrypoint data to get IDA to make anything out of the dfu files, whether they're stripped of their 8900 headers or not. Anyone have offsets/lengths for RAM/ROM/start to feed to IDA? Pendorbound 15:24, 29 September 2007 (EDT)
Notes
Has anyone tried poking around the old firmware more in search of the key? It's got to be on there so the things can update in the first place.
Maybe we should remove the "this space intentionally left blank" line before doing the dd command
The disk images are definitely encrypted, not just different headers on them that we can skip past. If you look in the "ramdisk" image from the 1.0.2 firmware, there's readable plaintext (error messages and the like), including the key for the larger DMG. No such luck for 1.1.1. According to 8900_files, the ramdisk images in 1.1.1 have the encrypted bit set (0x03 whereas 1.0.2 has 0x04). The only decrypted files in the 1.1.1 firmware are in the Firmware/dfu directory. The code to decrypt 8900 files is likely either in one of those img2 files (which means there's some decompilation work to be done), OR they're in the phone's ROM bootloader which means a very long road ahead. Pendorbound 16:45, 28 September 2007 (EDT)
It depends if the bootloader has been updated in this new deployment as well.. Really need to strip the flash off and dump its contents or get access with JTAG to the ARM core see what you can get access to. Normally you have to program a few registers such as the memory controllers etc to be able to access anything properly via the JTAG that is off chip. (ie: the Flash on the local bus or the DDR)
But its an interesting idea, the key should be in the boot loader for it to be able to extract and mount those images... What would need to happen is someone needs to dump the flash, reverse the bootloader and look through for where its loading or checking that bit... could possibly search for the AND with the bit setting (the encrypted or not).. again, need a flash programmer...then you want to solder down a ZIF socket, makes life easier..
A useful trick for 'poor mans flash reader' is to get a cheap CF or something about that same size and sometimes you can plonk the chip straight onto the cheap CF card and do raw read/wr.. [edit] Bootloader changed by 1.1.1?
If the phone will not restore to 1.02 after a 1.1.1 update, then is seems that the bootloader must have been modified. The modification could be simple - accept encrypted images only, for example. Or it could be complex, adding a signature requirement to the image file. A secure bootloader is probably on the horizon, even if not in 1.1.1
Once the iPhone has a secure bootloader in it, it seems that software access will become impossible without buffer overflows and similar tactics, or hardware access.
203.170.139.22 23:05, 28 September 2007 (EDT)
Interesting to note how Apple's efforts to lock down the iPhone parallel Sony's efforts with the PSP (Sony has been using a "secure" bootloader for some time now). It is at least encouraging to note that despite several years effort to stop hackers, the Sony PSP remains hackable without special "hardware access", albeit with more advanced methods than have been used so far on the iPhone.
We know that downgrading the firmware has always been impossible, since 1.0.1. So we can assume that Apple has a way of assuring the firmware is not an older one, without checking if its encrypted. So if we can learn how to downgrade from 1.0.2 to 1.0.1, the process might be similar from 1.1.1 to 1.0.2.
Has anyone looked at Users/(username)/Library/Lockdown in OS X?
UPDATE 10/2/07: These files exist back to iPhones I was connecting to my machine on 9/21, before 1.1.1 was released... So this is not a new file. It appears it contains the activation certificates/keys for the phone. [edit] iBEC.m68ap.RELEASE.dfu - could be the key
It seems that iBEC.m68ap.RELEASE.dfu (new file) is taking over the iPhone during 1.1.1 update, restarts the iPhone and loading the first ramdisk. Therefor iBEC.m68ap.RELEASE.dfu could hold the key for decrypting 022-3630-9.dmg.
From the #iPhone-dev: "from a supposed manual restore, iBEC comes first, and then a reboot. Then 022-3630-9.dmg is loaded. Which to me says iBEC is probably the bootstrap from 1.0.2 to 1.1.1, and there is no iBEC in 1.0.2".
"iTunes uploads iBEC. Phone reboots, then it starts asking for files instead of iTunes feeding them to the phone."
I assume you guys are seeing all the plaintext command info in the iBEC file, correct?
Confirmed, there seem to be some references to tftp calls to server 17.202.24.178 which resolves to apple.com and accepts connections. Why shouldn't they store the key on a server?
Console.app confirms this, but there are multiple failures when attempting to connect to that address. If they store the key on the server, you sniff the tcip/ip packets instead of the usb packets, should be fairly straight forward.
Is a network connection required during a normal 1.1.1 update (Assuming the 1.1.1 update file has already been downloaded)? What happens when one is not available?
10/2/07 MD: Interesting item in IBEC.m68ap.RELEASE.dfu (1.1.1) - at $0001706C to $00017074. Take a look at it with HexEdit. "GameOver". Already tried it as the DMG password, no luck.
10/3/07 Bgm: Looking at strings in iBEC, iBSS (also iBoot and LLB in 1.0.2 and bellow) it seems like all those files are very similiar in structure and are using the same library code. The library code seems to have some minimalistic command line debugging capabilities including memory read/write and even go to <address> commands (looks like it even can load scripts from tftp). It might be the case that loading one of those files in DFU mode will allow us to issue these commands. If memory peaking/pocking works this is a way to run unsigned code on any FW version. If someone provides me with IPHUC binary for Windows that supports DFU I would love to give it a try. [edit] Tools to get you going
windows tools:
1. OllyDbg : http://www.ollydbg.de/ 2. PEditor: http://www.softpedia.com/get/Programming/File-Editors/PEditor.shtml 3. USB Trace: - http://www.sysnucleus.com/USBTrace_Build_31_030907_Installer.exe = 14day trial 4. USBlyzer - Software USB Protocol Analyzer for Microsoft Windows 5. Network Trace: http://www.wireshark.org/
Some Info on ARM Secure Boot: http://www.arm.com/miscPDFs/15500.pdf ARM TrustZone Home: http://www.arm.com/products/esd/trustzone_home.html Two Phase Boot Loader Part #1: http://www.mobilehandsetdesignline.com/howto/softwareandsecurity/197800854 Two Phase Boot Loader Part #2: http://www.mobilehandsetdesignline.com/howto/softwareandsecurity/197801581
mac tools: ?????
Maybe try here: http://software.oxalyn.com/aemonitor/
This is an apple event monitor I have used in the past;seems to work. -Digitol-
This should help to monitor the trace between iphone and itunes - post info, comments etc [edit] Is it possible Apple use the same tech just like Software Update Service
[2] [edit] SHA1 and MD5 cracking
If one needs to crack a SHA1 or MD5 code this is a good place to start: http://nsa.unaligned.org/ [edit] Maybe the key was on the Iphone all along
Apple must have known that eventually the Iphone would be unlocked. What if they were planing for it all along and hide a key to re lock it?
---
In that case we find the code that does the decrypt, put it onto a 1.0.2 phone and let the phone decrypt the binaries for us. No need for the actual key TonyHoyle 04:18, 2 October 2007 (EDT) [edit] Approach change to think about
Build a bootloader that allows you to use iPhone with open source and no baseband. Reboot and you can use 1.1.1 signed application and make phone calls. Windows/Linux uses this approach. You already have the bootloader for 1.0.0 and 1.0.1 and 1.02. You merely need to boot to 1.02 or to 1.1.1. This might keep Apple happy and allow them to not hurt users in the process and Community will keep applications available. The seperation will be healthy and will lead to code on the open source side moving to the signed side as Apple permits (under their control for signautre) but allows it to function as the community develops it wouthout their approval if the developer doesnt care. The bootloader would load Community Iphone or Apple Signature Iphone.
Just some general thinking about the fastest way to get my brick out off the ground.
Brett in Riverside
Decryption
I can't understand one thing - when you have installed 1.1.1 - in Iphone flash, you already have decrypted system. You can take out flash and read it! Make dumps of this flash.
- The filesystem is still encrypted on the flash. Plus dumping flash is very hard.. you've got to destroy the phone for a start.. TonyHoyle 08:37, 2 October 2007 (EDT)
- Well, the filesystem on the flash, at that point, is no longer encrypted. But unless you can physically remove the flash chip and read it directly, you are out of luck. (Some people do have the facilities to remove the flash chip and read it, though. Still, the secpack isn't stored in the flash chip. And the secpack is vital to many steps of the unlocks to date).
Still another proposed approach: What about an ARM emulator with a fully functional 1.0.2 image, which you could then upgrade to 1.1.1 and then watch everything unfold as things get communicated and decrypted? How difficult would it be to write an emulator for an 1.0.2 iphone given that we have full access to one? And after upgrading it you would have a 1.1.1 emulator, ready for 1.2.1 :)
- Yeah some people are trying to get a iPhone emulator up and running. Don't know where they are at yet....
- One problem with the emulator approach is that it needs more than just an ARM instruction set emulator. The emulator needs knowledge about the overall system-level architecture of the iPhone. If you already knew enough about that architecture to write an emulator, you would already know enough to have an unlock/activate solution.
Cryptanalysis
Some people are eager to do cryptanalysis on some iphone firmware files, so I have provided the following code: [3] (works on linux)
Here is what to do:
- Find an unencrypted file, as well as its encrypted counterpart. Right now we hypothesize that applelogo.img2 is one such file, and here is what to do for this step:
o Extract the 1.0.2 firmware. Run Unpack_89001.0.c on applelogo.img2 and save the result as applelogo.img2.decrypted o Extract the 1.1.1 firmware. Run Unpack_89001.0.c on applelogo.img2 and save the result as applelogo.img2.encrypted
- Compile [4] and run it like this:
o aescompare applelogo.img2.encrypted applelogo.img2.decrypted keyfile
This will extract (and properly XOR) the last two cipherblocks from the encrypted and decrypted file, and will make a plaintext/ciphertext block pair that does not require the IV, but only the key, in order to be verified. Then, it will slide a 128-bit window through the keyfile (in byte boundaries) and use all possible (binary) keys to verify the block pair. If the key is found, it will be output.
In other words, if the encryption of applelogo.img2.encrypted is aes-128-cbc, and they 128-bit encryption key appears somewhere in the "keyfile", it will be found. I have tried this already with iBEC.m68ap.RELEASE.dfu as the keyfile and it's not there. This of course doesn't mean anything; the key could still be stored in hex/ascii (right now the program only tries raw binary), stored in reverse order (big-endian vs little-endian), etc., but if you are paranoid you can modify the aescompare.c source and handle all such cases.
If you perform binary/raw USB captures and you believe the key is somewhere there in the communication, throw it to the program! If you find another suitable pair (other than applelogo.img2), please document that as well. It could also be the case that the key is the hash of some other data, so not stored anywhere directly. Nevertheless this program is useful as we don't have to guess the IV!
Good luck!
---
Thanks for this. If the key is anything like the first it, it will probably be in reverse order.
---
I've been through every file in the firmwares (iPhone 111,102 and Touch 111) as well as everything in iTunes (just for kicks) and found nothing. Very likely the key is byte-swapped hex. Should be interesting to try again when we enable little-endian hex in this tool. --benanzo
A simplified version of this should get us usable key material to decrypt at least part of the ramdisk DMG. ... Pendorbound 13:16, 4 October 2007 (EDT)
Or not... Mindless mumblings of a deranged idiot (namely myself) removed. The known plaintext of the applelogo gains nothing. They almost certainly used CBC blocking with 128 bit AES. Knowing the plaintext gains nothing there. Pendorbound 13:56, 5 October 2007 (EDT)
The known plaintext does buy us something - we know when the decryption is done right. Cyt0plas 21:05, 16 October 2007 (EDT)
- AES is a block cipher, not a stream cipher. There is no keystream!
A potential attack approach
Back in the mists of time I used to crack games on Acorn (ARM-based) computers, removing their copy protection. The main tool I used for this was just a simple ARM debugger. I'd load code into memory, point the debugger to it, and look through the code. The debugger I used could single step, and also allow me to set breakpoints. Games on these computers would often be encrypted as part of their protection measures. Most of the time I'd let the game code itself do the decryption. On rare occasions I'd write tools to do decryption by effectively copying out the ARM routines that did the job. Once the relevant code sections had been decrypted I'd null out the code that did the decryption, save out the resultant new code, and just run it up.
If I had the time this is exactly the approach I'd be using with attempting to crack 1.1.1. I'd find, build, and install an ARM debugger on a 1.0.2 iPhone, copy over the relevant 1.1.1 files, and get cracking.
Doing the cracking on an iPhone itself will let you do things like use the Samsung encryption engine, or any other pieces of hardware that the iPhone upgrade code attempts to make use of. Attempting to disassemble and crack on a different platform (Mac or PC) doesn't make sense to me.
One other thing - there's a chance that earlier firmware versions (like the 1.0.2 upgrade) contains within it keys relevant for decoding the 1.1.1 update.
If what u say is true than maybe u should try to upgrade from firmware 1.0.1, if it can decode the firmware 1.1.1 update, we can have a try to find the keys in 1.0.1 if it does not we will be sure the key is in firmware 1.0.2. good luck
Just to add to the 1.0.1 vs. 1.0.2 key theory: it might depend on the iTunes version as well. The prw-7.4.1 versions do not offer the 1.1.1 upgrade. What if the 1.1.1 decryption happens in iTunes?
Could we add a custom kext to a 1.0.2 iPhone or is the kernel already signed there? If we could cook up the right kext, maybe we could trap & emulate the upgrade process. [edit] iTunes should have the key [edit] Added 10.04.2007 - socketface
IMPORTANT
1. The main reason that iTunes prior to 7.4.1 does not work is the protocol. It has changed from Push <=> Progress to iTunes initiating the update and turning into Server <=> Request/Send Progress Back. Everything, from the Command Dictionaries to performing disk operations (i.e. mount, ditto, umount, etc) has changed. 2. The advice that you speak of that iTunes provides is a link that it gets from the version file @ itunes.com/version. It has the same name as the .ipsw, but with a .ipd, which stands for iPod Documentation. It has a read me file in it that is displayed to you in the popup I give Apple permission to rape my in the *** dialog.
iPhone 1.1.1 restore file trace
Ok, on this page you can see the iPhone 1-1-1 restore file trace, this restore is made on a iPhone that came with 1.1.1 install by default.
More on Plist file found in ~/Library/Lockdown
These are most likely just used for the ssl connections with iTunes. Which means they have some use, but probably don't directly relate to decrypting the firmware.
Reorg
I want to try and clear out a lot of the discussion here (there is so much content here, I can't do diffs anymore), and organize it into something a little more manageable. I created some possible topics on the main page. We should mirror them here, and clean out a lot of the duplication (and off topic, and dead-ends) here
The entropy analysis and the USB logs are useful and cool, but I think they might benefit from having their own pages. [edit] Possible App That Mimics 1.0.2 -> 1.1.1 Update
Do we have much information about the update process on the iPhone from 1.0.2 to 1.1.1? I'm wondering if it's possible to write an app for 1.0.2 that mimics the normal update process but either exports the decrypted files or leaves executable code on 1.1.1 after the update process.
If we gain a better understanding of the update process I could see this as a real possibility. Is there anything I'm forgetting?
Might have to do this as a custom kext on the 1.0.2 phone.
- If we want to master the update process we should accomplish these steps on the 1.0.2 platform. Maybe it's already done - maybe not. Please check mark if we do.
1. Understanding the 1.0.2 upload sequence 2. Replicating the 1.0.2 upload sequence by our code, so we can control/intervene at each steps. 3. Creating bad signature on 1.0.2 firmware components, observing if signature is used or not. 4. Uploading new signature check certificates to jail-broken 1.0.2, re-signing firmware files with our own CA 5. Uploading tampered encryption content, while having valid signature, observing if further checks are used or not. 6. Uploading new encryption keys to jail-broken 1.0.2 (if in flash or ramdisk) and testing valid 1.0.2 re-encrypted images and our own signature.
8900 Boot .pem files on 1.1.1 iPhone filesystem
I don't know enough about encryption / certificates to know if this is relevant - please delete if not.
In Erica's read-only access of the 1.1.1 iPhone filesystem, there are a group of files in /System/Library/Lockdown *on the iPhone* named: SBOOT_S5L8702.pem SBOOT_S5L8702_DEV.pem SBOOT_S5L8900.pem SBOOT_S5L8900_DEV.pem
The last two both reference the '8900' code and appear to have a device key and a host key - not sure if these are of any use, but they are now available for 1.1.1 as anyone can pull them off the read-only filesystem. Perhaps related to the boot process in some way? -cyberface
- The same file names exist under 1.0.2 filesystem. These are certificates, that contain public keys. It's only good to verify the signature on a signed 8900 file. If we replace these file with our own that's the real deal. Reading them is not helping at all.
How was the key found?
I see from the article page that the key for the -17 file was found. But there is no mention in the Talk page about how it was accomplished.
BTW, congrats to the team on finding it!
-- Yes, Can anyone tell the processor to find the Firmware 1.1.1 key ? -- And how about the ramdisk key ?
Can anyone please share the info ? where was the key ? what mode was the aes ? just curios.
