How Mac OS 9 Checked File Integrity During Updates

During the Classic Mac OS era, maintaining system stability during software upgrades required precise validation of existing operating system files. Unlike modern macOS systems that rely on cryptographically signed snapshots and System Integrity Protection, Mac OS 9 update packages utilized a combination of resource fork inspections, Cyclic Redundancy Checks (CRC), and custom installer scripts to verify system integrity. If any targeted system files were modified—a frequent occurrence due to resource hacking or third-party extensions—the updater would detect the alterations and halt the installation to prevent system corruption.

The Role of Version Resources (vers)

In Mac OS 9, files were structured with two distinct forks: the data fork and the resource fork. Core system components, including the "System" file and the "Finder," stored their metadata, interface elements, and versioning inside the resource fork.

Apple’s Installer and standalone delta patchers first inspected the vers (Version) resources within target files. Every component contained two vers entries:

  • vers 1: Described the overall release version of the component (e.g., Mac OS 9.1).
  • vers 2: Provided package-specific or localized release tracking.

Before attempting any modification, the updater matched the vers resource ID and build numbers against an internal compatibility manifest. If a system file's version did not match the exact baseline expected by the update package (such as attempting to apply a 9.2.2 delta update directly over 9.0.4), the updater immediately flagged the file as incompatible and refused to proceed.

CRC and Checksum Verification

To ensure that target files were pristine and not merely displaying the correct version number, update packages performed byte-level integrity checks using Cyclic Redundancy Checks (typically CRC-32) or proprietary checksum algorithms.

Because delta updates worked by applying binary patches directly to existing files rather than replacing them entirely, the source file had to be an exact bit-for-bit match with Apple's baseline release. The installer read the target file, calculated its checksum, and compared it against the expected hash embedded in the updater’s installation script. If even a single byte deviated from the official release, the integrity check failed.

Detection of User and Third-Party Modifications

During the Mac OS 9 era, users and utility programs frequently modified core files. Tools like ResEdit allowed users to alter system sounds, dialog boxes, and icons directly inside the System file. Additionally, third-party system extensions often patched or altered system code in memory or on disk.

When an update package encountered a file that failed either the vers inspection or the CRC verification, it flagged the file as modified. Because applying a binary patch to a modified file would inevitably result in a corrupted, unbootable system, the updater protected the installation by:

  1. Halting the Process: Displaying an alert stating that a required file had been modified and could not be updated.
  2. Recommending a Clean Install: Prompting the user to run a "Clean Installation" of the OS from the original installation media. This process created a brand-new, unmodified System Folder while archiving the old one as "Previous System Folder."

Tome Archives and Manifest Verification

Mac OS 9 update packages were distributed using compressed archive files known as Tomes (often bearing the .tome extension), managed by the Apple Installer utility.

Within each package, the Tome was accompanied by an Installer Script (inss resource or data payload) that acted as the manifest. This manifest defined:

  • The exact file paths and Creator/Type codes required.
  • The expected pre-installation state (hashes, sizes, versions).
  • The installation recipe: whether to apply a binary patch in place or swap the file with a complete replacement extracted directly from the Tome.

Combo updates, which were substantially larger than standard delta packages, often bypassed strict binary patching by containing full, unpatched versions of system files inside their Tomes. In these cases, the installer relied primarily on version comparisons rather than strict byte-level checksums, completely replacing any modified files with fresh, pristine copies from the installer archive.