本文记录的是一次真实适配过程。项目源码在 rnadow/aircard，独立项目页在 rnadow.github.io/aircard。当前实验包为 v1.3.3 (2643)，面向我的 iOS 26.4 测试环境；它不是对所有设备和系统版本的兼容承诺。

为什么 Windows 不能直接编译 IPA

iOS 应用最终仍要使用 Apple 的 SDK、Xcode 和签名工具链，Windows 本机无法直接完成这一步。我的做法是让 Windows 只负责提交源码和下载产物，把真正的编译交给 GitHub Actions 的 macOS Runner。

winget install --id GitHub.cli
gh auth login

Set-Location "C:\Projects\AirCard-iOS-26.4"
powershell -ExecutionPolicy Bypass -File .\build-from-windows.ps1 `
  -Repository "rnadow/aircard"

脚本会推送当前源码、触发工作流、等待构建、下载无签名 IPA，再用 SHA-256 文件核对下载结果。最终产物是 build/AirCard-iOS.ipa，仍需使用自己控制的 SideStore、AltStore、TrollStore、LiveContainer 或其他方式签名安装。

两个容易踩到的 Windows 问题：

  • gh 无法识别：GitHub CLI 刚安装后，重新打开 PowerShell，让 PATH 生效。
  • detected dubious ownership：只信任这个仓库的准确路径，不要把整个磁盘加入白名单。
git config --global --add safe.directory \
  "H:/CWD/Documents/ChatGPT/个人/AirCard-iOS-26.4"

.p12 不是 pairing file

SideStore 导出的 .p12 是签名证书，用于给 IPA 签名；它不包含 AirCard 与 iPhone 建立 Remote Pairing 所需的设备凭据。AirCard 需要的是 .plist、.mobiledevicepairing 或 .mobilepair。

iOS 26 上，开发者模式页面不一定出现“Pair This iPhone”的授权提示。因此 v1.3.2 增加了外部导入。我的可用路径是通过 iLoader 处理：

  1. 执行 Delete Stored Pairing；
  2. 重新连接手机，并在 iPhone 上点“信任”；
  3. 进入 Manage Pairing File，选择 Place；
  4. 将生成的配对文件导入 AirCard。

连接设备前还要保持 LocalDevVPN 或 SideStore WireGuard 这类回环 VPN 运行。若日志出现 failed to parse raw pairing file from bytes，先检查是否误选了 .p12，再检查回环隧道是否真的启动。SideStore 官方的 pairing file 文档也说明了配对文件的用途与生成流程。

先用 canary 验证，不直接碰 Wallet

仅把 Deployment Target 改成 iOS 26.4，不能证明 AirTraffic 路径可用。这个分支加入了兼容性探针：它在 /var/mobile/Library/Caches 下写入随机 canary，通过 AirTraffic 导出并校验完全相同的字节，最后清理临时对象。

探针不写入 Passbook，也不修改 Wallet。只有回环网络、配对、AFC、AirTraffic、遍历写入、回读和清理都成功，结果才会显示绿色。

这一步把“连接成功”和“确实具备可控写入/回读能力”区分开了。如果探针失败，应导出阶段日志定位问题；不要在未知状态下直接测试批量卡面。

10 张卡时，为什么扫描结果不等于目标卡

兼容性探针通过后，新的问题出现了：Wallet 中有 10 张卡，扫描能列出多个哈希，但不能确认哪一个对应当前想修改的卡。通用日志可能包含枚举、缓存刷新和历史卡片信息，因此“最后出现的哈希”并不是可靠依据。

v1.3.3 的处理方式是区分发现卡片与卡片获得前台焦点。正确操作顺序是：

  1. 在 AirCard 开始扫描；
  2. 打开 Wallet，点进真正想换卡面的那一张；
  3. 等待 AirCard 中唯一的条目出现绿色 CURRENT CARD 标记；
  4. 用“银行名 + 尾号四位”添加本地备注；
  5. 给它分配图片，只 Flash 当前选中的一张。

普通发现事件只会加入候选列表，不再自动覆盖当前选择。只有明确的焦点事件才会设置 CURRENT CARD。这样即使扫描出 10 个标识符，也不会因为后台日志刷新而把目标切到另一张卡。

安全边界

  • AirCard 修改的是设备上的本地视觉缓存，不会修改支付凭据、余额、银行端卡片资料或 Secure Element。
  • Pairing record 是当前设备的敏感认证材料，不能提交到 GitHub、博客附件或公开日志。
  • .p12、UDID、卡片哈希和包含设备标识的完整日志同样不应公开。
  • 第一次只测试一张卡和一张可随时替换的图片；确认识别准确前不要 Batch Flash。
  • 无签名 IPA 必须由使用者自己签名，仓库和下载产物不应包含私人证书。

这个版本最终解决了什么

从 Windows 构建、外部配对、回环 VPN、AirTraffic 安全探针，到多卡精准识别，这条链路现在已经形成了可重复的操作顺序：先取得正确 pairing file，再保持隧道运行；先探针验证，再打开目标卡；最后等待 CURRENT CARD，只写一张。

上游项目是 Mak5er/AirCard-iOS，底层研究来自 AirLift。本分支保留了相关致谢，并把这次 iOS 26.4 的实验适配、Windows 工作流与排错说明公开在仓库 README 中。