ftabutil

A simple utility to build and unpack 'ftab' (aka 'rkosftab') images found in firmware images of accessories produced by Apple.

A quick into 'ftab' file format

'ftab' (which probably means File TABle) files are simple tables of files where a key is a 4-byte tag (e.g. 'rkos' which stands for RTKit OS) and a value are the contents of the corresponding file. An optional APTicket may be included as a signature of the file's contents.

Building 'ftab' files

ftabutil introduces a concept of manifest — a TOML description of the 'ftab' file fields and contents. Manifests are automatically produced when unpacking 'ftab' files but can also be created manually. Here's an example of such a manifest:

```toml

Unknown fields that are ignored by all the available parsers, required.

unk0 = 83886336 unk1 = 4294967295 unk2 = 0 unk3 = 0 unk4 = 0 unk5 = 0 unk_6 = 0

Path to the ticket to be included in the 'ftab' file, optional.

ticket = "ApImg4Ticker.der"

List of files to be included as the file's segments.

[[segments]]

Path to the file to be included as a segment.

path = "rkos.bin"

The tag to be assigned to the segment. Can either be a 4-byte string

or an integer less than 2^32 that will be encoded as a big-endian

32-bit integer.

tag = "rkos"

Unknown field that is always equal to zero.

unk = 0

...

```

Such a manifest can be used with the pack subcommand like this:

shell ftabutil pack path/to/manifest.toml optional/path/to/ftab.bin

For more info see documentation for the pack subcommand.

Unstable access to unknown fields

Some fields of the format are unknown and unused at the time of writing. The tool provides the access to these fields without really documenting them. In the future the names for these fields is very likely to change, so you shouldn't rely on the manifest format to be stable.

License

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Pull requests are always welcome. I may ask you to match the coding style more closely though, but generally it's just about running rustfmt. Feature requests should be filed as issues.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.