一、概述
拿到 Mac 镜像后的第一个障碍不是技术，是心智模型。
国内多数资料讲的是 Windows，思路固定："配置进注册表、行为进事件日志、用户痕迹进 AppData"。这套思路搬到 Mac 上会连续踩空——macOS 没有注册表、没有传统事件查看器、没有 AppData。
macOS 的组织方式不一样，而且更整齐：
| 维度 |
Windows |
macOS |
| 用户数据主位置 |
C:\Users\<u>\AppData（Roaming/Local/LocalLow 三分） |
~/Library/（一个根目录，子目录按用途分类） |
| 系统配置 |
注册表 hive |
.plist 文件（一个文件一项） |
| 系统日志 |
多个 .evtx 文件 |
统一日志，单一后端 |
| 启动项 |
5 个 Run 键 + 计划任务 + 服务 |
launchd 统一管理 |
| 全卷加密 |
BitLocker（可选） |
FileVault 2（Monterey 后默认开启） |
最需要先立起来的一条认识：macOS 的用户痕迹几乎全在 ~/Library/ 下。
Apple 把"系统的东西"放 /System、/Library，把"你的东西"全放 ~/Library。这条线划得干净、可预测，直接对应取证上"用户级证据"的边界。
三个最贵的处置错误：
- 只镜像了某个卷而没镜像整个 APFS 容器。macOS 10.15 之后，系统盘是一个容器里挤着系统卷、数据卷、预启动卷、恢复卷、交换卷。单独
dd 数据卷会丢掉容器超级块和块池分配表，证据完整性在法律层面就站不住（详见第八篇）。
- 发现设备开着就直接拔电。Spotlight 索引、内存交换、运行时统一日志一并丢失，还改变了设备状态。
- 把
~/Library 当普通目录扫过去。它有几百个子目录，其中 Containers/、Group Containers/ 是 10.14 Mojave 之后的沙盒迷宫，漏掉等于漏掉整个应用生态的用户数据。
在取证流程中的位置：本篇是 macOS 板块的入口篇，位置在接手检材之后、任何具体分析之前。它的输出是一份提取清单，而不是分析结论——读它是为了知道"该往哪些路径去取"，取完才轮到 plist 解析、日志检索、钥匙串解密这些具体动作。所以它同时依赖上游的镜像规范（只读挂载与安全接入）并把清单交给下游各篇：plist 与偏好设置、Quarantine 与 Gatekeeper、Keychain 与 Safari 痕迹、取证实战流程。具体动作的先后顺序由最后一篇决定。
本篇处理的证据形态，是三层目录加两个存储后端：
| 层次 |
路径 |
内容与判读要点 |
| 系统层 |
/System |
Big Sur 起是独立的签名系统卷（SSV），基本无个性化证据，价值最低 |
| 全局可写层 |
/Library |
所有用户共享：LaunchDaemons/（★ 系统级启动项，开机即跑 root）、Preferences/、Application Support/、Keychains/System.keychain |
| 用户层 |
~/Library/ |
几乎所有个人痕迹：Preferences/（+ ByHost/）、Application Support/、Containers/ 与 Group Containers/（10.14+ 沙盒数据）、Safari/、Keychains/、Messages/、Mail/、LaunchAgents/、Mobile Documents/、Autosave Information/（被删文档的历史版本）、~/.Trash（在 ~ 根下，不在 Library 内） |
| 统一日志 |
/var/db/diagnostics/ |
持久化存储，现役日志的唯一后端；导出用 log show，现场就要做 |
| 其他系统级 |
/private/var/log/install.log、wtmp、appfirewall.log、/etc/hosts、/etc/sudoers、/private/var/db/dslocal/nodes/Default/users/（本地用户目录服务数据库） |
安装日志、关机时间锚点、sudo 授权 |
/var/log 与 /private/var/log 是同一个目录（/var 是 /private/var 的符号链接，两者 inode 相同），工具里可互换，报告里统一写 /private/var/log。
某个用户在系统上做过什么（~/Library/ 的覆盖）、装过哪些应用（Containers/ 下的 bundle id 目录）、系统级持久化有哪些（LaunchDaemons/）、设备什么时候开过关机（wtmp）、哪些软件被安装过（install.log）、以及该去哪些路径取哪些工件。
目录存在不代表内容被读取过——Caches/、HTTPStorages/、Autosave Information/ 里都可能残留早已不用的数据，判断使用行为要靠访问时间戳与应用侧记录，不是靠"文件在不在"。路径清单也不覆盖加密内容：Messages/ 的数据库是加密的、Keychains/ 解不开就只有一堆密文，而这两处恰好是聊天证据与凭据证据的主力。具体解读都要交给下游各篇，本篇只给地图。阴性结果的边界在这里最明显：没在 ~/Library/ 下找到东西，等于说它在用户目录里没有，不能推广到 /var/db/、FSEvents 日志、交换卷、APFS 快照（快照里可能有已删除目录的旧版本，容易与当前状态混淆）。另外版本差异是硬约束：10.14 之后 Safari 多已迁到 Containers/，按老路径去 ~/Library/Safari/ 找会得到一个空目录——"没找到"有时候只是路径过时。
读者前提：需要先有 APFS 容器与快照 的概念基础，理解容器与卷的关系——不理解这一点，就没法理解为什么单独 dd 数据卷会破坏完整性声明；需要知道 launchd 是 macOS 的统一启动管理机制，LaunchAgents 与 LaunchDaemons 的区别是用户级与系统级；需要理解 ~/Library 是 Apple 刻意划出的用户数据边界，这正是"用户级证据"这个概念在 macOS 上的落点；还要接受一件事：这台机器的具体版本与架构（Intel 还是 Apple Silicon、大版本号）决定了一部分路径是否存在，动手前先定版本，否则清单会有一半是废弃路径。
二、核心原理
APFS 容器与卷结构原理见文件系统分析板块，本篇不重复 B-tree 与 checkpoint 机制。
2.1 三层目录结构：系统 / 全局 / 用户
/System 只读系统卷（Big Sur 起独立为 SSV 签名卷）→ 基本无个性化证据
/Library 全局可写层：所有用户共享的第三方内容
├── LaunchDaemons/ ★ 系统级启动项（开机即跑，root）
├── Preferences/ Application Support/ Keychains/System.keychain
~/Library ★★★ 用户级：几乎所有个人痕迹都在这里
├── Preferences/ (+ByHost/) 偏好设置 plist
├── Application Support/ 应用数据库、浏览器、IM 数据
├── Containers/ (+Group Containers/) 沙盒数据（10.14+）
├── Safari/ Keychains/ Messages/ Mail/
├── LaunchAgents/ ★ 用户级启动项
└── Mobile Documents/ Caches/ HTTPStorages/ Metadata/
/Library（全机持久化）与 ~/Library（个体行为）都要提取。
时间有限时 ~/Library 优先级高于 /Library。
2.2 关键目录速查：~/Library/ 各子目录用途
这张表是 macOS 取证最常用的参考。★ 表示高取证价值。
| 子目录 |
用途 |
价值 |
备注 |
Preferences/ |
偏好设置 .plist |
★★★★★ |
见03，注意 cfprefsd 缓存 |
Preferences/ByHost/ |
按主机区分的偏好 |
★★★★ |
文件名含主机 UUID，可确认拷机痕迹 |
Application Support/ |
应用数据库与配置 |
★★★★★ |
Chrome/Firefox/IM/邮件核心数据 |
Containers/ |
沙盒应用数据 |
★★★★★ |
10.14+；路径形如 com.vendor.app/Data/… |
Group Containers/ |
沙盒应用组共享 |
★★★★ |
扩展插件、共享数据库 |
Safari/ |
Safari 历史/书签/会话 |
★★★★★ |
10.14+ 多已迁至 Containers，见07 |
Messages/ |
信息/iMessage 附件 |
★★★★★ |
聊天证据主力；数据库加密 |
Keychains/ |
登录钥匙串 |
★★★★★ |
解密需用户密码，见07 |
LaunchAgents/ |
用户级启动项 |
★★★★★ |
恶意持久化高发，见02 |
Application Support/MobileSync/Backup/ |
iOS 设备备份 |
★★★★★ |
见06 |
Mobile Documents/ |
iCloud 同步目录 |
★★★★ |
含 ~apple 云盘痕迹，见03 |
Mail/ |
邮件账户与缓存 |
★★★★ |
新版多在 Containers/com.apple.mail |
HTTPStorages/ |
各站点 Cookie/会话 |
★★★ |
部分为数据库格式 |
Logs/ |
用户级应用日志 |
★★★ |
很多是纯文本，可直接读 |
Autosave Information/ |
iCloud 自动保存版本 |
★★★ |
被删文档的历史版本 |
CloudStorage/ |
第三方云盘挂载 |
★★★ |
反映装过哪些网盘 |
Metadata/ |
捆绑与标签元数据 |
★★★ |
macOS 特有的"标签"体系 |
Caches/ |
各类缓存 |
★★ |
价值低但含 WebKit 缓存/临时凭据 |
~/.Trash |
用户废纸篓 |
★★★★ |
在 ~ 根下，不在 Library 内 |
Containers/ 最容易漏。
ls -1 ~/Library/Containers/ | grep -iE 'safari|chrome|wechat' 能快速判断装过哪些应用。
2.3 系统级关键位置
| 路径 |
内容 |
价值 |
/Library/LaunchDaemons/ |
系统级启动项 plist |
★★★★★ |
/Library/LaunchAgents/ |
系统级登录项（较少） |
★★★★ |
/System/Library/LaunchDaemons/ |
Apple 自带守护进程 |
★★ 基线比对用 |
/var/db/diagnostics/ |
统一日志持久化存储 |
★★★★★ |
/private/var/log/install.log |
软件安装日志（现为纯文本） |
★★★★ |
/private/var/log/wtmp |
登录会话历史（关机时间锚点） |
★★★★ |
/private/var/log/asl/ |
旧版 Apple System Log |
★★★ 10.12 前 |
/private/var/log/appfirewall.log |
防火墙记录 |
★★★ |
/Library/Preferences/SystemConfiguration/ |
网络配置 |
★★★★ |
/etc/hosts、/etc/sudoers |
主机名映射、sudo 授权 |
★★★★ |
/private/var/db/dslocal/nodes/Default/users/ |
本地用户目录服务数据库 |
★★★★★ |
/var/log 与 /private/var/log 是同一个目录（/var 是 /private/var 的符号链接，两者 inode 相同）。工具里可互换，报告里统一写 /private/var/log，避免复核人困惑。
2.4 版本与架构差异
差异直接决定工件是否存在、路径在哪，不是学术问题。
| 差异点 |
10.14 Mojave 及以前 |
10.15 Catalina 起 |
11 Big Sur 起 |
12 Monterey 起 |
| 系统盘结构 |
单 HFS+/APFS 卷 |
单 APFS 卷 |
系统卷 + 数据卷分离（SSV） |
同 |
| FileVault |
可选 |
可选 |
可选 |
默认开启 |
| Safari 数据 |
~/Library/Safari/ |
~/Library/Safari/ |
迁至 Containers/com.apple.Safari/ |
同 |
| iCloud 目录名 |
~/Mobile Documents/ |
~/Library/Mobile Documents/ |
同 |
同 |
| 旧 ASL 日志 |
/private/var/log/asl/*.asl 存在 |
逐步停用 |
基本停用 |
无 |
| Apple Silicon |
— |
— |
M1 首发 |
主流 |
三条必须记住的架构事实。
（1）Apple Silicon 与 Intel 的启动安全模型根本不同。
Intel Mac 可按住 Option 选外接启动盘或进恢复环境；Apple Silicon 机型只能启动签名的系统映像，恢复环境受启动安全性策略（Boot Security Policy）约束。
这意味着不能在 Apple Silicon Mac 上用传统方式制作可启动的取证副本，只能逐块物理镜像。副作用是降低了扣押后被远程启动攻击的风险。
（2）T2 芯片机型有 Secure Enclave（安全隔区）。
FileVault 密钥与生物识别数据存在这块独立处理器里。T2 的加密是硬件辅助的，部分 APFS 解析库不支持硬件加密内层——解不开时先确认是不是这一类，而不是反复试密码。
（3）Big Sur 之后用户数据在 Data 卷，System 卷只读且带签名。
跨卷解析能力差的工具在 Big Sur+ 上会漏数据。
APFS 容器必须整体镜像的原因也在这里：各卷共享同一块池。
2.5 取证准备：卷布局与镜像
现场第一件事：搞清楚盘上有几个卷、哪个是容器。
/dev/disk0 (internal, physical):
0: GUID_partition_scheme *500.3 GB disk0
1: Apple_APFS_ISC Container disk1 524.3 MB disk0s1
2: Apple_APFS Container disk3 494.4 GB disk0s2 ← ★ 主容器
/dev/disk3 (synthesized):
0: APFS Container Scheme +494.4 GB disk3
1: APFS Volume Macintosh HD 14.1 GB disk3s1 ← 只读系统卷
2: APFS Volume Preboot 21.7 GB disk3s2
3: APFS Volume Recovery 3.1 GB disk3s3
4: APFS Volume Macintosh HD - Data 447.8 GB disk3s5 ← ★ 用户数据在这
5: APFS Volume VM 5.4 GB disk3s6 ← 交换
disk3 是 synthesized（合成）设备——不
