lijianfei.com

在苹果现代移动操作系统（特别是演进到最新的 iOS 27.x）的安全架构中，系统卷的签名快照（Sealed System Volume，简称 SSV）配合只读根目录保护机制，如同一座牢不可破的数字堡垒。过去数年间，在研究硬件级双系统（Dual-Boot）与定制固件（CFW）方案时，我总是被两个几乎不可调和的工程痛点所困扰：一方面，全量克隆双系统需要将包含庞大系统镜像和共享动态库缓存的整个根分区完整复制，瞬间吞噬 15 到 22 GB 的宝贵闪存空间；另一方面，这类方案对系统快照签名的破坏，导致设备一旦意外重启或在户外电量耗尽，便会直接锁死在恢复模式（Recovery Loop），毫无容灾退路。

近期由独立安全开发者 Huy Nguyen（GitHub 账户 34306）开源的越狱项目 doublera1n，彻底打破了这一技术僵局。该项目巧妙借助 A12/A13 芯片上的硬件级 BootROM 漏洞 usbliter8，提出了一种 “共享官方只读密封系统卷，外挂分立第二数据卷（2nd Data Volume）” 的冷启动架构。它不仅在 iPhone 11 Pro（搭载 A13 Bionic 芯片）运行的最新 iOS 27.2（系统内部编译号 24B119）上成功引导出具有动态插件注入能力的根无（Rootless）越狱环境，更实现了常规重启毫秒级平滑回退至纯净原生系统的无感体验。在这篇手记中，我将以第一视角深入拆解其启动链热补丁、设备树劫持、SEP-less 内核修补与 APFS 卷重定向的底层工程实现。

一、 存储拓扑革新：从“全量系统克隆”到“分立第二数据区”

在评估任何非易失性或半持久化的 iOS 引导方案时，文件系统拓扑的开销与容灾表现是决定其实用性的核心标尺。传统的自制固件双系统（CFW Dual-Boot）之所以难以普及，根源在于它在 APFS 容器内部对整套系统环境进行了硬性复制。

为了清晰展现两者在底层架构上的本质跨越，我绘制了以下架构对比演进图：

如上图的演进对比所示，doublera1n 与传统方案存在三个根本性的架构分野：

1. 密封系统卷原样共享（Zero-Duplication Sealed System）：
   • 传统方案：强行新建一个容量高达 15~22 GB 的次级系统卷，并将官方 IPSW 解压后的只读快照硬拷贝写入。这不仅严重挤占有限的用户存储，而且极易破坏苹果针对 APFS 根目录实施的 SHA-256 树状快照验签。
   • doublera1n：完全保留原机已经安装、由苹果官方合法签名的密封系统卷（System 卷），在引导过程中以只读方式继续挂载为根文件系统 /，在存储层面完全实现零冗余复用。
2. 轻量无加密第二数据卷（APFS DataB as /private/var）：
   • doublera1n 仅在设备的现有 APFS 容器中追加一个未加密且未分配角色的轻量卷（命名为 DataB）。
   • 该卷仅容纳越狱环境特有的用户目录树、软件包管理器、bootstrap 基础运行库（初始解压仅占用约 35 MB）以及后续安装的用户插件与应用，存储开销呈数量级暴跌。
3. 零污染的秒级官方系统回退（Stock Fallback）：
   • 传统 CFW 方案修改了 NAND 中的底层启动项或引导链配置，一旦离开专用主机引导，设备因验签失败必定直接卡在恢复界面。
   • doublera1n 的所有引导改动全部发生于内存中。当设备因电量耗尽或手动重启时，硬件默认遵循官方冷启动时序，原生 iBoot 自动挂载默认的官方数据卷，设备瞬间无缝回归纯净的官方 iOS 27.2，通信基带与日常功能完好无损。

二、 硬件之钥：usbliter8 缺陷与 RP2350 调试板协同

再精巧的软件重定向，也必须依托硬件底层的执行控制权。doublera1n 之所以能够在安全防御高度森严的 iOS 27.2 下获得立足点，关键基石正是其依托的硬件级 BootROM 漏洞：usbliter8。

[!NOTE] 什么是 usbliter8 硬件级漏洞？
usbliter8 是针对苹果 A12（T8027）与 A13（T8030，即 iPhone 11 系列、iPhone SE 第二代与 iPad 第九代）芯片 SecureROM 固件的物理漏洞。由于该固件在芯片出厂时已固化在硅晶圆中，苹果完全无法通过后续的 OTA 软件更新对其修补。

1. 物理利用与硬件板协同

与旧时代全软件漏洞不同，利用 usbliter8 对时序精度的要求极其严苛：

• 在设备进入 DFU 模式时，攻击者必须通过 USB 控制端点（EP0）在毫秒甚至纳秒级别构造竞态请求，利用 USB 描述符缓冲区解析溢出破坏堆栈，从而夺取 BootROM 的代码执行权；
• 普通的电脑 USB 端口由于操作系统调度延迟，极难保证竞态成功率。因此，doublera1n 深度依赖搭载树莓派 RP2350 微控制器 的硬件外设板（如社区定制的 B4 PICO DFU 硬件板）；
• 该板卡直接集成了 Lightning 接口公头与 USB-C 接口，由 RP2350 固件精准产生纳秒级电气时序脉冲，将 iPhone 11 Pro 稳定击穿并注入 pwned DFU 状态。

2. 串口（UART）提取实机原生 APTicket

现代 iOS 引导安全的核心在于 APTicket（应用处理器签署票据）。当我们在内存中向设备推送自定义引导镜像时，如果缺乏合法的票据哈希，后续的基带握手与固件初始化均会异常终止。

doublera1n 在首阶段引导中，借助 RP2350 板载的硬件 UART 串口通道，直接从设备内部闪存挂载的 Preboot 分区中转储了当前系统实际生效的官方票据（路径为 Preboot/<BootManifestHash>/System/Library/Caches/apticket.der）。这确保了后续在内存中组装引导链时，每一个固件镜像都能绑定实机独有的签名哈希（IM4M）。

三、 逐级击穿启动链：从 pwned DFU 到内核装载的 5 阶穿透

当设备通过 usbliter8 成功进入 pwned DFU 模式后，启动脚本 boot.sh 会调用底层的 lib/boot_chain.py，拉开一场惊心动魄的内存固件热补丁接力。

为了理清这一整套复杂的启动流程，我绘制了下面的阶段化执行管道拓扑图：

从上图中可以清晰地归纳出引导链穿透的 5 个关键阶段：

阶段 1：SecureROM 物理接管与 iBSS/iBEC 载入

利用 usbliter8ctl 驱动，主机向设备注入并执行经过去除验签约束的 iBSS.raw，随后引导 iBEC.img4。与社区常见的 irecovery -c 暴力发送不同，doublera1n 封装了底层控制传输：

def cmd(c, may_disconnect=False):
    dev = recovery()
    try:
        # 发送控制传输指令，精准捕获 STALL 异常
        dev.ctrl_transfer(0x40, 0, 0, 0, c.encode() + b'\0', 30000)
    except usb.core.USBError as e:
        if may_disconnect: return
        sys.exit(f"!! command {c} failed: {e}")

这保证了在 iBoot 初始化过程中一旦发生固件拒绝指令，流水线能在进入跳板 bootx 之前立即熔断自检。

阶段 2：iBoot 内存热补丁（patch_iboot.py）

在 iBEC 装入 RAM 后，脚本对其执行动态内存反汇编与特征修补：

1. 绕过 Image4 验签回调：定位特征字符串 "Unknown ASN1 type %llu\n"，将其下游的签名校验判定分支强行重写为返回 0（Success），使 iBoot 能够信任未经苹果二次公钥签署的修改版内核；
2. 重写 boot-args 引导参数：在 iBoot 格式化参数的 snprintf 调用点，替换格式化串为自定义参数 jb=md0；
3. 控制台命令 memboot 劫持：将控制台命令 memboot 的函数指针重定向至内部的 fsboot 处理器。这一设计极其精妙——它使得设备能够带着从 RAM 注入的热补丁，回过头直接从本地 NAND 闪存加载真实的官方固件与票据。

阶段 3：设备树（DeviceTree）魔改注入（dt_patch.py）

这是 doublera1n 实现“无需克隆系统卷”的核心绝技。在固件移交控制权前，脚本解析并就地修改了扁平化设备树结构（Flattened DeviceTree）：

# lib/dt_patch.py 核心设备树修改指令集
OSB_OPS = [
    '--del', '/defaults:content-protect',               # 禁用默认硬件级文件级强制内容保护
    '--set', '/defaults:no-effaceable-storage=1',
    '--set', '/product:boot-ios-diagnostics=1',
    '--set', '/chosen:ephemeral-storage=1',
    '--set', '/filesystems/fstab/data-vol:vol.fs_role=0',# 【核心绝技】将 data-vol 角色覆盖为 0
    '--setstr', '/filesystems/fstab/xart-vol:vol.fs_type=ro',
    '--setstr', '/filesystems/fstab/update-vol:vol.fs_type=ro',
    '--setstr', '/filesystems/fstab/hardware-vol:vol.fs_type=ro',
]

在 iOS 原厂设计中，XNU 内核的 DT_get_fstab_entries 函数在遍历 APFS 容器挂载表时，会去寻找角色标识为 0x40（系统预设的默认用户数据分区）的卷作为 /private/var。而通过将设备树中的 data-vol 角色强制改为 0，内核在开机解析时就会自动跳过原厂的数据卷，转而精确选中 APFS 容器内唯一未设置角色的自定义卷 DataB，并将其挂载为用户空间根目录！

同时，为了防止越狱环境意外改动系统共用分区的硬件凭证，doublera1n 将 xart-vol、update-vol 和 hardware-vol 均强制指定为只读（ro），唯独放行基带蜂窝模块 baseband-vol 保持读写（rw），确保蜂窝网络通讯协议栈正常运转。

四、 内核语义修补与防崩实录：SEP-less、睡眠唤醒与设备树劫持

当控制权递交给 XNU 内核时，现代 iOS 极度严格的安全子系统会立刻引发一系列连锁反应。其中最为致命的阻碍，来自安全隔离协处理器（Secure Enclave Processor，简称 SEP）。

从 pwned DFU 冷启动时，由于我们缺乏对 SEP 固件的完整密钥解密与重新签名能力，次级数据环境必须在 SEP-less（无 SEP 硬件环境） 模式下运行。若不对内核进行语义级精准修复，设备将在启动的数毫秒内直接遭遇内核恐慌（Kernel Panic）。

为了直观呈现内核修补所穿透的多层防御体系，我构建了如下垂直分层技术栈模型：

从底层的硬件特权到顶层的用户空间，doublera1n 的语义补丁查找器（lib/kpatchfind.py）针对内核代码实施了外科手术式改造：

1. 拔除 SEP 断言恐慌桩（kernel.sep.no-panic）

在 iOS 27.2 的内核缓存中，AppleSEPUserClient 驱动内部包含大量显式的完整性校验：

REQUIRE(!booted) panic("AppleSEPUserClient: SEP not alive or state invalid")

在正常的系统引导中，一旦 SEP 通信未就绪，驱动会直接向 XNU 抛出 panic 中断。补丁引擎通过特征交叉引用（Cross-Reference），定位到所有指向 panic 桩的条件跳转指令 B.EQ，并将其批量重写为机器码 0xD503201F（NOP，空操作），直接放行后续执行流。

2. 伪装密钥库就绪状态（AppleSEPKeyStore）

钥匙串与数据保护模块 AppleSEPKeyStore 拥有唯一的读取接口检查 SEP 是否已引导。补丁引擎定位到该函数的入口：

// 原函数入口指令
PACIBSP
SUB SP, SP, #0x20
...
// 补丁替换后
MOV W0, #0
RET

直接将该函数入口改写为返回数值 0（false）。上层密钥库驱动由此认定当前环境无需硬件 SEP 参与，从而绕过针对加密凭据的硬件解密检查。

3. 攻克锁屏睡眠崩溃难题（kernel.sep.sleep.sep-not-alive）

在早期无 SEP 越狱方案中，有一个长期困扰开发者的恶性 Bug：手机一旦锁屏进入深度睡眠（Deep Sleep），内核电源管理器 AppleSEPManager::_setPowerState 会因无法收到 SEP 协处理器的电源就绪回执而触发断言崩溃，导致手机黑屏死机并自动重启。

doublera1n 在 kpatchfind.py 中找到了该崩溃判定的精确汇编片段：

# AppleSEPManager::_setPowerState 睡眠分支判定修补
# 原指令逻辑：CMP W8, #2 ; B.NE (若状态不符合则 panic)
# 补丁指令逻辑：CMP W8, #7 ; B.GE (放宽状态阈值，允许降级睡眠)

通过放宽比较范围，确保在屏幕息屏休眠与深度睡眠周期中，电源状态机能够平稳降级，彻底根治了锁屏假死的问题。

4. 首次部署初始化工具 rdsetup

在初次安装阶段，系统并不会直接启动完整桌面，而是引导进入由官方恢复内存盘定制的 rdsetup 执行环境：

• rdsetup 接替了官方原厂的 restored_external 守护进程；
• 通过调用 IOKit 原生框架遍历当前 APFS 容器中的所有卷宗；
• 若检测到尚未创建次级数据卷，则通过系统调用执行 newfs_apfs -A -v DataB <Container_BSD>，在保留原容器所有数据的前提下，动态开辟出 DataB 空间；
• 将只读挂载的原厂系统卷中的 /private/var 模板文件（包括核心系统应用骨架 staged_system_apps）完整同步至 DataB；
• 将 Preboot 中的官方原版 apticket.der 备份存入 DataB:/jb/ 供持久化复用。

五、 用户态运行时与 Rootless 生态构建

一旦内核与 APFS 重定向准备就绪，系统便正式进入用户空间。在这个由未加密 DataB 所支撑的第二数据区中，doublera1n 搭建起了一套高度工业化的根无（Rootless）越狱生态。

1. PID 1 代理中继（jbinit）

系统启动的第一个用户态进程并非原生的 launchd，而是注入在内存盘中的 jbinit。jbinit 执行以下核心职责：

• 动态调用 bindfs，将存有越狱二进制工具链的 /jbin 伪装挂载至 /cores 目录；
• 在挂载完成后，无缝中继拉起系统的真实 /sbin/launchd；
• 通过 DYLD_INSERT_LIBRARIES 注入环境变量，向核心守护进程挂载全局钩子动态库 obhook.dylib 与 systemhook.dylib。

2. Sileo 2.5.1 的 Swift 架构字符串特征绕过

在原生软件包管理器 Sileo 的源码设计中，其架构探查模块 Jailbreak.swift 存在一段针对硬件架构名称的硬编码检测逻辑：

// Sileo 原生检测逻辑
if NXGetLocalArchInfo()->name != "arm64e" {
    // 仅在非 arm64e 架构下才触发 palera1n rootless 判定
    checkPalera1nRootless()
}

由于 iPhone 11 Pro 的 A13 芯片属于标准的 arm64e 架构，原生 Sileo 在运行时会直接拒绝识别该挂载环境。

doublera1n 在 lib/patch_sileo.py 中巧妙利用了 Swift 编译期对短字符串（Small String Literal）的汇编打包特性：

• Swift 编译器在编译 arch() == "arm64e" 时，会将 "arm64e" 拆解为 MOVZ / MOVK 指令片段（十六进制编码 0x7261, 0x366D, 0x6534）；
• 补丁脚本定位到这组指令序列，将末尾的 "4e" 替换为 "4x"（十六进制 0x7834）；
• 这一改动使得 A13 芯片在执行架构对比时恒判定为 false，从而成功欺骗 Sileo 触发其自带的 palera1n Rootless 适配分支，正确识别 /cores/jbloader 并挂载 Procursus 软件源生态。

六、 实测边界、风险权衡与开发者启示

经过在 iOS 27.2（build 24B119）环境下的实际工程验证，doublera1n 展现出了令人惊艳的稳定性，但同时也必须清醒认识到其物理层面的固有局限：

doublera1n 的工程价值，绝不仅仅局限于“又一款 iOS 越狱工具”的诞生。在苹果持续收紧内核安全基线、SSV 签名快照与只读根文件系统全面铺开的今天，它向逆向安全研究人员指明了一条全新且极具启发性的思路：

不再执着于彻底砸碎或重写不可触碰的只读系统堡垒，而是借助内存热补丁与设备树挂载机制，优雅地引导系统与并行的轻量数据空间握手共生。 这种在物理硬件利用与逻辑架构解耦之间的精准平衡，不仅极大地拓宽了安全研究员在受限硬件上的探查纵深，更为未来移动系统级沙盒调试与虚拟化探索提供了弥足珍贵的实战样本。

原文链接与参考资料

• PBX Science 报道原文：iOS 27.2 Jailbreak Boots on iPhone 11 Pro via doublera1n, but Only for A13 Devices and Experts (PBX Science)
• doublera1n 官方开源项目仓库：34306/doublera1n (GitHub)
• usbliter8 概念验证前作仓库：wh1te4ever/usbliter8-fun (GitHub)
• Liter8 开源引导探索项目：Xplo8E/Liter8 (GitHub)
• AppleDB 固件数据库索引：iOS 27.2 (24B119) Firmware Information