2026 年 7 月底，意大利电子数据取证机构 Forenser 公布了一组 iPhone XS 测试结果：一台安装 iOS 18.7.9 的 iPhone XS，可以从 BootROM 漏洞触发的 PWND DFU 状态继续启动经过修改的 iBoot、内核和 SSH ramdisk，最终通过 USB 建立 root SSH 会话，并挂载设备上的 APFS 文件系统。Apple 的安全公告确认，iOS 18.7.9 于 2026 年 5 月 11 日发布，适用于 iPhone XS、XS Max 和 XR。

这项实验比“在 iPhone XS 上取得 root”更值得取证人员关注。它把近年来针对 A12/A13 的公开 BootROM 研究推进到了一个已经能实际读取数据的阶段。只是这个“读取数据”的范围必须先明确一下：目前得到的是一个 BFU 条件下的文件系统访问环境，距离通常所说的、能够读取大量第三方 App 数据和钥匙串内容的完整文件系统提取，还有 Secure Enclave 这一关。

从 BootROM 漏洞一路启动到 SSH

这条链的入口是针对 A12/A13 的 usbliter8。设备进入 DFU 后，由外部微控制器触发 BootROM 中的 USB 漏洞，在操作系统尚未启动时获得代码执行能力，并把普通 DFU 转换成 PWND DFU。Forenser 此前已经在同一台 iPhone XS 上完成了这一阶段；7 月 31 日公布的是后续启动链。

整套过程可以压缩为三个阶段：

1. 1. BootROM 阶段。 利用 usbliter8 使 A12 设备进入 PWND DFU，BootROM 中的自定义 handler 随后可以接收后续启动代码。
2. 2. iBoot 阶段。 向设备送入修改后的 iBoot，绕过 Image4 启动镜像验证，使设备能够继续加载非 Apple 正常签名链下的组件。
3. 3. 内核与 ramdisk 阶段。 加载 DeviceTree、trustcache、SSH ramdisk、经过修改的内核以及相关协处理器固件，关闭部分 AMFI 和调试限制。内核启动后以 ramdisk 为根文件系统运行最小用户空间，并由 Dropbear 提供 SSH 服务。主机通过 iproxy 转发 USB 连接，即可进入设备上的 root shell。

公开的 ICH_A12_plus_Ramdisk 项目已经把这套流程做成相对完整的构建和启动框架。目前其 README 将支持范围标为 A12/A13，并针对 iOS 17、18、26 以及 27 以上版本采用不同的内核补丁路径；进入 SSH 后，mount_ich 用于挂载 System、Preboot、xART、Data 等文件系统。这里的“支持”仍应理解为项目层面的适配范围，具体设备、iOS 构建号和补丁组合仍需逐一验证。

能挂载 Data 卷，还不等于已经获得完整 FFS

SSH 成功后，设备上的 APFS 结构已经能够被查看。System、Data、Preboot、xART 等卷可以挂载，文件目录、部分元数据和可解密文件也随之进入操作范围。

真正限制取证数据量的是 iOS Data Protection。

iPhone 上的文件并非因为 APFS 卷已经挂载就自动以明文出现。Apple 为文件划分了不同的数据保护类。A 类 NSFileProtectionComplete 需要相应类密钥处于可用状态；B 类采用“文件打开期间可用”的机制；C 类 NSFileProtectionCompleteUntilFirstUserAuthentication 在设备第一次完成用户认证后才进入可访问状态；D 类 NSFileProtectionNone 的类密钥只依赖设备硬件 UID。Apple 同时明确指出，没有另外指定保护级别的第三方 App 数据默认属于 C 类。

这正是 SSH ramdisk 当前能力的边界。

设备经历 DFU 和自定义启动后，并没有完成用户密码认证。Secure Enclave 没有把受密码保护的类密钥释放给当前环境。于是可以遍历 Data 卷，却会在访问部分文件时碰到权限或解密失败。目录存在、文件 inode 存在、文件大小可见，并不能说明文件内容已经可读。

从取证术语看，这更接近 BFU（Before First Unlock）文件系统获取。

BFU 并不等于“没有取证价值”

BFU 有时被简单理解为“只能看到系统文件”，这种说法同样不准确。

D 类文件所需的密钥全部存在设备本身，因而可以在没有用户解锁的情况下解密。系统运行所需的一部分数据库、配置、日志、诊断信息以及其他使用较低数据保护等级的数据，都可能落在当前可访问范围。Forenser 的实测也报告，可以读取系统结构、日志、诊断数据库以及部分未受到更高等级 Data Protection 约束的数据。

这类数据对时间线分析、设备状态判断、网络痕迹分析和系统异常调查已经有实际价值。对某个具体 App 能拿到多少，却不能根据“BFU”三个字预先下结论。保护类别由文件实际采用的数据保护属性决定，同一个 App 的数据库、缓存、附件和临时文件也可能采用不同策略。

还有一个容易混淆的地方：通过 SSH 逐文件复制，与制作 APFS 块设备的逐比特镜像是两回事。

目前公开实验首先证明了“能够进入并读取文件系统”。Forenser 自己也把 APFS 卷自动化镜像、哈希计算和标准格式输出列为后续工作。也就是说，这项成果已经具备提取数据的基础条件，但尚未公开展示一套完整的、经过验证的案件级镜像流程。

真正难的一关仍然在 Secure Enclave

A12 这一代设备把文件加密密钥体系与 Secure Enclave 紧密绑定。Apple 的设计是，即使应用处理器上的内核已经被攻破，敏感密钥仍不应因此直接暴露。文件本身使用独立密钥加密，文件密钥再由相应的数据保护类密钥封装；其中部分类密钥同时受到设备 UID 和用户密码保护。

用户 keybag 也由 Secure Enclave 管理。密码正确时，Secure Enclave 才参与解封相应类密钥。对 A9 以后的设备，keybag 还与 Secure Enclave 控制的 anti-replay 状态关联。

因此，取得 root shell 并没有绕开这套密码学边界。

Forenser 下一步设想是在已知设备密码的条件下，从修改后的内核通过 AppleSEPKeyStore 与 Secure Enclave 通信，让 SEP 完成正常的密码认证和类密钥解封，再把相应密钥交给 APFS 使用。这样得到的数据访问状态可以称作“AFU-equivalent”，因为其可读范围可能接近设备完成首次解锁后的状态。原文明确说明，这项能力在其实验环境中目前还没有完成。

这里需要比原文更加谨慎。

Apple 从 A10 开始就在 Secure Enclave AES Engine 中加入了与启动状态有关的 lockable seed bits，其中一个用途就是限制设备从 DFU 模式启动时访问受密码保护的数据。Secure Enclave 还通过设备 UID、anti-replay 机制以及与运行环境绑定的密钥材料限制密钥使用。

所以，“密码已知”并不自动推出“只剩一次 IOKit 调用”。如何让经过修改的启动链与 SEP 建立它认可的状态，怎样完成 keybag 解锁，又怎样把结果安全地交给 APFS，仍然涉及相当多的设备和系统版本相关工程。

公开的 usbliter8-fun 已经在 iPhone 11 Pro、A13 和特定 iOS 27 beta 构建上展示了更长的启动链，包括针对内核、用户空间和 SEP 相关组件的修改。但该项目自己也明确警告，补丁偏移与具体构建绑定，换设备或换版本必须重新验证。它能证明这条研究路线可以继续走，不能直接证明 iPhone XS/A12/iOS 18.7.9 上的 SEP 解锁只剩简单移植工作。

对取证工作的价值，首先在“可控”

如果后续链条稳定下来，这类开源 ramdisk 的价值不只体现在“可以少买一个商业工具”。

商业手机取证工具往往只向用户暴露“BFU”“FFS”“Premium”等能力名称，底层到底启动了什么组件、修改了哪些代码、对目标设备做了哪些操作，很难完整观察。公开启动链提供了另一种研究条件：iBoot、kernel patch、ramdisk 内容、工具版本和执行命令都可以被检查。

这使实验室有机会独立验证一个问题：手机取证工具得到的数据究竟来自哪里。

比如某商业工具宣称在某个 iPhone XS 和 iOS 版本上完成 BFU FFS，可以利用公开 ramdisk 在同类测试机上建立对照环境，比较目录范围、文件数量、Data Protection 状态、数据库内容和时间戳差异。NIST 的 CFTT 项目一直强调移动设备获取工具应通过功能性测试来确认其能力和结果，而不是仅依据工具厂商的描述。2026 年更新的 Federated Testing 项目仍提供移动设备获取工具测试模板。

对于工具验证研究，这可能比直接用于案件更早产生价值。

“重启即恢复”还不足以证明取证无扰动

SSH ramdisk 的一个优点很明确：它是依赖外部引导启动的，理论上不会直接修改检材数据，因而可以保证电子数据的完整性。修改后的启动环境驻留在当前运行状态中，设备重新启动后不会像传统持久化越狱那样继续存在。Forenser 也把这一点视为适合取证研究的条件。

但“没有持久化越狱”和“没有改变检材”之间还隔着一套验证工作。

当前 ICH_A12_plus_Ramdisk 的公开说明显示，mount_ich 会挂载包括 Data 在内的所有 NAND 文件系统，但 README 在这一层没有说明所有证据相关卷均强制以只读方式挂载。

对研究设备这不构成大问题；进入案件环境后就不能含糊。自定义内核启动、文件系统挂载、用户空间程序执行，都需要测试是否会产生 APFS 元数据、日志、缓存、时间戳或其他状态变化。即使最终确认没有发生 NAND 写入，也应以实验结果证明，而不是从“ramdisk 位于内存中”推导出来。

NIST 对移动设备取证的基本要求仍然适用：获取方法需要经过验证，并覆盖保全、获取、检验、分析和报告过程。NIST 的移动设备取证工具测试工作同样强调，工具能力应通过明确的测试断言、测试步骤和预期结果进行验证。

如果把这套链真正做成实验室方法，至少需要记录启动链各组件的版本和 SHA-256、目标设备型号与构建号、全部 kernel/iBoot patch、挂载参数、执行命令、读取范围、错误信息以及获取文件或镜像的哈希值。还应在专用测试机上重复执行，比较操作前后的 APFS 容器、文件元数据和关键系统数据库。

这一步很枯燥，却决定了它最终是一套“能跑起来的研究工具”，还是可以写进检验记录的方法。

适用范围

Forenser 的实验对象只有一个明确组合：iPhone XS、A12、iOS 18.7.9。Apple 确认 18.7.9 确实支持 XS 系列，但这不能自动外推到所有 A12 设备，更不能外推到后来的芯片。

公开项目目前已经把 A12/A13 和多个 iOS 大版本纳入代码，但不同 iOS 分支使用不同 patchfinder 或固定偏移；项目 README 甚至专门规定，某些 iOS 26 构建的内核偏移不匹配时应直接停止，而不是继续套用补丁。

这反映了移动设备底层获取常见的麻烦：从“某型号能工作”到“某一代设备稳定支持”，中间通常有大量小版本的适配。

对实际案件而言，应把兼容性写到“设备型号 + SoC + iOS 版本 + 构建号”的粒度，而不是简单记成“A12 支持”。

目前最准确的定位：一个已经具有取证用途的 BFU 入口

这项研究已经越过了纯漏洞演示阶段。

PWND DFU 本身只能说明 BootROM 控制权已经取得；现在的 SSH ramdisk 已经可以启动受控内核、建立 root shell、挂载 APFS，并从设备中读取 BFU 条件下能够解密的数据。对于系统日志、配置、部分数据库、文件系统结构以及工具验证研究，它已经具有现实用途。

它暂时还不能被描述成“iPhone XS 完整文件系统提取方案”。

第三方 App 数据默认使用 C 类数据保护这一点尤其关键。大量调查人员最关心的 App 数据、附件以及钥匙串项目，要等 Secure Enclave 和 user keybag 的问题解决后才能进入稳定的可读范围。钥匙串本身还有独立的数据保护机制，敏感值的解密需要 Secure Enclave 参与，因此即便未来普通文件达到 AFU-equivalent，钥匙串仍需要单独验证其可获取范围。

下一次真正具有分水岭意义的进展，不会是 SSH 界面上多看到几个目录，而是同一台 A12 测试机在已知密码条件下能够稳定解锁 user keybag，并证明 A、B、C 类文件的读取结果可重复；随后再把这个过程收敛成只读、可验证、有完整哈希和操作记录的获取方法。

做到那一步，A12 设备的公开取证链才真正接近今天商业 FFS 工具所解决的问题。

参考文献

1. 1. Forenser, SSH ramdisk su iPhone XS con iOS 18.7.9: la chain completa fino al file system
2. 2. https://github.com/Pa7r0n/ICH_A12_plus_Ramdisk
3. 3. https://github.com/34306/usbliter8-fun