★ FEATURED ARTICLE 很多人学 iOS 逆向第一步就是狂装工具class-dump 装了、Hopper 装了、Theos 也配好了然后对着一个陌生的二进制文件陷入茫然。我见过太多人卡在这一步问题不是工具不行而是脑子里的储备没跟上。所谓“逆向储备”不是囤软件、背命令而是打仗前把弹药和地图备好——你得知道看什么、用什么看、看到的结果意味着什么。这篇我按这些年做 iOS 安全分析和 App 结构拆解的真实经验把一套能直接落地的储备清单整理出来。适合刚接触逆向、想把地基打牢的新人也适合有一定基础、但总感觉知识碎片化、想系统梳理的同行。1. 逆向储备的整盘规划先想清楚要“兑付”什么1.1 储备不是背资料而是建立作战地图把“储备”理解成背单词方向就错了。iOS 逆向的战场在二进制世界你面对的是一个经过程序编译、链接、可能还被混淆和加壳的 Mach-O 文件它不会主动告诉你逻辑。储备的核心是建立一条“输入—处理—输出”的链路认知输入是你拿到的 IPA 包或者测试设备上的文件系统处理是你手里的工具链输出是你对目标 App 结构、算法和调用关系的结论。如果连 Mach-O 的段布局都没概念就算 class-dump 跑出一堆头文件你也分不清哪些类是业务核心、哪些只是系统框架的引用。我自己的体会是把储备当成盖房子的脚手架而不是装修材料。脚手架解决的是“接下来从哪里下脚”的问题材料只是顺手取用。所以规划阶段别急着下载什么“逆向全家桶”先想清楚你要面对的目标长什么样再决定补哪块。1.2 两条主线静态储备与动态储备逆向能力体系分成两条主线缺一条都会瘸腿。静态储备解决“看”的问题看懂文件格式、段分布、符号表通过 class-dump、Hopper、Ghidra 这类工具还原出结构和伪代码。动态储备解决“试”的问题让目标 App 真实跑起来之后用断点、内存读写、方法拦截去验证你的静态判断工具是 LLDB、Frida、Theos 这一挂。大多数新手只囤了静态工具缺动态视角结果就是“看了一堆伪代码不知道从哪下手”。反过来只玩动态不补静态的人遇到加壳、反调试的目标会直接懵掉。我的建议是两条主线同时推进哪怕每个方向只掌握一套工具箱也够你应付九成以上的场景。1.3 给自己定一个“最小可逆向”目标先别挑战那种“全网最强加固”级别的目标那是后期的事。给自己定一个最小可逆向目标比如“搞清楚某记账 App 的本地数据库加密口令”或者“定位某页面请求里 token 的拼接位置”。定这个目标的好处是储备阶段从泛泛学习变成按需取用你不用看完一整本汇编教材才动手而是缺哪块补哪块。我见过最快的入门路径就是带着一个具体小问题去逆向两周后他对 Mach-O 和 LLDB 的熟悉度超过了许多啃了三个月教程的人。2. 认知储备绕不开的四块地基2.1 Mach-O 文件格式看得懂二进制骨架Mach-O 是 Mach Object 的缩写是 iOS 和 macOS 系可执行文件的标准格式。你可以把它类比成 docx 的本质——一个 zip 包里面分层存放着不同类型的文件。Mach-O 由三大部分构成文件头Header、加载命令Load Commands和数据区Data。文件头 64 位下的魔数是 0xfeedfacf读文件头就能知道这是什么架构、有多少条加载命令。加载命令最关键的有这几条LC_SEGMENT_64 描述每个段的偏移、大小和内存权限LC_MAIN 标记入口地址LC_LOAD_DYLIB 列出它依赖的动态库LC_SYMTAB 指向符号表。数据区最常见的两个段是 __TEXT 和 __DATA__TEXT 是只读可执行段寄存器里跑的大部分代码在这里字符串常量、Objective-C 方法名也在这边__DATA 是读写段存放全局变量和 Objective-C 运行时数据比如类列表 __objc_classlist、方法名列表 __objc_methname。逆向时你找“类名、方法名、字符串”其实就是在这些段里挖。理解 Mach-O 最大的价值在于你知道了符号和信息分别放在哪就能解释为什么 class-dump 能还原出类结构也能理解为什么加壳后这些信息会被加密隐藏。2.2 Objective-C Runtime 与消息机制iOS 世界里大量业务代码是 Objective-C 写的Swift 混编也改变不了整体骨架而 Objective-C 的方法调用本质是消息发送。你写[obj doSomething:]编译出来不是一次普通函数调用而是变成了objc_msgSend(obj, selector(doSomething:))。运行时沿着对象的 isa 指针找到所属类在类的方法列表中查找对应 SEL找到 IMP 再执行。这个机制对逆向意味着两件大事。第一类名和方法名默认会留在二进制里除非做了符号剥离或混淆这就是 class-dump、dsdump 这类工具能还原类结构的根本原因。第二既然查找方法的过程发生在运行时我们就可以在这一步做文章通过 Method Swizzling 或者注入代码把某个方法的实现替换成我们自己的逻辑就能在方法被调用时打印参数、篡改返回值。动态调试、插件注入的理论基础全在这里。2.3 ARM64 汇编速成路径现在的移动设备基本都是 arm64 架构你不需要成为汇编大师但必须认识指令的“形状”。最常遇到的是这几类数据传输指令 MOV/LDR/STR算术指令 ADD/SUB跳转指令 B/BL/RET比较与条件跳转 CBZ/CBNZ。再加上调用约定x0 到 x7 依次传参x0 同时用作返回值LRx30寄存器存返回地址SP 是栈指针。看反编译工具的伪代码时遇到一个不认识的 bl 调用先确认参数放在哪些寄存器就大概能猜出这个函数在干什么。速成技巧是不要从指令全集开始啃。找一个功能明确的片段比如“判断密码长度是否合法”的汇编片段配合伪代码逐行对照一遍比看任何视频教程都管用。你会发现汇编的思维方式跟高级语言不一样它是线性的、“一步步挪数据”的接受这个视角之后后面看 Hopper 的输出会顺畅许多。2.4 系统框架与应用沙盒的基础认知目标 App 不可能凭空实现一切功能它必然会链入 UIKit、Foundation、CFNetwork 这类系统框架。储备阶段要摸清它们各自的职责UIKit 管界面与页面生命周期Foundation 管数据结构和基础工具CFNetwork/NSURLSession 管网络请求Security 管密钥链和证书CryptoKit 提供现代加密接口Keychain 里的数据受系统级保护。判断一个 App 是否真的“有问题”很多结论来自框架使用对比。比如一个计算器 App 却引入了 Security 框架和 Keychain 访问逻辑这就非常可疑。沙盒机制则约束每个 App 只能访问自己的容器目录和偏好设置系统通过 container path 加代码签名来强制隔离。搞懂这些你分析一个目标时就能快速区分“这是系统能力还是业务私有逻辑”大大减少无效翻找。3. 工具储备一套能跑起来的逆向工作台3.1 静态分析三件套第一件是 MachOView 或 010 Editor用来查看文件头、加载命令和段布局是理解 Mach-O 的最佳教具。第二件是 class-dump它能把 Objective-C 的头文件原样导出如果你要对付 Swift 写的类建议同时装上 dsdump它对 Swift 符号的覆盖比老牌 class-dump 好不少。class-dump 的输出直接就是一组头文件类名、方法名、属性一目了然很多新手第一眼看到它会产生“逆向也没多难”的错觉——其实这只是开始。第三件是反编译器主流是 Hopper 和 Ghidra。看完 class-dump 的头文件后进反编译器里搜具体方法看它调用了哪些系统函数、引用了哪些字符串、走什么逻辑分支一条调用链就浮出来了。两者选哪个看预算和习惯Ghidra 免费开源、插件生态大Hopper 的伪代码阅读体验更接近 IDE。我的建议是先用 Ghidra 练手能白嫖又够用真正觉得不够了再考虑 Hopper。3.2 动态调试与注入工具动态储备的核心是 LLDB它是 Xcode 自带的调试器也是所有动态验证的基础。进入断点之后常用的技能有image list 查看当前进程加载了哪些模块expression 直接执行表达式memory read 读指定地址内存bt 看完整调用栈。熟悉这套后你对“某一个方法在真实运行时发生了什么”会有极直观的感受。往上走一层是 Frida注入脚本到目标进程直接调用内部函数、拦截方法、遍历堆上的对象。frida-trace 可以一键给多个方法加调用日志objection 可以看到当前界面层级和导出类的实例。实测下来排查“哪个方法被调用了、参数是什么”这类问题时Frida 的效率比手动下断点高得多。如果想进一步“改行为”就需要 Theos。它是个编译模板配合 Logos 语法用极简代码写 hook产物是一个动态库封装成 deb 包安装到测试设备里。还有老牌的 Cycript在旧设备和老教程里仍然能见到可以作为补充了解但不建议在上面花太多时间。工具在精不在多一套熟悉到条件反射胜过十套都只装不用的。3.3 测试设备的准备与注意事项强烈建议用一台专门的测试设备做逆向把你的主力机排除在外。安装、调试、崩溃分析都在这台机器上操作真出了问题也不影响日常使用。系统版本、设备型号要和你想分析的目标 App 匹配版本太新可能过不了系统校验版本太旧又装不上新版安装包。有条件的话准备两台不同系统版本的设备因为同一 App 在不同系统的行为往往有差异。常见的分析动作比如查看文件系统、安装插件、hook 系统调用很多确实需要越狱环境。但这条边界必须划清楚整个过程只应发生在你自己拥有完全控制权的测试设备上只用于学习和安全分析不扩展到任何别人的设备上。非越狱环境也不是不能做通过重签名加调试会话或者注入动态库的方式也能完成不少分析只是门槛更高。动手之前想清楚目标与边界比会多少技巧更重要。3.4 环境变量与实用命令速记把下面这几条命令练到手指记忆你的手速储备就算及格file 查看文件类型otool -l 查看 Mach-O 的加载命令nm 查看符号表strings 提取字符串codesign -d 查看签名信息log show 拉取系统日志symbolicatecrash 还原崩溃堆栈。再把取包流程脚本化unzip target.ipa -d out file out/Payload/*/.app/* class-dump -H out/Payload/*.app/* -o headers第一次手动跑通第二次就可以写成一个脚本往后“取包—解包—导出头文件—扔进反编译器”这条流水线五分钟内完成。别小看这五分钟它决定你愿不愿意对每个样本做一次完整分析而逆向能力的差距往往就是“肯不愿意每个样本都走完整流程”拉开的。4. 实操用储备的知识拆解一个模拟目标4.1 从应用包结构入手拿一个我自己练习时反复用的模拟项目举例这里就叫它“记账Demo”。拿到它的 IPA 包后把它当 zip 解压进入 Payload 目录里面是一个 xxx.app 目录。先读 Info.plist拿到 bundle identifier、最低系统版本和可执行文件名这几个字段决定了后面很多选择。接着用 file 检查主二进制用 lipo -info 看是不是胖二进制同时包含 arm64 和 armv7 那种是的话按目标架构拆分现代设备上基本只看 arm64。这一步不做深入分析但必须养成习惯任何目标动手前先把包结构、架构、系统版本记录下来。这不是形式主义是为了后续分析结论可复现。我见过太多人分析到一半忘了自己看的到底是哪个版本回头重来一遍非常浪费时间。4.2 静态分析拿到类结构对主二进制执行 class-dump导出头文件。然后按关键词扫描我常搜的是 encrypt、decrypt、token、auth、Secret、salt、AES、RSA 这几个。在模拟项目里很快就能看到 XXEncryptor 和 XXNetworkManager 这样的类前者大概率负责数据加密后者负责网络通信。接着进反编译器在对应类里搜方法实现观察它调用了哪些系统函数。如果调用了 CCCrypt那多半是系统级对称加密如果调用了 SecKeyEncrypt那是公钥算法如果只是几个异或和移位运算拼在一起那就是自制混淆。一次典型的静态分析到这里已经能回答“算法在哪、大概是什么类型”但还不能证明运行时真的这么走所以下一步必须动态验证。4.3 动态验证关键方法静态结论必须动态验证否则是纸上谈兵。在 LLDB 中对-[XXEncryptor encryptData:]下断点触发一次加密行为观察 x0-x7 寄存器和栈上的参数对比输入输出长度基本能确认这个方法的真实行为。再用 Frida 写一段简单脚本在方法入口打印调用栈看是哪个页面或哪个管理器调用了它Interceptor.attach(ObjC.classes.XXEncryptor[- encryptData:], { onEnter: function (args) { console.log(encryptData called); console.log(Thread.backtrace(this.context, Backtracer.ACCURATE) .map(DebugSymbol.fromAddress).join(\n)); } });如果还要进一步确认因果就用 Theos 写一个 tweak把返回值改成固定值重新运行后观察目标行为是否如你预想地变化。能验证到这一层你对这个目标的判断就算闭环了。很多新手习惯止步于静态分析的“看起来像是”但真正的逆向结论一定要能在运行时被证伪或证实。4.4 沉淀你自己的“储备清单”每次分析完一个目标把结论按三段式写下来必选项包括 bundle identifier、版本号、架构技术点包括用了什么加密、什么网络库、有没有混淆和反调试关键方法清单列出类名、方法名和它们的作用。攒够十个目标你就有了一个完全属于自己的案例库。以后遇到新目标第一件事是翻旧报告匹配模式。看到一个 App 用了跟某旧目标一样的加密方式你就能直接调出当时的反编译笔记省掉重新踩坑的时间。这份清单不是给别人看的越私人越好用因为它记录的是你自己的思维路径。5. 常见问题与排查技巧实录5.1 工具链异常速查表现象大概率原因处理方式class-dump 提示不是 Mach-O 文件拿到的是加壳或加密前的错误文件先看文件头魔数确认目标确实未加密再导出反编译器里方法空空如也符号被 strip 或者被混淆不要硬啃改从字符串引用和动态调用交叉定位LLDB attach 失败设备证书或签名问题目标带反调试确认开发者模式在自有测试设备上排查反调试点Frida 报 process not found进程名写错或服务未启动先用 frida-ps -U 列出真实进程名再附tweak 装了不生效安装包没重签或注入时机不对检查 deb 重签名流程确认插件加载路径正确这张表是根据我自己和身边的开发者反复踩坑总结出来的不一定覆盖所有情况但命中率极高。遇到工具不工作先对照现象找原因别立刻怀疑是“工具不行”九成问题出在文件拿错、环境不匹配这些基础环节。5.2 架构与系统版本带来的坑最常见的坑是拿到一个很老的 App它可能只含 armv7 架构而你的分析环境默认只处理 arm64导致很多符号根本读不出来。解决办法是先把二进制按架构拆分分完再进反编译器。另一个高发坑是开发机系统版本太新目标设备系统太旧Frida 和 Theos 的新版本往往不支持老系统装上去直接崩。我的做法是给每台测试设备固定一套“系统版本工具版本”组合写进设备标签里。重装环境时直接对照标签操作不在“为什么又崩了”上浪费一整天。版本问题看着小实际耗掉的时间一点不比处理一个反调试少。5.3 反调试与崩溃定位的思路遇到反调试先别硬刚。判断它属于哪一类ptrace 检测、sysctl 检测还是代码签名校验。针对一个你完全掌控的测试设备用静态分析找出检测函数的准确位置就能决定是绕过还是 patch。重点是先判断类型再动手而不是一上来就试图关闭所有防护那样只会把自己绕晕。崩溃分析则相反不要直接看一堆堆栈。先明确崩溃类型EXC_BAD_ACCESS 通常是野指针SIGABRT 多半是断言失败NSException 则是抛出异常。然后从调用栈里最后的业务方法名回到反编译器里定位这一步能省掉一半时间。逆向和崩溃调试一样都是“先定性再定位”顺序反了效率极其低下。5.4 几个“不写在文档里”的独家心得第一把取包、脱壳、重签这些重复操作全部脚本化别手动操作。手一抖就要白干二十分钟而脚本永远不会抖。第二class-dump 的输出不要全信。它擅长 Objective-C但 Swift 的扩展、泛型和 C 的内容常常救不回来这时必须配合反编译器才能拼出完整拼图。第三养成先找字符串的习惯。很多敏感逻辑会通过日志字符串暴露自己从字符串反查引用位置比从二进制里硬啃快得多。第四多设备记录很重要。有些分析结论只在一个系统版本上成立写报告时务必标注验证环境不然过两周连你自己都会怀疑这个结论是不是真的。最后说点个人的体会也算是在收尾时交代一下过来人的判断依据。我做逆向分析这几年真正的分水岭不是某一次把某个 App 的加密算法完整还原了而是某天突然发现自己不再“慌”拿到一个陌生目标我知道先看文件头、再看符号、再下断点每一步都有依据、都有退路。这就是“逆向储备”的全部意义——它不是一个能写进简历的技能名而是一套你随时可以调用的判断系统。如果你现在还处在四处找工具、囤教程的阶段不妨先停下来把这篇里的清单过一遍再找个最简单的目标走通全流程。储备到位了后面的事只是时间问题。
阅读完成 · 觉得有帮助？
