Previously in 24: Jack Bauer is on the track of iPhone encryption and discovers that a bunch of terrorists already crack Apple algorithms using an undercover agent located in a inoffensive recovery tool. While Jack shoot some kneecaps CTU still doesn't know exactly which encryption algorithms Apple use in their iPhones... Did Nadia will finally approve an interrogation technique that might prove fatal to iPods ?
Day 2 : 8:00 PM - 9:00 PM (And back to serious things :D) I continue to look for informations about iPhone encryption (and try to link them with nanos): The iPhone firmware located in the .dmg file is encrypted using FileVault (http://www.apple.com/fr/macosx/features/filevault/) an Apple branded encryption system for HFS+ partitions (http://developer.apple.com/technotes/tn/tn1150.html#VolumeHeader). I'm unable to find any clear specification about .dmg files but, in our case: - Clear .dmg seems to enclose an HFS+ partition (.dmg start with an header and some zero padding bytes after we've got a HFS+ header). - Crypted .dmg start with an different header and payload data seems to be encrypted. So, the iPhone firmware is encrypted with the FileVault technology. And the crypted data is enclosed in the .dmg file (which also contains some cryptographic informations). Ralf-Philipp Weinmann, Jacob Appelbaum, and Christian Fromme did a FileVault reverse engineering a while ago (before iPhone I mean): http://crypto.nsa.org/vilefault/ http://crypto.nsa.org/vilefault/23C3-VileFault.pdf They wrote vfdecrypt as a part of their work. A modified version of this tool was used by iPhone hackers to decrypt the .dmg firmware. They only change a few things (recovering more data from headers, keys format, ...) because the firmware .dmg (seems to) use FileVault headers. The header is: typedef struct { unsigned char sig[8]; uint32_t version; uint32_t enc_iv_size; uint32_t unk1; uint32_t unk2; uint32_t unk3; uint32_t unk4; uint32_t unk5; unsigned char uuid[16]; uint32_t blocksize; uint64_t datasize; uint64_t dataoffset; uint8_t filler1[0x260]; uint32_t kdf_algorithm; uint32_t kdf_prng_algorithm; uint32_t kdf_iteration_count; uint32_t kdf_salt_len; /* in bytes */ uint8_t kdf_salt[32]; uint32_t blob_enc_iv_size; uint8_t blob_enc_iv[32]; uint32_t blob_enc_key_bits; uint32_t blob_enc_algorithm; uint32_t blob_enc_padding; uint32_t blob_enc_mode; uint32_t encrypted_keyblob_size; uint8_t encrypted_keyblob[0x30]; } cencrypted_v2_pwheader; Header is 832 bytes long (including unknown fields). Our Nano headers doesn't look like to be the same as the FileVault one's. That doesn't mean nano 2g aren't encrypted with FileVault algorithms because FileVault exist before nano2g come to stores and I really think Apple doesn't have time to build from scratch a strong encryption system when they got a working one (Or Apple hire a bunch of trainees in their crypto labs in summer 2k6 :) ). Summary: - iPhone firmware use FileVault encryption. - iPod Nano 2g firmware doesn't seems to use exactly the same FileVault system... - ... but nano 2g probably use similar algorithms. And, last minute thoughts, maybe nano2g use OLD versions of FileVault (maybe the release version of FV when nano2g was developped). Enjoy, JD. _______________________________________________ Linux4nano-dev mailing list Linux4nano-dev@gna.org https://mail.gna.org/listinfo/linux4nano-dev http://www.linux4nano.org
