The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "IMG3 File Format"
(→Tags: added ECID tag information) |
|||
(32 intermediate revisions by 11 users not shown) | |||
Line 1: | Line 1: | ||
+ | The '''IMG3''' file format was introduced with [[iOS|iPhone OS]] 2.0b4 to replace the broken [[S5L File Formats|IMG2 format]]. This format is used on all devices with an [[S5L8920]] or older; [[S5L8960|A7]] and newer devices use [[IM4P File Format|IM4P]] and [[IMG4 File Format|IMG4]] files. |
||
− | This is the replacement for the [[IMG2 File Format]] in 2.0 firmware. |
||
− | == |
+ | ==Encryption== |
+ | Apple got smarter this time, requiring the Hardware AES engine to be run per file. Decrypt the [[KBAG]] tag data with the [[GID Key]] to get the key and IV, and use those to decrypt the [[DATA]] section of the firmware file. |
||
− | struct Img3 { |
||
− | unsigned int magic; // fourcc="IMG3" |
||
− | unsigned int fullSize; // full size of fw image |
||
− | unsigned int sizeNoPack; // size of fw image without header |
||
− | unsigned int sigCheckArea; // although that is just my name for it, this is the |
||
− | // size of the start of the data section (the code) up to |
||
− | // the start of the RSA signature (SHSH section) |
||
− | unsigned int iden; // identifier of image, used when bootrom is parsing images |
||
− | // list to find LLB (illb), LLB parsing it to find iBoot (ibot), |
||
− | // etc. |
||
− | |||
− | } typedef Img3; |
||
+ | In the current method, iBoot will always use the first 16 bytes of the [[KBAG]] as the IV, then the remaining 16 (aes-128, used with [[S5L8900]] and [[S5L8720]]), 24 (aes-192), or 32 (aes-256, used with [[S5L8920]]) bytes for the key. |
||
− | ==Tag Format== |
||
− | unsigned int magic; |
||
− | unsigned int total_length; //data_length+0xC |
||
− | unsigned int data_length; |
||
− | == |
+ | == Contents == |
+ | All numbers are stored in [[wikipedia:Endianness#Little-endian|little endian]] byte order; this includes the magic ''numbers'' (<code>magic</code> and <code>ident</code>). |
||
− | VERS: Version |
||
+ | typedef struct img3File { |
||
− | SEPO: Unknown |
||
+ | uint32_t magic; // ASCII_LE("Img3") |
||
− | PROD: Processor to be used with. |
||
+ | uint32_t fullSize; // full size of fw image |
||
− | CHIP: Chip to be used with. "0x8900" for [[S5L8900]] and "0x8720" for [[n72ap|S5L8720]]. Instead of there being a check against some piece of hardware, whatever is verifying this (bootrom / iBoot / LLB / etc.) has this hardcoded in. |
||
+ | uint32_t sizeNoPack; // size of fw image without header |
||
− | BORD: Board to be used with |
||
+ | uint32_t sigCheckArea;// although that is just my name for it, this is the |
||
− | [[KBAG]]: contains the KEY and IV required to decrypt encrypted with the [[GID-key]] |
||
+ | // size of the start of the data section (the code) up to |
||
− | SHSH: RSA encrypted SHA1 hash of the file |
||
+ | // the start of the RSA signature (SHSH section) |
||
− | CERT: Certificate |
||
+ | uint32_t ident; // identifier of image, used when bootrom is parsing images |
||
− | ECID: Electronic Chip ID unique to every iPhone 3GS. |
||
+ | // list to find LLB (illb), LLB parsing it to find iBoot (ibot), |
||
+ | // etc. |
||
+ | img3Tag tags[]; // continues until end of file |
||
+ | }; |
||
+ | typedef struct img3Tag { |
||
− | ==Signature Check== |
||
+ | uint32_t magic; // [[#Tags|see below]] |
||
− | Decryption is done using the modulus at cert + 0xA15 |
||
+ | uint32_t totalLength; // length of tag including "magic" and these two length values |
||
− | 0xC to HSHS is SHAed |
||
+ | uint32_t dataLength; // length of tag data |
||
+ | uint8_t data[dataLength]; |
||
+ | uint8_t pad[totalLength - dataLength - 12]; // Typically padded to 4 byte multiple |
||
+ | }; |
||
− | == |
+ | == Tags == |
+ | Due to being written in little-endian byte order, these tags are actually backwards when written to the file (e.g. <code>VERS</code> is stored as <code>S R E V</code>). |
||
− | Apple got smarter this time, requiring the Hardware AES engine to be run per file. Decrypt the [[KBAG]] tag data (0x20 byte?) with the hardware AES engine and get the 0x10 byte IV and the 0x10 byte KEY. |
||
+ | [[VERS]]: [[iBoot]] version of the image |
||
+ | [[SEPO]]: Security Epoch |
||
+ | [[SDOM]]: Security Domain |
||
+ | [[PROD]]: Production Mode |
||
+ | [[CHIP]]: Chip to be used with. example: <code>0x8900</code> for [[S5L8900]]. |
||
+ | [[BORD]]: Board to be used with |
||
+ | [[KBAG]]: Contains the IV and key required to decrypt; encrypted with the [[GID Key]] |
||
+ | [[SHSH]]: RSA encrypted SHA1 hash of the file |
||
+ | [[CERT]]: Certificate |
||
+ | [[ECID]]: Exclusive Chip ID unique to every device |
||
+ | [[TYPE]]: Type of image, should contain the same string as the header's <code>ident</code> |
||
+ | [[DATA]]: Real content of the file |
||
+ | [[Nonce|NONC]]: [[Nonce]] used when file was signed. |
||
+ | [[CEPO]]: Chip epoch |
||
+ | [[OVRD]]: |
||
+ | [[RAND]]: |
||
+ | [[SALT]]: |
||
+ | ==Signature Check== |
||
− | iBoot has support for aes-192 and aes-256 also. In the current method, iBoot will always use the first 16 bytes as the IV, then the remaining 16 (aes-128, current method), 24 (aes-192), or 32 (aes-256) bytes for the key. |
||
+ | Decryption is done using the modulus at cert + 0xA15 |
||
+ | 0xC to [[SHSH]] is SHAed |
||
+ | [[Category:File Formats]] |
||
− | ==Resources== |
||
− | [http://www.iphonelinux.org/img3.tar.gz cmw's IMG3 Unpacker] |
Latest revision as of 18:35, 2 March 2023
The IMG3 file format was introduced with iPhone OS 2.0b4 to replace the broken IMG2 format. This format is used on all devices with an S5L8920 or older; A7 and newer devices use IM4P and IMG4 files.
Contents
Encryption
Apple got smarter this time, requiring the Hardware AES engine to be run per file. Decrypt the KBAG tag data with the GID Key to get the key and IV, and use those to decrypt the DATA section of the firmware file.
In the current method, iBoot will always use the first 16 bytes of the KBAG as the IV, then the remaining 16 (aes-128, used with S5L8900 and S5L8720), 24 (aes-192), or 32 (aes-256, used with S5L8920) bytes for the key.
Contents
All numbers are stored in little endian byte order; this includes the magic numbers (magic
and ident
).
typedef struct img3File { uint32_t magic; // ASCII_LE("Img3") uint32_t fullSize; // full size of fw image uint32_t sizeNoPack; // size of fw image without header uint32_t sigCheckArea;// although that is just my name for it, this is the // size of the start of the data section (the code) up to // the start of the RSA signature (SHSH section) uint32_t ident; // identifier of image, used when bootrom is parsing images // list to find LLB (illb), LLB parsing it to find iBoot (ibot), // etc. img3Tag tags[]; // continues until end of file };
typedef struct img3Tag { uint32_t magic; // see below uint32_t totalLength; // length of tag including "magic" and these two length values uint32_t dataLength; // length of tag data uint8_t data[dataLength]; uint8_t pad[totalLength - dataLength - 12]; // Typically padded to 4 byte multiple };
Tags
Due to being written in little-endian byte order, these tags are actually backwards when written to the file (e.g. VERS
is stored as S R E V
).
VERS: iBoot version of the image SEPO: Security Epoch SDOM: Security Domain PROD: Production Mode CHIP: Chip to be used with. example:0x8900
for S5L8900. BORD: Board to be used with KBAG: Contains the IV and key required to decrypt; encrypted with the GID Key SHSH: RSA encrypted SHA1 hash of the file CERT: Certificate ECID: Exclusive Chip ID unique to every device TYPE: Type of image, should contain the same string as the header'sident
DATA: Real content of the file NONC: Nonce used when file was signed. CEPO: Chip epoch OVRD: RAND: SALT:
Signature Check
Decryption is done using the modulus at cert + 0xA15 0xC to SHSH is SHAed