Difference between revisions of "S5L File Formats"

From The iPhone Wiki
Jump to: navigation, search
m (Tags: wikified tags)
 
(17 intermediate revisions by 5 users not shown)
Line 1: Line 1:
==IMG2==
+
== IMG2 ==
This was the file format used prior to 2.0 firmware. Post 1.1.1, it was encrypted with [[Key 0x837]]. It can only be parsed by an iBoot in a firmware version less than beta 3, or the [[S5L8900]] [[VROM]]. The [[S5L8720]] has no support for it.
+
This was the file format used prior to iPhone OS 2.0. For iPhone OS 1.1.x, IMG2 files were encrypted with [[AES Keys|Key 0x837]]. IMG2 files can only be parsed by an [[iBoot]] in firmwares prior to iPhone OS 2.0 beta 3, or the [[S5L8900]] [[VROM]]. The [[S5L8720]] and newer [[bootrom]]s have no support for it.
   
==8900==
+
== 8900 ==
  +
This is the file format used by the [[S5L8900]]. Usually this wraps around an [[#IMG2|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]] and newer have no support for it.
 
  +
=== Header ===
This is the file format used by the [[S5L8900]]. Usually this wraps around an [[IMG2 File Format|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 {
 
typedef struct {
uchar magic[4]; // string "8900"
+
uint8 magic[4]; // string "8900"
uchar version[3]; // string "1.0"
+
uint8 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.
+
uint8 format; // plaintext format is 0x4, encrypted with [[AES Keys#Key 0x837|Key 0x837]] format is 0x3,
  +
// boot plaintext is 0x2, boot encrypted with [[UID-key]] is 0x1.
uint32 unknown1;
 
  +
uint32 unknown1;
uint32 sizeOfData; // size of data (ie, filesize - header(0x800) - footer signature(0x80) - footer certificate(0xC0A))
 
  +
uint32 sizeOfData; // size of data (i.e: file size - header(0x800) - footerSig(0x80) - footerCert(0xC0A))
uint32 footerSignatureOffset; // offset to footer signature
 
  +
uint32 footerCertOffset; // offset to footer certificate, (relative to end of header)
uint32 footerCertLen;
 
  +
uint32 footerCertLen;
uchar salt[0x20]; // a seemingly random salt (an awfully big one though... needs more attention)
 
  +
uint8 salt[0x20]; // a seemingly random salt for the signature
uint16 unknown2;
 
  +
uint16 unknown2;
uint16 epoch; // the security epoch of the file
 
  +
uint16 epoch; // the security epoch of the file
uchar headerSignature[0x10]; // encrypt(sha1(header[0:0x40])[0:0x10], key_0x837, zero_iv)
 
  +
uint8 headerSignature[0x10]; // encrypt(sha1(header[0:0x40])[0:0x10], key_0x837, zero_iv)
uchar padding[0x7B0];
 
uint32 footerCertOffset; // offset to footer certificate, from end of header (0x800)
+
uint32 footerSignatureOffset; // offset to footer signature (relative to end of header)
  +
uint8 padding[0x7B0]; // pad to 0x800 (i.e: 2 KiB)
 
} Apple8900Header;
 
} Apple8900Header;
   
  +
== [[IMG3 File Format|IMG3]] ==
===Resources===
 
  +
This is the replacement for the [[#IMG2|IMG2 file format]] in iPhone OS 2.0. The [[S5L8720]] (and newer) bootroms can understand this by default, but [[WTF#Version 2|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.
[http://wikee.iphwn.org/s5l8900:8900_format The dev team's wiki page on the topic]
 
  +
=== Header ===
 
  +
typedef struct {
==IMG3==
 
  +
uint8 magic[4]; // string "IMG3"
This is the replacement for the [[IMG2 File Format]] in 2.0 firmware. The [[VROM (S5L8720)|S5L8720 Bootrom]] 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.
 
  +
uint32 fullSize; // full size of fw image
 
  +
uint32 sizeNoPack; // size of fw image without header
===Header===
 
  +
uint32 sigCheckArea; // although that is just my name for it, this is the
struct Img3 {
 
  +
// size of the start of the data section (the code)
unsigned int magic; // fourcc="IMG3"
 
unsigned int fullSize; // full size of fw image
+
// up to the start of the RSA signature (SHSH section)
unsigned int sizeNoPack; // size of fw image without header
+
uint32 iden; // identifier of image, used when bootrom is parsing images
unsigned int sigCheckArea; // although that is just my name for it, this is the
+
// list to find LLB (illb), LLB parsing it to find
// size of the start of the data section (the code) up to
+
// iBoot (ibot), etc.
// 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;
+
} AppleImg3Header;
  +
=== Tag Header ===
 
  +
typedef struct {
===Tag Format===
 
  +
uint8 magic[4]; // one of the tags [[#Tags|below]] (stored in little-endian order)
unsigned int magic;
 
  +
uint32 totalLength; // (dataLength + sizeof(AppleImg3TagHeader))
unsigned int total_length; //data_length+0xC
 
  +
uint32 dataLength; //
unsigned int data_length;
 
  +
} AppleImg3TagHeader
 
===Tags===
+
=== Tags ===
 
[[VERS]]: Version
 
[[VERS]]: Version
 
[[SDOM]]: Security Domain
 
[[SDOM]]: Security Domain
  +
[[PROD]]: Production Mode, intended to determine if the image is for a dev or production fused device. Like CHIP, whatever verifies this has the intended value hardcoded. If the device is development fused, the check is skipped.
[[PROD]]: Processor to be used with.
 
[[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.
+
[[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.
 
[[BORD]]: Board to be used with
 
[[BORD]]: Board to be used with
[[KBAG]]: contains the KEY and IV required to decrypt encrypted with the [[GID-key]]
+
[[KBAG]]: contains the KEY and IV required to decrypt encrypted with the [[GID Key]]
 
[[SHSH]]: RSA encrypted SHA1 hash of the file
 
[[SHSH]]: RSA encrypted SHA1 hash of the file
 
[[CERT]]: Certificate
 
[[CERT]]: Certificate
 
[[ECID]]: Exclusive Chip ID
 
[[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 bytes?) with the hardware AES engine and get the 0x10 byte [[wikipedia:Initialization vector|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.
===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.
 
   
  +
== Resources ==
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.
 
  +
* [http://www.jbfaq.com/article.asp?id=70 cmw's IMG3 Unpacker]
  +
* [http://wikee.iphwn.org/s5l8900:8900_format The iPhone Dev Team on 8900]
   
  +
[[Category:File Formats]]
===Resources===
 
[http://www.iphonelinux.org/img3.tar.gz cmw's IMG3 Unpacker]
 

Latest revision as of 17:01, 12 July 2017

IMG2

This was the file format used prior to iPhone OS 2.0. For iPhone OS 1.1.x, IMG2 files were encrypted with Key 0x837. IMG2 files can only be parsed by an iBoot in firmwares prior to iPhone OS 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 and newer have no support for it.

Header

typedef struct {
    uint8  magic[4];              // string "8900"
    uint8  version[3];            // string "1.0"
    uint8  format;                // plaintext format is 0x4, encrypted with Key 0x837 format is 0x3,
                                  //   boot plaintext is 0x2, boot encrypted with UID-key is 0x1.
    uint32 unknown1;
    uint32 sizeOfData;            // size of data (i.e: file size - header(0x800) - footerSig(0x80) - footerCert(0xC0A))
    uint32 footerSignatureOffset; // offset to footer signature (relative to end of header)
    uint32 footerCertOffset;      // offset to footer certificate, (relative to end of header)
    uint32 footerCertLen;
    uint8  salt[0x20];            // a seemingly random salt for the signature
    uint16 unknown2;
    uint16 epoch;                 // the security epoch of the file
    uint8  headerSignature[0x10]; // encrypt(sha1(header[0:0x40])[0:0x10], key_0x837, zero_iv)
    uint8  padding[0x7B0];        // pad to 0x800 (i.e: 2 KiB)
} Apple8900Header;

IMG3

This is the replacement for the IMG2 file format in iPhone OS 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

typedef struct {
    uint8  magic[4];     // string "IMG3"
    uint32 fullSize;     // full size of fw image
    uint32 sizeNoPack;   // size of fw image without header
    uint32 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 iden;         // identifier of image, used when bootrom is parsing images
                         //   list to find LLB (illb), LLB parsing it to find
                         //   iBoot (ibot), etc.
 
} AppleImg3Header;

Tag Header

typedef struct {
    uint8  magic[4];    // one of the tags below (stored in little-endian order)
    uint32 totalLength; // (dataLength + sizeof(AppleImg3TagHeader))
    uint32 dataLength;  // 
} AppleImg3TagHeader

Tags

VERS: Version
SDOM: Security Domain
PROD: Production Mode, intended to determine if the image is for a dev or production fused device. Like CHIP, whatever verifies this has the intended value hardcoded. If the device is development fused, the check is skipped.
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 bytes?) 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