Apple Silicon Forensics: What M-Series Macs Change

Apple Silicon Macs (M1 and later) look like any other Mac from the desktop, but for an examiner they are closer to an iPhone than to a classic PC. The question this article answers is practical: when the evidence is an M-series Mac, which acquisition methods still work, which ones are gone, and what platform features explain the difference? Understanding the Secure Enclave, always-on storage encryption, the boot security policy and the sealed system volume lets you plan an acquisition that succeeds instead of one that ends with an unreadable image. For the general workflow, start with macOS forensic acquisition.

From Intel to T2 to Apple Silicon

Apple moved security functions into dedicated silicon in two steps.

The T2 already made raw chip-off or off-device imaging useless because the storage controller encrypts everything with keys that never leave the chip. Apple Silicon integrates the Secure Enclave and storage controller into the main system on a chip and adds a much finer-grained boot security model.

Secure Enclave and storage encryption

Always-encrypted internal storage

On Apple Silicon, every byte written to internal flash passes through the dedicated AES engine in the storage path. The keys are derived from hardware secrets unique to the device and protected by the Secure Enclave. Consequences for the examiner:

• Chip-off and raw NAND reads are not viable. The data is ciphertext bound to that specific SoC.
• FileVault off does not mean unencrypted. Without FileVault, the volume key is protected only by hardware, so the Mac unlocks the Data volume automatically at boot. The data is readable through that Mac once it boots, but not off it.
• FileVault on adds the user's password (or a recovery key, or an institutional key where configured) to the key hierarchy. Without one of those, the Data volume stays locked.
• Erasure is fast and final. Erasing the device destroys keys, not data blocks, which is why "Erase All Content and Settings" is effectively irreversible.

Data Protection and per-file keys

Apple's platform security documentation describes Apple Silicon Macs as using the Data Protection model familiar from iOS: files get per-file keys, which are wrapped by class keys, which are in turn protected by the Secure Enclave and, depending on class, the user's credentials. Apple documents that most Mac files use a class that becomes available after the first unlock following boot. Treat the exact class assignments for individual file types as version-dependent and verify against the current Apple Platform Security guide rather than assuming iOS behavior carries over identically.

The practical takeaway: a running Mac that has been unlocked at least once since boot exposes far more data to a logical collection than a Mac that was just powered on and is sitting at the login window.

What this means for keychains and memory

Keychain items and other secrets may be further protected by the Secure Enclave. Copying keychain files gives you metadata-bearing, encrypted containers, not usable secrets (see keychain concepts). Physical memory acquisition on Apple Silicon is not practical with public tools at the time of writing, so volatile evidence must come from live commands (processes, network connections, loaded services) rather than a RAM image.

Share Disk replaces Target Disk Mode

Intel Macs offered Target Disk Mode, which made the internal disk appear as an external block device to another computer. Apple Silicon removes that. Instead, macOS Recovery offers Share Disk (sometimes called Mac Sharing Mode):

1. Start the Mac into recoveryOS by holding the power button until startup options appear, then choose Options.
2. Authenticate as an administrator if prompted.
3. Choose Share Disk from the Utilities menu and select the volume. For an encrypted volume you must unlock it with credentials.
4. Connect the examination Mac with a USB-C/Thunderbolt cable; the shared volume appears as a network (SMB) share.

Because this is file sharing, you get a logical copy: files, directories and most metadata, but no unallocated space and no block-level structures. Verify that your copy method preserves extended attributes and timestamps, and document that the acquisition went through SMB, since some metadata (for example certain timestamps or xattrs) may not survive the protocol identically. Test your procedure on a lab Mac of the same generation first.

Boot security policy

Each installed macOS on an Apple Silicon Mac has its own boot security policy, stored and enforced by the boot chain:

The policy is changed from Startup Security Utility in recoveryOS and requires an administrator's authentication. It is not a toggle an attacker can flip remotely from userland. For an investigator this cuts both ways: you cannot easily lower it to boot an external forensic OS, and if you find it already lowered, you need to explain why.

On the live system you can at least record SIP state, which is part of the policy picture:

csrutil status

bputil exists for inspecting and modifying the policy, but its options have changed across releases and it is intended for administrators; consult man bputil on the target version before using it, and prefer read-only display options.

The sealed system volume

Since Big Sur the System volume is a signed snapshot. Every file and metadata block is covered by a Merkle tree of SHA-256 hashes whose root, the seal, is verified at boot. The Mac boots from a snapshot of that volume, not the live volume. You can see the sealed status with:

diskutil apfs list

Look for the System volume and its snapshot being reported as sealed. Implications:

• The OS is not where attacker changes live. Persistence and payloads land on the Data volume: /Library/LaunchDaemons, ~/Library/LaunchAgents, /usr/local, /Applications, user folders. See launchd persistence.
• You rarely need to collect the System volume. Record sw_vers output and the build number; the content is reproducible.
• A broken seal (for example on a Mac with SIP and authenticated root disabled) is a significant finding. On Full Security it should not boot.

The System and Data volumes are joined by firmlinks so that paths like /Applications and /Users look unified. More on this layout in APFS snapshots and timestamps.

Recovery, DFU and actions to avoid

Apple Silicon Macs have several recovery paths, and some of them destroy evidence:

• recoveryOS (hold the power button) is where Share Disk, Terminal, Disk Utility and Startup Security Utility live. Booting into it does not erase data.
• Fallback recovery is a second copy used if the primary recoveryOS is damaged.
• DFU mode with Apple Configurator offers "Revive" (reinstalls firmware and recoveryOS, intended to keep user data) and "Restore" (erases everything). Never run Restore on evidence, and treat Revive as a last resort with documented justification.

Also consider Activation Lock and Find My: if the device is linked to an Apple Account, a remote erase is possible while it has network access. Isolate the Mac from networks while keeping it powered if you intend a live acquisition.

Apple Silicon specific artifacts

A few artifacts exist only because of the architecture:

• Rosetta 2 translates x86_64 binaries. Researchers have documented that ahead-of-time translation files cached under /private/var/db/oah can indicate that a specific Intel binary was executed on the Mac, even after the original is deleted. The cache format and retention are undocumented by Apple, so treat findings as supporting evidence and verify on your target version.
• Architecture of binaries: checking whether a suspicious binary is arm64, x86_64 or universal helps attribution and explains whether Rosetta was involved:

file /Users/analyst/Downloads/example-agent
lipo -archs /Users/analyst/Downloads/example-agent
codesign -dv /Users/analyst/Downloads/example-agent

On Apple Silicon, native arm64 code must be at least ad-hoc signed to run, so codesign output is always relevant.

Acquisition strategy for M-series Macs

Putting it together, a realistic plan looks like this:

1. Keep the Mac powered and isolated. Do not shut down unless you hold credentials or an escrowed recovery key.
2. Obtain credentials legally (user cooperation, organizational policy, MDM-escrowed FileVault recovery key).
3. Collect volatile data and Unified Logs live with native commands and log collect (see Unified Logs forensics).
4. Run a live logical triage with Aftermath or UAC, with Full Disk Access granted to the collector.
5. If a fuller copy is required, use a commercial logical imaging tool that supports Apple Silicon, or Share Disk from recoveryOS with the Data volume unlocked.
6. Hash and document everything, including every security-relevant change you made.

Caveats

• Apple changes recovery features, Share Disk behavior and security policy tooling between releases. Validate procedures on the same macOS version and hardware generation as your evidence.
• Statements about Data Protection classes on macOS come from Apple's documentation, which is high-level. Do not assert a specific file's protection class in a report without testing.
• Commercial tool claims about "full file system" acquisition of Apple Silicon Macs usually still mean logical acquisition from an unlocked system. Read the fine print and describe the method accurately.
• Absence of unallocated space means deleted-file recovery is largely off the table; lean on artifacts such as FSEvents, Unified Logs and APFS snapshots instead.

Frequently asked questions

If FileVault is off on an Apple Silicon Mac, is the disk unencrypted?

No. The internal storage is always encrypted with keys protected by the Secure Enclave. Without FileVault the volume unlocks automatically at boot on that specific Mac, but the flash contents are still unreadable if removed or copied off the device. FileVault adds the user's credentials to the key hierarchy.

Can I use Target Disk Mode on an M-series Mac?

Not in the traditional sense. Apple Silicon Macs offer Share Disk from macOS Recovery, which exposes the volume as a file-level SMB share after authentication. It does not provide raw block access, so it supports logical copying, not a physical image.

Should I lower the security policy to boot a forensic environment?

Generally no. Changing the boot security policy requires authentication in recoveryOS, alters the security state under examination, and still does not give access to encrypted data without credentials. Prefer live logical collection or Share Disk with valid credentials.