S5L File Formats

IMG2
This was the file format used prior to iOS 2.0. For iOS 1.1.x, IMG2 files were encrypted with Key 0x837. IMG2 files can only be parsed by an iBoot in firmwares prior to iOS 2.0 beta 3, or the S5L8900 VROM. The S5L8720 and newer bootroms have no support for it.

8900
This is the file format used by the S5L8900. Usually this wraps around an IMG2 file. It can only be parsed by an iBoot in a firmware version less than 2.0 beta 3, or the S5L8900 VROM. The S5L8720 has no support for it.

Header
typedef struct { uchar magic[4];              // string "8900" uchar version[3];            // string "1.0" uint8 format;                // plaintext format is 0x4, encrypted with GID-key format is 0x3, // boot plaintext is 0x2, boot encrypted with UID-key is 0x1. uint32 unknown1; uint32 sizeOfData;           // size of data (ie, filesize - header(0x800) - footer signature(0x80) - footer certificate(0xC0A)) uint32 footerSignatureOffset; // offset to footer signature uint32 footerCertOffset;     // offset to footer certificate, from end of header (0x800) uint32 footerCertLen; uchar salt[0x20];            // a seemingly random salt (an awfully big one though... needs more attention) uint16 unknown2; uint16 epoch;                // the security epoch of the file uchar headerSignature[0x10]; // encrypt(sha1(header[0:0x40])[0:0x10], key_0x837, zero_iv) uchar padding[0x7B0]; } Apple8900Header;

Resources
The dev team's wiki page on the topic

IMG3
This is the replacement for the IMG2 file format in iOS 2.0. The S5L8720 (and newer) bootroms can understand this by default, but WTF 2.0 must be uploaded to the DFU Mode of an S5L8900 that has code in it to parse IMG3 files, or the S5L8900 will not be able to understand them.

Header
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;

Tag Format
unsigned int magic; unsigned int total_length;  //data_length+0xC unsigned int data_length;

Tags
VERS: Version SDOM: Security Domain PROD: Processor to be used with. CHIP: Chip to be used with. "0x8900" for S5L8900 and "0x8720" for S5L8720. Instead of there being a check against some piece of hardware, whatever is verifying this (bootrom / iBoot / LLB / etc.) has this hardcoded in. BORD: Board to be used with KBAG: contains the KEY and IV required to decrypt encrypted with the GID-key SHSH: RSA encrypted SHA1 hash of the file CERT: Certificate ECID: Exclusive Chip ID TYPE: Type of IMG3 (like 0x6C6F676F for logo) DATA: actual content SEPO: Security Epoch

Encryption
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.

iBoot has support for AES-192 and AES-256 also, but the former remains unused. In the current method, iBoot will always use the first 16 bytes as the IV, then the remaining 16 (AES-128), 24 (AES-192, unused), or 32 (AES-256) bytes for the key.

Resources
cmw's IMG3 Unpacker