用 Virtualization.framework 在 Mac 上跑虚拟 iPhone:vphone-cli 完整实战指南
长期以来,安全研究者和应用开发者想要一台可自由折腾的 iPhone 几乎只有两条路:要么花钱买一堆真机,要么在黑灰产里淘一台带漏洞的老设备。苹果在 macOS 15(Sequoia)里悄悄打开了一扇侧门 - - Virtualization.framework 开始支持 PV=3 级别的私有客户机,加上 Internal 渠道泄露的 PCC 研究型虚拟机基础设施,让普通研究者在自己的 Mac 桌面上就能跑起一台几乎与真机无异的 iOS。本篇文章要拆解的,就是 Lakr233 开源的 vphone-cli 这套工具链,它把下载、合并、打补丁、DFU 恢复、安装越狱环境、首次启动这一整条流水线自动化,让"虚拟 iPhone"从一个研究员的小众玩具变成了可以一键复现的工程实践。 首先要理解这背后的硬件与系统门槛。Virtualization.framework 的私有客户机模式仅在 Apple Silicon 的 M 系列芯片上可用,Intel Mac 已经被彻底排除在外。同时宿主机必须运行 macOS 15 或更新版本,且需要安装最新版本的 Xcode 与 iOS SDK,因为工具链中有一个跨平台编译的 guest 守护进程 vphoned 需要使用 Apple 工具链进行构建。
更敏感的一点在于,苹果对 PV=3 客户机的限制写在系统完整性与签名校验里:默认情况下,AMFI 会拒绝未签名二进制携带这些私有权利运行,所以必须先对 SIP 与 AMFI 进行放行。常见做法是进入恢复模式执行 csrutil disable 以及 csrutil allow-research-guests enable,再回到正常系统通过 sudo nvram boot-args="amfi_get_out_of_my_way=1 -v" 让内核彻底放行;如果你希望保留 SIP 完整性不被全关,可以走另一条路,启用 csrutil enable --without debug,再使用 vphone-amfidont 单独为 vphone-cli 二进制做白名单,这样既能满足研究需要,又尽量减少宿主机暴露面。 宿主机环境准备妥当后,下一步是部署依赖。vphone-cli 并没有把全部外部组件打进自己的 .app 里,而是依赖 Homebrew 提供 Python 3.13、aria2、wget、gnu-tar、openssl@3、ldid-procursus、sshpass、keystone、cmake、libusb、ipsw、zstd 等一系列工具。aria2 负责多线程下载体积庞大的 iPhone 与 cloudOS IPSW,gnu-tar 在解压苹果特有的压缩格式时比 BSD tar 更稳,ldid-procursus 用来对补丁后的系统二进制进行伪签名,keystone 则是逆向与汇编时常用。安装命令一句 brew install 即可搞定,但要注意一个隐藏的坑:截至撰文时 Homebrew 仓库中 ldid-procursus 的稳定版本在处理某些 entitlements plist 中整数值为 0 的字段时存在一个未定义行为导致的死循环,CFW 安装阶段会表现为内存被吃光、签名进程卡死。
解决办法是从源码构建 brew install --HEAD ldid-procursus,再 brew link --overwrite 覆盖版本。如果已经卡住,sudo kill -9 杀掉相应 ldid 进程后重装即可。 vphone-cli 的安装非常贴心地提供了一条龙体验。不想自己折腾编译的用户可以直接通过第三方 tap 拉取预编译版本,命令是 brew install zqxwce/tap/vphone-cli;想要跟随主分支迭代的研究者则建议走源码路线:git clone --recurse-submodules 把 pymobiledevice3 等子模块一起拉下来,然后依次执行 scripts/setup_tools.sh 与 scripts/build.sh。前者会装齐所有依赖、构建工具链子模块并准备好一个隔离的 Python 虚拟环境;后者会编译并签名 vphone-cli 本身、将其打包成独立的 .app,并交叉编译出运行在客户机里的 vphoned。最终产物落在 .build/vphone-cli.app/Contents/MacOS/vphone-cli,直接 --help 就能看到完整子命令树。
整个项目刻意把虚拟机的数据目录与 .app 拆开,前者统一放在 ~/.vphone/ 之下,方便用户通过环境变量 VPHONE_ROOT、VPHONE_LIBRARY_ROOT、VPHONE_VENV_DIR 灵活重定向位置;这让团队协作、批量跑多台 VM 备份恢复都成为可能。 数据目录里最关键的子目录是 VMs、ipsws、tools 与 debs。VMs 用来存放一台一台独立的虚拟机束,每台 VM 拥有自己的 CPU/内存/磁盘配置、磁盘镜像、恢复目录、签名缓存与 host 控制套接字 vphone.sock;ipsws 缓存下载过的 iPhone 和 cloudOS 固件包,避免重复拉取那动辄七八 GB 的体积;tools 用来放 apfs_sealvolume 等补丁阶段需要的辅助二进制;debs 则是越狱变体下要注入客户机的 Sileo、apt 等 deb 包缓存。理解这棵目录树之后,你基本就能像使用 Docker 一样管理一组虚拟 iPhone。 真正让 vphone-cli 区别于其他玩具项目的,是它把端到端创建一台虚拟 iPhone 的全部步骤浓缩成一条命令:vphone-cli vm create myphone -V jb。参数 -V 决定安全绕过等级,可选 less、regular、dev、jb、exp 五个变体。
less 是最保守的"补丁最少"路线,只打 4 个补丁,分两阶段部署 CFW,目的就是保留 iOS 自身的缓解机制,适合只想观察默认行为的研究者;regular 是默认基线,42 个补丁、十阶段 CFW,覆盖 AMFI、SSV、Img4、TXM 几条主线;dev 在 regular 之上额外打开 TXM 调试与权利绕过,53 个补丁十二阶段;jb 进一步把所有越狱需要的钩子打齐,113 个补丁十四阶段,启动后自动部署 Sileo 与 TrollStore;最激进的 exp 在 jb 之上叠加反虚拟化检测的研究型补丁,共 141 个补丁十八阶段,常见于安全对抗与红队测试。详细到每个二进制组件的差异,作者在 research/0_binary_patch_comparison.md 里做了逐项对比,建议在选择前先读一遍。 对于需要细粒度控制的高级用户,vphone-cli 同样提供了拆分执行的能力。第一步是 vphone-cli vm new 创建空束,支持自定义 CPU 核数、内存大小、磁盘容量,后续也能用 vphone-cli vm config 动态调整。第二步是 vphone-cli fw prepare myphone --iphone-version 26.1,这一阶段会下载对应版本的 iPhone IPSW 与 cloudOS IPSW,把它们合并成适合虚拟化的格式,并预拉取 apfs_sealvolume 工具。第三步是 vphone-cli fw patch myphone --variant jb,把你选择的变体写入启动链;如果是从一个旧版本升级到新版本,可以指定 --iphone-source /path/to.ipsw --cloudos-source /path/to.ipsw 直接以本地 IPSW 为输入,避免重新下载。
第四、五步是真正进入恢复与安装阶段:先用 vphone-cli vm launch myphone --dfu & 把 VM 启动到 DFU 模式后台运行,再执行 vphone-cli restore myphone --get-shsh 拉取 SHSH 票据,随后 vphone-cli restore myphone 走完整的 DFU 恢复流程。恢复完成后用 vphone-cli vm stop myphone 退出 DFU 启动,接着用 vphone-cli cfw install myphone --variant jb 把越狱环境通过宿主挂载的方式写入客户磁盘 - - 这一步因为要写宿主内核保护下的镜像,所以会要求 sudo 提权。最后,vphone-cli vm launch myphone 完成首次启动,理论上你就能在屏幕上看到锁屏界面了。 启动之后的连接与日常运维同样不容忽视。SSH 是最高效的入口,端口固定为 22222,越狱变体下使用 ssh -p 22222 mobile@<vm-ip> 加上默认密码 alpine 进入;非越狱变体下用 root 账户登录即可。需要图形化交互时,可以直接打开 macOS 自带的"屏幕共享"应用,输入 vnc://<vm-ip>:5901,或者用任意 VNC 客户端连过去。
VNC 在首次配置时尤其重要,因为 iOS 在初始化阶段会卡在"按下主屏幕键继续"的提示上,真机用户只需按一下侧键或 Home 键,虚拟环境则需要在 VNC 窗口里用两指点击或右键来模拟物理按键。如果你打算在 CI 或远程开发机里跑这套环境,更建议用 vphone-mcp 把宿主控制套接字封装成 MCP 协议,让 AI 代理直接驱动点击、滑动、截图、剪贴板这些动作,从而实现端到端的自动化测试。 在 vphone-cli 的日常命令里,vm list 与 vm info 负责清点当前所有 VM 的状态,vm clone 提供基于 APFS 快速克隆的新身份副本,vm export 与 vm import 则把整台机器打包成 zstd(默认)或 xz 压缩档,方便在不同 Mac 之间迁移或归档。导出路径可以是具体的 .tzst/.txz 文件,也可以是目录让工具自动命名,并且会主动跳过恢复目录与临时暂存文件以减小体积。导入时配合 --name 指定新的 VM 标识。vm rename 与 vm delete 负责改名和彻底清理。
当然,这条路并不总是平坦的。README 末尾的 FAQ 几乎是把用户最容易踩的坑都写了出来。首当其冲的是 zsh: killed ./vphone-cli,这种情况 100% 是 AMFI 与调试限制没有被放行,请回头检查 csrutil 与 amfi_get_out_of_my_way 状态。第二个常见错误是"Virtualization is not available on this hardware",这通常说明你的 macOS 本身已经跑在一台虚拟机里,例如在 Parallels、UTM 或云 Mac 里再嵌套一次;PV=3 客户机无法在虚拟化宿主机上启动,必须使用裸金属的 Apple Silicon。第三个坑是首次启动卡在"Press home to continue",VNC 两指点一下就好。第四个坑在系统应用装不上,原因是初始化向导里把地区选成了日本或欧盟,这些地区带有额外的合规校验,虚拟环境里的 nvram 没法满足;选美国或大多数其它地区就能顺利通过。
还有一类崩溃以 EXC_GUARD / GUARD_TYPE_MACH_PORT 形式出现,多见于 iOS 18 底包的应用,解决方案是加 --force-exc-guard 重新打补丁再恢复,并在 jb/exp 变体下保持开启 - - 实际上 vphone-cli 已经在 iOS 18 底包上默认开启该选项。 最后需要强调合法合规与适用边界。vphone-cli 面向的是有 Apple Developer Enterprise 或安全研究授权的研究者、越狱社区贡献者、iOS 应用兼容性测试工程师,而不是给普通用户绕开系统限制的捷径。苹果的 EULA 在不同地区对逆向、虚拟化和越狱的容忍度有差异,把它用于商业产品测试前请确保你拥有相应设备的固件下载授权、SHSH 票据来源合法,以及不违反所在地的出口管制法规。对研究社区而言,vphone-cli 最大的意义是它把原本散落在 GitHub Gist、Discord 频道、Telegram 群组里的"内部知识"沉淀成可复现的工程实践,任何一个新人只要有一台合规的 Apple Silicon Mac、一份官方的 iPhone IPSW、cloudOS IPSW 与 SIP 放行能力,就能在半小时内跑起一台带 SSH 与 VNC 的虚拟 iPhone,开始他们原本必须依赖昂贵真机或灰产设备才能完成的研究。对于 iOS 应用开发者来说,这也是低成本回归测试的利器:通过 vm clone 在数秒内复制出十几台配置相同的 VM,并行跑不同语言、不同地区、不同 Apple ID 下的安装与启动流程,比脚本农场里的真机维护成本低得多。
综上所述,vphone-cli 不是一次简单的"把 iOS 装进 VM"实验,而是一个成熟的工程化框架:它在 Virtualization.framework 之上补齐了固件合并、启动链补丁、DFU 恢复、CFW 注入、宿主控制这些缺失的环节,又通过 Homebrew tap、明确的数据目录、独立的环境变量重定向、详尽的 FAQ,把研究流程变得可安装、可复现、可分享。可以预见的是,随着 iOS 27 beta 已经在固件目录里被加入,未来虚拟 iPhone 的迭代节奏只会越来越快,而对希望深入理解 iOS 内核、AMFI 信任链或应用沙箱的工程师来说,这扇门已经开到了足够宽的位置。 。
