Decryption can be performed by running the following in a command line application (make sure you have the img4lib): With S5L8960, Apple changed the file format to use IMG4 files instead of IMG3. For those that don't know how AES256 works, this now means that the first 0x10 bytes are the IV, and the remaining 0x20 bytes (not 0x10 anymore!) are the key.
CPFMs of lower than 01 are normally prototypes in the DVT stage or lower. The first KBAG has an identifier in it's header indicating that it is to be decrypted with the GID Key on SoCs that have a CPFM of 03 (Production & Secure), and the second seems to be for decrypting with SoCs that have a CPFM of 01 or 00 (Development & Secure or Development & Insecure), as the CPFM seems to change which GID Key it uses. They have two KBAGs, which use AES-256 instead of the S5L8900 and S5L8720 that are using AES-128 still. The iPhone 3GS firmware files are interesting. You can decrypt those on a 2.2.1 aes setup no problem whatsoever. Apple incorrectly assumed that by encrypting iBEC and iBSS they were being sly. Once you have decrypted the KBAG, decryption using the keys in it is the same as above.īusiness as usual, but keys and IVs have to be decrypted on the device still, unlike with the new S5L8900 KBAGs. This makes obtaining the keys for this version dead simple. With the 3.0 Golden Master (7A341) and 3.0.1, Apple messed up and, instead of using the application processor-specific GID Key, used a pseudo-GID of 5f650295e1fffc97ce77abd49dd955b3 to encrypt the KBAG. A discussion on extracting those files is available on the talk page. This results in some zero sized files in the disk image if you don't use Snow Leopard or newer. With 3.0 (what beta?), Apple began using Snow Leopard to package the ramdisks. OS X Snow Leopard introduced the HFS compressed disk image. If input was a ramdisk, output will be a mountable HFS filesystem. Once decrypted, you will be left with either a raw binary blob. The IV and key for a specific firmware is available through the Firmware Keys page or from the ist file underneath PwnageTool's /FirmwareBundles folder. In order to decrypt an IMG3 file, open a console and run one of the commands depending on your program choice:
DECRYPTEDFILE DMG CODE
His code was later implemented into xpwntool. This format was soon reversed and img3decrypt was created by Steven Smith stroughtonsmith) on 21 August 2008. With the fourth beta of 2.0, Apple introduced the IMG3 file format, replacing the broken IMG2 file format. Once decrypted, you will be left with either an IMG2 file or a mountable HFS filesystem. To decrypt, open up a console and run openssl(1) : The ramdisk is encrypted using AES-128 with cipher block chaining (CBC). Once the header is stripped, you need to do the actual decryption.
You can do this with either a hex editor, or open up a console and run dd(1) :ĭd if= input of= stripped bs=512 skip=4 conv=sync In order to decrypt them, you need to remove the 2048 byte (2 KiB) 8900 header from, then decrypt the resulting file. The decryption key wasn't obscured however, and a simple analysis of iBoot by Zibri revealed the 0x837 key. With the release of the iPod touch, Apple added a layer of encryption around the IMG2. Once the header has been stripped, you will be left with either an IMG2 file or a mountable HFS filesystem. You can do this with either a hex editor, or open up a console and run dd(1) :ĭd if= input of= output bs=512 skip=4 conv=sync So, in order to use them, all you need to do is remove the 2048 byte (2 KiB) 8900 header from the file. With the release of the iPhone, the IMG2 files weren't encrypted. The listed console commands are applicable to the IMG2 or IMG3 files under /Firmware also. This section details the decryption of the ramdisks in an IPSW file.
0 kommentar(er)
