ARTICLE · 1161368
有人把越狱版 iOS 装进了虚拟机:一个脚本,白得一台「虚拟 iPhone」
在一台 Apple Silicon Mac 上，跑起一台完整的、开箱即越狱的 iOS 虚拟机——真 iOS 内核，不装模拟器，一个脚本搞定。它的底层，用的是苹果自己藏在云服务器固件里的那套东西。
这个项目的开头，其实有点荒诞。
它不是从零造出来的，而是"捡"出来的——捡的，是苹果自己的零件。
先说它到底是什么：不是模拟器，是"真 iOS 虚拟机"
很多人第一反应是 Xcode 那个 iPhone 模拟器。但这两个东西完全不是一回事。
Xcode 模拟器，本质是在 macOS 上"假装"跑 iOS 的界面和用户态组件。它跑不了 App Store、跑不了 iCloud、Metal 图形受限，很多系统级的东西碰不到。
而这个 vphone，走的是虚拟化（Virtualization）路线：
它是在 Apple 的 Virtualization.framework 上，真正启动了一套 iOS 内核。
说人话就是：这不是"装样子"，是一台货真价实的虚拟 iPhone。
那这套固件是哪来的？答案在苹果的云上。
苹果搞 AI 要跑「私密云计算」（Private Cloud Compute, PCC）。为了在服务器上跑 iOS 逻辑，苹果的 cloudOS 固件里，藏了一个组件，代号 VPHONE600AP——说明书写得明明白白："iPhone 研究环境虚拟机"。
安全研究员 wh1te4ever 发现，把这块组件"移植"到 iPhone 16 的固件上、再修一修，就能让 iOS 在虚拟机里跑起来。
后来 Lakr233 把它做成了工具，而 34306 又做成了今天这个"一键版"。
vphone-aio：一个脚本，全给你打包好
仓库地址：github.com/34306/vphone-aio
一句话概括作者的自述："1 script run the vphone（iOS 26.1），已经越狱，bootstrap 也装好了。"
最省事的地方在于——它把整个虚拟机镜像（约 12GB）拆成 7 份，直接放在仓库里，你跑个脚本自动合并、解压、启动。
流程拆开看是这样：
| 步骤 | 做什么 |
|---|---|
| 1. 装依赖 | brew install git-lfs wget zstd libimobiledevice |
| 2. 调安全设置 | 关掉 SIP，并设置 amfi_get_out_of_my_way=1 |
| 3. 拿镜像 | 克隆仓库（约 12GB，作者说他用了 20 分钟） |
| 4. 跑脚本 | 执行 vphone-aio.sh，缺的分片会自动补下载 |
| 5. 等它合并 | 合并完自动解压，约 15 分钟 |
| 6. 连上去 | VNC 打开 vnc://127.0.0.1:5901 |
| 7. 开玩 | —— |
它还给了 SHA-256 校验码，用来核对镜像有没有下坏。
注意第 2 步——这恰恰是它最大的代价，我们放到后面"硬门槛"那一段细说。
「开箱即越狱」到底意味着什么
普通 iPhone 想越狱，难。版本得对得上，漏洞得能利用，越晚了苹果就把口子补了。
而这个镜像，你什么都不用做——它本来就是越狱状态，bootstrap 环境已经装好了。
意味着你一开机，就能直接装系统级插件、访问文件系统、跑那些 App Store 上根本不给上架的东西。 对做安全和逆向的人来说，这等于跳过了最折腾的一步。
这也正是它能火起来的原因：越狱版 iOS，白给。
但作者自己说了句实在话：去用 vphone-cli
这一点必须单独拎出来讲——因为它最能说明一个项目的成熟度。
vphone-aio 的作者在 README 第一行就写了：
"它好像又被人在 X 上随机发了一遍、又火了一次。建议大家改用 vphone-cli，更新和支持都更好。顺便，vphone-cli 现在支持到 iOS 27 了。"
翻译一下：这个"一键版"，作者自己都在劝你换到更正式的那个。
那就得说说 vphone-cli 了。
github.com/Lakr233/vphone-cli——已经有将近 15,000 Star，MIT 许可证，今天还在更新。
它比 aio 强在哪？
| 方面 | vphone-aio | vphone-cli |
|---|---|---|
| iOS 版本 | 停在 26.1 | 支持到 iOS 27 |
| 维护状态 | 8 月后再没动过 | 几乎每天更新 |
| 许可证 | 没有 LICENSE 文件 | MIT |
| 安全设置 | 关掉 SIP | SIP 保持开启，只放开调试限制 |
| 上手方式 | 一个脚本 | 图形界面 Launchpad + 命令行 |
| 访问方式 | VNC | SSH（root, 22222）/ VNC（5901）/ RPC（5910） |
vphone-cli 还能创建不同"补丁级别"的固件——从完全不打补丁的 less，一路到直接越狱、自动装 Sileo/TrollStore 的 jb。你要多干净有多干净，要多能折腾有多能折腾。
它甚至支持备份、导出、克隆虚拟机。 一台调好，克隆十台。
更值得玩味的一点：它专门为 AI / 自动化留了口子
这可能是它和"玩具"的分界线。
vphone-cli 提供了三种"脱离人手"的驱动方式：
•
本地 HTTP + WebSocket 接口——脚本直接控制；
•
配套的 MCP 服务器——接给 AI Agent，让它自己截图、点按、滑动、按硬件键、读写剪贴板；
•
SSH root 登录——想怎么脚本化就怎么脚本化。
它甚至内置了一段"让 Agent 帮你装"的提示词：你把那段话丢给 Claude Code，它会自己读文档、检查环境、装好、然后在需要你输密码或进恢复模式的时候停下来问你。
换句话说：一台可以完全被程序驱动的 iOS 真机环境，跑在你自己的 Mac 上。
做自动化测试、批量验证、App 行为研究的人，应该能立刻明白这意味着什么。
硬门槛和风险，必须说在前面
这段是全文最重要的部分，真想上手，请逐条看清。
第一，只有 Apple Silicon Mac 能跑，Intel 彻底无缘。
而且——不能在 macOS 虚拟机里跑（不支持嵌套虚拟化）。这不是"下载个软件"的轻量工具，是一整套内核级环境。 磁盘上，每个虚拟机默认 64GB 虚拟盘，作者建议留 128GB 以上空闲空间。
第二，代价是系统安全被调松。
vphone-aio 要求关闭 SIP（系统完整性保护），并设置 amfi_get_out_of_my_way=1——这会显著降低整台 Mac 的安全级别。
强烈建议只在专门的、不存放重要数据的机器上做这件事。 相比之下，vphone-cli 的做法更克制：SIP 保持开启，只放开调试相关的限制（csrutil enable --without debug + csrutil allow-research-guests enable）。如果只是想试试，优先走 vphone-cli 这条路。
第三，aio 那个下载方式本身就不太靠得住。
镜像走 Git LFS，而 GitHub 免费额度是 1GB 存储 / 1GB 流量——镜像却有 12GB，所以 git clone 经常直接挂掉。 加上它没有 LICENSE 文件、校验自动化被作者移除过，真要用，建议转向 vphone-cli 的官方发布页。
第四，它处在法律和合规的灰区。
这套东西的本质，是把苹果为自家云服务准备的固件"挪作他用"，并绕过固件签名校验。 苹果至今没公开表态。更现实的风险是：哪天 PCC 固件不再带 VPHONE600AP 这个组件，这条路可能一夜之间就断了。 它被明确地定位为安全研究工具，而不是日常生产力工具。
第五，关于"撸毛"这件事，我得说句实话。
虚拟化出来的 iOS，和真机在硬件指纹、传感器、网络特征上是有差异的。 拿它去批量注册、跑营销活动、多开账号薅羊毛——轻则被平台风控识别、封号清退，重则可能触碰平台条款甚至法律。
这类操作的后果，全在你身上。 工具本身不替你负责。把它用在正当的研究、开发和自动化测试上，才是它真正值钱的地方。
写在最后
这个项目最让人感慨的，其实不是"技术上多牛"，而是它的来路。
苹果为了做私密云计算，在自己服务器固件里留了一道门；研究人员发现这道门能通向一台"虚拟 iPhone"；于是今天，任何人都能在自己的 Mac 上，跑起一台开箱越狱的 iOS。
一个闭源公司精心修筑的基础设施，最后被开源社区用出了它从没想过的玩法。 这种事，过去十几年一次次上演。
它不会替代你的真机——门槛摆在那里，风险也摆在那里。但对搞安全、做逆向、玩自动化的人来说，这是过去很难拿到手的一件工具。
想试的话，从更成熟的 vphone-cli 入手：
•
vphone-cli（推荐）：github.com/Lakr233/vphone-cli
•
vphone-aio（本文主角，一键版）：github.com/34306/vphone-aio
•
原始研究记录（想看原理）：github.com/wh1te4ever/super-tart-vphone-writeup
觉得有意思的话，点个赞 or 分享给身边搞 iOS 安全、做 App 测试的朋友。（另外，动手前请一定先把"硬门槛"那段读完。）