#固件兼容性

哪些客户机固件与 cloudOS 的组合已知可以在哪些宿主机上启动。为新虚拟机选择版本之前，或者创建失败、想知道该组合是否测试过时，请查看本页。

要查看当前目录在你的 Mac 上提供哪些版本，请运行：

vphone-cli fw catalog

#已测试的环境

以下是用原生 JB 流程完整跑通的 iPhone17,3 组合。两行 PR #486（PR #486）进入了锁定屏幕并响应了 vphoned ping；另外一次全新的 26.6.2 vm create 也完成了所有阶段，并在首次启动 ping 后成功退出。

#使用哪个 cloudOS

除非有特别的理由，请使用 cloudOS 26.4 beta（26.4-23E5207q）。它是包含 vphone600ap 的最新 cloudOS，客户机的内核、SEP 和设备树都来自这一身份，而且除了 vphone-cli 之外不需要任何其他东西。

之后的所有 cloudOS（2026-10-03 核查）都只列出 PCC 主板和 vresearch101ap：SupportedProductTypes 中已没有 iPhone99,11，也没有 kernelcache.*.vphone600、sep-firmware.vphone600 或 DeviceTree.vphone600ap。在这类 cloudOS 上由研究主板代替（Research Board 补丁集）：

• fw patch 把研究主板的设备树和 SEP 转换为 vphone600 的版本，并按照该 kernelcache 的配方，用 vphone600 的虚拟化 kext 重新构建它的 kernelcache。
• KDK 提取在本机原生完成；只有链接需要 root 权限（vphone-cli fw kernelcache）。见 kernelcache 配方和固件准备。
• 没有配方覆盖的 cloudOS 会被 fw prepare 拒绝。
• fw catalog 会在推荐的 cloudOS 旁列出每个 iOS 版本自己的 cloudOS，Launchpad 在 Firmware（固件）下提供它。

其他 iPhone 和 iPad 版本或许可以与 26.4-23E5207q 配合使用，但尚未通过同样的完整检查。

#iOS 18 客户机

iOS 18.1 到 18.7.2 运行在各自版本的 cloudOS 上，用户空间来自 iPhone XS 系列的 IPSW：

• 用 vm create --device iPhone11,6 创建。默认使用 Minimal 预设；--preset standard 已在 18.6 上验证。
• fw catalog --device iPhone11,6 会列出这些版本。
• 它们的内核是 kernel-first 布局。从 macOS 26.4 起，需要由另一台运行 macOS 15 或 26.0 到 26.3 的 Mac 或 macOS 虚拟机通过 ssh 链接组合（VPHONE_KMUTIL_SSH；见固件准备）。
• Launchpad 以 iPhone XS Max 的名义提供它们，并以那台 Mac 作为 macOS 构建机。

18.1、18.5 和 18.7.2 已在虚拟机上验证；其他四个配方尚未启动过。

#iOS 27.0.1 上的 iPhone17,3

iOS 27.0.1（24A446）在 bundle 2.5.0 及更早版本上首次启动失败（2026-10-04 复现，使用未修改的 Apple launchd 也一样）：TXM 的 selector-24 预检查在 init 阶段拒绝所有二进制文件，启动时以 unexpected SIGKILL of init panic。旧的 txm-boot-precheck_admission 补丁修复了这个问题（见研究记录）。打上补丁后，26.4-23E5207q 上的 iPhone17,3 27.0.1 可以启动到客户机，并响应 vphoned 的 device.info（当天验证）。bundle 2.6.0 是第一个包含该补丁的版本。

本次改动用 txm-cfw-executable_remap 替代原来强制归为 type 10 的准入方式，standard 预设默认选中该补丁，不受操作系统版本限制。宿主机测试覆盖了原先的签名拒绝路径。在 iOS 27.1（24A94425）上，测试者反馈启动和 App 加载正常；运行时探针的主程序和 framework 原始代码 remap 执行测试共 28 项，全部通过，实际映射权限均为 RX。此前出现问题的 iOS 27.0.1 完整组合尚未复测。见替换方案评估。

#macOS 26.6.2 宿主机

于 2026-10-23 使用 Core Bundle 2.12.1 验证，2026-10-24 又使用 Core Bundle 2.12.2 再次验证，宿主机为 Mac mini M4（Mac16,10，16 GB，macOS 26.6.2 25G83）。每台虚拟机都从零开始通过 CLI 创建。研究主板组合以普通用户身份准备 kernelcache 组合，用 sudo 链接，然后运行 sudo vphone-cli vm create。“默认”表示 fw catalog 在这台 Mac 上为该设备给出的最新组合，也就是 Launchpad 的 New Machine 会选择的组合。之后每台虚拟机都以无界面方式启动两次：vphoned 有响应，device.info 报告了正确的版本，客户机的串口日志中没有 panic。

tvOS 27.0（24J361）和 HomePod 软件 27.2（24K120）的 OTA 使用 LZRAVEN 压缩负载，只有 macOS 27 能够解压。在较旧的 Mac 上，fw catalog 不会列出它们，因此 Launchpad 为这些设备提供的默认版本是 tvOS 26.6 和 HomePod 软件 27.0；如果指定其中任何一个，会在下载任何内容之前被拒绝。

Apple TV 4K（第 4 代），即 AppleTV18,1 / J265AP，目前仅供早期适配，使用 tvOS 27.2 beta（24K120）：它的完整 OTA 叠加在 Apple TV HD 26.6 恢复基础和 cloudOS 26.4 beta（23E5207q）之上。它需要 macOS 27 和 tvos-4k 预设。2026-10-24，一台虚拟机完成了恢复和自定义固件安装，并两次冷启动到 vphoned 和旧版 TVSetup 的 4K 语言屏幕；设置本身没有完成。它不在上面的测试表中。见适配记录。

cloudOS 26.7（23H20）没有可以搭配的 iPhone 版本。使用 iOS 26.6.2 的用户空间准备时，它的组合可以链接，28 个 kernelcache 补丁也都能应用，但 CFW 补丁 _vm_fault_enter_prepare 在该内核中找不到补丁位置。它尚未启动过。

#其他 iPhone 机型

iPhone17,3 以外的机型见其他 iPhone 机型。

#iOS 27 上的 iPhone18,1 和 iPhone18,2

这两款需要 kernel-boot-shared_region_size 补丁（issue #596，27.0 和 27.0.1）。自 2026-10-06 起，standard 预设在 iOS 27 基础系统上默认开启它。

它们在 27.0.1 上的 dyld 共享缓存记录的 sharedRegionSize 为 0x185804000，大于 cloudOS 26.4 客户机内核的 0x180000000 共享区域，因此即使 dyld-boot-maxslide 取消了滑动，缓存也无法映射。没有这个补丁时，launchd 会在首次启动时以 Library not loaded: /usr/lib/libSystem.B.dylib panic。iPhone17,3 的 27.0.1 缓存（0x17D508000）仍然放得下。

该补丁把 arm64 区域扩大到 0x1C0000000，这是不超过 26.4 内核自身任务映射上限的最大值。当虚拟机的内核带有该补丁时（其 PatchReceipt.plist 中会注明），cfw install 会按扩大后的区域衡量缓存，因此这些设备可以安装和启动；这已在上文的 iPhone18,2 27.0.1 上验证。

没有该补丁时（bundle 较旧，或取消勾选了该补丁），cfw install 会拒绝这样的缓存并给出上述说明，而不是留下一个会 panic 的客户机。iOS 27 请使用 iPhone17,3，这些设备请使用 iOS 26。

#iPadOS

iPad 客户机见 iPadOS 客户机。

#早期报告的组合

以前的 README 记录了以下宿主机与固件组合。它们早于当前的单一模式流程，或者缺少同等的 vphoned 验收证据，因此请把它们视为研究历史，而不是当前的支持矩阵。

全部补丁及各自的适用范围见补丁清单。

#另请参阅

• 固件准备
• 其他 iPhone 机型
• iPadOS 客户机
• 创建与运行虚拟机