Initially used in iPhone OS 2.0 beta 4, IMG 3 files were created to address the problems with the older 8900/IMG2 combination. This format was used on all devices using 32-bit processors (S5L8955 (A6X) and earlier). All 64-bit processors (S5L8960 (A7) and newer) use the IMG4 format.
Problems with IMG2
The biggest problem with the 8900/IMG2 format combination was that they all were encrypted with the same key: Key 0x837. IMG3 addressed this glaring security hole by encrypting each payload with its own IV/key. This IV/key pair is stored in the file with the payload, but is itself encrypted with the GID key, a key shared by all devices with the same processor. The GID key is burned into the processor and cannot be accessed directly; Instead, every time the key is needed, the processor will be instructed to use it (at no time providing it to the kernel or user code).
File Format
Despite requiring a bit more to process, at least when compared to the 8900/IMG2 combination, the IMG3 file is quite simple. It consists of a 20 byte header followed by a series of tags, one after the other.
Img3 { 0 uint32 magic // '3gmI' ('Img3' in little endian) 4 uint32 fileSize 8 uint32 tagsSize // size of file minus 0x14 header C uint32 shshTagOffset 10 uint32 ident // appears to be the same as the TYPE tag's contents 14 Img3Tag[] tags }
Tags
A "tag" is a block of data consisting of a "magic," some info about its size, its (possibly encrypted) contents, and some padding. Each tag serves a unique purpose; For example, the KBAG
tag contains the IV and key to decrypt the DATA
tag's contents. Not every known tag is present in every firmware file.
Img3Tag { 0 uint32 magic 4 uint32 size // including header and padding 8 uint32 dataSize C uint8[] data // `dataSize` bytes ???? uint8[] padding // `size - dataSize - 0xC` bytes }
List of Known Tags
There exist many different tags, each with their own purpose:
BORD
: Board to be used withCERT
: CertificateCEPO
: Chip epochCHIP
: Chip to be used withDATA
: IMG3 payloadECID
: "Exclusive Chip ID"KBAG
: The (encrypted) IV/key used to decrypt the payloadNONC
: Nonce used when the file was signedOVRD
PROD
: Production modeRAND
SALT
SDOM
: Security domainSEPO
: Security epochSHSH
: Encrypted hash of the payloadTYPE
: Type of image; contains the same value as that in the header'sident
fieldVERS
: iBoot version of the image