Inst file formats

This is a page documenting various parts of the IRIX 6.5 inst file formats. The goal here is to build a formal specification through reading and analyzing files. We do not intend to use disassembly or other methods to RE these formats if possible.

`/var/inst` — per-product record file format

Overview

A product record file stores metadata for a single installed product. It contains:

A fixed ASCII signature and version
One or more TLV-like record blocks (binary header fields + NUL-terminated ASCII strings)
4-byte tokens (timestamps/IDs/checksums) associated with records

All multi-byte integer fields are big-endian.

File header

Notes: 0x0d..0x0f are consistent across many samples; treat as header flags/format info.

Record block (high level)

Records are variable-length. A common pattern:

Record header often appears as compact fields (examples observed):

Strings are stored as usual ASCII and terminated by 0x00. The set and order of string fields are consistent per record type (product name -> long name -> build id -> subsystem entries, etc.).

Common tokens & patterns

pd001 — product DB magic.
V630, V650, etc. — format/release code.
P00, P01 — file-type marker.
Repeating 4-byte sequences near records typically represent UNIX timestamps or stable IDs.
\0 is used widely as a delimiter between strings.

`hist` — inst history file (draft)

High-level layout

String table

Appears as a contiguous region filled with many NUL-terminated printable strings (product/subsystem names).
The parser should locate it by picking the file window that contains many NUL-separated printable ASCII runs (heuristic).

Binary record format (canonical candidate)

Many history records follow this layout (big-endian):

name_off_be is an absolute offset into the history file; reading from that offset to the next NUL yields the referenced product/subsystem string.
Follow-on payload bytes (after the 12-byte header) vary by action_be value and can include counts, other offsets, path strings (NUL terminated), and 4-byte timestamps/checksums.

Semantics (what to interpret)

ts_be — time the event occurred (seconds since epoch).
action_be — action code: e.g. install, remove, update, patch, etc. (numerical mapping TBD).
flags_be — modifiers for action (e.g. success/failure bits, location flags).
name_off_be — link to string in the string table.

Unknowns / caveats

Exact semantics of action_be and flags_be are not yet decoded into human labels. They are likely bitpacked and depend on record class.
Some records use slightly different header shapes (longer/shorter), so the parser should be resilient: find timestamp test for nearby name_off that points into the string table → treat as candidate record.
The string table location and size are variable; rely on heuristics (max-count window) or header-specified offsets that may exist in other product files.