BIF (Binary Information File)
BIFs are essentially giant, uncompressed data silos. Because they act as the raw storage tier of the KOTOR engine, they don’t waste bytes on complex metadata or internal filenames – they are simply pure, tightly packed continuous byte arrays for game resources. They are designed to be randomly accessed extremely quickly at runtime strictly via their companion KEY index file.
At a Glance
| Property | Value |
|---|---|
| Extension(s) | .bif |
| Magic Signatures | BIFF (version V1 ) |
| Type | Archive Blob Payload |
| Rust Reference | View rakata_formats::Bif in Rustdocs |
Data Model Structure
The rakata-formats crate handles raw Bif parsing for you by reading the internal offset tables. However, developers very rarely interact with a raw Bif file on its own.
- Unified Access: Typically, you’ll use the
KeyFileAPI (rakata_extract::keyfile::KeyFile), which automatically ties.keyindex files to their.bifdata payloads so you don’t have to map them yourself. - Seek Performance: To prevent loading 100MB+ binary files completely into memory just to read a tiny script, Rakata jumps directly to the exact file coordinate on your hard drive (via
KeyFile::read_resource_by_seek), extracting only the single resource you specifically asked for!
Tip
The compressed
BZFBIF variant did not exist in the original 2003 PC version of the game. It was added much later by Aspyr for their modern iOS, Android, and Nintendo Switch ports simply to save storage space on mobile devices. While our parser can read theBZFlayout, it falls slightly outside our core focus on the original PC version and hasn’t been heavily tested against real mobile game files yet.
Engine Audits & Decompilation
The following documents the engine’s exact load sequence and field requirements for .bif archive headers mapped from swkotor.exe.
(Decompilation logic for this section was entirely audited and verified via native Ghidra pipeline against swkotor.exe, explicitly pulling from CExoResFile::LoadHeader (0x0040d910) and CExoResFile::ReadResource (0x0040da20).)
Archive Initialization (CExoResFile::LoadHeader)
Mapped from 0x0040d910.
| Pipeline Event | Engine Behavior & Result |
|---|---|
| Signature Check | The engine strictly validates both the BIFF magic and the exact V1 version. It does not actively process any files that deviate from this signature pair. |
| Variable Table Loading | The system extracts the variable_count value from the header and physically reads variable_count * 16 bytes from the variable_table_offset to map the resource keys. |
| Fixed Table Bypass | The fixed_count header scalar is entirely decorative. It is not part of the active runtime read path (files with nonzero values are accepted but never mapped). |
| Direct Asset Extraction | When reading a physical asset out of the .bif, the engine isolates the entry_index using (resource_id & 0x3fff) * 0x10. It then calls a direct C fseek(SEEK_SET) strictly matching the raw data_offset extracted from the 16-byte variable table entry. No alignment or structural normalization is applied—the data is dumped entirely blindly. |
Caution
Because the engine passes the internal
data_offsetinteger directly into a raw Cfseek(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.