尧图网站建设 
vphone-cli 内核 JB 补丁 A1 深度解析AMFI CDHash trustcache 查询强制放行的静态逆向与 AArch64 补丁实现【免费下载链接】vphone-cli项目地址: https://gitcode.com/GitHub_Trending/vp/vphone-cli导读A1 是 vphone-cli 项目内核越狱JB补丁套件中的首个签名策略补丁JB-01其目标是在内核二进制层面把AMFIIsCDHashInTrustCache函数改写为无条件返回成功从而让不在 Apple trustcache 中的 CDHash典型如 ad-hoc 重签名、非 Apple 签名的二进制与 dylib通过 AMFI 的 vnode 签名校验链。本文以 research/kernel_patch_jb/patch_amfi_cdhash_in_trustcache.md 为核心骨架结合仓库中 Swift 补丁实现、运行时验证产物与补丁对比表完整还原该补丁的精确补丁点、静态调用链、结构匹配算法、IDA 命名工作、运行时验证结论与风险边界读者可据此理解对剥离符号的 iOS 内核做语义级二进制补丁的完整方法论。1. 补丁定位A1 在 JB 补丁体系中的角色在 vphone-cli 的 JB 内核补丁清单research/0_binary_patch_comparison.md 中的 JB-Only Kernel Methods 参考表中A1 对应JB-01归入Group AAMFI / 签名策略组目标函数为AMFIIsCDHashInTrustCache补丁语义为Always return true store hash始终返回真并写入 out 元数据在 JB 变体中默认启用。从调度顺序看sources/FirmwarePatcher/Kernel/KernelJBPatcher.swift 的findAll()A1 是 Group A 的第一个补丁先于patchTaskConversionEvalInternal()、patchSandboxHooksExtended()、patchIoucFailedMacf()执行。findAll()在解析 Mach-O、构建 ADRP 索引、BL 索引、符号表和findPanic()之后进入补丁流水线说明 A1 依赖的是纯指令形状匹配而非符号表——这一点正是后续结构匹配器设计的出发点。文档级背景补丁分析文档明确说明A1 的分析模式是静态二进制分析IDA-MCP 反汇编 恢复符号无运行时补丁执行针对的研究内核为vm/iPhone17,3_26.1_23B85_Restore/kernelcache.research.vphone600IDA 数据库为kernelcache.research.vphone600.macho。2. 精确补丁点与语义2.1 补丁点地址唯一语义匹配点0xfffffe0008637880→ 分析标签jb_a1_patched_amfi_is_cdhash_in_trustcache补丁位置函数入口处的 4 条指令 stub2.2 补丁前后对比补丁前原函数行为函数把请求转发给jb_a1_supp_txm_sel14_query_cdhash_trustcache0xfffffe0007FFCA08返回布尔成功v4 0并可选地通过 out 指针写入结果元数据。补丁后入口 stub4 条 AArch64 指令序号指令语义1mov x0, #1返回值强制为 1true2cbz x2, 8若 out 指针x2为空跳过写入3str x0, [x2]把 1 写入 out 元数据4ret返回伪代码对照/* Before */ int ok txm_query_cdhash(hash, type, out_meta); return ok 0; /* After */ if (out_meta) *out_meta 1; return 1;净效果对所有调用者而言trustcache 成员查询被强制判定为存在。AArch64 层面这是对函数前 1216 字节的重写不对函数尾部做任何处理属于标准的入口 stub 替换模式。3. 静态调用链全貌3.1 下游被绕过的路径jb_a1_patched_amfi_is_cdhash_in_trustcache (0x8637880) - jb_a1_supp_txm_sel14_query_cdhash_trustcache (0x7FFCA08) - sub_FFFFFE0007FFE5CCTXM selector 14 路径补丁生效后从 A1 调用者出发的 TXM trustcache 检查路径不再可达——也就是 selector 14 的 CDHash trustcache 查询逻辑被整体短路。3.2 上游进入 AMFI 策略的路径Kernel MAC 分发jb_a1_supp_mac_vnode_check_signature0x82DC0E0policy_ops0x980分发回调指针由jb_a1_supp_amfi_register_mac_policy0x8640718存储于0x8640ac8注册AMFI 回调jb_b5_supp_vnode_check_signature0x8641924trustcache 门位于0x8641de4调用jb_a1_supp_check_cdhash_any_trustcache_type0x863F9FC该 helper 以 classes 1/2/3 调用jb_a1_patched_amfi_is_cdhash_in_trustcache主镜像校验路径进入 MAC 门jb_a1_supp_mach_loader_process_signature (0x805620C对应 mach_loader.c) - jb_a1_supp_cs_blob_validate_image (0x8022130) - jb_a1_supp_mac_vnode_check_signature (0x82DC0E0)Exec 激活路径同样重入该检查器jb_b16_supp_exec_activate_image (0x7FAD47C) - jb_a1_supp_exec_handle_signature_enforcement (0x7FAC6FC) - 0x7FACFAC 处调用 jb_a1_supp_mach_loader_process_signature这一调用链说明 A1 处于签名验证的汇聚点无论是load_machfile的常规镜像加载还是 exec 激活阶段的签名强制最终都会落到同一个mac_vnode_check_signature→check_cdhash_any_trustcache_type→is_cdhash_in_trustcache的判定上。4. 为什么这个补丁对非 Apple 签名执行至关重要分析文档强调了一个容易被混淆的关键区别完全无签名没有任何 code signature blob的二进制在更早的阶段就会被jb_a1_supp_execve_cred_label_update0x863FC6C日志路径在0x863fcfc处杀死——A1 并不绕过这一层。实际越狱场景面对的是ad-hoc / 重签名的非 Apple 代码它有 CDHash但不在 Apple trustcache 中。对后者A1 是决定性的jb_b5_supp_vnode_check_signature的信任路径依赖jb_a1_supp_check_cdhash_any_trustcache_type。没有 A1 时非 trustcached 的 CDHash 会落入非信任分支最终走向 deny / untrusted 处理。有 A1 时信任路径被强制打开0x8641df8处设置csflags | 0x04000000可选0x2200位于0x8641e18从而启用内核内的 trust-cache 接受路径。也就是说A1 不是放开所有签名而是把 trustcache 成员判定这个单点改成恒真配合csflags的相应置位让携带合法 CDHash 但不在 Apple trustcache 里的代码走信任分支。5. 对 launchd dylib 工作流的意义同一个签名门在 exec 镜像激活及后续镜像签名处理中被复用0x7FACFAC→jb_a1_supp_mach_loader_process_signature→ MAC vnode 签名回调链。因此与 launchd 相关的注入 / 重签名 dylib只要不在 trustcache 中就会撞上同一个 CDHash trustcache 门。A1 把这个门强制打开使 launchd 关联的非 Apple dylib 镜像检查可以走信任分支而不是因 trustcache 成员检查失败而拒绝。文档基于静态流程 共享门复用给出的推断是这就是 A1 成为本 JB 链中可靠 launchd dylib 工作流前置条件的原因。注意这是推断性结论Inference而非运行时可观测事实引用时应保持这一措辞边界。仓库侧的佐证来自 watchdogd 用户态补丁的分析research/0_binary_patch_comparison.mdcfw_patch_watchdogd.py对 watchdogd 做字节级修改后会重新计算CS_CodeDirectory的 slot hash导致其 cdHash 变化但existing JB kernel patchpatch_amfi_cdhash_in_trustcacheaccepts any cdHash, so AMFIs trust-cache check still passes at execve——这正是 A1 在真实安装链路中被依赖的实例用户态二进制被改动后 cdHash 已非原始值A1 保证 execve 时的 trustcache 检查依然通过。6. 源码实现Swift 结构匹配器语义函数匹配补丁分析文档记载的 patcher 源为scripts/patchers/kernel_jb_patch_amfi_trustcache.pyPython 时代模块。在当前仓库中该补丁已随 Swift 迁移落地为 sources/FirmwarePatcher/Kernel/JBPatches/KernelJBPatchAmfiTrustcache.swift文件头历史注明确认derived from the legacy Python firmware patcher during the Swift migration核心逻辑在patchAmfiCdhashInTrustcache()。6.1 匹配策略不依赖偏移与字符串锚点匹配器在 AMFI kext 的__TEXT_EXEC.__text范围内扫描以PACIBSP0xd503233f为边界的函数寻找符合AMFIIsCDHashInTrustCache函数体形状的唯一函数。AMFI 文本范围由 sources/FirmwarePatcher/Kernel/KernelPatcherBase.swift 的amfiTextRange()提供——它从__PRELINK_INFO中按 bundle IDcom.apple.driver.AppleMobileFileIntegrity解析 kext 文本段解析失败时回退到整个内核代码范围。6.2 指令形状约束结构签名匹配器按顺序在函数体内寻找如下指令序列全部为语义常量无硬编码偏移步骤指令编码常量说明i1mov x19, x20xAA02_03F3保存 out 指针 x2i2stp xzr, xzr, [sp, #imm]mask0xFFC0_7FFF/ val0xA900_7FFF栈清零对忽略 immi3mov x2, sp0x9100_03E2把栈槽作为 out 参数i4bl anythingmask0xFC00_0000/ val0x9400_0000TXM 查询调用i5mov x20, x00xAA00_03F4保存查询结果i6cbnz w0, ...W 源寄存器为 0mask0x7F00_0000/ val0x3500_0000已信任快速路径i7cbz x19, ...X 源寄存器为 19mask0xFF00_0000/ val0xB400_0000空 out 指针保护只有恰好一个函数满足完整形状时才允许补丁guard hits.count 1存在歧义时拒绝应用——这正是文档中site resolution uses anchor opcode-shape control-flow context; ambiguous candidates are rejected的 Swift 落地。6.3 写入补丁 stub确认唯一命中后用 4 条指令重写函数入口emit(funcStart, ARM64.movX0_1, patchID: amfi_trustcache_1, ...) // mov x0,#1 emit(funcStart 4, ARM64.cbzx2_8, patchID: amfi_trustcache_2, ...) // cbz x2,8 emit(funcStart 8, ARM64.strX0X2, patchID: amfi_trustcache_3, ...) // str x0,[x2] emit(funcStart 12, ARM64.ret, patchID: amfi_trustcache_4, ...) // ret每次写入都携带patchID、虚拟地址和描述文本产出标准PatchRecord可被上层流水线与验证工具消费。7. IDA 命名工作两组分析文档记录了在 IDA 中完成的两组符号命名用于提高可读性与可追溯性7.1 已补丁函数组0xfffffe0008637880→jb_a1_patched_amfi_is_cdhash_in_trustcache函数入口处添加注释[PATCHED GROUP] A1 patchpoint: force trustcache success...7.2 辅助supplement组地址分析标签0xfffffe000863F9FCjb_a1_supp_check_cdhash_any_trustcache_type0xfffffe000863F984jb_a1_supp_check_cdhash_primary_or_fallback0xfffffe000863FC6Cjb_a1_supp_execve_cred_label_update0xfffffe00082DC0E0jb_a1_supp_mac_vnode_check_signature0xfffffe0008022130jb_a1_supp_cs_blob_validate_image0xfffffe000805620Cjb_a1_supp_mach_loader_process_signature0xfffffe0007FAC6FCjb_a1_supp_exec_handle_signature_enforcement0xfffffe0007FFCA08jb_a1_supp_txm_sel14_query_cdhash_trustcache0xfffffe0007FFCAACjb_a1_supp_txm_sel15_query_cdhash_restriction0xfffffe0008640718jb_a1_supp_amfi_register_mac_policy0xfffffe00086346D0jb_a1_supp_restricted_exec_mode_cdhash_gate关键跟踪点0x8641de4、0x8641df8、0x8641e0c、0x82dc374、0x8640ac8、0x863fef4、0x7facfac均添加了补充注释。8. 运行时与 IDA 验证8.1 2026-03-05 运行时验证针对 PCC-CloudOS 26.3kernelcache.research.vphone600Base VA0xFFFFFE0007004000的运行时验证记录于 research/kernel_patch_jb/runtime_verification/runtime_verification_summary.md状态hit4 次补丁写入method_returnTrue包含于KernelJBPatcher.find_all()TrueIDA 映射4/4 个点在已识别函数内0 个点为 code-cave / contenteditable="false">【免费下载链接】vphone-cli项目地址: https://gitcode.com/GitHub_Trending/vp/vphone-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 vphone-cli 内核 JB 补丁 A1 深度解析：AMFI CDHash trustcache 查询强制放行的静态逆向与 AArch64 补丁实现
vphone-cli 内核 JB 补丁 A1 深度解析AMFI CDHash trustcache 查询强制放行的静态逆向与 AArch64 补丁实现【免费下载链接】vphone-cli项目地址: https://gitcode.com/GitHub_Trending/vp/vphone-cli导读A1 是 vphone-cli 项目内核越狱JB补丁套件中的首个签名策略补丁JB-01其目标是在内核二进制层面把AMFIIsCDHashInTrustCache函数改写为无条件返回成功从而让不在 Apple trustcache 中的 CDHash典型如 ad-hoc 重签名、非 Apple 签名的二进制与 dylib通过 AMFI 的 vnode 签名校验链。本文以 research/kernel_patch_jb/patch_amfi_cdhash_in_trustcache.md 为核心骨架结合仓库中 Swift 补丁实现、运行时验证产物与补丁对比表完整还原该补丁的精确补丁点、静态调用链、结构匹配算法、IDA 命名工作、运行时验证结论与风险边界读者可据此理解对剥离符号的 iOS 内核做语义级二进制补丁的完整方法论。1. 补丁定位A1 在 JB 补丁体系中的角色在 vphone-cli 的 JB 内核补丁清单research/0_binary_patch_comparison.md 中的 JB-Only Kernel Methods 参考表中A1 对应JB-01归入Group AAMFI / 签名策略组目标函数为AMFIIsCDHashInTrustCache补丁语义为Always return true store hash始终返回真并写入 out 元数据在 JB 变体中默认启用。从调度顺序看sources/FirmwarePatcher/Kernel/KernelJBPatcher.swift 的findAll()A1 是 Group A 的第一个补丁先于patchTaskConversionEvalInternal()、patchSandboxHooksExtended()、patchIoucFailedMacf()执行。findAll()在解析 Mach-O、构建 ADRP 索引、BL 索引、符号表和findPanic()之后进入补丁流水线说明 A1 依赖的是纯指令形状匹配而非符号表——这一点正是后续结构匹配器设计的出发点。文档级背景补丁分析文档明确说明A1 的分析模式是静态二进制分析IDA-MCP 反汇编 恢复符号无运行时补丁执行针对的研究内核为vm/iPhone17,3_26.1_23B85_Restore/kernelcache.research.vphone600IDA 数据库为kernelcache.research.vphone600.macho。2. 精确补丁点与语义2.1 补丁点地址唯一语义匹配点0xfffffe0008637880→ 分析标签jb_a1_patched_amfi_is_cdhash_in_trustcache补丁位置函数入口处的 4 条指令 stub2.2 补丁前后对比补丁前原函数行为函数把请求转发给jb_a1_supp_txm_sel14_query_cdhash_trustcache0xfffffe0007FFCA08返回布尔成功v4 0并可选地通过 out 指针写入结果元数据。补丁后入口 stub4 条 AArch64 指令序号指令语义1mov x0, #1返回值强制为 1true2cbz x2, 8若 out 指针x2为空跳过写入3str x0, [x2]把 1 写入 out 元数据4ret返回伪代码对照/* Before */ int ok txm_query_cdhash(hash, type, out_meta); return ok 0; /* After */ if (out_meta) *out_meta 1; return 1;净效果对所有调用者而言trustcache 成员查询被强制判定为存在。AArch64 层面这是对函数前 1216 字节的重写不对函数尾部做任何处理属于标准的入口 stub 替换模式。3. 静态调用链全貌3.1 下游被绕过的路径jb_a1_patched_amfi_is_cdhash_in_trustcache (0x8637880) - jb_a1_supp_txm_sel14_query_cdhash_trustcache (0x7FFCA08) - sub_FFFFFE0007FFE5CCTXM selector 14 路径补丁生效后从 A1 调用者出发的 TXM trustcache 检查路径不再可达——也就是 selector 14 的 CDHash trustcache 查询逻辑被整体短路。3.2 上游进入 AMFI 策略的路径Kernel MAC 分发jb_a1_supp_mac_vnode_check_signature0x82DC0E0policy_ops0x980分发回调指针由jb_a1_supp_amfi_register_mac_policy0x8640718存储于0x8640ac8注册AMFI 回调jb_b5_supp_vnode_check_signature0x8641924trustcache 门位于0x8641de4调用jb_a1_supp_check_cdhash_any_trustcache_type0x863F9FC该 helper 以 classes 1/2/3 调用jb_a1_patched_amfi_is_cdhash_in_trustcache主镜像校验路径进入 MAC 门jb_a1_supp_mach_loader_process_signature (0x805620C对应 mach_loader.c) - jb_a1_supp_cs_blob_validate_image (0x8022130) - jb_a1_supp_mac_vnode_check_signature (0x82DC0E0)Exec 激活路径同样重入该检查器jb_b16_supp_exec_activate_image (0x7FAD47C) - jb_a1_supp_exec_handle_signature_enforcement (0x7FAC6FC) - 0x7FACFAC 处调用 jb_a1_supp_mach_loader_process_signature这一调用链说明 A1 处于签名验证的汇聚点无论是load_machfile的常规镜像加载还是 exec 激活阶段的签名强制最终都会落到同一个mac_vnode_check_signature→check_cdhash_any_trustcache_type→is_cdhash_in_trustcache的判定上。4. 为什么这个补丁对非 Apple 签名执行至关重要分析文档强调了一个容易被混淆的关键区别完全无签名没有任何 code signature blob的二进制在更早的阶段就会被jb_a1_supp_execve_cred_label_update0x863FC6C日志路径在0x863fcfc处杀死——A1 并不绕过这一层。实际越狱场景面对的是ad-hoc / 重签名的非 Apple 代码它有 CDHash但不在 Apple trustcache 中。对后者A1 是决定性的jb_b5_supp_vnode_check_signature的信任路径依赖jb_a1_supp_check_cdhash_any_trustcache_type。没有 A1 时非 trustcached 的 CDHash 会落入非信任分支最终走向 deny / untrusted 处理。有 A1 时信任路径被强制打开0x8641df8处设置csflags | 0x04000000可选0x2200位于0x8641e18从而启用内核内的 trust-cache 接受路径。也就是说A1 不是放开所有签名而是把 trustcache 成员判定这个单点改成恒真配合csflags的相应置位让携带合法 CDHash 但不在 Apple trustcache 里的代码走信任分支。5. 对 launchd dylib 工作流的意义同一个签名门在 exec 镜像激活及后续镜像签名处理中被复用0x7FACFAC→jb_a1_supp_mach_loader_process_signature→ MAC vnode 签名回调链。因此与 launchd 相关的注入 / 重签名 dylib只要不在 trustcache 中就会撞上同一个 CDHash trustcache 门。A1 把这个门强制打开使 launchd 关联的非 Apple dylib 镜像检查可以走信任分支而不是因 trustcache 成员检查失败而拒绝。文档基于静态流程 共享门复用给出的推断是这就是 A1 成为本 JB 链中可靠 launchd dylib 工作流前置条件的原因。注意这是推断性结论Inference而非运行时可观测事实引用时应保持这一措辞边界。仓库侧的佐证来自 watchdogd 用户态补丁的分析research/0_binary_patch_comparison.mdcfw_patch_watchdogd.py对 watchdogd 做字节级修改后会重新计算CS_CodeDirectory的 slot hash导致其 cdHash 变化但existing JB kernel patchpatch_amfi_cdhash_in_trustcacheaccepts any cdHash, so AMFIs trust-cache check still passes at execve——这正是 A1 在真实安装链路中被依赖的实例用户态二进制被改动后 cdHash 已非原始值A1 保证 execve 时的 trustcache 检查依然通过。6. 源码实现Swift 结构匹配器语义函数匹配补丁分析文档记载的 patcher 源为scripts/patchers/kernel_jb_patch_amfi_trustcache.pyPython 时代模块。在当前仓库中该补丁已随 Swift 迁移落地为 sources/FirmwarePatcher/Kernel/JBPatches/KernelJBPatchAmfiTrustcache.swift文件头历史注明确认derived from the legacy Python firmware patcher during the Swift migration核心逻辑在patchAmfiCdhashInTrustcache()。6.1 匹配策略不依赖偏移与字符串锚点匹配器在 AMFI kext 的__TEXT_EXEC.__text范围内扫描以PACIBSP0xd503233f为边界的函数寻找符合AMFIIsCDHashInTrustCache函数体形状的唯一函数。AMFI 文本范围由 sources/FirmwarePatcher/Kernel/KernelPatcherBase.swift 的amfiTextRange()提供——它从__PRELINK_INFO中按 bundle IDcom.apple.driver.AppleMobileFileIntegrity解析 kext 文本段解析失败时回退到整个内核代码范围。6.2 指令形状约束结构签名匹配器按顺序在函数体内寻找如下指令序列全部为语义常量无硬编码偏移步骤指令编码常量说明i1mov x19, x20xAA02_03F3保存 out 指针 x2i2stp xzr, xzr, [sp, #imm]mask0xFFC0_7FFF/ val0xA900_7FFF栈清零对忽略 immi3mov x2, sp0x9100_03E2把栈槽作为 out 参数i4bl anythingmask0xFC00_0000/ val0x9400_0000TXM 查询调用i5mov x20, x00xAA00_03F4保存查询结果i6cbnz w0, ...W 源寄存器为 0mask0x7F00_0000/ val0x3500_0000已信任快速路径i7cbz x19, ...X 源寄存器为 19mask0xFF00_0000/ val0xB400_0000空 out 指针保护只有恰好一个函数满足完整形状时才允许补丁guard hits.count 1存在歧义时拒绝应用——这正是文档中site resolution uses anchor opcode-shape control-flow context; ambiguous candidates are rejected的 Swift 落地。6.3 写入补丁 stub确认唯一命中后用 4 条指令重写函数入口emit(funcStart, ARM64.movX0_1, patchID: amfi_trustcache_1, ...) // mov x0,#1 emit(funcStart 4, ARM64.cbzx2_8, patchID: amfi_trustcache_2, ...) // cbz x2,8 emit(funcStart 8, ARM64.strX0X2, patchID: amfi_trustcache_3, ...) // str x0,[x2] emit(funcStart 12, ARM64.ret, patchID: amfi_trustcache_4, ...) // ret每次写入都携带patchID、虚拟地址和描述文本产出标准PatchRecord可被上层流水线与验证工具消费。7. IDA 命名工作两组分析文档记录了在 IDA 中完成的两组符号命名用于提高可读性与可追溯性7.1 已补丁函数组0xfffffe0008637880→jb_a1_patched_amfi_is_cdhash_in_trustcache函数入口处添加注释[PATCHED GROUP] A1 patchpoint: force trustcache success...7.2 辅助supplement组地址分析标签0xfffffe000863F9FCjb_a1_supp_check_cdhash_any_trustcache_type0xfffffe000863F984jb_a1_supp_check_cdhash_primary_or_fallback0xfffffe000863FC6Cjb_a1_supp_execve_cred_label_update0xfffffe00082DC0E0jb_a1_supp_mac_vnode_check_signature0xfffffe0008022130jb_a1_supp_cs_blob_validate_image0xfffffe000805620Cjb_a1_supp_mach_loader_process_signature0xfffffe0007FAC6FCjb_a1_supp_exec_handle_signature_enforcement0xfffffe0007FFCA08jb_a1_supp_txm_sel14_query_cdhash_trustcache0xfffffe0007FFCAACjb_a1_supp_txm_sel15_query_cdhash_restriction0xfffffe0008640718jb_a1_supp_amfi_register_mac_policy0xfffffe00086346D0jb_a1_supp_restricted_exec_mode_cdhash_gate关键跟踪点0x8641de4、0x8641df8、0x8641e0c、0x82dc374、0x8640ac8、0x863fef4、0x7facfac均添加了补充注释。8. 运行时与 IDA 验证8.1 2026-03-05 运行时验证针对 PCC-CloudOS 26.3kernelcache.research.vphone600Base VA0xFFFFFE0007004000的运行时验证记录于 research/kernel_patch_jb/runtime_verification/runtime_verification_summary.md状态hit4 次补丁写入method_returnTrue包含于KernelJBPatcher.find_all()TrueIDA 映射4/4 个点在已识别函数内0 个点为 code-cave / contenteditable="false">【免费下载链接】vphone-cli项目地址: https://gitcode.com/GitHub_Trending/vp/vphone-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考