Understanding and Decoding the Newest iOS SEGB Format

At Cellebrite, we strive to bring you the most up-to-date support for parsing artifacts on iOS and Android devices. We are sharing our research on iOS’s most recent SEGB format used for Biome files in iOS 17, which is ready for our customers in Physical Analyzer versions 7.64 and 8.7. 

Background: SEGB

SEGB is the format used by the Biome service in iOS, which emerged in iOS 15 and became a crucial source of forensic information in iOS 16. Notable data that exists in Biome streams includes screen activity time, usage of airplane mode, application usage time, instant messages content and more.

In case you missed it, we discuss the original version of SEGB in Cellebrite’s recent I BEG TO DFIR episode 21.

The new SEGB v2 format

Apple released the iOS 17 and made several changes to Biome as a whole, most notably to the SEGB format. While it resembles the original version, its binary structure changed significantly. We refer to the new version as SEGB v2 and the older version as SEGB v1. 

Structure updates

Similarly to SEGB v1, the different Biome streams sort into different folders, each commonly containing a “local” directory and inside, one or more SEGB binary files. The name of the file is a number representing the creation time of the file. The format of the SEGB v2 files is as follows:

In v1, both the header and the entries section existed, yet in v2, both of their internal formats changed. The most notable change in v2 is the introduction of the new trailer section. Some of the entries’ information is now stored in the trailer and it is necessary to parse this section to read the file. With each written record, both the entries and trailer sections gradually expand into the “unused area.”  Once the unused area is unable to allow more writes, a new SEGB is created.

The header

The header of SEGB v2 consists of 32 bytes. As we understand them, these are their meanings:

To successfully parse the file, we only need to read the “Entries Count.”

The Trailer

The trailer starts at the end of the file and contains 16-byte records. Every record belongs to an entry in the entries section. New records are written before any of the existing records and closer to the file’s beginning. Effectively the trailer is “growing” into the unused area section, taking 16-bytes out of it at a time. Every record in the trailer has the following format. Please note the “Entry End Offset” is relative to the end of the file header.

To parse the trailer, we will iterate the records from the end of the file towards the beginning. We expect the number of records to match the “Entries Count” read from the header.

Entries Section

Entries are arranged in the entries section one after the other, with some padding when needed. In v1, each entry was padded to the nearest multiple of eight. In v2, this changes to the nearest multiple of four.

Parsing of every entry must start by parsing its matching record in the trailer and the record before it. To know where the entry starts, we use the last record’s “Entry End Offset” and round up to a multiple of four. Since the first entry does not have a record preceding it, it simply starts at the end of the file’s header. Starting at that offset, we can read the small “Entry Header” of 8 bytes. The data in this header is used by Biome’s internal implementation.

After the header, we expect to see the payload spanning up to the “Entry End Offset” of the current entry’s record.

Just like SEGB v1, the payloads of the entries are commonly protobufs. In many of the cases we have examined, streams that had a certain protobuf structure under SEGB v1 (in iOS 16 or 15) had the same structure in iOS 17 after swapping SEGB v1 with v2.

It is clear Biome files are still an important part of iOS17 and continue to have important forensic implications. Our research into this area is ongoing and we anticipate more data will be available over time. New decoding features will be clearly communicated in PA’s Release Notes.