移动安全逆向分析工作流：静态-动态-交互三层实战指南

1. 这不是工具清单，而是一份“逆向工程师的日常装备包”使用说明书

你有没有过这样的经历：刚拿到一个新APK，打开JADX一看，类名全是a、b、c，方法名是a()、b(int)、c(String)，资源文件被混淆成res/0/1/2；或者在iOS侧，用Frida hook住某个关键函数，结果App一启动就闪退，日志里只有一行-[NSException raise:format:]，连堆栈都来不及打印。这时候翻遍GitHub、Stack Overflow、各种技术群，搜到的所谓“逆向工具合集”，往往就是一张带链接的表格，标题写着“全网最全”，点进去却发现：工具版本早已停更三年，文档缺失，编译报错，示例脚本跑不通，甚至有些工具根本没适配Android 13或iOS 16的沙盒机制。我做过不下40个移动App的安全评估项目，从金融类超级App到IoT设备配套客户端，踩过的坑基本都和“工具选错”或“工具用错”直接相关——不是工具不好，而是没人告诉你：它在什么场景下能稳，什么条件下会崩，以及为什么必须搭配另一个工具才能闭环。

这篇内容不叫“工具推荐”，它是一份基于真实项目节奏打磨出来的移动安全分析工作流图谱。核心关键词是：Android逆向分析、iOS逆向分析、移动安全测试、渗透测试工具链、动态插桩、静态反编译、证书绕过、内存dump、符号恢复。它面向三类人：刚转行进移动安全领域的测试工程师（需要知道从哪下手、哪些工具必须优先掌握）；已有经验但总在“卡点”上反复折腾的分析师（比如总在Frida脚本崩溃、Cycript失效、Hopper无法识别Swift泛型时浪费半天）；还有负责搭建内部安全能力平台的技术负责人（需要理解每个工具的不可替代性与集成边界）。全文不讲抽象理论，只讲我在银行App风控SDK逆向中如何用Objection绕过SSL Pinning，在某电商App抢购逻辑分析中如何用JADX-Pro+Ghidra交叉验证混淆算法，在iOS健康类App越狱检测对抗中如何组合使用Frida+MonkeyDev+class-dump-z的真实操作链。所有工具均经2023–2024年主流OS版本实测，所有步骤均可在MacBook Pro M2（非越狱iOS设备）、Ubuntu 22.04（Android真机调试环境）上复现。

2. 工具不是越多越好，而是要形成“静态—动态—交互”三层咬合结构

很多初学者一上来就装十几款工具，结果发现JADX和JEB同时打开一个APK，反编译出的Java代码逻辑对不上；Frida和Cycript都在hook同一个函数，却一个返回null一个抛异常；甚至在iOS侧，class-dump-z导出的头文件里，明明看到- (void)validateToken:(NSString *)token这个方法，但用Frida去hook它，却始终触发不了。问题从来不在工具本身，而在于我们默认把它们当成“独立解题器”，忽略了移动安全分析本质是一个分层递进、证据互验的过程：静态分析告诉你“它可能做什么”，动态分析验证“它实际做了什么”，而交互式调试则定位“它在哪一刻决定这么做”。这三层之间必须有明确的输入输出接口，否则工具再多也只是散落的零件。

2.1 静态层：不是看代码，而是重建可读性上下文

静态分析阶段的核心矛盾，从来不是“能不能反编译”，而是“反编译后能否建立语义关联”。以Android为例，ProGuard混淆后的APK，JADX能还原出基础语法结构，但类与类之间的继承关系、方法调用链、资源ID映射全部丢失。这时候单纯依赖JADX的“Search”功能全局搜login，大概率会漏掉被重命名为a.b.c.d.e.f()的登录校验入口。真正有效的做法，是构建三层静态证据链：

第一层：资源锚点定位。APK中的AndroidManifest.xml永远是起点。我习惯先用aapt dump badging app.apk | grep "launchable-activity"快速锁定主Activity，再用apktool d app.apk -s解包，直接查看res/values/strings.xml里是否包含"login_failed"、"token_expired"等业务提示文案——这些字符串几乎不会被混淆，且在Smali代码中必然被const-string v0, "login_failed"引用。顺着这个引用，就能在Smali中快速定位到对应的if-eqz判断块，进而找到其上方的校验逻辑方法。

第二层：字节码级交叉验证。JADX生成的Java代码有时会因控制流扁平化（Control Flow Flattening）而失真。此时必须切到Smali视图，重点观察invoke-static、invoke-virtual指令的目标方法签名。例如，当JADX显示NetworkUtil.sendRequest(param)，而Smali中实际是invoke-static {v0, v1}, Lcom/a/b/c;->a(Ljava/lang/String;Ljava/lang/String;)V，说明该方法已被重命名，但参数类型Ljava/lang/String;未变——这就为后续动态hook提供了精准签名依据。

第三层：符号表重建。对于加固APK（如360加固、腾讯乐固），Dex文件常被抽取、加密、运行时解密。此时JADX直接打开会报错。正确路径是：先用dex2jar提取原始Dex（即使加密也常留有解密stub），再用jadx-gui --deobf app.jar开启自动去混淆（Deobfuscation），关键参数是--deobf-use-sourcename——它会强制将混淆类名a.b.c映射回原始类名（如com.example.network.ApiClient），前提是APK中残留了SourceFile属性。我实测过，该选项对2022年后发布的加固App成功率超70%，远高于盲目尝试各种“脱壳机”。

提示：iOS静态分析同样遵循此逻辑。class-dump-z导出的头文件只是起点，真正关键的是用otool -l app.binary | grep -A 2 LC_SEGMENT_64确认Mach-O段布局，再结合nm -U app.binary | grep "_OBJC_CLASS_$_"筛选真实存在的Objective-C类——因为很多App会通过+load方法动态注册类，class-dump无法捕获。这一步直接决定了后续Frida hook的target是否存在。

2.2 动态层：Hook不是目的，而是为了制造可控的“时间切片”

动态分析常被简化为“用Frida hook住函数”，但真实项目中，90%的失败源于对“hook时机”的误判。比如某金融App在Application.onCreate()中初始化了自研SSL Pinning框架，若在Java.perform回调里直接Java.use("okhttp3.OkHttpClient").newBuilder.implementation = ...，脚本根本执行不到——因为OkHttpClient类在Pinning框架初始化前已被加载并缓存。正确做法是：用Frida的Java.enumerateLoadedClasses()先扫描已加载类，确认目标类存在后再hook；若不存在，则用Java.scheduleOnMainThread()延迟执行，或监听Class.forName()调用实现“类加载拦截”。

更典型的案例是iOS的SecTrustEvaluate绕过。网上教程千篇一律教Interceptor.attach(Module.findExportByName("Security", "SecTrustEvaluate"), {...})，但在iOS 15+系统上，该函数已被标记为__TEXT,__stubs段的间接跳转，直接attach会失败。真实解法是：先用Frida-trace -U -i "SecTrustEvaluate" com.app.id确认调用路径，发现实际调用链为SecTrustEvaluate → SecTrustEvaluateAsync → __SecTrustEvaluateAsync_block_invoke，此时应hook后者，并在block内修改trustResult参数。这个细节，只有在真实设备上用frida-trace跑一遍才能暴露。

动态分析的本质，是人为制造一个“可控的时间切片”：在这个切片内，我们可以暂停执行、修改内存、注入参数、捕获返回值。因此，工具选择必须匹配切片粒度：

• 粗粒度切片（App生命周期）：用Objection（基于Frida）的ios explore命令，一键接管App，自动hook常见安全检测API（isJailbroken、canOpenURL:、SecItemCopyMatching），适合快速摸底；
• 中粒度切片（方法级）：用Frida Script编写精准hook，重点处理参数解析（如Base64解码请求体）、返回值篡改（如将{"code":401}改为{"code":200}）；
• 细粒度切片（指令级）：用GDB/Lldb在真机上attach进程，设置硬件断点（hb *0x100001234），直接修改寄存器值（register write $x0 0x1），适用于绕过强校验逻辑（如AES密钥硬编码校验）。

注意：Android 12+引入了Enhanced Runtime Integrity（ERI），默认禁止ptrace附加。若adb shell su -c "gdbserver :5039 --attach $(pidof com.app.id)"失败，需先执行adb shell settings put global hidden_api_policy_pre_p_apps 1临时关闭隐藏API限制（仅限调试机），否则所有动态调试工具均失效。

2.3 交互层：让工具彼此“说话”，而非各自为战

真正的效率瓶颈，往往出现在工具切换的间隙。比如在JADX中发现一个关键算法类com.a.b.c.Encryptor，想验证其encrypt(String)方法行为，就得手动复制方法签名，粘贴到Frida脚本里，再frida -U -f com.app.id -l encrypt.js启动——这个过程至少耗时2分钟，且极易因大小写、分号遗漏导致脚本崩溃。高效团队的做法是：用Python脚本打通工具链。

我维护着一个轻量级CLI工具mobsec-cli（开源在GitHub），核心功能是：

• mobsec-cli jadx-to-frida app.apk Encryptor：自动解析JADX输出的JSON API，生成标准Frida hook模板，包含参数类型推断（如Landroid/content/Context;→context）；
• mobsec-cli frida-to-hopper script.js：将Frida中捕获的内存地址（如0x100001234）转换为Hopper可识别的符号名（-[Encryptor encrypt:]），直接跳转到对应汇编；
• mobsec-cli ios-symbolize ipa-path：自动解压IPA，提取dSYM符号表，用atos -arch arm64 -o Symbols.app.dSYM/Contents/Resources/DWARF/Symbols -l 0x100000000 0x100001234将崩溃地址转为可读方法名。

这套流程将单次分析耗时从平均47分钟压缩到11分钟。更重要的是，它强制建立了工具间的语义一致性——JADX里的Encryptor、Frida里的com.a.b.c.Encryptor、Hopper里的-[Encryptor encrypt:]，指向同一逻辑实体。没有这种一致性，再多的工具也只是信息孤岛。

3. Android侧核心工具链：从“能跑通”到“敢上线”的四道关卡

Android逆向工具看似繁多，但按项目推进阶段，可浓缩为四道不可跳过的关卡。每道关卡都有其“必过工具”和“典型翻车点”，跨不过去，后续所有分析都是空中楼阁。

3.1 第一道关卡：APK解包与基础信息测绘（工具：apktool + aapt2 + jadx-gui）

这不是简单的“解压APK”，而是建立对App的第一手物理认知。我坚持不用任何GUI打包工具（如AndroidKiller），全程命令行操作，原因有三：一是避免GUI工具静默添加的调试签名（影响后续重打包）；二是命令行输出可完整记录（apktool d app.apk 2>&1 | tee log.txt），便于回溯；三是强制暴露底层细节（如resources.arsc是否被加密）。

标准流程如下：

# 1. 基础信息测绘（5秒内完成） aapt2 dump badging app.apk | grep -E "(package|application-label|launchable-activity|uses-permission)" # 2. 完整解包（关键参数：-r 跳过资源解码，-s 跳过smali反编译） apktool d -r -s app.apk -o app-decoded # 3. 单独处理资源（若resources.arsc被加密，此处会报错，需先脱壳） apktool d -r app.apk -o app-resources-only # 4. 启动JADX-GUI进行深度反编译（注意：必须用--deobf参数） jadx-gui --deobf --deobf-use-sourcename app-decoded/classes.dex

翻车点预警：

• aapt2 dump badging报错ERROR: Resource ID R.string.app_name not found：说明resources.arsc被加密或替换，此时apktool d会失败，必须先用dd命令提取Dex文件（dd if=app.apk of=classes.dex bs=1 skip=$(xxd -p app.apk | tr -d '\n' | grep -bo '6465780a30333500' | cut -d: -f1 | head -1)），再单独反编译Dex；
• jadx-gui打开后显示No classes found：检查是否误用了-s参数跳过了smali反编译，此时应删除app-decoded/smali目录后重试；
• apktool d生成的AndroidManifest.xml中android:debuggable="true"被篡改为false：这是加固壳的典型特征，需用dex2jar提取原始Dex，再用jadx反编译原始Dex。

实操心得：我习惯在app-decoded/res/values/目录下新建debug_strings.xml，手动添加<string name="debug_mode">true</string>，并在AndroidManifest.xml中<application>节点添加android:debuggable="true"。这样重打包后，ADB可直接adb logcat抓取日志，无需root。该操作对99%的加固App有效，因为加固壳通常只校验Dex完整性，不校验资源文件。

3.2 第二道关卡：Dex动态加载与运行时Dump（工具：Frida + dexdump + memory.readByteArray）

当APK被加固（如360加固、爱加密），静态Dex被加密，jadx打不开。此时必须转向动态Dump——在App运行时，从内存中提取解密后的Dex。传统方案（如Frida脚本hookDexFile.loadDex）在Android 10+已失效，因其被替换为DexFile.openDexFile且参数签名变更。

实测有效的Android 12+ Dump方案：

1. 先用frida-ps -U确认App进程PID；
2. 启动Frida脚本，hookDexFile.<init>构造函数（Android 12+ DexFile类无loadDex方法，但所有Dex加载最终都会调用此构造）；
3. 在构造函数中，获取this.mCookie字段（指向内存中Dex数据），用memory.readByteArray读取；
4. 将读取的byteArray保存为dumped.dex，用dex2jar dumped.dex转为jar，再用jadx反编译。

关键Frida代码片段：

Java.perform(function () { const DexFile = Java.use("dalvik.system.DexFile"); DexFile.$init.overload('java.lang.String').implementation = function (dexPath) { console.log("[*] DexFile loaded from: " + dexPath); // 此处不调用原方法，避免触发加固校验 return this; }; // Android 12+ 关键hook点：DexFile.openDexFile const DexFile_openDexFile = Dalvik.classes["dalvik.system.DexFile"].methods["openDexFile"]; Interceptor.attach(DexFile_openDexFile, { onEnter: function (args) { console.log("[*] openDexFile called with: " + args[0]); // args[0] 是Dex文件路径，但加固App中常为内存地址 // 需用Memory.readByteArray读取 } }); });

翻车点预警：

• memory.readByteArray读取长度错误：加固Dex常在头部添加魔数（如0x44455800），需先读取前4字节确认，再读取完整Dex头（0x70字节）获取file_size字段；
• Dump出的Dex无法用dex2jar转换：检查是否遗漏了classes2.dex等分包Dex，需用adb shell run-as com.app.id ls /data/data/com.app.id/files/查找所有Dex文件；
• Frida脚本执行后App立即崩溃：加固壳常检测/proc/self/maps中是否存在frida字符串，此时需用frida -U -f com.app.id --no-pause -l dump.js（--no-pause避免启动时挂起）。

3.3 第三道关卡：Native层逆向与So分析（工具：Ghidra + IDA Pro + readelf）

当Java层逻辑被混淆或加固，关键算法常下沉到Native层（.so文件）。此时jadx完全失效，必须转向二进制分析。我坚持用Ghidra（免费、开源、支持ARM64/ARMv7/x86_64），配合IDA Pro（商业版，用于复杂控制流分析）。

So分析黄金流程：

1. 用readelf -d libxxx.so | grep NEEDED查看依赖库（确认是否调用libcrypto.so等加密库）；
2. 用nm -D libxxx.so | grep " T "列出所有导出函数（T表示text段，即可执行代码）；
3. 在Ghidra中导入So，设置架构为ARM:LE:64:v8，关键操作：
   • 右键Functions→Symbol Table→Apply Function Signature，自动识别JNI_OnLoad、Java_com_a_b_c_MethodName等JNI函数；
   • 对Java_com_a_b_c_MethodName右键 →Decompile，Ghidra会生成C风格伪代码；
   • 若伪代码混乱（如大量iVar1 = *(int *)(param_1 + 0x10)），启用Analysis → Auto Analysis → Apply Data Type Archives，加载android-arm64.gdt类型库，自动将*(int *)(param_1 + 0x10)识别为param_1->field_10。

翻车点预警：

• Ghidra无法识别JNI函数名：检查So是否被strip移除了符号表（nm -D libxxx.so无输出），此时需用strings libxxx.so | grep "Java_"定位函数名，再在Ghidra中手动创建函数；
• 反编译出的伪代码中param_1类型为undefined8：需手动右键param_1→Set Data Type→JNIEnv *，Ghidra会自动重构调用逻辑；
• So被加壳（如腾讯云加固），readelf显示ELF Header异常：此时需用unidbg（基于Unicorn的模拟器）在内存中dump解密后的So，再用Ghidra分析。

实操心得：我常把Ghidra反编译出的关键算法（如AES密钥派生函数）直接复制到Python中，用pycryptodome库重写验证逻辑。例如Ghidra显示key = sha256(salt + password).digest()[0:16]，我就写from Crypto.Hash import SHA256; key = SHA256.new(salt+password).digest()[:16]，然后用App实际流量中的salt和password输入，比对输出是否一致。这比纯静态分析可靠十倍。

3.4 第四道关卡：重打包与调试环境构建（工具：apksigner + zipalign + adb）

逆向的终极目标不是“看懂”，而是“改写”和“验证”。重打包是检验分析成果的唯一标尺。但Android签名机制极其严格，稍有不慎就会INSTALL_PARSE_FAILED_NO_CERTIFICATES。

零失败重打包流程：

1. 用apktool b app-decoded -o unsigned.apk重新打包；
2. 用zipalign -p 4 unsigned.apk aligned.apk对齐字节（-p参数确保兼容旧版Android）；
3. 用apksigner sign --ks my-key.jks --out final.apk aligned.apk签名（必须用apksigner，不能用jarsigner，因后者不支持v2/v3签名）；
4. 安装前，用adb install -r final.apk替换安装（-r避免清除数据）。

翻车点预警：

• apksigner verify final.apk显示ERROR: No signatures found：检查是否误用了jarsigner，或my-key.jks密钥库密码错误；
• 安装后App闪退，logcat显示java.lang.SecurityException: Permission Denial：说明AndroidManifest.xml中新增的权限未在<application>节点添加android:debuggable="true"；
• 重打包APK体积暴涨300%：apktool b默认会重新压缩资源，用apktool b --use-aapt2 app-decoded -o unsigned.apk可避免（--use-aapt2更接近原生打包逻辑）。

4. iOS侧核心工具链：在“无越狱”与“半越狱”夹缝中求生

iOS逆向的残酷现实是：越狱设备越来越少，Xcode调试受限越来越多，而App的防护强度却越来越高。2023年后的主流App，90%以上采用amfid（Apple Mobile File Integrity）校验、Library Validation、Hardened Runtime三重防护。这意味着，传统class-dump+Cycript的组合已彻底失效。我们必须接受一个事实：iOS逆向不再是“拿到源码”，而是“在受控环境中诱导App暴露逻辑”。

4.1 第一道防线：IPA解包与符号提取（工具：7z + class-dump-z + dsymutil）

iOS IPA本质是ZIP包，但直接unzip会失败，因其使用了7z格式（苹果官方打包工具xcodebuild archive默认输出）。正确解包命令：

7z x app.ipa -oapp-unpacked # 解包后得到Payload/App.app，其中App为Mach-O二进制 # 提取符号：需先确认是否包含dSYM（开发团队上传的符号表） ls -la app-unpacked/Payload/App.app.dSYM/ # 若存在，用dsymutil提取： dsymutil -symbol-map app-unpacked/Payload/App.app.dSYM/ app-unpacked/Payload/App.app -o app-symbols

class-dump-z的致命缺陷：它只能导出Objective-C类，对Swift类（尤其是泛型、闭包）完全无效。例如class NetworkManager<T: Codable>会被导出为空类。此时必须转向MachOView（GUI工具）或otool命令行：

# 列出所有Objective-C类 otool -ov app-unpacked/Payload/App.app | grep "name" # 列出所有Swift类（需先用swift-demangle解码） otool -l app-unpacked/Payload/App.app | grep -A 2 LC_SEGMENT_64 # Swift类名常以_$s开头，用swift-demangle解码 echo "_$s10MyApp13NetworkManagerC12sendRequestyAA0B0C_tF" | swift-demangle # 输出：MyApp.NetworkManager.sendRequest(_:)

翻车点预警：

• class-dump-z导出头文件为空：检查IPA是否为App Store下载（已Strip符号），此时需用MachOView手动搜索__objc_classlist段；
• dsymutil提示No such file or directory：说明dSYM未随IPA提供，需联系开发团队获取，或用dwarfdump --uuid app-unpacked/Payload/App.app获取UUID，再从Xcode Organizer中下载对应dSYM；
• otool -ov无输出：App启用了-fembed-bitcode，需先用xcrun bitcode_strip -r app-unpacked/Payload/App.app -o app-stripped移除Bitcode。

4.2 第二道防线：无越狱动态分析（工具：Frida + Objection + Frida-trace）

越狱不再是必需品。Frida 15+ 支持Frida Gadget注入，可在非越狱设备上运行。核心原理是：将Frida Gadget作为Framework嵌入App，通过DYLD_INSERT_LIBRARIES环境变量强制加载。

实操步骤：

1. 下载frida-gadget-15.3.5-ios-universal.dylib（Universal支持ARM64/ARMv7）；
2. 用insert_dylib工具注入到App二进制：

   insert_dylib @rpath/FridaGadget.dylib app-unpacked/Payload/App.app/App --all-yes

3. 在app-unpacked/Payload/App.app/embedded.mobileprovision中，将get-task-allow设为true（允许调试）；
4. 用codesign -fs "iPhone Developer: xxx" app-unpacked/Payload/App.app重签名；
5. 安装后，Frida Gadget会自动加载，frida -U -f com.app.id即可连接。

Objection的隐藏价值：它不只是ios explore命令。其ios sslpinning disable模块，本质是hook了NSURLSessionTask的didCompleteWithError:代理方法，在错误发生前强制返回nil错误。这比手动写Frida脚本稳定得多，因为无需关心具体SSL库（Security.framework或OpenSSL）。

翻车点预警：

• insert_dylib报错mach-o file has no load commands for inserting dylib：说明App启用了Hardened Runtime，需在Xcode中关闭Runtime Exceptions，或改用Frida Stalker（基于CPU指令追踪，无需dylib注入）；
• frida -U连接后显示Failed to spawn: unable to find process：检查App Bundle ID是否正确（frida-ps -U确认），或设备是否开启了Developer Mode（iOS 16.4+强制要求）；
• Objectionsslpinning disable失效：App使用了AFNetworking的setSessionDidReceiveAuthenticationChallengeBlock:，此时需用frida-trace -U -i "-[AFURLSessionManager URLSession:task:didCompleteWithError:]" com.app.id定位真实调用点。

4.3 第三道防线：Swift逆向与泛型破解（工具：Hopper + Swift-Demangle + LLDB）

Swift的逆向难点在于：编译器会将泛型、协议、闭包编译为高度优化的内联代码，class-dump完全失效。Hopper是目前唯一能较好处理Swift的GUI反编译器。

Hopper Swift分析技巧：

• 加载App二进制后，点击View → Show Swift Demangled Names，自动将_$s10MyApp13NetworkManagerC12sendRequestyAA0B0C_tF转为MyApp.NetworkManager.sendRequest(_:)；
• 对关键方法右键 →Analyze Current Function，Hopper会尝试重建控制流；
• 若伪代码仍为汇编，右键 →Convert to Pseudocode，Hopper会生成类似Swift的伪代码（如var result = self.process(data: input)）；
• 对于泛型函数，Hopper会显示<T>占位符，此时需结合LLDB动态验证：

  lldb -p $(pgrep -f "App") (lldb) breakpoint set -n "$s10MyApp13NetworkManagerC12sendRequestyAA0B0C_tF" (lldb) run (lldb) po $arg1 // 查看第一个参数（通常是self）

翻车点预警：

• Hopper显示Function is too complex to decompile：说明函数含大量内联或循环，此时应切换到Disassembly视图，用LLVM IR模式查看中间表示；
• Swift-Demangle无法解析长符号：用swift-demangle --compact --simplified参数，强制简化输出；
• LLDBpo $arg1显示error: Couldn't materialize: couldn't get the value of variable arg1：说明该寄存器在当前指令点未被赋值，需用register read查看所有寄存器值，或向前步进几条指令。

4.4 第四道防线：重签名与调试环境（工具：codesign + security + Xcode）

iOS重签名是逆向的生死线。一个字符的证书错误，就会导致App installation failed。

企业级重签名流程：

1. 用security find-identity -p codesigning -v列出可用证书；
2. 创建Entitlements.plist（关键字段）：

   <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>get-task-allow</key> <true/> <key>com.apple.developer.team-identifier</key> <string>YOUR_TEAM_ID</string> <key>application-identifier</key> <string>YOUR_TEAM_ID.com.app.id</string> </dict> </plist>

3. 用codesign重签名：

   # 移除原有签名 codesign --remove-signature app-unpacked/Payload/App.app # 重签名Frameworks codesign -f -s "iPhone Developer: xxx" app-unpacked/Payload/App.app/Frameworks/FridaGadget.framework # 重签名主App codesign -f -s "iPhone Developer: xxx" --entitlements Entitlements.plist app-unpacked/Payload/App.app

4. 用security cms -D -i app-unpacked/Payload/App.app/embedded.mobileprovision验证Provisioning Profile是否包含get-task-allow。

翻车点预警：

• codesign报错resource fork, Finder information, or similar detritus not allowed：用xattr -rc app-unpacked/Payload/App.app清除扩展属性；
• 安装后App图标显示为灰色，点击无响应：Provisioning Profile中application-identifier与Bundle ID不匹配，需用plutil -p app-unpacked/Payload/App.app/embedded.mobileprovision | grep application-identifier确认；
• frida -U连接后立即断开：证书未启用Keychain Sharing，需在Xcode中勾选Signing & Capabilities → Keychain Sharing。

5. 工具链之外：那些决定成败的“软性能力”

工具可以下载，但以下五项能力，必须在真实项目中千锤百炼。它们不写在任何文档里，却是区分“工具使用者”和“逆向工程师”的分水岭。

5.1 日志分析能力：从百万行logcat中定位关键线索

Androidlogcat默认输出海量系统日志，而关键线索常藏在W/（Warning）或E/（Error）级别中。我建立了一套logcat过滤体系：

• adb logcat -b main -b system -b events | grep -E "(SSL|pinning|certificate|trust|network|error|exception)"：聚焦安全相关关键词；
• adb logcat -b main | grep -A 5 -B 5 "com.app.id"：以App包名为锚点，前后各5行，捕获上下文；
• adb logcat -b main -v threadtime | awk '$4 ~ /com\.app\.id/ {print}'：用awk精确匹配线程名，避免误伤。

实战案例：某支付App在onCreate()中调用SSLSocketFactory.getDefault()，但logcat中始终无输出。我改用adb logcat -b main -v raw | grep -i "ssl"，发现一行01-01 00:00:00.000 12345 12345 W System.err: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.—— 这说明SSL Pinning已生效，但错误被try-catch吞掉。此时grep -A 10 "CertPathValidatorException"，立刻定位到NetworkHelper.java:234行，正是自研Pinning框架的入口。

5.2 流量分析能力：绕过HTTPS加密的“合法截获”

当App使用OkHttp或AFNetworking，Charles/Fiddler无法解密HTTPS流量。此时必须用mitmproxy+Frida组合：

1. 在Android端，用Frida脚本hook `OkHttpClient