Raion: Created page with "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..."

2025-10-12T15:54:57Z

Created page with "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. == <code>/var/inst</code> — 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..."

New page

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.

== <code>/var/inst</code> — 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: <code>0x0d..0x0f</code> 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 ===

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

== <code>hist</code> — 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):

* <code>name_off_be</code> 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 <code>action_be</code> value and can include counts, other offsets, path strings (NUL terminated), and 4-byte timestamps/checksums.

----

=== Semantics (what to interpret) ===

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

----

=== Unknowns / caveats ===

* Exact semantics of <code>action_be</code> and <code>flags_be</code> 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 <code>name_off</code> 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.

Inst file formats - Revision history