macOS Sealed System Volume & DataVault

{{#include ../../../banners/hacktricks-training.md}}

Sealed System Volume (SSV)

Basic Information

Starting with macOS Big Sur (11.0), the system volume is cryptographically sealed using an APFS snapshot hash tree. This is called the Sealed System Volume (SSV). The system partition is mounted read-only and any modification breaks the seal, which is verified during boot.

The SSV provides:
- Tamper detection — any modification to system binaries/frameworks is detectable via the broken cryptographic seal
- Rollback protection — the boot process verifies the system snapshot's integrity
- Rootkit prevention — even root cannot persistently modify files on the system volume (without breaking the seal)

Checking SSV Status

# Check if authenticated root is enabled (SSV seal verification)
csrutil authenticated-root status

# List APFS snapshots (the sealed snapshot is the boot volume)
diskutil apfs listSnapshots disk3s1

# Check mount status (should show read-only)
mount | grep " / " 

# Verify the system volume seal
diskutil apfs listVolumeGroups

SSV Writer Entitlements

Certain Apple system binaries have entitlements that allow them to modify or manage the sealed system volume:

Finding SSV Writers

# Search for binaries with SSV-related entitlements
find /System /usr -type f -perm +111 -exec sh -c '
  ents=$(codesign -d --entitlements - "{}" 2>&1)
  echo "$ents" | grep -q "apfs.revert-to-snapshot\|apfs.create-sealed-snapshot\|rootless.install" && echo "{}"
' \; 2>/dev/null

# Using the scanner database
sqlite3 /tmp/executables.db "
SELECT e.path, c.name
FROM executables e
JOIN executable_capabilities ec ON e.id = ec.executable_id
JOIN capabilities c ON ec.capability_id = c.id
WHERE c.name = 'ssv_writer';"

Attack Scenarios

Snapshot Rollback Attack

If an attacker compromises a binary with com.apple.private.apfs.revert-to-snapshot, they can roll back the system volume to a pre-update state, restoring known vulnerabilities:

# Conceptual — the snapshot revert operation would:
# 1. List available snapshots
diskutil apfs listSnapshots disk3s1

# 2. Revert to an older snapshot (requires the entitlement)
# This restores the system to a state with known, patched vulnerabilities

System Binary Replacement

With SIP bypass + SSV write capability, an attacker can:

1. Mount the system volume read-write
2. Replace a system daemon or framework library with a trojaned version
3. Re-seal the snapshot (or accept the broken seal if SIP is already degraded)
4. The rootkit persists across reboots and is invisible to userland detection tools

Real-World CVEs

DataVault

Basic Information

DataVault is Apple's protection layer for sensitive system databases. Even root cannot access DataVault-protected files — only processes with specific entitlements can read or modify them. Protected stores include:

DataVault protection is enforced at the filesystem level using extended attributes and volume protection flags, verified by the kernel.

DataVault Controller Entitlements

com.apple.private.tcc.manager         — Full TCC database read/write
com.apple.private.tcc.manager.check-by-audit-token — TCC checks via audit token
com.apple.private.tcc.allow           — Access specific TCC-protected resources
com.apple.rootless.storage.TCC        — Write to TCC database (SIP-related)

Finding DataVault Controllers

# Check DataVault protection on the TCC database
ls -le@ "/Library/Application Support/com.apple.TCC/TCC.db"

# Find binaries with TCC management entitlements
find /System /usr -type f -perm +111 -exec sh -c '
  ents=$(codesign -d --entitlements - "{}" 2>&1)
  echo "$ents" | grep -q "private.tcc\|datavault\|rootless.storage.TCC" && echo "{}"
' \; 2>/dev/null

# Using the scanner
sqlite3 /tmp/executables.db "
SELECT e.path, c.name
FROM executables e
JOIN executable_capabilities ec ON e.id = ec.executable_id
JOIN capabilities c ON ec.capability_id = c.id
WHERE c.name = 'datavault_controller';"

Attack Scenarios

Direct TCC Database Modification

If an attacker compromises a DataVault controller binary (e.g., via code injection into a process with com.apple.private.tcc.manager), they can directly modify the TCC database to grant any application any TCC permission:

-- Grant Full Disk Access to a malicious binary (conceptual)
INSERT INTO access (service, client, client_type, auth_value, auth_reason, auth_version)
VALUES ('kTCCServiceSystemPolicyAllFiles', 'com.attacker.malware', 0, 2, 4, 1);

-- Grant camera access without a prompt
INSERT INTO access (service, client, client_type, auth_value, auth_reason, auth_version)
VALUES ('kTCCServiceCamera', 'com.attacker.malware', 0, 2, 4, 1);

Keychain Database Access

DataVault also protects the keychain backing files. A compromised DataVault controller can:

1. Read the raw keychain database files
2. Extract encrypted keychain items
3. Attempt offline decryption using the user's password or recovered keys

Real-World CVEs Involving DataVault/TCC Bypass

References

• Apple Platform Security — Data Protection
• The Nightmare of Apple OTA Updates (APFS Snapshots)
• Objective-See — TCC Exploitation

{{#include ../../../banners/hacktricks-training.md}}