I can confirm that there are ghosts in Macs. I know because I have seen them, spectres of rock bands from well over 50 years ago, speaking to us from the past, a dozen years before the first Mac, and four years before Apple was even founded. The band in question is named Creedence Clearwater Revival, who split up in 1972. Their appearance on Macs has been sporadic, in the form of a mystery volume that seems to mount from nowhere, whose name starts with the distinctive neologism coined by CCR’s rhythm guitarist Tom Fogerty after his friend Credence Newball.
Last week it turned out that mystery volume is a cryptex, one of the 23 used to provide support for Apple Intelligence in macOS, iOS and iPadOS.
Cryptexes are both straightforward and rather strange. They’re basically just a cryptographically secured disk image, but when they’re loaded by APFS, rather than being mounted as a volume, they get grafted into the file system almost as if they had been firmlinked into it. Although they didn’t exactly impress when used for Rapid Security Responses (RSRs) in macOS Ventura, since then they’ve been put to better use adding flexibility to the Signed System Volume (SSV), an immutable snapshot of the System volume that’s sealed with cryptographic hashes.
While the SSV is a powerful way to secure the boot process, it’s also a little too rigid for some purposes. Not only do cryptexes provide a convenient way to deliver Safari and its supporting components, which previously had to be installed on the Data volume, but they are a flexible solution for large dyld caches, accommodating to the differing needs of Intel and Apple silicon Macs. Intel Macs only use those built for their own architecture, but Apple silicon Macs require support for both, with the Intel version available for use by Rosetta 2 when running translated x86 code.
What I hadn’t realised, and hadn’t seen reported elsewhere, was how the extras needed for Apple Intelligence, another single-platform feature, are also provided in cryptexes. Unlike those for the system, these aren’t grafted early during the boot process, so can be downloaded and installed when a user enables AI, and thereafter grafted after that user has logged in. Their contents then appear among the thousands of install-on-demand linguistics and other components in /System/Library/AssetsV2, as I described earlier this week.
Presumably they merit this special protection because of their access to Private Cloud Compute (PCC), consistent with Apple’s stringent policies and engineering to ensure the robustness of PCC. Indeed, as Apple describes, the PCC is apparently an enthusiastic user of cryptexes: “Additional software outside the base operating system can be delivered to the system only in the form of cryptexes, which contain their own Image4 manifest and trust cache.” Apple goes on to provide a detailed account of how cryptexes are handled by PCC. This illustrates how sophisticated their management can be, and explains why, despite their shaky introduction as RSRs, cryptexes are proliferating.
This could change when macOS 27 goes single-architecture next year, and there’s no need to cater for both chalk and cheese. But I suspect the advantages of augmenting the SSV with the flexibility of cryptexes will remain sufficiently attractive to ensure they are retained in macOS, as they already are in iOS and iPadOS.
Cryptexes are also remarkably unobtrusive, as has been apparent with the 23 currently used to support AI. That is until something unearthly happens deep inside the grafting mechanism in macOS and accidentally mounts a cryptex as a disk image, making it appear like a spectre in the Finder. In my case it must have occurred when I copied a cryptex from its hiding place among those files in /System/Library/AssetsV2 and mounted it to see what it contained. Exorcising this ghost required compressing the cryptex, trashing the copy I had made, and repeatedly trying to unmount it until it finally stopped appearing following startup.
But I still know how to summon the spirit of Creedence Clearwater Revival whenever I need to remind myself of the early 1970s. Now if someone would be kind enough to tell me which cryptex brings the spirit of Pink Floyd, I’ll leave you in peace.
Somewhen around late versions of macOS Monterey, and certainly by the release of Ventura, macOS started to use cryptexes to load Safari and parts of the operating system including dyld caches, rather than installing them to the Data volume. Over a period of three months, cryptexes were also used to install Rapid Security Responses (RSRs) in an experiment that was quickly discontinued. What I hadn’t realised until recently was that they are also used to deliver much of the additional components required to support Apple Intelligence features in Apple silicon Macs. This article looks as how that works.
Cryptexes
These first appeared on Apple’s customised iPhone, its Security Research Device, which uses them to load a personalised trust cache and a disk image containing corresponding content. Without the cryptex, engineering those iPhones would have been extremely difficult. According to its entry in the File Formats Manual from five years ago (man cryptex), ‘A cryptex is a cryptographically-sealed archive which encapsulates a well-defined filesystem hierarchy. The host operating system recognizes the hierarchy of the cryptex and extends itself with the content of that hierarchy. The name cryptex is a portmanteau for “CRYPTographically-sealed EXtension”.’
In practice, a cryptex is a sealed disk image containing its own file system, mounted at a randomly chosen location within the root file system during the boot process. Prior to mounting the cryptex, macOS verifies it matches its seal, thus hasn’t been tampered with. Managing these cryptexes is the task of the cryptexd service with cryptexctl. Because cryptexes aren’t mounted in the usual way, they’re not visible in mount lists such as that produced by mount(8).
System cryptexes
Once kernel boot is well under way, APFS mounts containers and volumes in the current boot volume group, followed by others to be mounted at startup. When those are complete, it turns to mounting and grafting the three standard system cryptexes:
os.dmg, around 6 GB (macOS 15.5), containing system components such as dyld caches;
app.dmg, around 23 MB, containing Safari and supporting components;
os.clone.dmg, apparently a copy of os.dmg and the same size.
AI cryptex collection
About 5 seconds later, and over 14 seconds after APFS first started work, it checks and grafts a series of 23 cryptexes primarily involved with Apple Intelligence features. These are handled one at a time in succession, each reported in a sequence of log entries as follows (times in seconds after an arbitrary start).
First the Image4 file containing the cryptex is validated 9.434431 root_hash_execution_cb_mobile_asset:3066: image4_trust_evaluate: successfully validated the payload and the manifest
Then it’s grafted into the file system of the Data volume as a ‘PFK volume’. In this extract I omit the bulk of the cryptex’s name using […] for the sake of brevity. 9.434465 apfs_graft:695: disk3s5 Grafting on a PFK volume
9.434509 graft_dev_init:480: disk3 UC_[…]_Cryptex.dmg GRAFT (compiled @ Apr 22 2025 19:49:43)
9.434514 graft_dev_init:484: disk3 UC_[…]_Cryptex.dmg device_handle block size 4096 real block size 4096 block count 11264 features 0 internal VEK
9.434695 nx_mount:1308: UC_[…]_Cryptex.dmg initializing cache w/hash_size 512 and cache size 512
9.437484 nx_mount:1630: UC_[…]_Cryptex.dmg checkpoint search: largest xid 15, best xid 15 @ 7
9.437497 nx_mount:1657: UC_[…]_Cryptex.dmg stable checkpoint indices: desc 6 data 31
9.438117 er_state_obj_get_for_recovery:8420: UC_FM_LANGUAGE_INSTRUCT_3B_CONC No ER state object for volume RevivalB13M201388.UC_[…]_Cryptex - rolling is not happening, nothing to recover.
9.438124 apfs_log_op_with_proc:3263: UC_FM_LANGUAGE_INSTRUCT_3B_CONC grafting volume RevivalB13M201388.UC_[…]_Cryptex, requested by: mobileassetd (pid 457); parent: launchd (pid 1)
Note the volume name starts with Revival. Names of all other cryptex volumes in the AI collection start with the same code name, except for the PKI cryptex examined below, which uses Creedence instead. Perhaps these are a reference to Creedence Clearwater Revival?
The root hash of the cryptex file system is then authenticated 9.438156 graft_dev_blockmap_lut_switch_to_metadata_based_if_needed:1312: UC_FM_LANGUAGE_INSTRUCT_3B_CONC lut contains 26 extents, 3 of which contain metadata
9.438160 is_root_hash_authentication_required_osx:387: UC_FM_LANGUAGE_INSTRUCT_3B_CONC Release kext with internal build: 0, ARV disabled: 0, booting xid: 0
9.438164 is_root_hash_authentication_required_osx:418: UC_FM_LANGUAGE_INSTRUCT_3B_CONC strict graft, root hash authentication failure is required
9.438167 is_root_hash_authentication_required:557: UC_FM_LANGUAGE_INSTRUCT_3B_CONC Strict Graft, root hash authentication is required
9.438179 authenticate_root_hash:642: UC_FM_LANGUAGE_INSTRUCT_3B_CONC successfully validated on-disk root hash
9.438191 apfs_lookup_ge_jobj_id:5028: disk3s5 Found OBJID 0x66a1b8 type 3
The graft is then completed. 9.438195 apfs_graft:1045: disk3s5 Graft ino 6557986, jobj_id range 6725836+76
9.438396 apfs_graft:1138: disk3s5 successfully grafted ino 6557986 on dir 6725835, dev_name [UC_[…]_Cryptex.dmg]
Fortunately, these log entries provide the inode number for the location of the grafted cryptex, and that can be used in Mints to obtain its full path.
Among the AI cryptex collection is a secure public key infrastructure (PKI) trust store, located at /System/Library/AssetsV2/com_apple_MobileAsset_PKITrustStore/purpose_auto/[…].asset/AssetData/Restore/SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex.dmg
In the log, this is recorded as being 4.2 MB in size, and that is the same size as reported for the .dmg file by the Finder. Disk images are in APFS (Case-sensitive) format, and might be identical to their equivalents provided for iOS and iPadOS.
When mounted, that disk image becomes a volume named Creedence11M6270.SECUREPKITRUSTSTOREASSETS_SECUREPKITRUSTSTORE_Cryptex. That contains many property lists, certificate data, a SystemRootCertificates keychain, and two property lists that are grafted into /System/Library/CoreServices.
The names of all 23 cryptex disk images included in the macOS 15.5 AI cryptex collection are given in the Appendix. All are given as being compiled at Apr 22 2025 19:49:43, the same as the system cryptexes, implying that they were installed as part of the macOS 15.5 update. The whole sequence of processing the AI cryptexes took 0.78 seconds to complete, and the total size of disk images mounted in that period was 7.2 GB, which is similar to the reported size of additional files required to support AI.
Conclusions
Apple silicon Macs running macOS 15.5 with AI enabled load 23 additional cryptexes to support AI, totalling 7.2 GB.
Those AI cryptexes are grafted into the Data volume, in paths starting /System/Library/AssetsV2.
All except one have volume names starting with Revival
One cryptex is a secure PKI trust store, whose volume name starts with Creedence instead.
These cryptexes are installed and updated as part of macOS updates, although they could also be installed or updated separately, for example when AI is enabled.
If a Mac shows an unusual mounted volume with a name starting with Creedence or Revival, that’s almost certainly the respective disk image, which should normally be hidden and not visible in the Finder.
Appendix
Disk image names for the AI cryptex collection in macOS 15.5 (Apple silicon):
Login
