lijianfei.com

在 iOS 侧载与逆向工程领域，“脱离电脑完成应用自签名与安装”一直是许多开发者和极客探索的终极方向。无论是早期的 AltStore 还是基于本地 Wi-Fi 环回的 SideStore，多年来始终受制于两大工程枷锁：一是在无 JIT、无越狱的沙箱内无法本地运行 Apple 专有的 ADI / Anisette 核心算法，不得不将 Apple ID 凭证委托给第三方的云端公共服务器；二是在 iOS 17.4 以后苹果全面弃用老旧 Lockdown 协议，导致依赖本地通道的自动化安装方案大面积失效。

近日，iOS 越狱社区资深开发者 CokePokes（Phantom、AppStore++ 核心作者）正式开源了 LetraInstaller。它在 iOS 受限沙箱内嵌入了纯解释执行的 Unicorn TCI 虚拟机，直接模拟 x86_64 指令集运行 Apple 原始 CoreADI 库，同时结合本地 LocalDevVPN 虚拟网卡与 iOS 17.4+ 的 RPPairing 加密隧道，实现了“零电脑连接、零凭证出机”的纯端侧真机自签名与安装闭环。我在第一时间对其开源架构与 IPA 二进制产物进行了逆向解构，梳理出了这套优雅而硬核的端侧工程范式。

1. 端侧闭环：从资产接入到回环安装的架构全景

在过去，很多所谓的“手机端签名器”本质上只是把 IPA 上传到远端 VPS 编译重签再下发，这种方案不仅传输延迟大，而且存在严重的账号凭据泄露风险。

LetraInstaller 的底层实现则完全立足于 iPhone 本地算力。通过对其主可执行文件 letrainstaller 及关联组件的反编译审计，我整理出了该项目的五大核心子系统协作拓扑：

flowchart TD
    subgraph InputStage ["第一阶段：资产接入与元数据解析"]
        A1["本地 Files 文件挑选器<br/>(.ipa / .tipa)"] --> B["IPA 解包与 Mach-O 静态解析<br/>LEIPAInspector"]
        A2["Telegram 官方 TDLib 客户端<br/>libtdjson.dylib"] -->|粘贴 App Store 链接秒发包| B
    end

    subgraph PatchStage ["第二阶段：动态补丁与权限重构"]
        B --> C["ChOma 补丁引擎 (letra-patcher)<br/>插入 LC_LOAD_DYLIB"]
        C --> D1["导入 .dylib / .deb 插件<br/>提取 LETweakResources 资源包"]
        C --> D2["重写 Entitlements 权限字典<br/>修改 BundleID / 版本号"]
    end

    subgraph AnisetteStage ["第三阶段：纯端侧 Anisette 密码学认证"]
        E1["iOS ARM64 沙箱环境<br/>(严禁 JIT / 拦截 PROT_EXEC)"] --> E2["Unicorn TCI 虚拟机 (Tiny Code Interpreter)<br/>uc_open(UC_ARCH_X86, UC_MODE_64)"]
        E2 --> E3["C-Runtime 内存映射与桩函数<br/>CoreADIWin.dll / LEMacUnicornFixture"]
        E3 --> E4["计算 X-Apple-I-MD-M 与 OTP 摘要<br/>LEOnDeviceAnisetteProvider"]
    end

    subgraph SignStage ["第四阶段：证书签发与二进制签名"]
        E4 --> F1["Apple Developer Portal 客户端<br/>LEDeveloperPortalClient"]
        F1 --> F2["申请开发证书 / 注册 UDID / 拉取 Profile"]
        F2 --> G1["LELDIDSignApplication (原生证书签名)"]
        D2 --> G2["LELDIDTrollStoreRuntime (Ad Hoc 伪签名)"]
    end

    subgraph InstallStage ["第五阶段：闭环安装与生命周期维护"]
        G1 --> H1["LocalDevVPN 环回隧道 (127.0.0.1)<br/>minimuxer + rusty_libimobiledevice"]
        H1 -->|iOS < 17.4| I1["Lockdown 配对文件握手"]
        H1 -->|iOS 17.4+| I2["RPPairing (Remote Pairing) 隧道握手"]
        I1 & I2 --> J1["直连系统 installation_proxy 完成部署"]
        G2 --> J2["一键 URL Scheme 传递给 TrollStore"]
        J1 --> K["Keychain 凭证安全持久化<br/>7 天临期一键 Resign & Reinstall"]
    end

    style AnisetteStage fill:#0f172a,stroke:#38bdf8,stroke-width:2px
    style InstallStage fill:#0f172a,stroke:#22c55e,stroke-width:2px

2. 突破 W^X 封锁：在 iOS 沙箱内用 Unicorn TCI 运行 CoreADI

在整个项目中，最具技术含量的突破当属端侧 Anisette 算法的本地仿真。

2.1 传统侧载方案的“私钥上云”困局

当移动客户端与 Apple Developer Portal 或 GrandSlam 认证服务器通信时，苹果强制要求 HTTP 请求头中必须携带 X-Apple-I-MD、X-Apple-I-MD-M、X-Apple-I-MD-R 和 X-Apple-I-MD-LU 等一系列机器签名标头。这些数据是由苹果闭源动态库（如 macOS 的 CoreADI.framework 或 Windows 下 iTunes 内置的 CoreADI.dll）结合设备底层特征经过混淆变换计算得出的一次性密码（OTP）。

在未越狱的 iOS 设备上，第三方 App 既无法直接调用系统的内部私有框架，也无法直接执行未经签名的二进制代码。因此，SideStore 等开源项目长期以来只能退而求求其次：

1. 要求用户自行搭建或连接社区共享的远程 Anisette 服务器（通常是一个运行了精简 macOS 镜像或 Windows 容器的 Docker）；
2. 客户端把 Apple ID 与明文密码推给云端服务器，由服务器计算好标头再返回给手机。

这种机制不仅让用户的 Apple 账户处于巨大的安全暴露风险中，还极易触发苹果官方的“异地风控异动”，导致开发者账号频繁锁死。

2.2 巧妙绕过 JIT 禁令的 TCI 虚拟机

在 iOS 系统的内存安全保护机制下，未经特别提权（例如缺少 get-task-allow 或 dynamic-codesigning 权限）的普通 App 严格遵循 W^X（Write XOR Execute） 原则：一块内存页要么可写，要么可执行，严禁调用 mprotect(..., PROT_WRITE | PROT_EXEC)。这就导致绝大多数依赖 JIT（即时编译）的代码转换器或虚拟机（如通用版 QEMU、Dynarmic）一启动就会被内核直接发送 SIGKILL 处决。

CokePokes 在 LetraInstaller 中采用了一个非常精巧的逆向思路：集成 Unicorn Engine，并强制切换为 TCI（Tiny Code Interpreter）解释器模式。

TCI 是 QEMU/Unicorn 内部的一套无 JIT 虚拟机实现。它不会把客体机（Guest）的指令直接动态翻译成宿主机（Host）的 ARM64 机器码，而是把客体机器码解析为一组中间伪操作码（Opcodes），并在只读代码段中由一个巨大的解释执行主循环逐条分发！

通过逆向分析 letrainstaller 主二进制，我提取到了其初始化 Unicorn TCI 的核心调用链：

// 逆向反编译还原：LEMacUnicornBackend 初始化逻辑
- (BOOL)setupUnicornGuestEnvironment {
    uc_engine *uc = NULL;
    // 强制开启 x86_64 仿真架构
    uc_err err = uc_open(UC_ARCH_X86, UC_MODE_64, &uc);
    if (err != UC_ERR_OK) {
        NSLog(@"[Unicorn] Failed on uc_open: %u", err);
        return NO;
    }

    // 分配 16MB 连续内存作为 TCI 字节码缓冲（纯数据内存，规避 PROT_EXEC）
    uint32_t tci_buffer_size = 16 * 1024 * 1024;
    uc_ctl_set_tcg_buffer_size(uc, tci_buffer_size);

    // 映射客体机物理内存空间 (0x00000000 ~ 0x200000000)
    uc_mem_map(uc, 0x100000000, 0x10000000, UC_PROT_READ | UC_PROT_WRITE);

    // 设置客体机栈指针与 TLS 线程局部存储基址
    uint64_t guest_stack = 0x108000000;
    uc_reg_write(uc, UC_X86_REG_RSP, &guest_stack);
    
    return YES;
}

2.3 内存映射与 C-Runtime Shim 桥接

光有虚拟机还不够，苹果的 CoreADI 是针对 x86_64 平台编译的动态库（LetraInstaller 内部打包了 CoreADIWin.dll 以及用于 macOS 模拟的 LEMacUnicornFixture.macho）。动态库内部引用了大量的宿主系统 API（如内存分配、时间戳获取、随机数派生以及文件 I/O）。

在 letrainstaller 中，开发者编写了一套精密的 C 运行时打桩与转发中继层（Import Relay Page）：

1. 导出函数重定向：将动态库导入表中的 malloc、free、memcpy、GetSystemTimeAsFileTime 等系统符号劫持到一段硬编码的跳转指令；
2. Hook 异常与上下文切换：当 Unicorn 遇到特定的未处理指令或非法内存访问时，触发 uc_hook_add(..., UC_HOOK_MEM_INVALID)，由宿主 App 在真实的 iOS 环境中读取真实硬件特征或执行物理时间计算，再将结果写回虚拟机的寄存器中；
3. 调用核心认证入口：
   • 调用 ADILoadLibraryWithPath 载入本地缓存；
   • 调用 ADISetProvisioningPath 设定沙箱存储路径；
   • 调用 ADISetAndroidID 等硬件标识填充接口；
   • 最终执行 ADIGetLocalOTP，在 iPhone 端侧原生生成 X-Apple-I-MD-M 与时间戳标头。

这套体系在保证 100% 密码学等价的前提下，彻底斩断了与远端第三方案服务器的连接。

3. 安装通道革新：LocalDevVPN 环回与 iOS 17.4+ RPPairing 穿透

解决了“怎么在手机上合法签名”后，紧接着面临的第二个巨型难题是：“怎么把签名好的 IPA 装进系统桌面”？

3.1 本地开发者服务与 LocalDevVPN 环回

通常情况下，iOS 只允许通过两种官方途径安装应用：App Store 购买下发，或者连接 Mac/PC 上的 Xcode / Apple Configurator 走开发者调试协议。

在真机上，底层守护进程 installation_proxy 实际上一直在监听本地的 usbmuxd 端口。第三方工具如果想在手机上与它通信，受限于 iOS 的沙箱隔离，无法直接向 localhost 发起原始套接字握手。

LetraInstaller 继承并升华了 SideStore 探索出的 WireGuard 虚拟网络回环方案：

• 在系统内配置一个名为 LocalDevVPN 的本地网络扩展；
• 将网络流量定向至 127.0.0.1 环回接口；
• App 内部直接编译集成了 Rust 语言编写的 minimuxer 与 rusty_libimobiledevice 协议栈。

3.2 攻克 iOS 17.4+ RPPairing 协议断崖

许多折腾过侧载的用户都会发现：很多老工具在 iOS 17.4 之后彻底失灵。原因在于苹果对开发者通信协议进行了一次激进的“地基重构”：

• iOS < 17.4：使用经典的 Lockdown 握手协议，只需电脑生成一份 UUID.mobiledevicepairing 配对记录即可永久信任；
• iOS 17.4 及更高版本：苹果彻底弃用了老旧的 Lockdown 开发者通道，改用更加严苛的 Remote Pairing（RPPairing） 架构。配对会话不仅强制要求 TLS-PSK 双向协商，还引入了专门的 CoreDevice 与 DVT（Developer Tooling）通道认证。

在 LetraInstaller 最新的 0.4.7 版本二进制中，我发现了大量针对 RPPairing 隧道的全新 Rust 实现符号：

idevice-0.1.68/src/remote_pairing/tunnel.rs
RPPairing authentication failed: RPPairing listener creation failed
RPPairing tunnel connection failed: RPPairing TLS/CDTunnel handshake failed
rusty_libimobiledevice::services::mobile_image_mounter

其具体适配工作流非常清晰：

1. 一次性配对导出：用户初次使用时，在电脑上运行开源的 idevice_pair 或 iloader，设备点击信任后导出生成的 RPPairing 文件；
2. 凭据导入 Letra：通过 AirDrop 或系统分享将配对文件存入 Letra 设置，App 自动提取出设备 UDID 与长效通信公钥；
3. 建立加密隧道：当用户点击安装时，Letra 本地启动 Rust minimuxer 服务，利用 RPPairing 凭证与本机的 CoreDevice 守护进程建立受信任的 TLS-PSK 会话；
4. 流式推送安装包：通过 installation_proxy 的流式接口将已签名的 IPA 包写入系统，全程完全无需连接电脑。

4. 二进制级补丁与双通道签名引擎

除了签名与安装，LetraInstaller 还内建了一套工业级的二进制插桩与包重构管线。

4.1 基于 ChOma 的 Mach-O 动态重写

在应用内注入插件（如脱壳版 Telegram 汉化包、微信多开防撤回、去除广告插件等）时，传统的 PC 端做法往往是调用 insert_dylib 或 optool。

LetraInstaller 在其 App 内部打包了一个独立的 Helper 可执行程序 letra-patcher，其底层基于 opa334 开源的高性能 Mach-O 解析库 ChOma 构建。

usage: letra-patcher -i input -o output [-r old-dylib] [-d new-dylib]
ChOma stage=1 copying input Mach-O
ChOma stage=2 opening writable Mach-O
ChOma stage=3 inspecting load commands
ChOma stage=4 inserting LC_LOAD_DYLIB command

在执行注入时，letra-patcher 直接在手机内存中遍历目标可执行文件的 Mach-O Header，在 Load Commands 区域安全扩展并写入 @executable_path/Frameworks/xxx.dylib 路径，同时自动完成代码签名边界重新对齐。

4.2 越狱 .deb 格式自动解包与 Bundle 挂载

很多逆向开发者分享的插件往往是 Cydia/Sileo 时代的 .deb Debian 包格式，里面通常混杂着动态库本体以及专属的界面图像、国际化 .bundle 资源文件夹。

LetraInstaller 内部实现了 LEDebPackageImporter：

• 原生在端侧解析 .deb 内的 data.tar.gz / data.tar.xz；
• 自动提取目标动态库并放置于 App 的 Frameworks/ 目录下；
• 将相关的资源包自动解压至 Frameworks/LETweakResources/，确保插件在未越狱的沙箱环境下也能正确加载贴图与多语言文案；
• 甚至还内置了 CydiaSubstrate.framework、libsubstitute 以及 SideloadSpoofer 运行时，为依赖 Hook 框架的插件提供基础垫片。

4.3 双通道签名分流对比

针对不同用户的设备环境，LetraInstaller 在配置面板顶部提供了极为干脆的双通道分流：

5. 全生命周期自愈与安全性边界审计

很多个人侧载工具最让人抓狂的体验，就是每隔 7 天就会准时遇到“应用闪退打不开”的尴尬。

5.1 Keychain 凭据托管与静默续签

LetraInstaller 在解决“7 天重签之痛”上迈出了极为实用的一步。

• 硬件级安全存储：在账户设置中开启 Stay signed in 后，用户的 Apple ID 密码会直接加密存入 iOS 硬件隔离的 Keychain（钥匙串） 中。只要设备不被物理破解，数据就不会外泄；
• 本地应用仓库追踪：内置的 LEInstalledAppStore 模块会实时记录通过 Letra 安装的每一个 App 的安装时间戳与 Bundle Identifier；
• 一键 Resign & Reinstall：在证书即将过期的前夕，用户只需打开 Letra 的 Apps 页面点击重签，程序便会在后台默默调用端侧 Unicorn TCI 计算新鲜的 Anisette 凭据，向苹果开发者后台申请续签 Provisioning Profile，并再次通过 LocalDevVPN 完成静默覆盖安装。整个过程完全保留应用内部的聊天记录、游戏存档或本地配置。

5.2 安全与风控边界反思

尽管 LetraInstaller 在架构设计上极具创新性，但在实际使用中，我依然需要客观指出其技术边界：

[!WARNING]
关于苹果风控机制的客观提醒

1. 证书数量硬顶：Apple 对免费的 Personal Team 账户施加了严格的服务器端配额，每个免费账户单设备最多只能激活 3 个正在运行的签名应用；
2. 硬件摘要指纹偏置：由于 Unicorn TCI 内部模拟的底层硬件特征（如合成的 Android ID 或虚拟 Mac 序列号）与真实的物理 iPhone 存在差异，虽然目前苹果并未对此痛下杀手，但在高频并发申请证书时，仍建议使用专用的备用 Apple ID，避免主账号被风控机制触发短期验证码阻断。

6. 第一视角实操指南与踩坑避雷录

在实际体验 LetraInstaller 的配置与部署时，我梳理了以下几条核心操作路径与避坑关键点：

6.1 配对文件的关键一次性准备

[!NOTE] 什么是配对文件？
配对文件是 iOS 设备与电脑建立信任关系时生成的加密握手凭证。为了让手机内部的 LocalDevVPN 拥有向 installation_proxy 下发安装指令的权限，通常需要借用一次电脑导出这份凭据。

• iOS < 17.4 设备：
  直接在电脑上使用 iloader 连接设备，点击“Trust”后选择 Manage Pairing File 导出 .mobiledevicepairing 文件，然后通过 AirDrop 发送到手机并在 Letra 设置中导入；
• iOS 17.4 及以上设备：
  必须使用支持新协议的 idevice_pair 命令行工具，在终端执行配对命令导出 RPPairing 格式凭据，并在 Letra 设置中手动填入从电脑端读取到的 40 位 UDID 字符串。

6.2 常见实操故障速查表

7. 结语

在移动安全与终端工程的演进历程中，技术突破往往诞生于对“既定限制”的巧妙突围。

CokePokes 开源的 LetraInstaller 是一次充满想象力的工程范式跃迁：它没有选择在云端架设计算集群去抗衡苹果的风控，而是反其道而行之，硬生生地在受限的 iOS 沙箱里塞入了一个精巧的 Unicorn TCI 虚拟机，在手机本地跑通了 x86_64 CoreADI 密码学闭环；同时，它精准咬合了从 Lockdown 到 RPPairing 的底层协议变迁，将一整套原本属于桌面级 Xcode 的签名与安装链路完全浓缩到了 iPhone 掌心之中。

对于每一位关注 iOS 底层系统机制、Mach-O 逆向与现代密码学仿真的工程师而言，LetraInstaller 都是一份不可多得的高分实战范本。

原文链接与参考资料

• GitHub 源码与发布仓库：CokePokes/LetraInstaller - Modify and install ipa files on the fly
• LetraInstaller 官方构建发行包：LetraInstaller Releases (v0.4.7-1)
• TrollStore 免签运行时与安装器：opa334/TrollStore
• Mach-O 解析与操作引擎：opa334/ChOma
• iOS 配对与调试通信工具链：jkcoxson/idevice_pair 与 SideStore/minimuxer
• Telegram 官方多平台客户端核心：tdlib/td
• Unicorn 跨平台 CPU 仿真框架：unicorn-engine/unicorn