7.2 macOS File Systems: HFS+ and Apple File System (APFS) Architecture & Snapshots

7.2 macOS File Systems: HFS+ and Apple File System (APFS) Architecture & Snapshots

Quick Answer: Modern macOS investigations center on the Apple File System (APFS), which superseded legacy HFS+ (Mac OS Extended) starting in macOS 10.13 High Sierra. While HFS+ relied on fixed partition structures and five specialized B-Tree metadata files anchored by a Volume Header at offset 1024 (magic 0x482B), APFS introduces a flexible Container architecture with dynamic Space Sharing. Governed by a Container Superblock (NXSB) and Volume Superblocks (APSB), APFS uses an Object Map (OMAP) to map virtual Object IDs (OIDs) to Physical Block Numbers (PBNs). APFS utilizes Copy-on-Write (CoW) to guarantee atomic updates, which underpins APFS Snapshots—immutable, read-only historical volume states accessible via diskutil apfs listSnapshots and tmutil. Key forensic artifacts include extended attributes (com.apple.quarantine and kMDItemWhereFroms), the Apple Unified Log (AUL) .tracev3 binary logs, and FileVault 2 XTS-AES full-disk encryption.

---

Evolution of Apple File Systems: HFS+ vs. APFS

Apple transitioned from HFS+ to APFS to optimize performance for Solid-State Drives (SSDs), enhance cryptographic security, and provide native snapshotting capabilities across macOS, iOS, iPadOS, watchOS, and tvOS.

| Architectural Feature | HFS+ (Hierarchical File System Plus) | APFS (Apple File System) | |---|---|---|---| | Primary Storage Media | Mechanical Hard Drives (HDD) | Solid-State Drives (SSD / NVMe / Flash) | | Storage Model | Fixed Partition Boundaries | Container-based Space Sharing across Volumes | | Metadata Architecture | Five Static B-Tree Files | B-Tree Object Map (OMAP) & Object Trees | | Allocation Paradigm | In-place overwrite with journal | Redirect-on-Write / Copy-on-Write (CoW) | | Volume Header / Superblock | Volume Header at byte offset 1024 | Container Superblock (NXSB) at Block 0 | | Primary Magic Bytes | 0x482B (H+) or 0x4858 (HX - case-sensitive) | NXSB (0x4253584E), APSB (0x42535041) | | Timestamp Resolution | 1 Second (Mac Epoch: Jan 1, 1904 UTC) | 1 Nanosecond (POSIX Epoch: Jan 1, 1970 UTC) | | Snapshots | Not supported natively (Time Machine used hard links) | Native, read-only, instantaneous volume snapshots | | Native Encryption | None (FileVault 2 used CoreStorage volume layer) | Native Multi-Key Encryption per file/container/volume | | Clones / Fast Copy | Full cluster copy required | Zero-copy file cloning (shares common data blocks) |

---

Legacy HFS+ Architecture

Although APFS is the default on modern Mac systems, external backup drives, legacy systems, and older forensic images frequently feature HFS+ (Mac OS Extended).

+---------------------------------------------------------------------------------------------------+
|                                 HFS+ VOLUME LAYOUT                                                |
+-----------------+-------------------+-------------------+-------------------+---------------------+
| Boot Blocks     | Volume Header     | Allocation File   | Catalog B-Tree    | Extents Overflow    |
| Sectors 0 & 1   | Sector 2 (1024 B) | ($Allocation)     | ($Catalog)        | ($Extents)          |
+-----------------+-------------------+-------------------+-------------------+---------------------+

The HFS+ Volume Header (Offset 1024)

The HFS+ Volume Header occupies 512 bytes starting at byte offset 1024 (Sector 2). An identical mirror copy, the Alternate Volume Header, is stored 1024 bytes before the physical end of the volume.

• Magic Number: Bytes 0x00 - 0x01 contain 0x482B (H+ in ASCII) for standard HFS+, or 0x4858 (HX in ASCII) for case-sensitive HFSX.
• Allocation Block Size: Bytes 0x28 - 0x2B specify the block size (commonly 4096 bytes).
• Special File Descriptors: Contains HFSPlusForkData structures defining the size and extent locations of the five primary metadata files.

The Five Special HFS+ Metadata Files

1. Allocation File: A bitmap where each bit represents the allocation state of one allocation block (0 = free, 1 = allocated). Analogous to NTFS $Bitmap.
2. Catalog B-Tree: The most critical file for forensic analysis. Maintains a balanced B-Tree indexing all files and folders on the volume. Stores file names, Catalog Node IDs (CNIDs / Mac equivalent of inodes), and MACB timestamps.
3. Extents Overflow B-Tree: When a file becomes fragmented and exceeds the 8 contiguous extents stored in its Catalog record, additional extents are recorded here.
4. Attributes B-Tree: Stores extended attributes (EAs), fork descriptors, and Access Control Lists (ACLs).
5. Startup File: Designed for non-Open Firmware systems to facilitate system boot.

[!NOTE] The HFS+ Mac Epoch: Timestamps in HFS+ are stored as 32-bit unsigned integers representing seconds since January 1, 1904 UTC. Forensic tools convert this to the standard Unix epoch by subtracting 2,082,844,800 seconds.

---

Modern Apple File System (APFS) Architecture

APFS fundamentally re-architects storage by discarding rigid partition boundaries in favor of a dynamic Container Architecture.

+---------------------------------------------------------------------------------------------------+
|                                  APFS CONTAINER ARCHITECTURE                                      |
+---------------------------------------------------------------------------------------------------+
| Physical Container (e.g., /dev/disk1)                                                             |
| +-----------------------------------------------------------------------------------------------+ |
| | Container Superblock (NXSB) | Checkpoint Map | Space Manager (Spaceman) | Container OMAP     | |
| +-----------------------------------------------------------------------------------------------+ |
| | Dynamic Shared Storage Pool (All Volumes share unallocated space)                             | |
| | +-----------------------+ +-----------------------+ +-----------------------+ +-------------+ | |
| | | Volume 1: System      | | Volume 2: Data        | | Volume 3: Preboot     | | Volume 4:...| | |
| | | APSB + Volume OMAP    | | APSB + Volume OMAP    | | APSB + Volume OMAP    | | APSB        | | |
| | +-----------------------+ +-----------------------+ +-----------------------+ +-------------+ | |
| +-----------------------------------------------------------------------------------------------+ |
+---------------------------------------------------------------------------------------------------+

Core Structural Components of APFS

1. Container Superblock (NXSB - NX_SUPERBLOCK):
   • Located at Block 0 of the container.
   • Magic Signature: Four ASCII bytes NXSB (0x4E 0x58 0x53 0x42, little-endian integer 0x4253584E).
   • Contains container block size (typically 4096 bytes), total block count, container UUID, and pointers to the Space Manager, Checkpoint Map, and Container Object Map.
2. Checkpoint Map & Transactions:
   • APFS does not use a traditional circular journal like ext4 JBD2 or NTFS $LogFile.
   • Instead, it uses checkpoints. When state changes occur, metadata updates are written to new blocks, and an updated Checkpoint Superblock is committed atomically.
3. Volume Superblock (APSB - APFS_SUPERBLOCK):
   • Each volume inside the container has its own volume superblock.
   • Magic Signature: Four ASCII bytes APSB (0x41 0x50 0x53 0x42, little-endian integer 0x42535041).
   • Stores volume role (System, Data, Recovery, VM, Preboot), volume name, encryption settings, volume UUID, and points to the Volume Object Map.
4. Object Map (OMAP):
   • The critical translation layer of APFS. Maps virtual Object IDs (OIDs) to physical Block IDs (PBNs).
   • Because file system structures reference virtual OIDs rather than fixed disk sectors, APFS can relocate metadata or create instant snapshots without re-writing underlying data blocks.
5. Space Manager (Spaceman):
   • Manages free block allocation across the entire container pool. Maintains free-space allocation bitmaps, chunk structures, and allocation queues.

Copy-on-Write (CoW) Allocation & Forensic Persistence

APFS enforces a Copy-on-Write (redirect-on-write) design paradigm:

• When a file's metadata or data payload is updated, the operating system never overwrites the existing disk blocks in place.
• The storage driver writes the modified data to newly allocated blocks in the container pool.
• The OMAP is updated to point the virtual Object ID to the new physical block numbers.
• Forensic Impact: The original, un-modified blocks remain physically intact on the storage media until the Space Manager reclaims and redistributes them. In incident investigations, historical versions of system files, scripts, and logs can often be recovered by parsing superseded OMAP tree nodes from unallocated space!

---

APFS Snapshots in Digital Investigations

An APFS Snapshot is a read-only, point-in-time image of an APFS volume. Because APFS utilizes Copy-on-Write, creating a snapshot does not duplicate data blocks; it simply preserves the root node of the Volume Object Map at that precise instant.

+---------------------------------------------------------------------------------------------------+
|                                APFS SNAPSHOT PRESERVATION TIMELINE                                |
+---------------------------------------------------------------------------------------------------+
| Time T0: Snapshot Created   -> Volume OMAP Root frozen in snapshot record                         |
| Time T1: Malware Infection  -> New files written to NEW blocks; existing files updated via CoW    |
| Time T2: Anti-Forensics     -> Attacker runs 'rm -rf /var/log/*' and deletes payload             |
| Forensic Reality:           -> The snapshot STILL references the original T0 blocks!              |
|                             -> 100% of deleted logs and malware files remain intact in snapshot!   |
+---------------------------------------------------------------------------------------------------+

Forensic Value of Snapshots

• Immunity to In-Guest Deletion: Even if an adversary achieves root privilege, terminates logging daemons, and wipes event logs or bash histories from the active file system, they cannot alter an existing read-only snapshot without deleting the snapshot itself.
• Automated Retention: macOS automatically generates local APFS snapshots prior to operating system updates (APFS sealed system snapshots) and periodically via Time Machine (com.apple.TimeMachine.*.local).

Practical Snapshot Investigation Commands

Forensic examiners can enumerate and mount local snapshots during live triage or from mounted forensic disk images:

# 1. List all APFS snapshots on the Data volume using diskutil
diskutil apfs listSnapshots /System/Volumes/Data

# 2. List local Time Machine snapshots via tmutil
tmutil listlocalsnapshots /
# Output: com.apple.TimeMachine.2026-09-21-143022.local

# 3. Create a read-only mount point for a specific snapshot
mkdir /mnt/forensic_snapshot
mount_apfs -s com.apple.TimeMachine.2026-09-21-143022.local /System/Volumes/Data /mnt/forensic_snapshot

# 4. Analyze pristine pre-incident artifacts inside the mounted snapshot
ls -la /mnt/forensic_snapshot/Users/victim/Downloads/
cat /mnt/forensic_snapshot/private/var/log/system.log

---

Extended Attributes (xattr) & Gatekeeper Tracking

macOS relies heavily on file Extended Attributes (xattr) to enforce security boundaries and track file provenance. These attributes are preserved within the APFS inode or specialized attribute records.

+---------------------------------------------------------------------------------------------------+
|                        KEY macOS EXTENDED ATTRIBUTES IN DFIR                                      |
+---------------------------------------------------------------------------------------------------+
| com.apple.quarantine             | Flags, timestamp, downloading app, and UUID                   |
| com.apple.metadata:kMDItemWhereFroms | Dual-URL list: direct download URL + referrer web page    |
| com.apple.macl                   | macOS Catalina+ Mandatory Access Control Label (TCC privacy)  |
+---------------------------------------------------------------------------------------------------+

1. com.apple.quarantine

When an untrusted file is downloaded from the Internet via a web browser (Safari, Chrome), received via AirDrop, or transferred via an email client (Apple Mail), the operating system immediately attaches the com.apple.quarantine extended attribute.

• String Structure: flag;timestamp;agent_name;UUID
• Example Value: 0083;650dd201;Safari;9F83A20B-7D1E-4B9A-94B2-1E823C4D89A1
  • 0083: Quarantine flags (indicates Gatekeeper quarantine prompt required upon execution).
  • 650dd201: Hexadecimal representation of the POSIX download timestamp (0x650dd201 = September 22, 2023).
  • Safari: User-agent application responsible for the download.
  • 9F83A20B-...: A unique UUID assigned to the quarantine event.

The QuarantineEvents Database

The quarantine UUID links directly into a central SQLite database maintained in each user's profile: ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV* (typically QuarantineEventsV2)

Forensic examiners can query this database using SQLite to extract the exact origin of an infected binary:

-- Query the user's quarantine database for downloaded executables
SELECT 
    LSQuarantineEventIdentifier AS UUID,
    datetime(LSQuarantineTimeStamp + 978307200, 'unixepoch') AS DownloadTime,
    LSQuarantineAgentBundleIdentifier AS Application,
    LSQuarantineDataURLString AS DownloadURL,
    LSQuarantineOriginURLString AS ReferrerURL
FROM LSQuarantineEvent
WHERE LSQuarantineDataURLString LIKE '%.sh' OR LSQuarantineDataURLString LIKE '%.pkg';

2. com.apple.metadata:kMDItemWhereFroms

A binary Property List (.plist) extended attribute populated by Spotlight and browsers. It explicitly records a two-element array:

1. The direct URI from which the file was fetched (https://malicious-c2.com/stage2.bin).
2. The referring website (https://compromised-forum.com/thread/102).

# Inspect extended attributes on a suspicious file using xattr
xattr -l invoice_document.pdf

# Extract and print the binary plist of WhereFroms
xattr -p com.apple.metadata:kMDItemWhereFroms invoice_document.pdf

---

Apple Unified Log (AUL) Telemetry

Introduced in macOS 10.12 (Sierra), the Apple Unified Log (AUL) consolidated system logs into a unified, high-performance binary logging architecture managed by the logd daemon, deprecating plaintext /var/log/system.log files.

Storage Architecture and .tracev3 Files

• Log Directories:
  • /var/db/diagnostics/: Stores the primary binary log files (.tracev3). Subdirectories include Persist/ (standard long-term retention logs) and HighVolume/ (verbose subsystem logging).
  • /var/db/uuidtext/: Stores shared string formatting tables and UUID metadata. Logs in .tracev3 do not store full plaintext strings; they store pointers to format strings inside uuidtext to conserve disk space.
• Forensic Acquisition: To parse an extracted AUL offline, an examiner must collect both /var/db/diagnostics/ AND /var/db/uuidtext/. Parsing .tracev3 files without the matching uuidtext directory produces unresolvable string references.

Querying Logs with the log Utility

# Stream live logs filtered by subsystem
log stream --predicate 'subsystem == "com.apple.security.pki"'

# Query historical logs from an extracted forensic image mount
log show --diagnostics /mnt/image/var/db/diagnostics --predicate 'process == "sudo"' --style syslog

# Investigate external USB mass storage insertion events
log show --predicate 'eventMessage contains[c] "USB" and subsystem contains[c] "storage"' --last 2d

---

FileVault 2 Full-Disk Encryption & Recovery

FileVault 2 provides full-disk encryption for macOS systems using XTS-AES 128 or XTS-AES 256 ciphers.

• Key Hierarchy:
  1. Volume Encryption Key (VEK): The symmetric AES key that encrypts and decrypts raw disk sectors. Stored encrypted on the volume.
  2. Key Encryption Key (KEK): Encrypts the VEK. Derived from either the user's login password (via PBKDF2), an iCloud escrow, or a Recovery Key.
  3. Personal Recovery Key (PRK): An alphanumeric string generated during FileVault setup, presented to the user for emergency recovery.
  4. Institutional Recovery Key (IRK): An enterprise certificate deployed via Mobile Device Management (MDM) that allows corporate IT to unlock endpoints.
• Volatile Memory Extraction: When a FileVault 2 volume is unlocked and running, the VEK resides unencrypted in volatile system memory (RAM). If physical or DMA-based memory acquisition is conducted prior to shutdown, the VEK can be extracted from the kernel memory space to decrypt the APFS container offline.

---

FSEvents, Spotlight Metadata and APFS Acquisition Tooling

FSEvents: The macOS Change Journal

/.fseventsd/ on each volume holds gzip-compressed log files recording file system change events — creation, modification, rename, and removal — with a monotonically increasing event identifier rather than a wall-clock timestamp.

• Why it matters: FSEvents records that a file existed and was changed even after the file itself is deleted and its metadata is gone. It is the closest macOS analogue to the NTFS $UsnJrnl.
• Dating an event: because records carry event IDs rather than timestamps, the examiner anchors the sequence against files whose creation times are known, then interpolates. The per-log-file naming and modification times provide coarse bounds.
• Limitations: the store is periodically pruned, and events are coalesced per path, so a path changed many times may appear once with combined flags.
• Parsing: FSEventsParser (Nicole Ibrahim) and the FSEvents modules in mac_apt and commercial suites decode the flag bitfields into readable operations.

Spotlight Metadata

Spotlight maintains .Spotlight-V100/ on each volume, whose store files index far more than filenames: kMDItemWhereFroms (the URL a file was downloaded from), kMDItemLastUsedDate, kMDItemDownloadedDate, author, and application-specific attributes.

mdls suspicious.dmg                    # all Spotlight attributes for one item (live system)
mdfind "kMDItemWhereFroms == '*dropbox*'"

kMDItemWhereFroms frequently survives when browser history has been cleared, making it an independent source of download provenance. Offline parsing of the store files is supported by spotlight_parser and mac_apt.

Unified Logs and Quarantine

• Unified Logging (/var/db/diagnostics/*.tracev3) replaced the legacy /var/log/system.log and is a binary format read with log show --archive on a macOS host or parsed offline with UnifiedLogReader and mac_apt. It records process launches, network state, and authentication activity with high fidelity but a short retention window.
• Gatekeeper quarantine (com.apple.quarantine extended attribute plus QuarantineEventsV2 in the user's Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 database) records the download URL, referrer, and timestamp for files fetched from the internet.

APFS Acquisition Tooling

APFS's container-and-snapshot design complicates imaging: snapshots share blocks with the live volume, and a naive logical copy silently loses them.

[!IMPORTANT] On Apple Silicon and T2 systems, storage is encrypted at the hardware level and the internal drive cannot be imaged meaningfully by removing it. Acquisition must be performed on the live, unlocked system — typically a logical or targeted collection with credentials, or a memory acquisition — which makes the decision to power the machine down effectively irreversible.