The IMG4 file format is a replacement for the IMG3 file format and is used on devices running a 64-bit processor (A7 or newer). It's also used across the entire Apple Watch series, in both the armv7k and arm64_32 processors. Just like the old IMG3 file format, it is used to contain files used by iOS' secure boot chain (im4p files), signatures of those files (im4m/ApImg4Ticket
files) and some info used in the Restore Process ("IM4R
" can be found in MobileDevice framework). A complete IMG4 file is the result of concatenating the payload, manifest and restore info (aka boot nonce) in one file and wrapping it with an IMG4 header.
Structure[edit]
Contrary to the IMG3 file format where a custom binary format was used, IMG4 files (and their payloads) are DER encoded ASN.1 objects. The reason for Apple's choice of ASN.1/DER encoding over their own binary Property List (PList) file format is unknown.
sequence [
0: string "IMG4"
1: payload - IMG4 Payload, IM4P
2: [0] (constructed) [
manifest - IMG4 Manifest, IM4M
]
]
IMG4 Payload[edit]
Payload contains the actual content of the file. IMG4 format allows to store payload in a separate file with im4p extension. im4p files are used more often than complete IMG4 files. Payload is structured as follows:
sequence [ 0: string "IM4P" 1: string type - ibot, rdsk, sepi, ... 2: string description - 'iBoot-1940.1.75' 3: octetstring - the encrypted/raw data 4: octetstring - containing DER encoded KBAG values (optional) sequence [ sequence [ 0: int: 01 1: octetstring: iv 2: octetstring: key ] sequence [ 0: int: 02 1: octetstring: iv 2: octetstring: key ] ] ]
Item 0 in the KBAG sequences is 01 for the production KBAG and 02 for the development KBAG. Development KBAGs can only be decrypted with "development" devices (Apple-internal prototypes or demoted production devices), since they use a different GID. The result of that decryption is the same iv+key for either dev or prod KBAGs.
IMG4 Manifest[edit]
A.k.a. IM4M. Contains signature for one or multiple IMG4 payloads. Manifests are designed in a way that they can be stored separately from an IMG4 file or be a part of one. An example of an IMG4 manifest is ApImg4Ticket. Each IMG4 manifest is made of tags structured as follows (content = DER encoded object):
[type] (private) [ - DER tag's class is the type of the tag (4 bytes) encoded as a big-endian integer sequence [ string type - type of the tag, 4 bytes content - content of the tag ] ]
Manifest structure (tag <type> = tag of type 'type'):
sequence [ 0: string "IM4M" 1: integer version - currently 0 2: set [ tag MANB [ - manifest body set [ tag MANP [ - manifest properties set [ tag <manifest property> [ content ] ... - tags, describing other properties ] ] tag <type> [ - ibot, illb, sepi, krnl, NvMR, bbcl... set [ tag <tag property> [ content ] ... ] ] ... - tags for other images ] ] ] 3: octet string signature 4: sequence [ - containing certificate chain (arbitrary number of certificates) certificates ]