iOS虚拟手机实现能力现状-夜雨聆风

iOS虚拟手机实现能力现状

上一篇《iOS虚拟手机实现原理解析》写作时，vphone-cli还处在很早期的形态，仓库大约只有5个commit。那时它更像一个把Apple私有Virtualization.framework能力拉起来的启动工具：用少量Swift/ObjC代码创建PV=3虚拟机，再配合Python脚本和Shell脚本完成固件合并、引导链补丁、DFU恢复、Ramdisk启动和CFW安装。

截至2026-04-26分析时，vphone-cli已经不只是“能启动虚拟iPhone”的PoC，而是逐渐演化成了一套围绕iOS虚拟手机构建、修补、安装、运行、自动化、越狱和环境切换的研究平台。

本文不再重复上一篇中已经讲过的PV=3硬件模型、私有Entitlements、DFU恢复、SHSH签名、Ramdisk引导和基础CFW安装细节，而是从当前仓库的提交演进和文件结构出发，梳理vphone-cli现在具备了哪些能力，以及这些能力相比早期版本解决了什么问题。

1 分析基线

分析的仓库为：

https://github.com/Lakr233/vphone-cli

项目当前最关键的变化可以概括为五点。

第一，固件补丁逻辑从早期Python脚本为主，迁移到SwiftFirmwarePatcher模块为主。Python现在主要保留在CFW二进制修补、pymobiledevice3桥接、Ramdisk构建等脚本侧。

第二，工具入口从分散脚本变成Makefile统一入口。构建、签名、VM创建、固件准备、固件补丁、DFU恢复、Ramdisk、CFW、越狱安装、Host预检、AMFI绕过辅助和备份切换都集中在make目标中。

第三，固件变体从单一路线扩展为Patchless、Regular、Development和Jailbreak四种路径。不同路径对应不同的安全绕过强度、调试能力和越狱能力。

第四，虚拟机运行时不再只是显示图形界面和串口，而是通过vphoned和主机侧控制Socket提供文件、应用、钥匙串、剪贴板、IPA/TIPA安装、位置、电池、低电量、触控、按键、截图和自动化测试能力。

第五，研究环境从一次性制作转向可复用生命周期管理。VM配置进入config.plist清单，ECID和UDID可以稳定预测，VM状态可以备份、恢复和切换。

2 项目变化

项目初始提交发生在2026-02-27，主题是“Add vphone CLI, ObjC wrappers, and scripts”。这个提交一次性加入23个文件，大约4933行内容。这个阶段的核心目标很明确：把PCC固件里的vphone能力搬到本地macOS上，让虚拟iPhone可以进入DFU、恢复固件、启动系统，并通过SSH/VNC访问。它更像上一篇文章分析的形态，技术重点集中在“如何跑起来”。

从2026-03-01到2026-03-08，提交密度明显上升。2026-03-04单日就有43次commit，是整个仓库演进中最密集的一天。这一阶段集中出现了JB安装流程、TXM补丁重构、Kernel JB补丁验证、GDB调试Stub、Ramdisk测试流程、vphoned雏形、录屏截图、文件传输、位置模拟、窗口状态、JB首启收尾等能力。也就是说，项目已经从“启动链补丁工具”转向“可交互研究环境”。

从2026-03-10到2026-03-12，仓库进入结构化重构阶段。d042596提交完成Swift固件补丁器与CLI接线，6d11093加入VM manifest系统，e189b80加入vphoned模块化、菜单整合和SwiftUI应用浏览器。这个阶段的意义在于，早期散落在Python脚本和临时验证脚本中的固件补丁逻辑，开始沉淀为可测试、可复用、可由CLI直接调用的Swift模块。

从2026-03-14到2026-03-20，仓库开始补齐工程化能力。新增VM备份、恢复和切换，新增aria2c下载支持，pymobiledevice3替代大部分外部libimobiledevice工具，--install-ipa支持自动安装，boot_host_preflight.sh开始承担Host环境诊断职责。这些提交解决的是“每次都手工搭环境、手工排错、手工切换”的痛点。

从2026-03-28到2026-04-22，项目的重点又转向自动化和Patchless变体。主机侧vm/vphone.sock自动化控制Socket被加入，随后每次动作返回压缩灰度截图，适合AI或E2E测试工具闭环控制。Patchless路线则尝试减少传统引导链和内核安全绕过，转向文件系统重建、BuildManifest哈希更新、AEA密钥处理、GPU驱动和Mobile Activation修补等路线。2026-04中旬以后，AMFI预检、非完全关闭SIP/AMFI环境支持、amfidont辅助脚本、Patchless binpack和--no-vphoned选项也陆续出现。

这些提交线索说明，vphone-cli的目标已经从“证明iOS虚拟手机可启动”升级为“让安全研究者能够重复创建、修补、运行、控制和维护多个虚拟iOS环境”。

3 项目仓库结构

当前仓库结构已经明显分层。

sources/vphone-cli负责Host侧主程序。它包含CLI参数解析、VM生命周期、PV=3硬件模型、Virtualization配置、窗口和菜单、虚拟机视图、触控注入、位置转发、电池同步、Touch ID转发、录屏截图、文件浏览、应用浏览、钥匙串浏览、IPA/TIPA安装和主机侧自动化Socket。

sources/FirmwarePatcher负责Swift固件补丁。它按AVPBooter、iBoot、TXM、Kernel、DeviceTree、Filesystem和Manifest拆分模块，并通过FirmwarePipeline按固件变体组织执行顺序。这里还引入了ARM64编码/反汇编、IM4P处理、Mach-O辅助、PatchRecord输出和测试目标。

scripts/vphoned是Guest侧守护进程。它运行在iOS虚拟机内部，通过vsock端口1337和Host侧通信。它承担HID、文件、钥匙串、应用、剪贴板、URL、设置、位置、低电量、IPA安装等能力，并在非Patchless路径下支持自更新。

scripts/patchers现在主要保留CFW阶段的动态二进制修补逻辑，例如seputil、launchd_cache_loader、mobileactivationd和launchd的jetsam补丁。

research目录则记录补丁矩阵、TXM分析、Kernel JB补丁验证、DeviceTree、manifest来源、键盘事件链路、机器标识存储和迁移总结。它已经不只是说明文档，而是补丁可靠性和跨版本迁移的依据。

4 四种固件变体

当前项目把固件路线分为Patchless、Regular、Development和Jailbreak四种变体。它们不是简单的开关组合，而是四个不同目标的制作路径。

Patchless变体的目标是尽量减少传统意义上的引导链和内核安全绕过。它保留更多iOS安全机制，转而通过文件系统合并、trustcache生成、mtree生成、digest.db生成、SystemVolume root_hash生成、BuildManifest哈希更新和AEA重新加密来让系统接受修改后的文件系统。后续提交还加入了GPU驱动、Mobile Activation补丁、vphoned安装、binpack可选安装、--no-binpack和--no-vphoned开关。它适合研究“更接近原厂安全状态”的虚拟iOS环境，但并不等于完全无修改。

Regular变体是上一篇文章主线的延续。它会绕过AVPBooter、iBSS、iBEC、LLB、TXM和Kernel中的关键签名、SSV、APFS、AMFI、launch constraints、dyld策略和Sandbox路径，再通过CFW安装Cryptex、GPU驱动、iosbinpack64、launchd缓存加载器补丁、mobileactivationd补丁和LaunchDaemons。它的价值是稳定得到一个可SSH、可VNC、可运行基础工具的虚拟iPhone。

Development变体在Regular基础上增强调试能力。它使用TXMDevPatcher，加入get-task-allow、debugger entitlement、Developer Mode bypass等补丁，并在CFW阶段加入dev overlay、rpcserver_ios替换和debugserver权限修补。2026-04-20还加入了thread_guard_violation相关内核补丁，用于禁用EXC_GUARD交付，使行为更接近生产环境中不崩溃的路径。这个变体更适合动态调试、RPC控制和调试器接入。

Jailbreak变体是安全绕过最强的路径。根据research/0_binary_patch_comparison.md，它在基础补丁之外包含TXM Dev/JB补丁、iBSS nonce跳过、Kernel JB扩展、Procursus bootstrap、BaseBin hooks、TweakLoader、Sileo、TrollStore Lite和首启LaunchDaemon收尾。研究文档中的细粒度统计显示，Regular总计51项，Development总计65项，Jailbreak总计127项。这里的总数包含启动链补丁、CFW二进制补丁和安装组件，粒度比README首页的用户摘要更细。

从能力定位看，四种变体可以这样理解：

Patchless

用于尽量保留安全机制的文件系统重建路线。
Regular

用于稳定启动和基础远程访问。
Development

用于调试器、RPC和开发态实验。
Jailbreak

用于完整越狱环境、包管理器、插件加载和更深系统访问。

5 Swift固件补丁

早期仓库使用Scripts/patch_firmware.py处理固件补丁。当前仓库已经把这条主线迁移到SwiftFirmwarePatcher模块。Package.swift中可以看到独立的FirmwarePatchertarget，它依赖Capstone、Img4tool和MachOKit，并被vphone-cli可执行程序引用。

当前CLI支持两个直接面向固件补丁的子命令：

vphone-cli patch-firmware --vm-directory <dir> --variant regular
vphone-cli patch-component --component kernel-base --input <file> --output <raw>

FirmwarePipeline按以下顺序组织组件：

AVPBooter
iBSS
iBEC
LLB
TXM
kernelcache
DeviceTree
Filesystem
Manifest

不同变体会在这些组件上选择不同的patcher。Regular使用基础iBoot、TXM和Kernel补丁。Development把TXM切换为TXMDevPatcher，Kernel使用dev模式。Jailbreak会在基础Kernel补丁后追加KernelJBPatcher，并在iBSS阶段追加JB扩展。Patchless则跳过大部分传统引导链和内核补丁，把重点放到Filesystem和Manifest。

这次迁移的价值不只是“用Swift重写”。它改变了补丁工程的组织方式：

IM4P容器加载和保存由IM4PHandler统一处理。
PatchRecord可以输出为JSON，便于比较和回归。
DeviceTree、Filesystem和Manifest作为管线阶段参与，而不是散落在临时脚本中。
make fw_patch

、make fw_patch_dev和make fw_patch_jb都通过Swift管线执行，减少Python脚本与Swift启动器之间的语义漂移。
测试目标tests/FirmwarePatcherTests用于维持补丁行为的一致性。

上一篇文章中大量描述了AVPBooter、iBoot、TXM和Kernel的补丁原理。当前仓库真正新增的能力，是把这些补丁从“可执行脚本”提升为“项目内部可维护的固件补丁系统”。

6 自动化安装与运行

早期制作拉起虚拟iPhone需要人工串起多个步骤：安装依赖、构建工具、创建VM、下载两份固件、合并固件、补丁、启动DFU、获取SHSH、恢复、构建Ramdisk、发送Ramdisk、进入SSH、安装CFW、首次启动。当前Makefile已经把这些步骤统一成可组合目标。

一键流程入口是：

make setup_machine

它背后的scripts/setup_machine.sh会按顺序完成以下工作：

执行Host依赖安装、项目构建和签名。
创建VM目录并生成config.plist。
执行fw_prepare下载或复制iPhone IPSW和cloudOS IPSW。
根据参数选择fw_patch、fw_patch_dev、fw_patch_jb或fw_patch_less。
启动DFU并执行restore_get_shsh和restore。
再次进入DFU，构建并发送SSH Ramdisk。
启动usbmux端口转发并执行CFW安装。
启动首次正常系统并分析串口输出。

它还支持多个实用参数：

make setup_machine JB=1
make setup_machine DEV=1
make setup_machine LESS=1
make setup_machine NONE_INTERACTIVE=1
make setup_machine SUDO_PASSWORD=...
make setup_machine SKIP_PROJECT_SETUP=1
make setup_machine LESS=1 NO_BINPACK=1
make setup_machine LESS=1 NO_VPHONED=1

这些参数解决了不同研究场景下的重复制作问题。比如调试Kernel补丁时可以跳过项目安装，只重复固件和启动流程；做Patchless实验时可以排除binpack或vphoned，观察更小修改面的系统行为。

setup_tools.sh负责依赖安装。它会检查Homebrew依赖，构建trustcache和insert_dylib，创建Python虚拟环境，并在Patchless模式下额外准备apfs_sealvolume。这相比早期手工编译libimobiledevice生态的流程简单很多。

fw_prepare.sh也比早期更灵活。它不再只接受固定URL，而是支持本地IPSW、直接URL、版本号、Build号和固件列表查询。它优先使用aria2c下载，并能基于ipsw工具列出目标设备可下载固件。对于反复尝试不同iOS 26构建的研究者，这比手工找URL可靠得多。

恢复和Ramdisk发送也转向pymobiledevice3桥接。scripts/pymobiledevice3_bridge.py提供usbmux-list、recovery-probe、ramdisk-send、restore-get-shsh和restore-update等命令，减少对外部二进制工具和本地编译状态的依赖。

7 Host环境和AMFI管理

虚拟iPhone依赖Apple私有虚拟化API和私有Entitlements，Host环境一直是最容易失败的地方。当前仓库已经把这部分纳入工程化检查。

boot_host_preflight.sh会检查以下状态：

macOS版本和硬件型号。
是否运行在嵌套Apple VM中。
kern.hv_vmm_present

状态。
SIP状态。
allow-research-guests

状态。
当前kern.bootargs和下次启动的nvram boot-args。
Gatekeeper评估状态。
release二进制、debug二进制和签名debug二进制是否能正常执行。

如果release签名二进制启动即退出137，脚本会提示这是AMFI或执行策略不允许私有虚拟化Entitlements的典型表现。如果Host本身是嵌套Apple VM，它会在--assert-bootable模式下提前失败，避免浪费时间进入VM启动阶段。

当前README给出两类Host安全配置路径。第一类是完全关闭SIP并通过amfi_get_out_of_my_way=1禁用AMFI限制。第二类是保留大部分SIP，只关闭debug限制，再使用amfidont或amfree对项目路径做允许。仓库里的辅助目标是：

make amfidont_allow_vphone

它会构建bundle，然后运行scripts/start_amfidont_for_vphone.sh。当前脚本通过amfidont daemon --path "$PROJECT_ROOT" --spoof-apple为项目路径启动AMFI绕过。Patchless变体对Host执行策略更敏感，README中特别说明需要完整AMFI路径或带-S能力的amfidont路径。

这部分能力的意义在于，项目不再只告诉用户“请关闭SIP/AMFI”，而是提供了可诊断、可复现、可定位的Host启动前检查。

8 VM配置与备份切换

早期虚拟机参数主要靠命令行和脚本隐含约定。当前仓库引入config.plist清单，结构兼容Applesecurity-pcc的VMBundle.Config风格。vm_create.sh和vm_manifest.py会把CPU、内存、磁盘、屏幕、网络、ROM、NVRAM和SEP路径写入VM目录。

默认配置包括：

platformType: vresearch101
cpuCount: 8
memorySize: 8192MB
screen: 1290x2796, 460PPI, scale 3.0
network: NAT
diskImage: Disk.img
nvramStorage: nvram.bin
sepStorage: SEPStorage
romImages: AVPBooter.vresearch1.bin, AVPSEPBooter.vresearch1.bin

VPhoneVirtualMachine会从config.plist加载或生成VZMacMachineIdentifier，并据此解析ECID和预测UDID。预测结果会写入udid-prediction.txt，后续恢复、Ramdisk发送和usbmux端口转发可以用这个身份信息避免多设备环境中的误连。

VM备份能力由三个脚本完成：

vm_backup.sh

把当前vm/保存到vm.backups/<name>/，默认排除*_Restore*/固件目录，并使用rsync --sparse处理稀疏磁盘。
vm_restore.sh

把指定备份恢复到活动vm/目录，并检查VM是否仍在运行。
vm_switch.sh

先保存当前VM，再恢复目标备份，实现多环境切换。

对应Make目标为：

make vm_backup NAME=26.1-clean
make vm_restore NAME=26.1-clean
make vm_switch NAME=26.3-jb
make vm_list

这让虚拟iPhone环境更接近“快照式研究资产”。研究者可以保留干净系统、Regular环境、Development环境、Jailbreak环境和不同iOS构建之间的状态，而不必每次重走完整恢复链路。

9 CFW安装能力

CFW安装仍然是从“能启动”走向“能用”的关键阶段。当前Regular和Development路径依然通过Ramdisk SSH修改设备文件系统，Patchless则把部分文件系统变更提前进Swift文件系统重建流程。

基础CFW安装包含以下能力：

安装SystemOS和AppOS Cryptex。
修补seputil的Gigalocker路径格式。
安装AppleParavirtGPUMetalIOGPUFamily虚拟GPU驱动。
安装iosbinpack64基础工具集。
修补launchd_cache_loader，允许修改后的launchd.plist生效。
修补mobileactivationd，绕过激活流程。
注入LaunchDaemons，启动bash、dropbear、trollvnc、rpcserver_ios和vphoned等服务。

Development路径会额外处理调试能力。cfw_install_dev.sh会应用dev overlay，把rpcserver_ios替换为开发版本，还会修补debugserverEntitlements，添加调试所需权限，并修补launchd的jetsam路径，避免启动时陷入initproc崩溃循环。

Jailbreak路径会在基础CFW之外追加越狱相关组件。cfw_install_jb.sh会注入launchd dylib、部署Procursus bootstrap、部署BaseBin hook库、安装TweakLoader.dylib，并把vphone_jb_setup.sh作为首启LaunchDaemon放入系统。

vphone_jb_setup.sh负责首次正常启动后的收尾工作。它会建立/var/jb链接，修复权限，运行prep_bootstrap.sh，安装Sileo，配置APT源，安装TrollStore Lite，刷新uicache，并为SSH交互写入shell profile。日志写入：

/var/log/vphone_jb_setup.log

这说明当前越狱能力已经不仅是内核补丁，而是包含包管理器、用户态hook、插件加载器和首启自修复流程的完整运行环境。

10 vphoned与Guest侧控制协议

vphoned是当前仓库能力扩展中最重要的组件之一。它是一个运行在iOS虚拟机内的Objective-C守护进程，通过LaunchDaemon启动，在vsock端口1337监听Host侧连接。

协议是长度前缀JSON：

[uint32 big-endian length][UTF-8 JSON]

Host侧由VPhoneControl.swift负责连接、握手、自动重连、请求超时、二进制传输和能力检查。Guest侧在握手时返回能力列表，例如hid、devmode、file、keychain、location、ipa_install、clipboard、apps、url和settings。

非Patchless路径下，vphoned还支持自更新。Host在hello消息里携带当前签名vphoned二进制的SHA-256，Guest侧发现哈希不一致后请求更新，Host推送新二进制，Guest写入缓存路径并退出，由launchd重启后切换到新版本。这避免了每次修改Guest代理后都重做CFW安装。

当前Guest控制能力包括：

HID按键注入，支持Home、Power、音量等硬件键。
Developer Mode状态查询和启用。
文件列表、下载、上传、删除、重命名和创建目录。
钥匙串枚举，可通过Security API和直接读取/var/Keychains/keychain-2.db补充结果。
剪贴板读取和写入，支持文本和图片。
应用列表、应用启动、应用终止和前台应用查询。
URL打开。
Settings读取和写入。
位置模拟和停止模拟。
低电量模式同步。
IPA/TIPA安装。
Accessibility树读取，前提是Guest暴露对应能力。

这些能力让虚拟iPhone不再只是VNC里的画面，而是可以被Host程序结构化控制的iOS实例。

11 Host侧自动化Socket

除了Guest内的vphoned，当前仓库还加入了Host侧自动化Socket。VPhoneHostControl.swift会在VM目录下创建Unix domain socket：

vm/vphone.sock

它接受一行JSON命令，执行后返回一行JSON结果。当前支持的命令包括：

{"t":"screenshot"}
{"t":"tap","x":645,"y":1398}
{"t":"swipe","x1":645,"y1":2600,"x2":645,"y2":1400,"ms":300}
{"t":"key","name":"home"}
{"t":"type","text":"Hello"}

除截图外，每个动作默认会等待短暂时间，然后返回一张压缩灰度JPEG截图的Base64字段。这个设计非常适合AI自动化和端到端测试：控制器每执行一次点击、滑动、按键或输入，都能立即拿到视觉反馈，用下一步决策闭环。

README中也明确提到vphone-mcp可以包装这个Socket，向Claude Code或Claude Desktop提供打开应用、返回、滚动、输入文本等高层工具。换句话说，当前vphone-cli已经具备面向AI测试代理的最小控制平面。

12 图形输入和传感器模拟

运行时体验也比早期版本完整很多。

触控方面，VPhoneVirtualMachineView负责把Host侧鼠标事件映射为虚拟触点，并通过私有_VZUSBTouchScreenConfiguration注入到Guest。主机侧自动化Socket的tap和swipe命令复用同一套像素坐标映射。

键盘和硬件键方面，VPhoneKeyHelper和菜单项支持Home、Power、Volume、Spotlight等操作，vphoned侧也可以接收HID按键事件。

显示和录屏方面，VPhoneScreenRecorder使用私有VZGraphicsDisplay截图能力，可以保存截图、复制截图到剪贴板，并用AVFoundation录制30FPS视频。后续提交修复了ImageIO SIGBUS问题，确保录屏总是捕获VM窗口。

位置方面，VPhoneLocationProvider可以同步Host位置，也可以发送预设位置和路线回放。菜单中内置了Apple Park、San Francisco Ferry Building、Times Square和Shibuya Crossing等预设点，还支持Apple Park Loop路线回放。

电池方面，VM内部配置了私有_VZMacSyntheticBatterySource，默认100%充电。菜单侧可以手动设置电量和连接状态，也可以通过IOKit同步Host电池状态，并把Host低电量模式同步到Guest。

Touch ID方面，VPhoneTouchIDMonitor通过macOS私有BiometricKit监听物理Touch ID传感器触摸事件，再把手指按下、抬起和双击等状态转发给Guest。这个能力需要com.apple.private.bmk.allow相关权限，体现了仓库对Host私有框架的进一步利用。

加速设备方面，2026-04-17的提交加入Entropy和Accelerator设备。当前VM配置中包含VZVirtioEntropyDeviceConfiguration，并尝试配置私有_VZMacVideoToolboxDeviceConfiguration和_VZMacNeuralEngineDeviceConfiguration。

这些改动说明项目已经开始模拟“手机运行环境”的外设和传感器，而不仅是让iOS内核启动。

13 文件应用和钥匙串

当前Host侧GUI也从早期单窗口启动器扩展为研究工具界面。

文件浏览器由SwiftUI实现，Host侧通过VPhoneFileBrowserModel和VPhoneFileBrowserView调用vphoned的文件接口。它支持目录浏览、搜索、排序、上传、下载、拖拽、删除、重命名和新建目录。2026-03-09以后还修复了指向文件夹的符号链接打开问题。

应用浏览器通过LSApplicationWorkspace和FrontBoardServices等Guest侧私有API列出应用，区分系统应用、用户应用和运行中应用，支持启动、终止和前台应用刷新。Host菜单会根据Guest能力动态启用或禁用Open URL和Install等动作，避免未连接时误操作。

钥匙串浏览器通过vphoned_keychain提供数据。它既尝试使用SecItemCopyMatching读取可访问项，也直接打开/var/Keychains/keychain-2.db读取genp、inet、cert和keys表。对于安全研究，这比普通iOS模拟器更接近真实设备取证和应用数据分析场景。

安装包支持也更完整。--install-ipa可以在VM启动后自动安装指定IPA或TIPA，菜单安装流程同样支持这两类包。vphoned_install.m会处理包解压、权限修复、Mach-O识别、签名证书、应用注册和清理流程。相比早期单纯依赖外部命令，这已经是Guest内建安装器。

14 Patchless路线

Patchless是近期提交中最值得单独关注的路线。它不是“完全没有补丁”，而是“尽量不走传统安全绕过补丁”。

早期Regular路线的核心思路是修改AVPBooter、iBoot、TXM和Kernel，让它们接受未签名或被修改的系统组件。Patchless路线则尝试从文件系统一致性出发解决问题：把Cryptex并入OS文件系统，修补必要用户态组件，重新生成trustcache、mtree、digest.db和root_hash，再更新BuildManifest中的组件哈希，使启动链尽可能看到一个一致的固件状态。

CryptexFilesystemPatcher中的注释概括了这条路线：

1. Collect the AppOS and SystemOS Cryptex from the iPhone BuildManifest
2. With the OS, AppOS, and SystemOS images, attach them and copy them to a target image
3. Create trustcache for resulting image
4. Create mtree for resulting image
5. Generate digest.db and SystemVolume root_hash
6. Join mtree and digest.db to Ap,SystemVolumeCanonicalMetadata

这条路线对安全研究有两个价值。

一方面，它让研究者可以观察更少安全绕过条件下的系统行为，避免Regular/Jailbreak路径把太多安全机制直接关闭，影响漏洞复现或策略分析。

另一方面，它把iOS系统镜像重建流程工程化了。它要求工具理解AEA加密、APFS镜像、Cryptex内容、dyld链接、trustcache、mtree、digest.db、root_hash和BuildManifest之间的关系，而不只是“哪里检查失败就patch哪里”。

近期提交中加入的embedded AEA key、按需remap fs、Patchless binpack、NO_BINPACK和NO_VPHONED，都说明这条路线仍在快速迭代。

15 越狱插件和用户态扩展

用户特别关心的越狱插件支持，主要体现在Jailbreak变体的几个层次。

第一层是内核和TXM安全绕过。Jailbreak变体启用TXM Dev/JB补丁、Kernel JB补丁、task_for_pid、NVRAM写入、sandbox扩展、MACF路径、dylinker限制、shared region、spawn persona、vm_protect、vm_fault等相关补丁。research/0_binary_patch_comparison.md把JB专属Kernel方法列成25个大项，部分方法内部还包含多个实际patch点。

第二层是BaseBin hooks。CFW安装会部署systemhook.dylib、launchdhook.dylib和libellekit.dylib到/cores/，并通过短路径/b把launchdhook.dylib注入launchd。这为用户态hook和越狱环境初始化提供基础。

第三层是Procursus。cfw_install_jb.sh会部署Procursus bootstrap，首启脚本会建立/var/jb，运行bootstrap准备脚本，配置APT源，并安装Sileo。Sileo出现后，虚拟机就具备了类似真实越狱设备的包管理入口。

第四层是TrollStore Lite。首启脚本会尝试安装com.opa334.trollstorelite，并在安装失败时不再轻易写入done标记，而是让日志暴露失败状态。这让越狱收尾过程更可诊断。

第五层是TweakLoader。2026-03-09的提交加入tweakloader到越狱安装流，当前research/0_binary_patch_comparison.md也把TweakLoader.dylib列为JB安装组件。它被安装到：

/var/jb/usr/lib/TweakLoader.dylib

这意味着当前Jailbreak变体不仅能启动越狱文件系统，还在向“可加载用户tweak、可验证插件行为”的方向推进。

16 当前能力边界

尽管能力已经大幅扩展，vphone-cli仍然是研究工具，不是普通意义上的iOS云手机产品。

首先，它强依赖macOS 15+、Apple Silicon、PV=3私有虚拟化能力和私有Entitlements。Host侧必须处理SIP、AMFI、allow-research-guests和Gatekeeper执行策略。没有这些条件，release签名二进制会直接被系统杀掉。

其次，Nested VM仍然不可用。如果Host本身运行在Apple虚拟机中，Virtualization.framework无法继续启动虚拟iPhone。当前boot_host_preflight.sh已经能提前识别这类环境。

第三，固件补丁虽已大量动态化，但仍跟iOS 26、cloudOS 26和vphone600/vresearch101平台深度绑定。README列出的已测环境集中在Mac16,12和iOS/cloudOS 26.1到26.3.1组合。未来iOS构建改变函数结构、字符串锚点或Image4布局时，仍可能需要重新定位补丁。

第四，Jailbreak变体的能力强，但修改面也最大。它适合逆向分析、调试和越狱生态实验，不适合验证“原厂安全策略下是否可利用”的漏洞条件。遇到策略相关研究时，Patchless或Regular可能更适合作为对照组。

第五，Guest侧高级能力依赖私有框架和运行时权限。应用管理、钥匙串、剪贴板、安装器、位置和Accessibility树都可能随系统版本变化而失效或降级。Host菜单中对Guest能力的动态检查，正是为了处理这类差异。

如果用一句话总结当前vphone-cli：它已经从“启动iOS虚拟机的命令行工具”演化成“面向iOS安全研究的虚拟设备制作和自动化控制平台”。

它的底层能力是PV=3虚拟硬件、PCC固件混合、DFU恢复和引导链补丁。

它的制作能力是Makefile一体化流程、Swift固件补丁管线、Patchless文件系统重建、Ramdisk和CFW安装。

它的运行能力是图形窗口、触控、键盘、串口、网络、SSH、VNC、RPC、位置、电池、Touch ID、截图和录屏。

它的研究能力是vphoned、文件浏览、应用控制、钥匙串读取、IPA/TIPA安装、剪贴板、Settings、Accessibility树和主机侧自动化Socket。

它的越狱能力是Jailbreak固件变体、TXM/Kernel JB补丁、Procursus、Sileo、TrollStore Lite、BaseBin hooks和TweakLoader。

它的环境管理能力是config.plist清单、稳定ECID/UDID、Host预检、AMFI辅助、VM备份、恢复和切换。

上一篇文章的结论是，iOS虚拟手机已经从“固件里发现的内部能力”变成“社区可以启动的研究环境”。现在更准确的结论应该是：vphone-cli已经把这个研究环境推进到可重复制作、可持续维护、可自动化操作、可切换安全强度、可承载越狱插件和动态分析工作流的阶段。

对于iOS逆向工程和移动安全研究来说，这个变化比“能不能看到SpringBoard”更重要。因为真正决定工具价值的不是第一次启动成功，而是能否在后续数百次测试中稳定重建环境、快速切换状态、自动收集反馈，并把Host侧工具链与Guest侧系统能力连接成一个闭环。当前vphone-cli已经基本具备了这个闭环的雏形。