先明确一件事：这不是给普通用户用的越狱
AirLift 是安全研究员 @0xjohnny 在 iOS 27 正式版推送当天公开的一个概念验证工具，他自己把它称作「配对越狱」。
名字里的「配对」是关键词。它不需要在 iPhone 端装任何应用、不需要越狱环境、也不需要签名描述文件，整条利用链路都跑在 macOS 这一侧。前置条件只有一个：你手上有一台此前已经和目标 iPhone 完成配对的 Mac。
作者公开的测试环境是 iOS 27.0 RC（版本号 24A435），并说明 iOS 27.0 正式版（24A437）同样有效。其它系统版本运行时会弹出警告提示。这种处理方式是典型的负责任披露：技术细节完整公开，但利用范围限制在已经推送的版本之外，避免被直接拿去滥用。
所以先把预期放正：这是一份给安全研究人员和越狱开发者看的技术材料，不是给日常用机的人准备的越狱工具。下面拆的是它的技术路径，不是推荐你去跑。
准备工作：需要的东西不多，但一样都不能少
如果你只是想跟着读代码逻辑，那什么都不用装。真要复现，按作者给出的路径需要下面这些。
- 一台 macOS 电脑，并安装 Xcode 命令行工具链
- 一台此前已经与该 Mac 完成过配对的 iPhone，系统为 iOS 27.0 RC 或正式版
- 从 GitHub 仓库获取代码，仓库地址：https://github.com/0xjohnnydev/airlift
- 主控脚本为 Python，另有两个 Objective-C 小工具需要编译
- 连接方式可选 Wi-Fi 或 USB，只要配对关系还在
仓库里的两个 Objective-C 文件分别是 device_helper.m 和 airtraffic_host.m，需要用 Xcode 工具链编译成可执行文件。Python 主控脚本负责串起整个流程。
跑起来会做什么：写一个随机金丝雀值，然后删掉
这一点值得单独说。PoC 运行时的动作被刻意限制在最小范围：它会在目标目录里写入一个随机的金丝雀值作为标记，确认写入确实落地之后立刻删除。
换句话说，它验证的是「我能写到这个位置」，而不是「我在这里留下了什么」。整个过程不污染用户数据，也不留痕迹。这是 PoC 的通行做法——证明能力存在即可，不越界。
执行入口是 airlift.py。在 Mac 上直接运行这个脚本，它会去连接那台已配对的 iPhone，然后顺着链路一层层往下走。
调用链从上到下走一遍
要理解这个漏洞，得先看清 macOS 和 iOS 之间是怎么「配对通信」的。这条链并不短，我把 mac 侧和 iOS 侧分开列。
macOS 侧：
- MobileDevice.framework —— 设备通信框架，负责识别和连接设备
- AirTrafficHost.framework —— 媒体同步主机框架，负责与设备侧同步服务对接
iOS 侧：
- streaming_zip_conduit —— 流式压缩传输管道
- afc —— 苹果文件连接服务，正常用途是传输媒体文件
- atc / AirTrafficDevice —— 媒体同步守护进程
- 图书同步客户端
- ATLegacyAssetLink —— 历史资源链接层，用来兼容旧版同步协议
- ATAirlock —— 沙箱闸门
- NSFileManager —— 最终执行文件操作的系统接口
整条链的设计初衷是让 Mac 能把音乐、图书、照片这类资源同步进 iPhone 的特定目录。问题出在链路末端的权限判定上：当请求一路走到 NSFileManager 时，最终生效的路径校验并不足以把访问范围约束在媒体目录内。
沙箱闸门是在哪几处漏的
把公开的分析归纳起来，这次的问题集中在三处。
- 第一处是兼容层。ATLegacyAssetLink 为了兼容旧协议保留了较宽松的路径处理逻辑，新的权限检查没有完全覆盖这条老通道。
- 第二处是闸门位置。ATAirlock 的校验发生在链路中段，而后续环节会重新拼接路径，校验过的路径和实际使用的路径存在不一致的空间。
- 第三处是调用者身份。请求最终以 AirTrafficDevice 守护进程的权限落到 NSFileManager，而这个守护进程本身的沙箱约束比应用层宽松得多。
三处单看都不算致命，叠在一起就构成了一条完整的逃逸路径。
能碰到哪些目录，碰不到哪些
PoC 展示出的可达范围相当宽。据公开的分析材料，它能够读写 /var/mobile 下的整个根目录，其中包括：
- 各应用的 Documents 目录
- 偏好设置（Preferences）文件
- SpringBoard 相关数据
- 短信数据库
- Safari 的浏览数据
- Containers 下的应用容器
这个范围基本覆盖了日常使用中绝大多数有价值的用户数据。
同样重要的是它没攻破的部分。MobileGestalt.plist 目前仍在保护范围之外——这个文件保存着设备的核心硬件标识信息，是很多越狱工具想要拿到的目标之一。AirLift 没能拿到它，说明这次逃逸虽然范围广，但并没有触及系统最底层的结构性保护。
也正因为这个限制，把它称作「沙箱逃逸」比称作「完整越狱」更准确。它拉开了口子，但没有拿下核心。
为什么这种「配对越狱」值得关注
传统的越狱路径大致分两类：一类靠硬件层漏洞，比如 checkm8 那类无法被软件修补的缺陷，代价是只对老机型有效；另一类靠软件漏洞，覆盖面广但苹果每次更新都可能封堵。
AirLift 属于第三类，攻击面落在「已配对设备的可信通道」上。这一类有几个特点：
- 不需要在目标设备上执行任何代码，本地防护手段比较难拦住
- 依赖配对关系，所以物理接触或长期持有配对凭证是前提
- 涉及的是系统服务之间的协议，而不是单一应用，修补起来要考虑兼容性
对普通用户来说，实际风险在于「配对过的电脑」这件事本身。如果你的 iPhone 曾经信任过某台电脑，那么这台电脑就成了一条可信通道。定期在设置里清理不再使用的信任设备，是成本最低的防护动作。
风险提示
最后把话说清楚。这个 PoC 目前的状态是概念验证，作者把写入动作限制在金丝雀值并立即删除，正是为了降低被滥用的可能。自己拿去改造成实际读写工具，风险全部由使用者承担，包括但不限于数据损坏、系统异常以及失去保修。
真机复现请务必使用备用设备，并提前做好完整备份。生产机、主力机上不要尝试任何未经验证的系统级操作。