GitHub 上一个叫 vphone-cli 的项目,这几天在越狱圈子里传得挺欢:一条命令,Apple Silicon 的 Mac 上就能起飞一台虚拟 iPhone,还能装 Sileo、跑 TrollStore,五档补丁方案从轻度绕过到全面越狱任你选。项目自称用的是苹果 Virtualization.framework 加 PCC(Private Cloud Compute)研究基础设施——听起来像是苹果偷偷开了个后门。
但这事没那么简单。真相是:这条路苹果压根没批准过,而且想让它跑起来,你得先把整台 Mac 的安全底裤脱了。
一条命令背后,五档由浅到深的绕过
vphone-cli vm create myphone -V jb 就能自动完成下载、打补丁、DFU 恢复、装 CFW、首次开机的全流程。核心卖点是五种补丁变体,绕过程度层层递进:
jb 档能直接越狱、装商店,exp 档更进一步,塞了"反虚拟机检测"的研究补丁,暗示能骗过一些完整性检测。这五档的野心,已经从"跑起来"变成了"跑得像真机"。
借道PCC是真的,但苹果没批过这条路
苹果确实为安全研究人员发过官方工具:Virtual Research Environment(VRE),配套 pccvre 命令行,专门用来在本地模拟 PCC 节点,走的是 csrutil allow-research-guests enable 这条被官方文档认可的通道。
vphone-cli 用的是同一批底层能力,但目的完全不同——它不是虚拟化 PCC 节点,而是拿 PCC 相关的私有 entitlement(PV=3)去虚拟化 iPhone 本体。苹果公开的开发者文档里,Virtualization.framework 只要求一个布尔型的 com.apple.security.virtualization entitlement,压根没有 PV=3 或者面向开发者的私有 security-research entitlement 说明。
- 风险.这是一条苹果文档体系之外的路,能跑通不代表被认可,苹果收紧相关签名或entitlement获取门槛的概率不小。
想跑起来,先把Mac的安全甲卸了
真正的成本在这里。要拿到 PV=3 权限,readme 给了两个选项:一是彻底关掉 SIP,再用 boot-arg 关掉 AMFI(amfi_get_out_of_my_way=1);二是保留 SIP 但用 amfidont 给这个二进制开白名单。
不管走哪条,本质都是在削弱整台 Mac 主机的系统级防护,而不只是"越狱一个虚拟设备"。SIP 和 AMFI 是 macOS 防止恶意代码篡改系统、伪造签名的两道核心闸门,平时普通用户接触不到,也不该轻易关。
虚拟机里越狱,代价却记在主机的安全账本上。
这笔账对越狱研究者可能划算——他们本就在专门机器上折腾。但如果哪天有人把这套教程当成"白嫖虚拟iPhone"的省钱攻略,直接搬到日常用的 Mac 上跑,那就是拿工作电脑的安全边界换一个玩具。
exp档的"反检测",谁验证过?
exp 档最诱人的宣传是"反虚拟机检测研究补丁",暗示能让虚拟 iPhone 骗过 App Attest、DeviceCheck 这类生产级完整性检测。但目前没有任何公开、独立的测试数据支撑这个说法。
拿商业方案 Corellium 做参照更清楚:Corellium 自己的官方文档都承认,它虚拟的 iOS 设备能通过序列号这类标识被识别出来,同时不支持 iCloud 登录、App Store 下载,GPU/Metal 支持也不完整。连专业团队多年打磨的产品都做不到"绝对隐身",一个开源项目靠补丁堆出来的反检测能力,可信度自然要打个问号。
vphone-cli 的 GitHub issue 列表里,DFU 恢复失败、Frida attach 引发内核 panic、应用启动崩溃这些问题也还挂着没解决。它更像一个正在快速迭代的研究玩具,而不是能替代 Corellium 的生产级工具。
- 结论.能跑起来的是虚拟iPhone,能验证的只是"技术上可行",距离"生产可用、检测无感"还差一大截。
苹果的设备完整性检测生态,眼下多了一个变量,但还不到需要重新设计防线的程度。真正该被这条新闻提醒的,反而是那些冲着"免费白嫖 Corellium 平替"跑去关自己 Mac 的 SIP 的普通开发者——工具能跑,安全代价却是真的。