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)

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.