courses

Apple File Systems: HFS+ and APFS

Apple has shipped two major file systems with macOS: HFS+ (HFS Plus, also called Mac OS Extended), which dates to 1998 and remains common on older drives and disk images, and APFS (Apple File System), introduced in 2017 and now the default on all Apple platforms. A forensic examiner working on Mac evidence must understand both: APFS is the present, but HFS+ volumes are still encountered in legacy hardware, backups, and disk images, and the two systems have very different forensic profiles.

HFS+

HFS+ was Apple’s primary file system for nearly two decades. It replaced the original HFS in Mac OS 8.1 (1998) and remained the macOS default until High Sierra (2017). It is a B-tree-structured file system, meaning most of its key metadata structures are organized as balanced trees.

Volume Header

The HFS+ volume header is the root metadata structure, stored at byte offset 1024 from the start of the volume (leaving room for the boot block). A backup copy is stored at 1024 bytes before the end of the volume. The volume header contains:

Field Description
drSigWord Magic number 0x482B (“H+”)
drCrDate Volume creation date
drLsMod Volume last-modified date
drVolBkUp Date of last backup
drNmFls Number of files on the volume
drNmAlBlks Number of allocation blocks
drAlBlkSiz Allocation block size in bytes
drClpSiz Default clump size
B-tree pointers Extents, catalog, attributes, startup, hot-files

Forensic note: the creation date in the volume header can help establish when a volume was first formatted. If a suspect reformatted a drive after a preservation order was issued, the volume creation date will post-date the order. Unlike NTFS’s $MFT creation time, the HFS+ volume header creation date is not normally updated after initial formatting.

HFS+ Timestamps

HFS+ stores timestamps as 32-bit unsigned integers representing seconds since January 1, 1904 (the original Mac epoch). The maximum representable time is February 6, 2040 — at that point, HFS+ timestamps will overflow.

Timestamps are stored in local time, not UTC. This is a significant forensic complication: the same timestamp value represents different absolute times depending on the time zone of the machine that wrote it. Forensic tools must know (or correctly assume) the time zone of the source machine to convert HFS+ timestamps to UTC.

Forensic note: HFS+ timestamps have one-second resolution. This is coarser than NTFS (100-nanosecond) and far coarser than APFS (nanosecond). Multiple events that occurred within the same second will share an identical timestamp, which can complicate timeline reconstruction.

B-Tree Structure

HFS+ organizes all metadata into B-trees — specifically, B* trees. Each B-tree is a special file whose data consists of tree nodes. There are four (optionally five) B-tree files on an HFS+ volume:

B-Tree Purpose
Catalog B-Tree All files and directories: names, metadata, fork extents for small files
Extents Overflow B-Tree Additional extent records when a file’s extents don’t fit in the catalog
Attributes B-Tree Extended attributes (xattrs)
Hot Files B-Tree Tracks frequently accessed small files (optional)
Startup File Boot code (optional)

The Catalog B-Tree

The catalog B-tree is forensically the most important structure in HFS+. It contains one or more catalog records for every file and directory on the volume:

When a file is deleted in HFS+, its catalog records are removed from the B-tree and the tree is rebalanced. The freed nodes become available for reuse by new B-tree records. Unlike NTFS’s MFT, where deleted file records persist until reallocated, HFS+ catalog records may be quickly overwritten after deletion. This makes deleted-file recovery via metadata more difficult on HFS+ than on NTFS.

The Extents Overflow B-Tree

HFS+ catalog records store up to 8 extent records per fork inline. If a file is fragmented into more than 8 extents, the overflow extents are stored in the extents overflow B-tree, keyed by (CNID, fork type, start block). Highly fragmented files will have more data here.

Forensic note: recovering a deleted file’s content when its catalog record has been overwritten requires finding its extents overflow entries (if any) and identifying its allocation blocks from the volume’s allocation file. Without the catalog record, you have no starting point for the extents, making metadata-based recovery essentially impossible. File carving on unallocated space is the fallback.

Allocation File

The allocation file is HFS+’s equivalent of NTFS’s $BitMap — a bitmap mapping every allocation block on the volume to an allocated (1) or free (0) status. When a file is deleted, its allocation blocks are marked free in the allocation file. The data in those blocks is not overwritten. Until the blocks are reused, the content is physically present on disk.

Forks: Data Fork and Resource Fork

A distinctive feature of HFS+ is that every file has two forks: a data fork (the normal file content) and a resource fork (structured metadata historically used to store Mac-specific data: icons, menus, sounds, code resources). Resource forks are largely unused by modern applications but persist in the file system.

When HFS+ files are copied to a non-HFS file system (FAT, NTFS, UFS), the resource fork is either lost or stored as a separate AppleDouble file — a hidden file with the same name prefixed by ._ (e.g., ._document.pdf). These ._ files are a common artefact on FAT-formatted USB drives and Windows NTFS volumes that were connected to a Mac. They can reveal that specific files originated from a Mac system.

Forensic note: resource forks can contain hidden data. An attacker with knowledge of HFS+ internals can store data in a resource fork, making it invisible to users and naive file browsing tools. Forensic tools must explicitly enumerate resource forks.

Extended attributes (stored in the attributes B-tree) are used by macOS to attach security and provenance metadata to files. Particularly significant ones are discussed in the Extended Attributes section below.

HFS+ Journaling

Journaling was added to HFS+ in Mac OS X 10.2 (Jaguar). The HFS+ journal is a write-ahead log stored on the volume. Metadata changes are written to the journal first, then applied to the main B-trees. If the system crashes before a change is committed, the journal entry allows recovery on next mount.

Forensic note: unlike NTFS’s $LogFile, the HFS+ journal is circular and of limited size (default 8 MB). It is overwritten quickly in normal use. On a recently seized system, the journal may contain recent metadata operations, but it is not a reliable long-term record. The journal does not record file content — only metadata changes.

HFS+ supports POSIX symbolic links (stored as file records with a special type and the link target in the data fork) and hard links. Hard links in HFS+ are implemented indirectly via indirect nodes stored in a hidden directory (\000\000\000\000HFS+ Private Data) at the volume root. Each hard-linked file’s catalog record points to an indirect node; multiple file records can point to the same indirect node.

Forensic note: the hidden private data directory is invisible in the Finder but accessible to forensic tools. If a user created hard links to sensitive files, those links persist in the private directory even after the user-visible file is deleted, as long as the link count in the indirect node is nonzero.

APFS

Apple File System (APFS) was designed from scratch for flash storage and announced at WWDC 2016. It became the default for iOS in iOS 10.3 (March 2017) and for macOS in High Sierra (September 2017). APFS replaces HFS+ on all Apple silicon Macs, T2-equipped Intel Macs, iPhones, iPads, Apple Watches, and Apple TVs. Time Machine drives still use HFS+ by default (as of macOS 14 Sonoma), but can use APFS on external SSDs.

APFS Container and Volumes

APFS introduces a two-level hierarchy analogous to ZFS pools and datasets:

Concept Description
Container The top-level storage unit, analogous to a ZFS pool. Spans one or more physical partitions. Manages space allocation for all volumes within it.
Volume A logical file system within a container. Multiple volumes share the container’s free space without pre-allocated partitions.

A standard macOS installation creates a single APFS container containing several volumes, each with a designated role:

Volume Role Purpose
System Read-only macOS system files (macOS 11+)
Data User data and installed applications
Preboot Files needed to boot each volume
Recovery macOS Recovery environment
VM Swap space
(User-created) Additional volumes as needed

Forensic implication: you cannot acquire a single APFS volume in isolation and expect a complete picture. All volumes in a container share the same allocation pool. To image an APFS system, you must image the entire container (or the entire physical disk). Tools that image only the “Macintosh HD” partition may miss other volumes in the same container.

Copy-on-Write and Transactions

Like ZFS, APFS is copy-on-write. Modifications never overwrite existing data in place; new versions are written to new locations, and the old data persists until its blocks are reclaimed. All changes within a single logical operation are grouped into a transaction and committed atomically.

Forensic implication: on a live APFS system, previous versions of recently modified files and metadata may be physically present on disk until their allocation blocks are reused. However, without snapshot metadata pointing to those blocks, they are not easily located — file carving on unallocated space is the primary recovery mechanism.

B-Tree Structure

APFS uses B-trees extensively, but they are more flexible than HFS+’s. Key APFS B-trees:

B-Tree Key Contents
Object Map (oid, xid) Maps logical object IDs to physical block addresses at a given transaction ID
File System Tree (per volume) (object ID, type, key) All file system objects: inodes, directory entries, xattrs, extent records
Extents B-Tree (per container) Physical block address Tracks which transactions reference which physical blocks (for space management)
Omap (per snapshot) Object ID Snapshot-specific object map
Free Queue Transaction ID Tracks blocks freed in each transaction

The object map is central to APFS’s snapshot and clone implementation. Every object in APFS (file, directory, metadata node) has a logical object ID (oid). The object map translates (oid, transaction ID) pairs to physical block addresses. A snapshot is essentially a frozen object map from a past transaction.

Snapshots

An APFS snapshot is a point-in-time read-only view of a volume. Because of CoW and the object map, creating a snapshot is instantaneous — it pins the current transaction ID, preventing the object map entries from that transaction from being evicted.

Time Machine on APFS uses local snapshots (called local snapshots or APFS snapshots) to provide quick restore points without a backup drive. These snapshots are stored on the same volume.

Forensic note: APFS snapshots are among the most powerful forensic artifacts on a Mac. They preserve the exact state of the volume at the time of the snapshot, including files deleted or modified afterward. To list snapshots:

# On the live system (requires root):
tmutil listlocalsnapshots /
# or with diskutil:
diskutil apfs listSnapshots disk3s1

Mounting a snapshot read-only:

# Mount the snapshot at a specific point:
mount -t apfs -o ro,nobrowse -o snapshot=<snapshot-name> /dev/disk3s1 /mnt/snapshot

On a forensic image, tools such as apfs-fuse (Linux) can mount APFS containers and access snapshots.

Snapshot creation time is recorded in the snapshot’s metadata and reflects wall-clock time with nanosecond precision (if the system clock was accurate). Time Machine snapshot names encode the creation time: com.apple.TimeMachine.2024-11-08-143022 is a snapshot taken on November 8, 2024 at 14:30:22 local time.

Clones

APFS clones are instant, space-efficient copies of files or directories. When a file is cloned (cp -c or clonefile(2) syscall), the clone shares all the original’s data blocks via the CoW mechanism. No data is actually copied — both the original and the clone reference the same physical blocks until either is modified.

Forensic note: clones complicate storage analysis. A du listing may dramatically over-report the space used by a directory if it contains clones — the actual on-disk footprint is much smaller because of shared blocks. More importantly, if an attacker creates clones of sensitive files and then deletes the originals, the data blocks persist as long as any clone exists. The clone appears as a normal file with no special markers visible to users.

Encryption

APFS supports per-volume encryption using AES-XTS. Encryption is always hardware-accelerated on Apple silicon and T2-equipped Intel Macs. Three encryption modes are available:

Mode Description
Not encrypted No encryption
Single-key All files in the volume share one encryption key
Multi-key Each file (and its metadata) encrypted with a per-file key

FileVault on macOS uses APFS single-key encryption for the Data volume. The encryption key is derived from the user’s login password via PBKDF2 and protected by the Secure Enclave on T2/Apple Silicon hardware.

Forensic implication: on a T2 or Apple Silicon Mac, the encryption key is bound to the Secure Enclave. Imaging the drive and attempting to decrypt it offline — without the Secure Enclave — is not possible without the user’s password. The Secure Enclave will not surrender the key to external hardware. Physical extraction of the NAND flash is possible but the data remains encrypted.

On older Intel Macs without T2, FileVault uses a software key stored on the volume’s Preboot partition. Imaging and offline decryption is possible if the password or recovery key is known.

What is not encrypted even with FileVault enabled:

Forensic note: metadata disclosure from an encrypted APFS container can reveal volume names, snapshot timestamps, and the existence of specific volumes (e.g., a volume named secure_docs) even without the decryption key. Container-level B-trees are not encrypted.

Sealed System Volumes

Starting with macOS 11 (Big Sur), the System volume (containing macOS itself) is sealed: a cryptographic hash tree covers every file on the volume. The hash tree root is embedded in the volume’s superblock and checked at boot by the boot ROM. Any modification to the System volume — even a single bit — will invalidate the seal and prevent booting.

Forensic note: the sealed system volume provides strong integrity assurance. An attacker cannot modify system binaries, kernel extensions, or launch daemons on the System volume without physically booting into Recovery Mode and explicitly disabling SIP and sealing. Any evidence of a broken seal (csrutil status) is forensically significant. Additionally, the System volume is mounted read-only at / and shares its data via firmlinks with the Data volume — forensic tools must understand this split to correctly enumerate all files.

APFS Timestamps

APFS stores timestamps as 64-bit nanoseconds since the Unix epoch (January 1, 1970 UTC). This provides nanosecond resolution and a range that won’t overflow until the year 2554. Timestamps are stored in UTC, eliminating the HFS+ time zone ambiguity.

Each inode in APFS stores four timestamps:

Timestamp Field Description
Created create_time When the inode was first created
Modified mod_time When the file’s data was last modified
Changed change_time When inode metadata was last changed
Accessed access_time When the file was last accessed

Forensic note: APFS access_time updates are suppressed by default on SSDs (similar to Linux’s relatime mount option) to reduce write amplification. Do not rely on access times as evidence of recent reading.

Checksums

APFS checksums all metadata blocks using Fletcher-64. However — unlike ZFS — APFS does not checksum user data blocks by default. This means:

Forensic note: checksum failures on APFS metadata may indicate physical media damage or deliberate tampering. A suspect who attempted to modify on-disk metadata structures directly (bypassing the file system) would likely produce checksum failures detectable by fsck_apfs -n.

Extended Attributes

Both HFS+ and APFS support extended attributes (xattrs) — arbitrary key-value pairs attached to files or directories. On Apple systems, xattrs are a primary mechanism for attaching provenance and security metadata, and are a rich source of forensic evidence.

com.apple.quarantine

The quarantine attribute is set by macOS Gatekeeper on any file downloaded from the internet or received via AirDrop, email, or messaging. Its value includes:

xattr -p com.apple.quarantine suspect_file.dmg
# Example: 0083;65b8c120;Google Chrome;A1B2C3D4-...

Forensic significance: the quarantine attribute establishes when a file was downloaded and what application downloaded it. The quarantine database at com.apple.LaunchServices.QuarantineEventsV2 is an SQLite database that persists records even after the xattr has been removed from the file:

sqlite3 ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2 \
  "SELECT * FROM LSQuarantineEvent ORDER BY LSQuarantineTimeStamp DESC LIMIT 20;"

com.apple.metadata:kMDItemWhereFroms

This xattr, set by Safari and many other download managers, stores the source URL and referrer URL from which a file was downloaded, as a binary plist:

xattr -p com.apple.metadata:kMDItemWhereFroms suspect.zip | xxd | ...
# or use mdls:
mdls -name kMDItemWhereFroms suspect.zip

Forensic significance: this attribute can establish exactly which URL a file was downloaded from, even if the browser history has been deleted. The referring URL is often the page that linked to the download (e.g., a specific forum post, an email link).

com.apple.provenance

Added in macOS 14 Sonoma, this xattr records a broader set of provenance information about a file’s origin, designed for use by Gatekeeper and XProtect.

Other Forensically Relevant xattrs

Attribute Meaning
com.apple.lastuseddate#PS Last time the file was opened by a user
com.apple.FinderInfo Finder color labels, file type codes
com.apple.ResourceFork Resource fork data (when stored as xattr)
security.selinux SELinux label (rare on macOS)

Spotlight Metadata

Spotlight is macOS’s system-wide indexing service. It indexes file contents, metadata, and xattrs and stores results in a private database at /.Spotlight-V100/ on each volume. The Spotlight database is a valuable forensic artifact:

Spotlight data can be queried on a live system with mdls (per-file metadata) and mdfind (content search):

# Metadata for a specific file:
mdls /path/to/file

# Search for files containing a term (live system):
mdfind "kMDItemTextContent == '*password*'c"

For forensic analysis of an offline image, the Spotlight store can be parsed by tools such as mac_apt and Autopsy.

Data Recovery on HFS+ and APFS

HFS+ Recovery

Because HFS+ removes catalog records on deletion and quickly reuses B-tree nodes, metadata-based recovery is less reliable than on NTFS. The primary approaches:

  1. Allocation file analysis: identify unallocated blocks. For recently deleted files, the block contents may still be intact.
  2. B-tree node carving: even if a catalog record has been overwritten in the live B-tree, the previous version of the B-tree node may still be physically present on the disk (HFS+ does not use CoW for B-tree updates in the same way APFS does). Specialized tools can search for HFS+ B-tree node headers in unallocated space.
  3. File carving: search for file signatures in unallocated blocks. HFS+ does not use compression by default, making carving more effective than on APFS or ZFS with compression enabled.
  4. Spotlight database: may contain metadata or indexed content for recently deleted files.

APFS Recovery

APFS’s CoW design means deleted file data persists until blocks are reused, but the object map metadata linking those blocks to their original file is removed on deletion. Recovery approaches:

  1. Snapshots: the most reliable method. List and mount available snapshots to access the file at a pre-deletion state.

  2. apfs-fuse with snapshot access (on Linux forensic workstations): supports mounting APFS volumes and reading snapshots from forensic images without touching the original media.

  3. fsck_apfs and apfs_diagnostic: Apple’s own tools can surface internal inconsistencies and, in some configurations, log transaction details useful for timeline reconstruction.

  4. Commercial tools: Cellebrite UFED, Elcomsoft Phone Breaker, BlackLight, and Axiom Cyber all support APFS parsing and snapshot enumeration. Autopsy with the APFS plugin can process APFS images.

  5. File carving: as with HFS+. APFS does not use compression by default on rotational media (though it does by default on flash), so carving may work on images from spinning-disk Macs. On SSD-based Macs with APFS compression enabled, carving is less effective.

  6. Trim/Secure Delete consideration: on SSD-based Macs, the OS issues TRIM commands to the SSD, which may cause the SSD controller to erase freed blocks at the hardware level. Data from deleted APFS blocks on an SSD may be irrecoverable even shortly after deletion, depending on the SSD firmware’s TRIM implementation.

Anti-Forensics on Apple Systems

Secure Empty Trash / Secure Erase

Apple removed the “Secure Empty Trash” option from the Finder in macOS Sierra (2016), citing its ineffectiveness on SSDs with APFS. On flash storage, TRIM and wear leveling mean that overwriting specific logical blocks does not reliably erase the underlying physical cells. Forensic examiners should note that the absence of a secure erase feature does not mean deleted content is always recoverable — TRIM complicates recovery independently of user action.

Clearing Quarantine Attributes

A user can remove the quarantine xattr from a file:

xattr -d com.apple.quarantine file.dmg

However, the quarantine database (QuarantineEventsV2) retains the original download event record. Removing the xattr from the file does not remove the database record. Forensic examination should always query the database, not just file xattrs.

Deleting Spotlight Data

The Spotlight index can be deleted by the user (sudo mdutil -E /) and is also automatically rebuilt. A rebuilt index will not contain entries for previously deleted files. However, the Spotlight store’s B-tree nodes, like other CoW B-trees on APFS, may leave recoverable traces.

FileVault on T2/Apple Silicon

As discussed above, FileVault on modern Macs binds the volume key to the Secure Enclave. There is no offline attack. The only practical access is via:

Forensic Workflow Summary

Step Action Tool
1 Image the entire physical disk (not just the partition) dd, dc3dd
2 Identify APFS container and volume structure diskutil apfs list, apfs-fuse, Autopsy
3 List APFS snapshots on each volume tmutil listlocalsnapshots, diskutil apfs listSnapshots
4 Mount evidence image read-only apfs-fuse -o ro, Autopsy, BlackLight
5 Mount and examine snapshots apfs-fuse snapshot option; mount -o snapshot=
6 Examine quarantine database sqlite3 ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV2
7 Extract per-file provenance xattrs xattr -l <file>, mdls <file>
8 Query Spotlight store for deleted file evidence mac_apt, Autopsy APFS plugin
9 Carve unallocated space (if no snapshots) photorec, foremost, Autopsy
10 Check volume seal integrity csrutil status, diskutil apfs list (sealed status)

Always work from a verified forensic image. APFS will not write to a read-only mounted container, but some macOS daemons (Spotlight, fseventsd, mds) will attempt to access newly mounted volumes. Mounting evidence images in a controlled environment (via write blocker or read-only mount) prevents contamination.

Further Reading