SB File Format
SB Loader

SB file format definitions. More...

Collaboration diagram for SB File Format:

## Data Structures

struct | sb_version_t
| Version struct used in SB files. More...
struct | sb_image_header_t
| Header for the entire boot image. More...
struct | sb_dek_dictionary_entry_t
| Entry in sb_dek_dictionary_t. More...
struct | sb_dek_dictionary_t
| The DEK dictionary always follows the image header, in the next cipher block. More...
struct | sb_section_header_t
| Information about each section, held in the section table. More...
struct | sb_section_table_t
| An index of all sections within the boot image. More...

## Enumerations

enum | { ROM_DISPLAY_PROGRESS = (1 << 0), ROM_VERBOSE_PROGRESS = (1 << 1) }
| Flag constants for the m_flags field of sb_image_header_t. More...
enum | { ROM_SECTION_BOOTABLE = (1 << 0), ROM_SECTION_CLEARTEXT }
| Section flags constants for the m_flags field of sb_section_header_t. More...

## Usage Information

SB file format definitions.

## Data Structure Documentation

struct sb_version_t

Version struct used in SB files.

Data Fields
uint16_t | m_major |
uint16_t | m_minor |
uint16_t | m_pad0 |
uint16_t | m_pad1 |
uint16_t | m_pad2 |
uint16_t | m_revision |

struct sb_image_header_t

Header for the entire boot image.

Fields of this header are arranged so that those used by the bootloader ROM all come first. They are also set up so that all fields are not split across cipher block boundaries. The fields not used by the bootloader are not subject to this restraint.

Image header size is always a round number of cipher blocks. The same also applies to the boot image itself. The padding, held in #sb_image_header_t::m_padding0 and #sb_image_header_t::m_padding1 is filled with random bytes.

The DEK dictionary, section table, and each section data region must all start on cipher block boundaries.

This header is not encrypted in the image file.

The m_digest field contains a SHA-1 digest of the fields of the header that follow it. It is the first field in the header so it doesn't change position or split the header in two if fields are added to the header.

Collaboration diagram for sb_image_header_t:
[legend]

Data Fields
sb_version_t | m_componentVersion |
uint8_t | m_digest[20] |
uint16_t | m_driveTag |
uint32_t | m_firstBootableSectionID |
uint32_t | m_firstBootTagBlock |
uint16_t | m_flags |
uint16_t | m_headerBlocks |
uint32_t | m_imageBlocks |
uint16_t | m_keyCount |
uint16_t | m_keyDictionaryBlock |
uint8_t | m_majorVersion |
uint8_t | m_minorVersion |
uint8_t | m_padding0[2] |
uint8_t | m_padding1[6] |
sb_version_t | m_productVersion |
uint16_t | m_sectionCount |
uint16_t | m_sectionHeaderSize |
uint32_t | m_signature |
uint32_t | m_signature2 |
uint64_t | m_timestamp |

struct sb_dek_dictionary_entry_t

Entry in sb_dek_dictionary_t.

The m_dek field in each entry is encrypted using the KEK with the m_iv field from the image header as the IV.

Data Fields
uint8_t | m_dek[16] | AES-128 key with which the image payload is encrypted.
uint8_t | m_mac[16] | CBC-MAC of the header.

struct sb_dek_dictionary_t

The DEK dictionary always follows the image header, in the next cipher block.

Collaboration diagram for sb_dek_dictionary_t:
[legend]

Data Fields
sb_dek_dictionary_entry_t | m_entries[1] |

struct sb_section_header_t

Information about each section, held in the section table.

See also
  sb_section_table_t

Data Fields
uint32_t | m_flags | Section flags.
uint32_t | m_length | Size of section data in blocks.
uint32_t | m_offset | Offset to section data from start of image in blocks.
uint32_t | m_tag | Unique identifier for this section. High bit must be zero.

struct sb_section_table_t

An index of all sections within the boot image.

The section table will be padded so that its length is divisible by 16 (if necessary). Actually, each entry is padded to be a round number of cipher blocks, which automatically makes this true for the entire table.

Sections are ordered as they appear in this table, but are identified by the sb_section_header_t::m_tag.

The data for each section in encrypted separately with the DEK in CBC mode using m_iv for the IV. This allows the ROM to jump to any given section without needing to read the previous cipher block. In addition, the data for each section is prefixed with a "boot tag", which describes the section which follows it.

The section table starts immediately after the image header, coming before the key dictionary (if present). The section table is not encrypted.

Collaboration diagram for sb_section_table_t:
[legend]

Data Fields
sb_section_header_t | m_sections[1] | The table entries.

## Enumeration Type Documentation

anonymous enum

Flag constants for the m_flags field of sb_image_header_t.

Enumerator
ROM_DISPLAY_PROGRESS | Print progress reports.
ROM_VERBOSE_PROGRESS | Progress reports are verbose.

anonymous enum

Section flags constants for the m_flags field of sb_section_header_t.

Enumerator
ROM_SECTION_BOOTABLE | The section contains bootloader commands.
ROM_SECTION_CLEARTEXT | The section is unencrypted. Applies only if the rest of the boot image is encrypted.