APFS: containers, volumes, snapshots and encryption

Apple File System (APFS) is the file system of every current Mac, iPhone and iPad. Its layout differs from NTFS and ext4: one partition holds a container, and the container holds several volumes that share its free space. This lesson explains the on-disk structures you will meet in a disk image, why user evidence sits on one particular volume, how snapshots and checkpoints can preserve earlier states, how APFS stores timestamps, and why encryption decides whether a Mac image is readable at all.

From partition to container

APFS replaced HFS+ as the default file system in iOS 10.3 and in macOS 10.13 High Sierra (both 2017). A Mac disk is partitioned with GPT (Lesson 1.1). The APFS partition has the GPT partition type GUID 7C3457EF-0000-11AA-AA11-00306543ECAC, and each such partition holds exactly one APFS container. A typical Intel Mac disk has a protective MBR at LBA 0, the GPT header at LBA 1, a small EFI System Partition and then the APFS container. Apple silicon Macs add small APFS containers for boot and recovery support; user data is in the main container.

The container is divided into blocks, normally 4,096 bytes. Every APFS object starts with a 32-byte header (a Fletcher-64 checksum, an object ID, a transaction ID, a type and a subtype), so the object's own fields start at offset 32. The container superblock (nx_superblock_t) sits in block 0 of the container and carries the magic NXSB at offset 32, followed by the block size and the block count.

Worked example: finding the container superblock

mmls reports an APFS partition starting at sector 409,640 on a disk with 512-byte sectors.

• Byte offset of the container: 409,640 × 512 = 209,735,680.
• Offset of the NXSB magic: 209,735,680 + 32 = 209,735,712.

At that offset you should read the bytes 4E 58 53 42 ("NXSB"). Check the sector size first: many Apple internal SSDs use 4,096-byte logical sectors, and multiplying by 512 there gives the wrong offset.

Copy-on-write, checkpoints and the object map

APFS is copy-on-write: it never overwrites live metadata in place. A change is written to new blocks, and the file system then commits a new checkpoint, a consistent snapshot of its metadata identified by a transaction ID (XID) that increases with every commit. Checkpoint descriptors and superblock copies are kept in a ring of blocks called the checkpoint descriptor area. When mounting, APFS looks for the valid superblock with the highest XID. The copy in block 0 is not guaranteed to be the newest one.

For an examiner this matters in two ways. First, older checkpoints still in the ring can describe an earlier metadata state, including directory entries for files that have since been deleted or renamed. Second, blocks released by copy-on-write are not wiped; they become free space and keep their content until reused. Lesson 1.8 covers how recovery tools exploit this.

Most metadata objects are virtual: they are referenced by an object ID, not by a block address. The object map (omap) is a B-tree that translates an object ID plus an XID into a physical block number. The container has its own object map, and every volume has another. Because entries are keyed by XID, an older object map can still point to an older version of the same object.

Volumes and the macOS volume group

A container can hold many volumes (the format allows up to 100). Each volume has its own superblock (apfs_superblock_t, magic APSB at offset 32), its own file system tree and its own encryption state, but none has a fixed size: all volumes allocate blocks from the container's shared free space. By default every volume therefore reports the same free space.

Since macOS 10.15 Catalina the startup disk is split into volumes with distinct roles; the System and Data volumes together form a volume group:

Since macOS 11 Big Sur the System volume is a Signed System Volume (SSV). Every file is covered by a tree of SHA-256 hashes, and the Mac boots from a sealed snapshot of that volume (named com.apple.os.update- followed by a hash) rather than from the live volume. Any modification breaks the seal. The practical conclusion: on Catalina and later, the user's files, settings, logs and application databases are on the Data volume.

Firmlinks

The user sees one file system tree, not two volumes. The Data volume is mounted at /System/Volumes/Data, and firmlinks, bidirectional links defined by the system (listed in /usr/share/firmlinks), make directories such as /Users, /Applications and /private (and so /private/var) appear at their usual locations. When you parse the Data volume of an image directly, a user's home is at /Users/<name> relative to that volume's root. A live system shows the same files at both /Users/<name> and /System/Volumes/Data/Users/<name>. Record which form your tool printed, and report the path the task asks for.

Snapshots

An APFS snapshot is a read-only, point-in-time view of a volume. Taking one costs almost nothing, because the snapshot only keeps the blocks that existed at that moment from being freed. Later changes go to new blocks under copy-on-write. Two kinds matter in casework:

• Local Time Machine snapshots of the Data volume, named com.apple.TimeMachine. plus a date and time (for example com.apple.TimeMachine.2024-03-05-101512.local on recent macOS). macOS creates them when Time Machine is enabled, usually about hourly, keeps them for a short time (about 24 hours) and removes them sooner when space runs low.
• System update snapshots of the System volume, created when macOS installs updates, including the sealed snapshot the Mac boots from.

A snapshot can hold an earlier version of a database, a document the user later deleted, or a log that has since rotated. On a live Mac, tmutil listlocalsnapshots / or diskutil apfs listSnapshots <volume> lists them. In an image, a tool that understands APFS can mount or parse a snapshot by name. Do not take a UTC time from the snapshot name: the snapshot's metadata record holds its creation time as an APFS timestamp, and that is the value to report. Always state which snapshot an artifact came from: a value read from a snapshot describes the volume at snapshot time, not at seizure.

Timestamps and file metadata

APFS stores timestamps as unsigned 64-bit integers counting nanoseconds since 1970-01-01 00:00:00 UTC, little-endian on disk. Each inode record has four:

APFS also keeps a date added in the directory entry, which Finder shows as "Date Added" and which records when an item arrived in its current folder. Other Apple time formats look different and must not be confused with APFS times:

Worked example: decoding an APFS timestamp

The eight bytes of a create_time field read 15 CD 85 3D FE 9C 97 17.

• Reverse the little-endian bytes: 0x17979CFE3D85CD15 = 1,700,000,000,123,456,789 ns.
• Divide by 1,000,000,000: 1,700,000,000 s plus 0.123456789 s.
• 1,700,000,000 Unix seconds = 2023-11-14T22:13:20.123456789Z.

The same instant as Mac Absolute Time is 1,700,000,000 − 978,307,200 = 721,692,800 (978,307,200 is the number of seconds from 1970 to 2001). In HFS+ form it would be 1,700,000,000 + 2,082,844,800 = 3,782,844,800. The magnitude of a number (about 10^18, 10^9 or 10^8 here) quickly reveals its epoch and unit. When a task asks for seconds precision, truncate the nanoseconds rather than rounding them.

Clones

On APFS, cp -c and Finder's Duplicate create a clone: a new file with its own inode and timestamps whose extents point to the same physical blocks as the original. Only blocks modified later are written separately. Two consequences follow. Identical hashes for two files do not mean the data exists twice on disk. Deleting the original does not free its blocks while a clone still references them. Do not infer a copy operation from timestamps alone: a clone receives its own creation time even though no data was copied.

Encryption

APFS encrypts at the volume level or per file. A volume can be unencrypted, encrypted with one key for the whole volume, or encrypted with multiple keys, where each file has its own key wrapped by a class key. Multi-key per-file encryption is the iOS model. On a Mac, FileVault protects the Data volume's key with the user's login password and a recovery key.

The hardware decides what an image is worth:

• Intel Macs without a T2 chip: without FileVault the Data volume is not encrypted. With FileVault it is encrypted in software, and a full image can be decrypted offline with a user password or the recovery key.
• Macs with the Apple T2 chip or Apple silicon: internal storage is always encrypted by a hardware AES engine with keys tied to the chip's Secure Enclave, even when FileVault is off. FileVault adds the requirement that the user's credentials unlock the key.

On T2 and Apple silicon Macs, a chip-off or raw physical image taken without the keys or an unlocked system yields no readable data. Acquisition therefore depends on the original hardware: usually the live, unlocked system (a logical or triage collection), plus, when FileVault is on, the user's password or FileVault recovery key to unlock it. Module 7 covers encrypted volumes in depth.

Tools and the exam context

Examples of free tools: apfs-fuse mounts APFS images on Linux, read-only, with an option to select a volume and support for a password on encrypted volumes. The Sleuth Kit supports APFS: pstat describes the container (the "pool") and lists its volumes with the block numbers of their APSB superblocks, and fsstat, fls and icat accept -P apfs together with -B <block> to select a volume. mac_apt parses macOS artifacts from images or from collected folders. Commercial suites offer similar parsing. Whatever the tool, check which volume and snapshot it read.

The CFX exam is multiple choice, so APFS questions test the concepts and calculations in this lesson rather than hands-on analysis of a Mac image. Container knowledge explains where macOS files come from; timestamp decoding and precise path reporting carry over to every platform.

Exam focus: Expect questions on the APFS hierarchy (partition, container, volume, snapshot), the NXSB and APSB signatures, and which volume holds user data on Catalina and later. Be ready to convert a 64-bit nanosecond APFS value to ISO 8601 UTC and to tell it apart from HFS+ and Mac Absolute Time values. Know why a raw image of a T2 or Apple silicon Mac is unreadable away from the original hardware and its Secure Enclave.

Key points

• One APFS container per GPT partition (type 7C3457EF-0000-11AA-AA11-00306543ECAC); the container superblock has the magic NXSB, each volume superblock APSB, both at offset 32.
• Copy-on-write, checkpoints and the XID-keyed object map mean older metadata states can survive until blocks are reused.
• Since Catalina the read-only System volume and the Data volume form a volume group; since Big Sur the system boots from a sealed snapshot. User evidence is on the Data volume, joined to the visible tree by firmlinks.
• Local Time Machine snapshots (com.apple.TimeMachine.*) and system update snapshots preserve earlier volume states. Always record which snapshot an artifact came from.
• APFS times are 64-bit nanoseconds since 1970-01-01 UTC. HFS+ uses seconds since 1904, and Mac Absolute Time uses seconds since 2001-01-01.
• T2 and Apple silicon Macs encrypt internal storage in hardware, so acquisition needs the original hardware, usually the live unlocked system, plus the user's credentials or recovery key when FileVault is on.