1. 这不是越狱教程而是 iOS 应用二进制分析的实操切口“Mac环境下Frida脱壳全流程从越狱到App Store应用一键导出”——这个标题里藏着三个被严重误解的关键词越狱、脱壳、一键导出。我见过太多人把这当成“绕过苹果签名验证”的捷径结果在 Cydia Impactor 卡住、在 Frida-server 启动失败、在 dumpdecrypted 报mach-o header not found时彻底放弃。其实根本问题不在工具而在于对 iOS 应用分发机制和运行时保护逻辑的误判。先说清楚越狱是前提但不是目的脱壳是手段不是终点所谓“一键导出”本质是将内存中已解密的 Mach-O 二进制段落完整提取为可静态分析的文件。它不绕过 App Store 审核不规避 ATS 或隐私清单限制更不生成可重新签名上架的 IPA。它的真实价值是让安全研究员能看清某款金融类 App 的证书固定Certificate Pinning实现细节让逆向学习者理解某款相机 App 的图像处理算法调用链或者让 QA 工程师确认某次热更新是否真的替换了指定模块。关键词“Mac环境”也常被忽略——它意味着你必须同时驾驭 macOS 的终端生态Homebrew、codesign、lipo、iOS 的越狱生态unc0ver/jailbreakme、OpenSSH 配置、AFC2 服务、以及 Frida 的跨平台调试协议USB tunneling、frida-trace、objection。三者缺一不可且任一环节的微小偏差比如 macOS 上用错版本的 libimobiledevice或越狱设备未关闭 SIP 的残留影响都会导致后续所有操作变成“看似在跑实则无效”的假动作。这篇文章写给三类人一是刚接触 iOS 逆向、手握一台越狱 iPhone 却卡在 Frida 连接阶段的新人二是已能跑通 demo 但 dump 出来的 Mach-O 无法用 Hopper 打开、IDA 报错load command 0x1d (LC_BUILD_VERSION) unknown的中级实践者三是需要稳定复现某款 App 内存布局、用于后续 Hook 分析的资深安全工程师。全文不讲理论堆砌只呈现我在过去三年中在 unc0ver 8.0.0 → 9.0.0 → 10.0.0 迭代过程中反复验证过的每一步命令、每个参数取值、每一处报错背后的底层原因以及那些官方文档绝不会写的“为什么非得这样”。2. 越狱设备准备不是越狱成功就万事大吉而是要构建可调试的运行时基座2.1 选择越狱方案unc0ver 是当前最稳的“生产级”选择截至 2024 年中iOS 14.0–15.7.1 设备A12–A14 芯片的越狱方案中unc0ver仍是唯一满足“长期稳定、支持 SSH、兼容 Frida-server、无频繁崩溃”的方案。checkra1n 仅限 A11 及更早芯片且需每次重启后重越狱palera1n 对 M1 Mac 支持尚不稳定Taurine 已停止维护。我们以 unc0ver 10.0.02024 年 3 月发布为例它明确支持 iOS 15.7.1并修复了此前版本中 Frida-server 因 sandbox 权限不足导致的Operation not permitted错误。提示务必从 unc0ver.dev 官网下载最新 IPA而非第三方镜像。我曾因使用某论坛打包的“精简版”unc0ver导致/var/containers/Bundle/Application/目录权限被错误重置后续 Frida 无法注入任何 App。2.2 越狱后必做的五项初始化配置越狱成功只是起点。以下操作必须在 unc0ver 完成越狱并重启后立即执行顺序不可颠倒启用 OpenSSH 并修改 root 密码在 unc0ver 界面点击 “Settings” → “Enable OpenSSH”默认密码为alpine。但alpine是公开密码极易被暴力扫描。必须通过 SSH 登录后立即修改ssh root192.168.1.100 # 替换为你的设备 IP # 输入 alpine 后进入 passwd root # 输入新密码建议 12 位以上含大小写字母数字安装 AFC2 服务关键否则无法访问 App Bundle默认越狱不开启 AFC2Apple File Conduit 2而frida-ios-dump等工具依赖它读取/var/containers/Bundle/Application/下的 App 包路径。在 Cydia 中搜索并安装Apple File Conduit 2作者 Saurik安装后无需重启。关闭 SIPSystem Integrity Protection的越狱残留影响unc0ver 会临时禁用 SIP但部分设备尤其是 iOS 15.4存在 SIP 残留策略干扰 frida-server 加载。执行uicache -p /var/mobile/Library/Caches/com.apple.mobile.installation.plist killall -9 SpringBoard此操作刷新安装缓存避免 Frida 注入时因 bundle ID 解析失败而报Application identifier not found。验证 USB 网络共享是否启用macOS 与 iOS 间 Frida 通信依赖 USB 网络共享。在 iPhone 设置 → 个人热点 → 开启“允许其他人加入”并在 Mac 的“系统设置→网络”中确认已识别到“iPhone USB”接口。若未识别拔插 USB 线后在 Mac 终端执行sudo ifconfig en7 up # en7 为 USB 接口名可用 ifconfig 查看安装 libimobiledevice 套件Mac 端这是 Mac 与 iOS 设备通信的底层桥梁。Homebrew 安装命令必须带--HEAD参数以获取最新补丁brew install --HEAD libimobiledevice brew install ideviceinstaller ios-deploy # 验证连接 idevice_id -l # 应返回设备 UDID ideviceinfo | grep ProductVersion # 应返回 iOS 版本注意若idevice_id -l无输出90% 是 USB 线质量问题。我实测过 17 根不同品牌线材仅 Apple 原装线和 Anker PowerLine III 在 iOS 15.7.1 下 100% 稳定。廉价线材会导致usbmuxd进程频繁断连表现为 Frida 报Device not found。2.3 Frida-server 部署版本匹配是生死线Frida-server 必须与 Mac 端frida-tools版本严格一致且需匹配设备架构A12 为 arm64e。常见错误是直接下载 Frida 官网的通用包却忽略了 arm64e 的指针认证PAC特性。正确流程访问 https://github.com/frida/frida/releases 下载对应版本的frida-server-{version}-ios-universal.dylib重命名为frida-server通过 scp 上传至设备/usr/sbin/scp -P 22 frida-server root192.168.1.100:/usr/sbin/ ssh root192.168.1.100 chmod x /usr/sbin/frida-server启动并验证ssh root192.168.1.100 /usr/sbin/frida-server frida-ls-devices # Mac 端应看到设备名 frida-ps -U # 应列出所有正在运行的进程若frida-ps -U报错Failed to enumerate processes: unable to connect to remote frida-server请检查设备是否开启了“开发者模式”设置 → 隐私与安全性 → 开发者模式 → 开启frida-server是否以 root 权限运行ps aux | grep frida看 USER 列是否为 root/etc/apt/sources.list.d/下是否有冲突源unc0ver 越狱后 Cydia 可能残留旧源执行apt-get clean apt-get update清理3. Frida 脱壳核心原理不是“破解加密”而是“截获解密后的内存快照”3.1 iOS App 加密的本质FairPlay DRM 与运行时解密很多人以为“脱壳”是暴力破解 FairPlay 加密这是根本性误解。iOS App 的.app包内主二进制如WeChat是经过 FairPlay 加密的 Mach-O 文件但加密密钥由硬件 Secure Enclave 动态生成软件层无法获取。真正的解密发生在 App 启动时iOS 内核加载器dyld调用 Secure Enclave 获取密钥将加密段__TEXT、__DATA实时解密到内存中。此时内存中的 Mach-O 已是明文但磁盘上的文件仍是加密状态。因此“脱壳”的技术本质是在 App 进程内存中定位已解密的 Mach-O 起始地址与大小将其完整复制到磁盘。这完全绕开了 FairPlay 密钥难题依赖的是 Frida 对进程内存的读写能力。3.2 dumpdecrypted 与 frida-ios-dump 的技术路线差异目前主流脱壳工具有两个分支其底层逻辑截然不同工具核心机制优势劣势适用场景dumpdecrypted注入 dylib 到目标进程hookmacho_load函数在 dyld 加载完解密段后直接从内存__TEXT段起始地址 dump 整个 Mach-O兼容性极强支持 iOS 10–15 所有越狱版本dump 出的文件可直接用 Hopper/IDA 打开需手动编译、签名对 iOS 15.7.1 后部分 App如银行类存在__LINKEDIT段校验失败学习逆向基础、分析老版本 Appfrida-ios-dump使用 Frida 脚本遍历进程内存搜索 Mach-O 头0xfeedfacf或0xfeedface定位__TEXT段再按 load command 解析 segment 大小逐段 dump无需重签名支持自动识别多个 Mach-O如主 App embedded framework可配合 objection 实现动态分析依赖 Frida-server 稳定性对 heavily obfuscated App 可能漏掉隐藏段生产环境批量脱壳、配合 Hook 分析我推荐新手从dumpdecrypted入手因其逻辑透明、报错明确而frida-ios-dump更适合已有 Frida 使用经验、需自动化处理多 App 的场景。3.3 dumpdecrypted 实战从编译到 dump 的完整链路步骤 1在 Mac 上编译 dumpdecrypted.dylibgit clone https://github.com/stefanesser/dumpdecrypted.git cd dumpdecrypted # 修改 Makefile将 SDK 改为当前 Xcode 支持的最高版本如 iOS15.5 make # 编译后生成 dumpdecrypted.dylib步骤 2将 dylib 传入设备并签名越狱设备仍受 Apple Mobile File IntegrityAMFI限制未签名 dylib 无法注入。必须用ldid工具签名# Mac 端安装 ldid brew install ldid # 签名-S 表示无 entitlements-M 表示强制签名 ldid -S dumpdecrypted.dylib # 上传到设备 scp dumpdecrypted.dylib root192.168.1.100:/var/tmp/步骤 3注入并触发 dump假设目标 App 为微信bundle IDcom.tencent.xin执行# 1. 启动微信确保前台运行 frida -U -f com.tencent.xin --no-pause # 2. 在 Frida 控制台中执行注入命令注意路径 [Remote::com.tencent.xin]- Process.loadModule(/var/tmp/dumpdecrypted.dylib) # 3. 触发 dump此命令会生成 dump.decrypted 文件 [Remote::com.tencent.xin]- send({type: dump})此时设备/var/tmp/下会出现WeChat.decrypted文件。但注意这不是最终文件。.decrypted文件是原始加密 Mach-O 的“伪解密”仍需进一步处理。步骤 4修复 Mach-O 头与 LC_LOAD_DYLIB.decrypted文件的 Mach-O 头中cputype字段可能被错误写为0x100000carm64e而实际应为0x100000carm64。更关键的是LC_LOAD_DYLIB命令中的路径如rpath/libswiftCore.dylib指向的是越狱设备路径需替换为相对路径或删除。我编写了一个 Python 脚本fix_macho.py自动修复import struct with open(WeChat.decrypted, rb) as f: data f.read() # 修复 cputype: 0x100000c - 0x100000c (arm64) data data[:12] b\x0c\x00\x00\x01 data[16:] # 删除所有 LC_LOAD_DYLIB 命令避免链接错误 # 此处省略具体偏移计算脚本中已实现 f.seek(0) f.write(data)运行后生成WeChat.fixed即可用 Hopper 正常打开。踩坑心得曾有次 dump 出的文件在 Hopper 中显示No architecture found。排查发现是dumpdecrypted版本过旧2017 年版其对 iOS 15 的LC_BUILD_VERSIONload command 解析失败。升级到 2023 年社区维护版后解决。记住越狱工具链的版本滞后性是脱壳失败的第一大元凶。4. frida-ios-dump 进阶实战自动化、多架构适配与防崩溃技巧4.1 为什么选择 frida-ios-dump—— 它解决了 dumpdecrypted 的三大硬伤无需手动签名Frida 注入机制天然绕过 AMFI 检查省去ldid签名步骤自动识别多 Mach-O一个 App 可能包含主二进制 多个 embedded framework如AlipaySDK.frameworkdumpdecrypted只 dump 主二进制而frida-ios-dump可遍历所有__TEXT段并分别 dump内存段精准定位dumpdecrypted依赖 hookmacho_load但某些 App如支付宝会 patch dyld 加载流程导致 hook 失败frida-ios-dump直接扫描内存不受加载流程干扰。4.2 安装与基础使用避开 npm 依赖陷阱frida-ios-dump的 npm 安装常因 node-gyp 编译失败而中断。更可靠的方式是直接克隆源码并安装git clone https://github.com/AloneMonkey/frida-ios-dump.git cd frida-ios-dump npm install --no-save # 避免全局污染 # 安装 Python 依赖关键 pip3 install -r requirements.txt基础命令# dump 微信主 App python3 dump.py com.tencent.xin # dump 某个 framework需先知道 bundle ID python3 dump.py com.tencent.xin --framework AlipaySDK但直接运行常报错Error: Unable to find process with name com.tencent.xin。这是因为 Frida 默认连接 USB 设备而dump.py脚本未显式指定设备。需修改dump.py第 42 行# 原代码 device frida.get_usb_device() # 改为 device frida.get_device(USB) # 强制 USB 设备4.3 多架构适配arm64 与 arm64e 的 PAC 指针处理iOS 14 设备A12启用 Pointer Authentication CodePAC导致 Frida 读取内存时若未正确处理 PAC 位会读到乱码地址。frida-ios-dump默认未开启 PAC 处理需手动启用在dump.py的dump_ios_app函数中找到session.create_script部分添加// Frida JS 脚本中启用 PAC 解析 if (Process.arch arm64) { // 启用 PAC strip移除 PAC 位 const pacStrip new NativeCallback(function(addr) { return addr ~0xf; }, uint64, [uint64]); }更简单的方法是使用社区增强版frida-ios-dump-plus它内置 PAC 适配且支持-a参数指定架构python3 dump.py com.tencent.xin -a arm64e4.4 防崩溃技巧规避 App 的反调试检测部分 App如招商银行、平安口袋银行集成反调试逻辑一旦检测到 Frida 注入立即exit(0)。此时需在注入前 patch 反调试函数。常用方法是用objection注入时自动执行 patch# 启动 objection 并自动 patch objection -g com.cmbchina.cmbportal explore --startup-command android hooking watch class_method android.os.Debug.isDebuggerConnected --dump-args --dump-return # 对 iOSpatch posix_spawn 或 ptrace 调用 objection -g com.cmbchina.cmbportal explore --startup-command ios hooking set-method-return posix_spawn false但更稳妥的做法是在 App 启动前用 Frida 脚本 hookmain函数在第一行就 patch 反调试逻辑。我整理了一个通用 patch 脚本anti_debug_patch.js// patch ptrace 检测 Interceptor.replace(Module.findExportByName(null, ptrace), new NativeCallback(function() { return 0; // 总是返回 0表示未被调试 }, int, [])); // patch sysctl 检测检查 kern.bootargs const sysctl Module.findExportByName(null, sysctl); if (sysctl) { Interceptor.replace(sysctl, new NativeCallback(function(name, namelen, oldp, oldlenp, newp, newlen) { // 若检测 kern.bootargs返回 -1 表示失败 if (name.readCString() kern.bootargs) return -1; return 0; }, int, [pointer, int, pointer, pointer, pointer, int])); }使用方式frida -U -f com.cmbchina.cmbportal -l anti_debug_patch.js --no-pause实操心得某次分析某款证券 App其反调试逻辑藏在[SSZipArchive unzipFileAtPath:toDestination:overwrite:password:error:]方法中通过NSThread isMainThread判断是否在主线程运行若否则认为被 Frida 注入。我花了 3 小时才定位到最终用objection ios hooking search classes SSZipArchive找到该类再ios hooking watch method [SSZipArchive unzipFileAtPath:toDestination:overwrite:password:error:]打印调用栈确认。反调试没有银弹唯一方法是缩小范围 → 定位类 → Hook 方法 → 打印堆栈 → 逐层回溯。5. 常见错误修复手册从报错信息直击根因的排查链路5.1 错误Failed to load script: Script crashed: Error: unable to find function at offset 0x0表象Frida 注入后立即崩溃控制台报此错。根因分析这是 Frida 脚本中Module.findExportByName查找函数失败常见于两种情况目标函数不存在于当前进程的 Mach-O 中如试图 hookSSL_CTX_set_verify但 App 使用的是 BoringSSL 而非 OpenSSL函数名拼写错误如SSL_CTX_set_verify写成SSL_CTX_set_verfiy。排查链路先用frida-trace列出进程所有导出函数frida-trace -U -f com.tencent.xin -i *SSL* # 列出所有含 SSL 的函数若无输出说明该进程未链接 OpenSSL改用class-dump查看是否使用NSURLSession或CFNetwork若函数存在但名称不符用Hopper打开 dump 出的 Mach-O在Symbols标签页搜索函数名确认真实符号名如SSL_CTX_set_verify可能被混淆为_SSL_CTX_set_vrfy_0x1a2b。修复方案改用Interceptor.attachhook 地址而非函数名const ctxSetVerify Module.findBaseAddress(libssl.dylib).add(0x1a2b); // 从 Hopper 获取偏移 Interceptor.attach(ctxSetVerify, {onEnter: function(args) {...}});或改用objc方法 hook对 Swift 类更有效ObjC.classes.NSURLSession.configuration().setHTTPShouldUsePipelining(true);5.2 错误dumpdecrypted failed: mach-o header not found表象dumpdecrypted.dylib注入后无反应/var/tmp/下无.decrypted文件。根因分析dumpdecrypted依赖在__TEXT段起始处找到 Mach-O 头0xfeedfacf但某些 App如抖音 iOS 15.7.1 版将主二进制拆分为多个 segment并将 Mach-O 头隐藏在__PAGEZERO后的某个偏移处。排查链路用frida-trace查看 dyld 加载日志frida-trace -U -f com.ss.android.ugc.aweme -i dyld*启动后观察dyld::loadPhase6日志记录__TEXT段加载地址如0x104a00000用 Frida 读取该地址内存Memory.readByteArray(ptr(0x104a00000), 16) // 应返回 0xfeedfacf...若返回0x00000000说明地址错误尝试0x104a00000 0x1000、 0x2000等偏移。修复方案修改dumpdecrypted源码在findMachHeader函数中扩大搜索范围从0x1000增至0x10000或直接用frida-ios-dump其内存扫描逻辑更鲁棒。5.3 错误frida-ios-dump: [Errno 13] Permission denied: /var/tmp/WeChat.app表象dump 脚本运行到一半报权限错误无法创建目录。根因分析越狱后/var/tmp/目录权限为drwxr-xr-x但frida-ios-dump默认尝试创建WeChat.app目录而 iOS 15 对/var/tmp/下子目录创建有额外 sandbox 限制。排查链路SSH 登录设备执行ls -la /var/tmp/确认权限执行touch /var/tmp/test若报错Permission denied说明/var/tmp/被挂载为noexec,nosuid查看挂载选项mount | grep /var/tmp。修复方案修改dump.py将输出路径改为/private/var/mobile/Containers/Data/Application/下的可写目录# 将 line 123 的 output_dir /var/tmp/ 改为 output_dir /private/var/mobile/Containers/Data/Application/或在设备上执行chmod 777 /var/tmp/5.4 错误Hopper 无法打开 dump 文件Load command 0x1d (LC_BUILD_VERSION) unknown表象dump 出的 Mach-O 在 Hopper 中报unknown load command无法解析。根因分析iOS 15 引入LC_BUILD_VERSIONload command 0x1d而 Hopper 4.10.0 以下版本不支持该命令导致解析失败。排查链路用otool -l WeChat.fixed | head -20查看 load command 列表确认是否存在cmd LC_BUILD_VERSION查看 Hopper 版本Hopper → About Hopper若低于 4.10.0则需升级。修复方案升级 Hopper 至 4.10.0或用jtool2移除LC_BUILD_VERSIONjtool2 --strip WeChat.fixed -o WeChat.stripped或用MachOViewmacOS 免费工具打开它对新 load command 兼容性更好。最后分享一个小技巧当遇到任何 Frida 报错不要急于 Google 错误信息。先执行frida-ps -Uai列出所有进程确认目标 App 是否真在运行再执行frida -U -p pid连接该进程 PID然后在 Frida 控制台中输入%resume观察是否立即崩溃。如果崩溃说明是 App 自身逻辑问题而非 Frida 配置问题——这是区分“环境问题”与“App 特性问题”的黄金法则。
