Since Big Sur, macOS updates have been substantial, both in their size and the complexity of their installation. Because all Macs running macOS 11 and later boot from a signed and sealed snapshot (SSV), every update to macOS has to construct a new 9 GB snapshot and its tree of hashes before it can restart from that and run the new version of macOS.

While this brings a high degree of security, some vital components that might require updating outside of macOS, such as Safari, aren’t part of the SSV, and require a secure and robust means of storage. To address these problems, Apple has introduced cryptographically sealed archives known as Cryptexes, a portmanteau word formed from CRYPTographically-sealed EXTension.

Those familiar with Dan Brown’s novel The Da Vinci Code may recognise the word cryptex as being used there for a portable secure vault with a combination lock. Apple’s Cryptexes also have an exotic origin, as they were first implemented to support Apple’s customised iPhone, its Security Research Device, which uses them to load a personalised trust cache and a disk image containing corresponding content.

Standard Cryptexes

A Cryptex can contain a wide range of different contents, typically including command tools, system executables, libraries, man pages, apps and frameworks. Many of the system components that used to be stored on the Data volume are now loaded by Ventura in Cryptexes, including Safari and all its supporting components, the JavaScriptCore framework, some AMD graphics drivers, and most importantly dyld shared caches, which had proved such a heavy burden in Big Sur updates.

Currently, macOS 13.3 has three standard Cryptexes, app.dmg, os.dmg, and os.clone.dmg, each of which is added into place in the system in a process termed grafting, detailed below. You can mount these Disk Images manually, and in the case of app.dmg you can even run the copy of Safari contained within it, although as that’s identical to the version shown in the main Applications folder, this is something of a pointless party trick.

These standard Cryptexes are one of few differences in the system installed on Intel and Apple silicon Macs. In addition to there being structural differences in their directories once grafted into macOS, os.dmg and os.clone.dmg are significantly larger on Apple silicon Macs, where they are around 4.4 GB each, but only 1.6 GB on Intel Macs.

Although it’s possible that Apple will move Rosetta 2 into a Cryptex in the future, currently it remains a separate on-demand installation to the Data volume, and not part of a standard Cryptex.

RSRs

Rapid Security Responses (RSRs) are new with Ventura, and provide a mechanism for Apple to deliver urgent security patches to macOS in between updates. Up to and including the release of Ventura 13.3, Apple hasn’t released any RSRs except for tests made during beta-testing of macOS. Its intention is that these will be offered to all Macs running the current release of macOS to patch critical vulnerabilities before they’re incorporated into the next macOS update.

Whenever possible, they should be reversible, allowing the user to disable them should they wish, and most should take immediate effect without requiring the Mac to be restarted. RSRs are expected to be offered through and controlled within Software Update in System Settings, but only available in Ventura and later macOS.

Loading

As Cryptexes are stored on the Preboot volume, which is mounted and accessed by the Low-Level Bootloader (LLB) during stage 1 of the boot process, they can be loaded at any time from then onwards, according to their requirements, as specified in the Cryptex build manifest. In theory this would enable contents of a Cryptex to be loaded before iBoot and the kernel, and could make it feasible for an RSR to modify those if required. The current version of the Cryptex build manifest includes keys indicating whether components should be loaded by LLB (IsLoadedByiBootStage1) or iBoot (IsLoadedByiBoot), although it isn’t clear whether those options are functional yet.

In practice, the contents of the current standard Cryptexes aren’t loaded until towards the end of the kernel’s early boot phase (as labelled by the kernel), in the sequence:

• 16.205828 kext loading enabled
• 16.230771 Cryptex loads start
• 16.242392 Cryptex loads complete
• 16.417686 mount the Data volume
• 17.025173 early boot complete, continuing system boot
• 17.358119 WindowServer launched, then dasd, cfprefsd, tccd, opendirectoryd et al.

with elapsed times given in seconds since the start of boot, for a Mac Studio M1 Max booting macOS 13.3 from its internal SSD.

Loading each Cryptex starts with validation of the payload and its manifest. It then undergoes a sequence of processes similar to the mounting of an APFS volume, with a checkpoint search to establish stable checkpoint indices, and a check to discover whether there’s anything to recover, which seems improbable.

The graft is then performed in a series of opaque steps, with root hash authentication and validation. The OBJID (object ID?) is found, and the graft completed, inserting the directory hierarchy of the Disk Image into an arbitrary location within the parent file system.

Once this has been completed for each of the three standard Cryptexes and any installed RSRs, the contents of those Cryptexes are effectively part of the system, as a hybrid of the SSV and Cryptexes. As with the current boot System and Data volumes, grafted Cryptexes aren’t ungrafted or unmounted until shutdown.

Paths

Cryptexes and their contents appear on multiple paths that can look confusing, and there are also differences between Intel and Apple silicon Macs. Their Disk Images and ancillary files are found at Preboot/[UUID]/cryptex1/current, through that volume’s mountpoint in /System/Volumes.

They also appear in Preboot/Cryptexes/ within App, Incoming, and OS directories. Safari.app appears grafted at Preboot/Cryptexes/App/System/Applications/Safari.app, and dylds at Preboot/Cryptexes/Incoming/OS/System/Library/dyld/ and Preboot/Cryptexes/OS/System/Library/dyld/. RSRs appear likely to be grafted into /var/run/com.apple.security.cryptexd/ from Preboot/com.apple.security.cryptexd/Cryptexes.

Apple doesn’t document Cryptexes yet, except in man cryptex, last updated in 2020 thus referring mainly to Apple’s Security Research Device. Hopefully Apple will explain more in this Spring’s revision to its Platform Security Guide.