【免费下载链接】VirtualMacOniPadPeople have dreamed of running macOS on iPad for more than a decade. Today, that dream comes true. With Virtual Mac, iPad finally breaks free from iPadOS, enabling pro apps like Xcode, Terminal, Final Cut Pro, Logic Pro, and Pixelmator Pro to run directly on device. Requires iPad Pro (M1, M2) or iPad Air (M1) running iPadOS 14 up to 16.3.1.项目地址https://gitcode.com/gh_mirrors/vi/VirtualMacOniPad点击查看免费下载Virtual MacVirtualMacOniPad是一款让越狱 iPad ProM1/M2与 iPad AirM1直接运行 macOS 虚拟机的开源项目支持 Xcode、Terminal、Final Cut Pro 等专业应用。它最核心的机关是一个名为vzxpchook的 dylib 钩子通过劫持 XPC 通道调用在 iOS 缺少 launchd XPCService 机制的环境下让苹果 Virtualization 框架“以为”自己连上了 macOS 的虚拟机守护进程VMM从而把整个 macOS 虚拟机栈搬上 iPad。本文带你完整看懂这套钩子机制。为什么 iPad 上“直接连接”行不通XPC 服务墙在 macOS 上虚拟机的启动流程很直接Virtualization 框架调用xpc_connection_create(com.apple.Virtualization.VirtualMachine)由 launchd 负责拉起对应的 XPCService 子进程并建立连接。但把这套栈移植到 iPadOS 后会在 launchd 这堵墙上连续撞三次rootless 越狱拿不到系统域为一个 XPC 服务注册 launchd 守护进程需要系统域权限而越狱环境Dopamine/Taurine只能落在用户域501。服务名被 launchd 保留com.apple.Virtualization.VirtualMachine是 launchd 特判的 Application 类型服务会强制拉到前台用户域直接用这个名字注册守护进程会被以EX_CONFIG拒绝。子进程侧的xpc_main也用不了VMM 二进制的main()会调用xpc_main(handler)而 iOS 的xpc_main要求 launchd 的 XPCService 上下文它会去读 job 的 XPCService 配置字典直接调用就报 “Could not retrieve service name”。也就是说客户端和服务器端同时失效。vzxpchook 的思路不是去讨好 launchd而是绕开它两端都改用“匿名 XPC endpoint Mach 端口”手工搭建一条点对点通道再让框架误以为一切正常。劫持流程总览从“假连接”到“真通信”的 4 步整条链路涉及两个钩子文件分别插在父进程iPad 上的宿主 App和子进程被拉起的 VMM里宿主侧VirtualMac/vz/host/vzxpchook.m以DYLD_INSERT_LIBRARIES方式注入子进程侧VirtualMac/vz/host/vmmhook.m通过链接依赖随 VMM 加载。流程图可以概括为拦截宿主进程内框架调用xpc_connection_create时命中钩子不再走 launchd 查找自己拉子进程钩子用posix_spawn直接启动 VMM 二进制子进程发布“门牌”子进程里的 vmmhook 建好匿名监听器把它的 Mach 端口号写进/tmp/vmm_ep.txt父进程取端口、换端点父进程利用越狱的task_for_pid权限把端口“偷”回自己命名空间重建 XPC endpoint 并发起连接——框架拿到的就是一个可用的连接对象。第一步拦截 xpc_connection_create只认两个“服务名”vzxpchook.m导出了一个与 libxpc 同名的xpc_connection_create见 vzxpchook.m 的导出实现。这里有个精妙之处它不是用__interpose而是直接导出平命名空间符号——因为提取出来的 Virtualization 框架对 iOS 侧很多符号是“认证弱导入”authenticated weak importdyld_dynamic_interpose枚举不到共享缓存来源的 GOT 槽位而 dyld 的全局平查找会在加载镜像里找到这个导出符号并完成绑定。钩子内部逻辑很克制服务名是com.apple.Virtualization.VirtualMachineVMM→ 走spawn_vmm_and_connect服务名是com.apple.Virtualization.Installation系统安装服务→ 走spawn_installation_and_connect其余调用一律转发给真正的系统实现不干扰 App 的其他 XPC 通信如果自建通道失败会回退返回一个真实的 XPC 连接让框架优雅报错而不是解引用空指针崩溃。第二步子进程自己发布“门牌”——vmmhook 接管 xpc_main父进程posix_spawn拉起 VMM 后子进程环境会被刻意剔除DYLD_INSERT_LIBRARIES避免把宿主钩子带进子进程子进程里的 vmmhook 对xpc_main的替换 接管了原本无法工作的入口创建一个匿名 XPC 监听器xpc_connection_create(NULL, ...)完全不需要 launchd 签到监听器的事件处理器就是 VMM 真正的连接处理器收到对端连接PEER 事件后直接转交通过xpc_endpoint_create拿到 endpoint 对象读出其内部第0x18字节处的 4 字节 Mach 端口名以文本形式发布到/tmp/vmm_ep.txt路径可用环境变量VZ_VMM_ENDPOINT_FILE定制。这个“0x18处藏着底层 Mach 发送权”的关键偏移量不是猜的而是项目先用探针程序 epprobe.m 在 iPad 上实测验证过的该探针还顺带验证了“克隆 endpoint 对象并覆写端口port-swap后仍能从新端点连到原监听器”这一整套会合原语是整个方案的地基。第三步task_for_pid 跨进程“偷”回 Mach 端口父进程这边开始轮询读取子进程发布的端口文件每 50ms 一次最多等约 60 秒给调试器留足了窗口。拿到端口号后用越狱环境才有的task_for_pid权限调用mach_port_extract_right以 COPY 语义把子进程命名空间里的发送权提取到自己的任务里。两个工程细节值得注意会话文件唯一化端口文件路径会自动拼上uid.pid如/tmp/vmm_ep.txt.501.1234防止上次崩溃残留的旧文件把端口“投毒”给新启动其他身份拥有文件时会自动换一条带随机后缀的新路径Taurine 越狱的预检兼容若检测到 Taurine 的 stage2 组件子进程会以 SUSPENDED 状态启动先把 jailbreak 环境“铺”到子进程里再恢复执行——保证 VMM 以正确的权限运行。第四步端口换装重建 endpoint 完成会合拿到端口后父进程完成最后一击见 spawn_vmm_and_connect 的实现创建一个临时的匿名连接 xpc_endpoint_create得到一个“形状正确”的 endpoint 对象直接把第0x18字节的 4 字节覆写为刚偷来的端口发送权即 epprobe 验证过的 port-swap调xpc_connection_create_from_endpoint建立连接——VMM 子进程的监听器随即收到 PEER 事件把它交给 VMM 真正的处理器。从此Virtualization 框架以为自己在和系统 XPC 服务对话实际上对面是钩子亲手拉起的 VMM 进程。配置下发、屏幕帧回传、键盘触控输入、音频等全部走这条自建通道对用户完全透明。Installation 服务同款玩法一个监听器多条连接安装 macOS 系统时框架还会连com.apple.Virtualization.Installation。这里钩子做了一个关键设计见 Installation 会合实现保留同一个重建出的监听 endpoint后续每次连接都从它派生新的对端连接最多支持 16 条。原因很实际launchd 托管的 XPC 服务本来就是“单监听器”模型Virtualization 在一次安装过程中会打开多条对端连接如果每次xpc_connection_create都新拉一个子进程DFU 状态就会散落在互不相干的 MobileDevice 实例里恢复流程直接崩掉。子进程退出后钩子用waitpid回收宿主退出前还会SIGKILL兜底清理不留野进程。钩子的“副业”让 macOS 框架在 iOS 环境活下来vzxpchook 远不止“牵线搭桥”。为了让从 dyld 共享缓存提取出来的 macOS 13.2.1 版 Virtualization 框架在 iPadOS 上正常工作它还顺手补齐了一批环境差异均在 vzxpchook.m 中被替换的调用问题钩子的对策sandbox_extension_issue_generic_to_processiOS 上该私有 API 弱导入不可用VZ 会抛出误导性的 “Failed to retrieve cache directory”返回假令牌字符串VirtualMac-no-sandboxVMM 本身以 no-sandbox 授权运行扩展无意义配对一个空实现的 releaseconfstr(65537/65538)iPadOS 对这些 per-user 临时/缓存目录选择子返回 0返回真实可写的/tmp/sysctlbyname(kern.osversion)iPad 自报 iPadOS 16.3.120D67与框架预期的宿主版本不符仅此一项返回 macOS 13.2.1 的22D68其余 sysctl 保持原生行为帧缓冲消息开机首帧前的控制消息与 ACK 时序敏感启动前暂存首条控制消息与process_frame_updatevz_host_vm_started后按序放行稳态 ACK 必须同步直发否则会耗尽有限的 IOSurface 缓冲池对于以 dlopen 方式而非启动注入加载钩子的 UIKit 宿主文件里的vz_rebind_virtualization还会做最后一道工序定位提取镜像里那批认证 GOT 槽位如xpc_connection_create在偏移0x147b98处vm_protect改写权限后用 ptrauth 以槽位地址为判别因子重新签名并绑定——这就是 arm64e 指针认证环境下的“外科手术式重绑”。相关授权配置可参考 VirtualMac/vz/patches/vmm.ents.xml早期基于 launchd 的尝试则保留在 VirtualMac/vz/host/vmm-launchd.plist 中作为对照。快速上手日志文件与调试开关清单想亲眼验证这套机制钩子把所有关键环节都落盘成了文本日志宿主侧日志/tmp/vzxpchook.log连接劫持、端口提取、endpoint 重建全程打点子进程日志/tmp/vmmhook.log监听器建立、端口发布、PEER 到达VMM 标准输出/错误/tmp/vmm.stderr.logroot 恢复与 mobile 启动各用独立路径互不污染Installation 服务日志/tmp/installation.stderr.log。常用调试环境变量VZ_DEBUG_LOGGING1打开宿主/子进程的完整计数与逐条消息日志VMMHOOK_DEBUG_SLEEPN子进程在接受连接前休眠 N 秒方便 lldb 挂上去打断点VZ_VMM_BIN/VZ_VMM_ENDPOINT_FILE替换 VMM 二进制路径与会合文件路径VMM_FACTORY_SETTLE_USEC调节设备工厂线程的停止/恢复节奏。配套的启动、部署与探测脚本都放在 VirtualMac/scripts/development/ 目录如deploy-ipad-vm.sh、run-ipad-vm.sh研究脚本见 VirtualMac/scripts/research/ 目录。总结把“缺胳膊少腿”变成“自定义骨架”vzxpchook 的精髓可以浓缩成一句话当系统拒绝按标准流程提供服务时就用框架自己认可的“原始积木”匿名 endpoint、Mach 端口、平命名空间符号导出把服务手工搭出来。拦截xpc_connection_create是入口task_for_pid 端口提取是钥匙port-swap 重建 endpoint 是门锁而 vmmhook 在子进程侧把xpc_main换成匿名监听器完成了对端。两者合璧Virtualization 框架在 iPad 上获得了与 macOS 体验一致的 XPC 通道——这也是 Virtual Mac 能让 Xcode、Final Cut Pro 这类重型 macOS 应用跑在 iPad 虚拟机里的底层基石。更多移植管线背景去缓存化、重盖章 iOS、各类 shim可参阅 README.md 的 Technical Overview 章节。赞分享【免费下载链接】VirtualMacOniPadPeople have dreamed of running macOS on iPad for more than a decade. Today, that dream comes true. With Virtual Mac, iPad finally breaks free from iPadOS, enabling pro apps like Xcode, Terminal, Final Cut Pro, Logic Pro, and Pixelmator Pro to run directly on device. Requires iPad Pro (M1, M2) or iPad Air (M1) running iPadOS 14 up to 16.3.1.项目地址https://gitcode.com/gh_mirrors/vi/VirtualMacOniPad点击查看免费下载相关推荐为什么 Virtual Mac 让 iPad 秒变 Mac运行 macOS 虚拟机的完整指南为什么 Virtual Mac 让 iPad 秒变 Mac运行 macOS 虚拟机的完整指南 Virtual Mac on iPad 是一款开源工具它让 iVirtual Mac 是怎么做到的拆解 macOS 虚拟机在 iPad 上的运行原理Virtual Mac 是怎么做到的拆解 macOS 虚拟机在 iPad 上的运行原理 ! Virtual Mac 在 iPad 上运行 macOS 虚拟机的webext-bridge类型安全协议确保扩展消息通信零错误的最佳实践webext bridge类型安全协议确保扩展消息通信零错误的最佳实践 webext bridge是一款专为Web扩展设计的消息通信库通过类型安全协议确保扩创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考