BIF (Binary Information File)

A BIF is bulk uncompressed storage: tightly packed resource bytes with no metadata and no filenames. It is built to be read at a known offset, which is what the companion KEY index supplies.

At a Glance

File Layout

A fixed 20-byte header, one or two resource tables, and the payload. The variable table is found by variable_table_offset; the fixed table, when a file has one, follows it directly. Payload bytes are addressed per entry.

There are no names anywhere in here. A BIF entry knows its own id, type, offset and size, and nothing else. The resref lives in the KEY, which reaches in by position. That is what makes a BIF unreadable on its own and why the two formats are always discussed together.

Header (20 bytes)

Variable Resource Entry (16 bytes each)

Fixed Resource Entry (20 bytes each)

Note

resource_id is positional, and it is the KEY’s word repeated A variable entry’s resource_id is the same packed value the KEY carries for that resource: the entry’s own index within this archive in the low twenty bits, this archive’s index in the KEY file table in the high twelve. Both halves hold in every variable entry of every archive a retail install’s chitin.key names.

The two files agree exactly. Every BIF entry is named by one key, no key points at an entry that is not there, and no two keys carry the same value, so the correspondence is one-to-one in both directions rather than merely consistent where it was checked.

That makes the field carry nothing a reader does not already have from position. A writer, though, has to compute it rather than copy it, because the high half is not a property of the BIF at all: it depends on where the archive lands in the KEY’s file table, which the BIF cannot see.

The fixed table’s resource_id is untested, since nothing shipped populates that table at all.

Note

The fixed table is a format feature nothing uses fixed_count is 0 in all 26 archives of a full vanilla install, without exception. The engine reads the scalar and then ignores it entirely, as the audit below records: files declaring fixed entries are accepted and those entries are never mapped. Rakata parses the table when one is present, so a file carrying it round-trips, but nothing in the game will ever look at what it holds.

The Compressed Variant (.bzf)

Compression did not exist in the original 2003 PC release. Aspyr added it for the modern mobile ports to save storage, and it is the one place the BIF format gets genuinely confusing, because nothing inside the file says it is compressed.

The extension is the only discriminator that exists in shipping data. Everything else matches. That has a direct consequence for tooling: compression has to be stated, not sniffed. Rakata reads it from the path when opening a file, and requires it as an argument when reading from a window that has no filename attached.

Payload Layout

Each resource is stored as its own LZMA-alone stream:

0x00        properties byte     packs (pb * 5 + lp) * 9 + lc
0x01..0x05  dictionary size     u32, little endian
0x05..      compressed data     terminated by an end-of-stream marker

There is no length field in the stream, because the uncompressed length already lives in the entry table. And there is no packed length recorded anywhere: an entry’s compressed extent runs from its offset to wherever the next entry begins, with the last one running to the end of the file. Trailing alignment inside that span is harmless, since the decoder stops at the end-of-stream marker.

Note

Ground truth and its limits. The facts above are read from a shipping Android bundle (com.aspyr.swkotor), whose 26 compressed archives every one carry the BIFF signature. Rakata decodes all 26, each entry to its exact declared length. iOS and Switch are unverified and simply assumed to match.

Two things worth flagging as inference rather than fact. Community references describe a BZF signature; no file in the bundle uses it, so Rakata does not look for one. And the engine presumably swaps the extension when resolving a KEY entry on mobile, since the KEY says .bif and the disk says .bzf, but that path has not been traced in a mobile binary. The Ghidra project carries the Android builds, so it is auditable whenever someone wants to.

Engine Audits & Decompilation

Read from CExoResFile::LoadHeader (0x0040d910) and CExoResFile::ReadResource (0x0040da20) in swkotor.exe. Provenance: derived, not attested. The rows below have not been separately re-derived, so they sit on the reverse-engineering queue.

Archive Initialization (CExoResFile::LoadHeader)

Mapped from 0x0040d910.

Caution

Because the engine passes the internal data_offset integer directly into a raw C fseek(SEEK_SET), any custom BIF files must meticulously guarantee byte-perfect offset tables. If the offset is even slightly misaligned, the engine will read garbage data into the stream, inevitably crashing the game.