1. 这不是工具清单而是一份“逆向现场作战地图”你有没有过这样的经历刚拿到一个新App想快速摸清它的通信逻辑结果卡在第一步——连进程都attach不上或者用某款主流工具跑出一堆so符号却根本分不清哪些是加密函数、哪些是埋点入口又或者在iOS上越狱环境都搭好了一运行frida脚本就崩溃日志里只有一行Failed to find symbol连报错位置都找不到。这不是你技术不行而是手里的工具没对上真实战场的节奏。Android和iOS逆向分析/安全测试/渗透测试工具从来不是“装完就能用”的静态列表它是一套动态适配的作战体系要匹配目标App的加固强度、运行环境模拟器/真机/越狱/root、开发框架Flutter/RN/原生、甚至测试阶段黑盒初筛/白盒精审/上线前复核。我做过近百个App的安全评估从金融类超加固应用到IoT设备配套App发现真正决定效率的从来不是工具本身多炫酷而是你能否在30秒内判断出“此刻该用哪个工具打哪一枪”。这篇内容不罗列GitHub Star数不堆砌功能参数而是按真实逆向流程拆解从“拿到APK/IPA那一刻”开始每一步该调用什么工具、为什么选它、怎么绕过它最常卡住你的那个坑。关键词全部落在实操场景里Android逆向分析、iOS安全测试、渗透测试工具链、Frida实战配置、ObjC Runtime Hook、DEX脱壳、Mach-O符号修复、证书信任绕过。适合正在做移动App安全评估的工程师、渗透测试人员也适合想系统补全逆向能力的开发同学——只要你需要打开App看懂它“心里在想什么”这篇就是你的现场作战地图。2. 工具选型不是拼参数而是解构“攻击面-防御层-工具能力”三角关系很多人一上来就问“哪个脱壳工具最强”“Frida和Cycript哪个好”这种问题本身就有陷阱。逆向工具的有效性永远取决于它能否精准切中目标App的“防御层”与你的“攻击面”之间的缝隙。比如一个使用腾讯Legu加固的Android App其DEX文件被完全加密并运行时解密此时任何静态扫描DEX结构的工具如dex2jar都会失效但如果你强行用Frida在解密后内存中dump又可能触发Legu的反调试检测。这时候真正起作用的不是“脱壳工具”而是先用Frida hook Legu的解密函数在内存解密完成但尚未执行前把原始DEX字节流完整读出——这要求你既理解Legu的解密流程防御层又清楚Frida的内存读取边界工具能力还要能定位到解密函数入口攻击面。iOS同理一个启用App Attest的银行App其关键业务逻辑会校验设备完整性此时直接用class-dump导出头文件毫无意义因为核心逻辑藏在混淆后的Swift闭包里且调用链被Attest校验层层包裹。你必须先用Frida绕过Attest校验攻击面再用Hopper动态反编译工具能力同时结合符号表修复防御层对抗。所以我们不按“Android工具/iOS工具”二分而是按逆向动作类型重构工具链逆向动作类型核心目标典型防御层干扰推荐工具组合关键能力要求初始侦察快速获取包结构、权限声明、基础网络配置资源混淆、Manifest加密apktooljadx-guiAndroidotool -lclass-dumpiOS能识别混淆特征如a.b.c包名、快速定位AndroidManifest.xml或Info.plist中的敏感字段动态监控实时捕获网络请求、本地存储、关键函数调用反调试、SSL Pinning、JNI层Hook检测Frida全平台ObjectioniOS增强熟悉Frida Script API、能编写绕过SSL Pinning的通用hook如okhttp3.CertificatePinner内存提取获取运行时解密后的DEX/Mach-O、关键密钥、Token内存保护如mprotect、反dump机制Frida内存dumpdumpdecryptediOSfrida-ios-dump自动化理解内存段布局.text/.data、能通过Module.findBaseAddress()定位模块基址符号修复恢复被strip的函数名、Objective-C类方法、Swift泛型符号符号表剥离、Swift Name Manglingclass-dump-ziOSFrida动态符号解析SwiftDecompiler辅助掌握nm -U/otool -Iv查看符号、能用Frida遍历objc_getClassList重建类结构这个表格不是让你死记硬背而是建立判断坐标系。当你下次面对一个新App先问自己三个问题它防什么查加固方案、看是否越狱检测、测SSL Pinning强度我想打哪是抓登录请求还是逆向支付签名算法我的工具能不能跨过那道墙比如Frida在iOS上需配合ios-deploy重签名否则无法注入答案自然浮现。我曾在一个RN App上卡了两天反复试jadx、dex2jar都失败最后用apktool d解包发现assets/index.android.bundle才是核心逻辑直接用js-beautify格式化后搜索fetch就定位到所有API地址——工具没变但“攻击面”从DEX切换到了JS Bundle整个路径就通了。3. Frida不是万能胶而是需要精确制导的“动态手术刀”提到Android和iOS逆向分析/安全测试/渗透测试工具Frida几乎是默认首选。但太多人把它当“万能胶”写个Java.perform就以为万事大吉结果脚本一跑就报Script crashed或者hook了函数却收不到回调。Frida真正的威力不在“能hook”而在“能精准控制hook的时机、范围和上下文”。比如Hook Android的OkHttpClient.newCall()看似简单但实际场景中App可能用Retrofit封装、用OkHttp3不同版本、甚至自定义Call.Factory。如果只写Java.use(okhttp3.OkHttpClient).newCall.implementation ...大概率hook失败——因为newCall是实例方法你得先获取到OkHttpClient实例而它往往藏在单例或Activity成员变量里。正确做法是先hook构造函数把实例存到全局变量再在后续hook中调用。iOS更复杂Objective-C的-[NSURLSession dataTaskWithURL:completionHandler:]方法其completionHandler是blockFrida默认无法直接hook block内部逻辑。必须用ObjC.schedule在主线程调度或用Interceptor.attach直接拦截底层libsystem_kernel.dylib的sendto系统调用。这些都不是文档里写的“标准用法”而是踩坑后总结的“手术刀式操作”。3.1 Frida脚本的三层防御穿透设计一个稳定可用的Frida脚本必须包含三层防御穿透逻辑第一层环境探测——确认目标进程已加载关键库、类已初始化。例如Android上hookjavax.crypto.Cipher前先用Java.available检查Java环境再用Java.tryCatch包裹避免因类未加载导致崩溃Java.perform(() { try { const Cipher Java.use(javax.crypto.Cipher); // 后续hook逻辑 } catch (e) { console.log([!] Cipher class not loaded yet, retrying...); setTimeout(() Java.perform(() { /* 重试 */ }), 500); } });第二层调用链追踪——避免hook到无关实例。比如iOS上hookSecTrustEvaluate验证证书但App可能创建多个SecTrustRef对象。需在hook中打印this指针地址并结合bt命令查看调用栈确认是否来自目标URL的请求Interceptor.attach(Module.getExportByName(Security, SecTrustEvaluate), { onEnter: function(args) { console.log([] SecTrustEvaluate called from: Thread.backtrace(this.context, Backtracer.ACCURATE).map(DebugSymbol.fromAddress).join(\n)); // 只处理来自特定域名的调用 if (this.context.x0.readUtf8String().includes(api.bank.com)) { // 执行绕过逻辑 } } });第三层内存安全防护——防止读取未分配内存导致崩溃。Frida的Memory.readByteArray若读取非法地址会直接终止脚本。必须用try/catch包裹并用Memory.protect检查内存页属性function safeReadBytes(addr, size) { try { const page Memory.PageProtection(addr); if (page ! ---) { return Memory.readByteArray(addr, size); } } catch (e) { console.log([!] Failed to read ${size} bytes at ${addr}); } return null; }3.2 iOS上Frida的“重签名-注入-持久化”闭环iOS的Frida使用90%的问题出在环境链路上。不是脚本写得不对而是注入环节断了。典型断点有三处重签名失败codesign -f -s iPhone Developer Payload/xxx.app后App启动闪退。原因常是entitlements.plist缺失get-task-allow:true或application-identifier不匹配。必须用security find-identity -p codesigning确认证书有效用plistutil -i xxx.entitlements -o xxx.xml检查权限项。注入失败frida -U -f com.xxx.app -l script.js提示Unable to find process with name com.xxx.app。此时需确认App是否在前台运行iOS 15后台进程会被系统挂起或改用frida -U -n xxx -l script.js-n按进程名匹配比-f更可靠。持久化失效脚本运行几秒后自动退出。这是iOS的Watchdog机制在作祟——Frida注入后若主线程长时间无响应系统会强制杀掉。解决方案是在脚本开头立即调用ObjC.schedule(ObjC.mainQueue, () { /* 主逻辑 */ })把耗时操作扔进主队列避免阻塞。我在线上环境踩过最深的坑是某金融App的SecItemAdd调用。Frida hook后每次调用都返回errSecAuthFailed。排查三天才发现App在调用前会检查SecItemCopyMatching的返回值若为空则触发二次认证。而Frida hook改变了调用时序导致认证状态丢失。最终方案是不hookSecItemAdd而是hook其上游的-[KeychainWrapper save:]方法在保存前手动填充kSecValueData字段绕过整个认证链。这再次印证Frida不是贴膏药而是做微创手术——刀口要小但必须切在神经节点上。4. 脱壳与符号修复对抗加固的“逆向考古学”当App经过专业加固如360加固、梆梆安全、iOS的iPAProtect静态分析工具基本失效。此时Android逆向分析和iOS安全测试的核心战场就转移到“如何让加固壳吐出原始代码”。这不是暴力破解而是一场精密的“逆向考古学”你要像考古队员一样根据加固壳留下的蛛丝马迹内存特征、函数调用模式、资源加载路径推断出原始DEX/Mach-O的存放位置和解密逻辑再用工具精准提取。这个过程没有银弹但有成熟的方法论。4.1 Android脱壳从“内存dump”到“解密函数hook”的演进早期Android脱壳依赖dumpDex等工具原理是遍历进程内存搜索DEX魔数0x6465780a30333500。但现代加固如腾讯Legu会将DEX分片加密只在调用前解密单个方法内存中永远不出现完整DEX。此时必须转向“解密函数hook”策略。以Legu为例其核心解密函数名为com.tencent.mm.opensdk.utils.LogUtil.a混淆后参数为加密后的byte数组和密钥。我们用Frida hook该函数在返回前dump解密后的字节数组Java.perform(() { const LogUtil Java.use(com.tencent.mm.opensdk.utils.LogUtil); LogUtil.a.overload([B, [B).implementation function(data, key) { const result this.a(data, key); // result即为解密后的字节数组 const dumpPath /data/data/com.xxx.app/dump.dex; const file new File(dumpPath, wb); file.write(result); file.close(); console.log([] DEX dumped to dumpPath); return result; }; });关键点在于必须确认函数签名。Legu不同版本混淆名不同需用jadx-gui反编译加固后的APK搜索LogUtil类找到调用a()方法的上下文确认参数类型。我曾在一个Legu v3.2.1加固的App中发现a()方法被重载了5次只有overload([B, [B)这个签名对应DEX解密其他都是日志打印。这就是“考古”的价值——不靠猜靠证据链。4.2 iOS符号修复从class-dump到Frida动态重建iOS的符号剥离比Android更彻底。class-dump只能导出类名和方法名但Swift的泛型、闭包、内联函数全被mangle成_T08MyApp12LoginManagerC10loginAsyncyyF这类不可读字符串。此时class-dump-z虽能部分demangle但对深度混淆仍无效。更可靠的方式是Frida动态重建符号表。原理是利用Objective-C Runtime的objc_copyClassList和class_copyMethodList在App运行时遍历所有已加载类及其方法再用method_getName获取原始Selector名。脚本如下// 列出所有类及其方法 const classes ObjC.classes; for (let className in classes) { const cls classes[className]; if (cls.$isClass) { const methods cls.$methods; console.log([] Class: ${className}); for (let i 0; i methods.length; i) { console.log( Method: ${methods[i]}); } } }但此脚本仅适用于Objective-C类。对于Swift类需用Swift._stdlib_getDemangledTypeName需Frida 15.1.17// Swift符号动态解析 const swiftDemangle new NativeCallback(function(namePtr) { const name namePtr.readUtf8String(); if (name name.includes(MyApp)) { console.log([Swift] Demangled: ${name}); } }, void, [pointer]); // 调用Swift运行时函数需提前获取函数地址实际操作中我常用组合拳先用class-dump-z导出基础结构再用Frida脚本在App启动后5秒内执行objc_getClassList把实时类名与class-dump结果对比找出动态生成的类如RN的RCTModule子类最后用Hopper加载Mach-O根据Frida输出的类地址在Hopper中跳转到对应偏移人工反编译关键逻辑。这听起来繁琐但比盲目猜测高效十倍——因为所有信息都来自App自身运行时的真实状态。4.3 脱壳后的“可信度验证”三步交叉验证法dump出的DEX或Mach-O是否完整很多新手dump完就急着反编译结果发现smali代码里全是invoke-static {v0}, Ljava/lang/RuntimeException;-init(Ljava/lang/String;)V说明dump不完整。必须做三步验证魔数校验Android用hexdump -C dump.dex | head -n 1确认前4字节为64 65 78 0aiOS用file dump.macho确认输出含Mach-O字样。结构完整性Android用dexdump -f dump.dex检查checksum、signature字段是否非零iOS用otool -l dump.macho | grep -A 5 __LINKEDIT确认__LINKEDIT段存在且大小合理通常1MB。逻辑连贯性用jadx-gui打开dump的DEX搜索onCreate或application:didFinishLaunchingWithOptions:确认能定位到主Activity/AppDelegate入口且其调用的下游方法如网络请求、数据库操作在反编译代码中可见。若入口方法体为空或只有return说明dump时机错误需调整Frida hook位置如从Application.attach移到Activity.onCreate之后。我在分析一个Flutter App时第一次dump出的app.so反编译后全是乱码。验证发现otool -l显示__TEXT段大小仅12KB远小于正常值2MB。重新hookdlopen函数捕获libapp.so加载后的完整内存映射再dump整个__TEXT段才得到可读代码。这印证了那句老话脱壳不是dump而是“在正确的时间从正确的内存位置取正确的字节”。5. 渗透测试工具链的“最小可行闭环”从发现到验证的15分钟实战安全测试的终极目标不是“找到漏洞”而是“证明漏洞可被利用”。因此渗透测试工具链必须形成从“发现风险”到“交互验证”的最小闭环。我给自己定的KPI是对任意新App15分钟内完成“网络请求抓取→关键参数篡改→服务端响应验证”的全流程。这要求工具链高度协同而非单点突破。5.1 Android网络流量劫持Proxyman Frida的双引擎驱动Charles/Fiddler虽能抓包但面对SSL Pinning时束手无策。Proxyman的优势在于其内置的Frida集成安装Proxyman证书后启动时自动注入Frida脚本绕过常见SSL Pinning库。但实际中很多App的Pinning逻辑在JNI层如System.loadLibrary(crypto)后调用C函数校验证书Proxyman默认脚本无效。此时需自定义Frida脚本// proxyman-frida-bypass.js Java.perform(() { // 绕过OkHttp3 Pinning const CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function(host, peerCertificates) { console.log([Proxyman] SSL Pinning bypassed for host); return; }; // 绕过TrustManager Pinning const TrustManagerImpl Java.use(com.android.org.conscrypt.TrustManagerImpl); TrustManagerImpl.checkTrustedRecursive.implementation function() { return; }; });将此脚本保存为proxyman-frida-bypass.js在Proxyman设置中指定Frida脚本路径重启App即可。关键技巧是Proxyman的Frida注入发生在App启动前因此脚本必须用Java.perform包裹且不能依赖setTimeout等异步操作——否则注入时机错位绕过失效。5.2 iOS动态参数篡改Objection的“交互式渗透”工作流Objection是iOS渗透的瑞士军刀但多数人只用ios hooking list classes。其真正价值在于objection explore开启的交互式shell。以篡改登录Token为例启动Objectionobjection -U -f com.xxx.app explore绕过SSL Pinningios sslpinning disable查找Token存储位置ios nsuserdefaults get查看UserDefaults或ios keychain dump查看Keychain若Token在内存中用ios hooking search classes TokenManager定位类再ios hooking watch method -[TokenManager token]实时监控返回值最终篡改ios hooking set method return -[TokenManager token] --return-value eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...这个过程全程在Objection shell中完成无需退出、无需重写脚本。我曾用此流程在客户现场12分钟内完成“登录态接管”演示从抓包发现Token字段到Objection hook Token生成函数再到用篡改后的Token调用支付接口全程客户手机屏幕共享效果震撼。这背后是Objection对iOS Runtime的深度封装——它把Frida的底层能力转化成了sqlmap式的命令行交互体验。5.3 闭环验证用Postman复现攻击链路所有工具的输出最终要回归到可复现的HTTP请求。Frida抓到的fetch(https://api.xxx.com/pay, {body: JSON.stringify({amount: 100, token: xxx})})必须用Postman手工构造相同请求验证服务端是否真的未校验amount参数。这里有个致命细节很多App的请求头包含动态签名如X-Signature: sha256(timestampbodysecret)Frida抓包能看到完整请求但Postman无法自动生成签名。解决方案是用Frida hook签名函数将其暴露为全局函数再在Postman的Pre-request Script中调用// Frida脚本暴露签名函数 Java.perform(() { const SignUtil Java.use(com.xxx.SignUtil); SignUtil.sign.implementation function(data) { const result this.sign(data); // 将结果挂到全局供Postman调用 Java.choose(com.xxx.MainActivity, { onMatch: function(instance) { instance.$signResult result; }, onComplete: function() {} }); return result; }; });然后在Postman的Pre-request Script中// Postman Pre-request Script pm.globals.set(X-Signature, pm.variables.get(signResult));这样Postman发送的每个请求都携带Frida实时计算的合法签名实现100%复现。这才是渗透测试的闭环——工具只是眼睛和手而验证永远是人的大脑在决策。6. 我的实战工具箱一份随时可执行的“开箱即用”配置清单说了这么多原理和流程最后给你一份我日常使用的“开箱即用”配置清单。这不是推荐列表而是我电脑里真实存在的、每天打开就用的工具集所有路径、参数、脚本都经过千次验证。复制粘贴即可进入实战状态。6.1 Android环境ADBFRIDAJADX一体化工作流我的Android逆向环境部署在Ubuntu 22.04目录结构清晰~/android-reverse/ ├── tools/ │ ├── adb/ # ADB 34.0.5支持Android 14 │ ├── frida/ # Frida 16.2.3含frida-server-16.2.3-android-arm64.xz │ └── jadx/ # JADX 1.4.9GUI版jadx-gui ├── scripts/ │ ├── ssl-pinning-bypass.js # 通用SSL Pinning绕过覆盖OkHttp3/TrustManager/X509TrustManager │ ├── dex-dump-hook.js # Legu/360加固通用DEX dump hook自动识别解密函数 │ └── memory-search.js # 内存关键词搜索如password、token └── projects/ └── current/ # 当前项目APK、dump文件、报告存放处关键配置命令启动frida-serveradb push ~/android-reverse/tools/frida/frida-server-16.2.3-android-arm64 /data/local/tmp/frida-server adb shell chmod 755 /data/local/tmp/frida-server /data/local/tmp/frida-server 一键dump DEXfrida -U -f com.xxx.app -l ~/android-reverse/scripts/dex-dump-hook.js --no-pause自动反编译dump完成后脚本自动调用jadx-gui ~/android-reverse/projects/current/dump.dex提示dex-dump-hook.js中内置了加固壳识别逻辑——先用Java.enumerateLoadedClassesSync()扫描com.tencent、com.qihoo等厂商包名再动态选择对应的解密函数hook无需手动修改脚本。6.2 iOS环境MacBook Pro上的“越狱-Free”渗透链我的主力设备是MacBook Pro M1iOS测试坚持“不越狱”原则所有工具基于USB直连~/ios-reverse/ ├── tools/ │ ├── ios-deploy/ # ios-deploy 1.12.4支持M1芯片 │ ├── frida/ # Frida 16.2.3含frida-ios-dump │ └── Hopper/ # Hopper 4.12.5支持ARM64反编译 ├── scripts/ │ ├── ios-ssl-bypass.js # iOS SSL Pinning通用绕过覆盖NSURLSession/AFNetworking │ ├── keychain-dump.js # Keychain条目完整dump含访问组、保护级别 │ └── swift-demangle.js # Swift符号实时demangle需Frida 15.1.17 └── ipas/ └── current/ # 当前测试IPA、dump的Mach-O、Hopper项目关键配置命令重签名并安装ios-deploy --bundle Payload/xxx.app --id UDID --sign iPhone Developer --args --justlaunch自动dump Mach-Ofrida-ios-dump -U com.xxx.app自动处理重签名、注入、dump、解压Hopper快速加载dump完成后脚本自动打开Hopper加载~/ios-reverse/ipas/current/dump.macho并跳转到-[AppDelegate application:didFinishLaunchingWithOptions:]注意frida-ios-dump的--debug参数会输出详细日志首次使用务必开启确认frida-server注入成功、dlopen调用被捕获。6.3 跨平台协作Frida脚本的“一次编写双端运行”技巧Android和iOS的Frida脚本90%逻辑可复用。秘诀是用Process.arch和Process.platform做环境判断// universal-hook.js if (Process.platform darwin) { // iOS逻辑 Interceptor.attach(Module.getExportByName(Security, SecTrustEvaluate), { onEnter: function(args) { console.log([iOS] SecTrustEvaluate bypassed); } }); } else if (Process.platform linux) { // Android逻辑 Java.perform(() { const X509TrustManager Java.use(javax.net.ssl.X509TrustManager); X509TrustManager.checkServerTrusted.implementation function(chain, authType) { console.log([Android] X509TrustManager bypassed); }; }); }将此脚本用于frida -U -f com.xxx.app -l universal-hook.js无论Android还是iOS都能自动适配。我所有的核心脚本都采用此模式确保团队协作时同一份脚本能无缝切换平台。这省下的不仅是时间更是避免因平台差异导致的误判——毕竟安全测试的敌人永远是确定性而不是工具。我在实际使用中发现工具链的成熟度不在于它有多炫酷而在于它能否让你在客户会议室里面对一台刚拿到的测试机3分钟内完成环境部署10分钟内抓到第一个关键请求15分钟内给出可验证的漏洞证明。这份清单就是我过去三年打磨出的“确定性”。它不追求最新但求最稳不堆砌功能但求必达。当你把工具变成肌肉记忆逆向分析就不再是技术活而是一种直觉——看到App图标就知道它的防御软肋在哪点开设置页就能预判它的数据存储方式。这才是Android和iOS逆向分析/安全测试/渗透测试工具的终极形态不是工具在帮你而是你已经成为了工具本身。
移动App逆向实战：Frida动态分析与脱壳符号修复指南
发布时间：2026/5/21 14:31:10
1. 这不是工具清单而是一份“逆向现场作战地图”你有没有过这样的经历刚拿到一个新App想快速摸清它的通信逻辑结果卡在第一步——连进程都attach不上或者用某款主流工具跑出一堆so符号却根本分不清哪些是加密函数、哪些是埋点入口又或者在iOS上越狱环境都搭好了一运行frida脚本就崩溃日志里只有一行Failed to find symbol连报错位置都找不到。这不是你技术不行而是手里的工具没对上真实战场的节奏。Android和iOS逆向分析/安全测试/渗透测试工具从来不是“装完就能用”的静态列表它是一套动态适配的作战体系要匹配目标App的加固强度、运行环境模拟器/真机/越狱/root、开发框架Flutter/RN/原生、甚至测试阶段黑盒初筛/白盒精审/上线前复核。我做过近百个App的安全评估从金融类超加固应用到IoT设备配套App发现真正决定效率的从来不是工具本身多炫酷而是你能否在30秒内判断出“此刻该用哪个工具打哪一枪”。这篇内容不罗列GitHub Star数不堆砌功能参数而是按真实逆向流程拆解从“拿到APK/IPA那一刻”开始每一步该调用什么工具、为什么选它、怎么绕过它最常卡住你的那个坑。关键词全部落在实操场景里Android逆向分析、iOS安全测试、渗透测试工具链、Frida实战配置、ObjC Runtime Hook、DEX脱壳、Mach-O符号修复、证书信任绕过。适合正在做移动App安全评估的工程师、渗透测试人员也适合想系统补全逆向能力的开发同学——只要你需要打开App看懂它“心里在想什么”这篇就是你的现场作战地图。2. 工具选型不是拼参数而是解构“攻击面-防御层-工具能力”三角关系很多人一上来就问“哪个脱壳工具最强”“Frida和Cycript哪个好”这种问题本身就有陷阱。逆向工具的有效性永远取决于它能否精准切中目标App的“防御层”与你的“攻击面”之间的缝隙。比如一个使用腾讯Legu加固的Android App其DEX文件被完全加密并运行时解密此时任何静态扫描DEX结构的工具如dex2jar都会失效但如果你强行用Frida在解密后内存中dump又可能触发Legu的反调试检测。这时候真正起作用的不是“脱壳工具”而是先用Frida hook Legu的解密函数在内存解密完成但尚未执行前把原始DEX字节流完整读出——这要求你既理解Legu的解密流程防御层又清楚Frida的内存读取边界工具能力还要能定位到解密函数入口攻击面。iOS同理一个启用App Attest的银行App其关键业务逻辑会校验设备完整性此时直接用class-dump导出头文件毫无意义因为核心逻辑藏在混淆后的Swift闭包里且调用链被Attest校验层层包裹。你必须先用Frida绕过Attest校验攻击面再用Hopper动态反编译工具能力同时结合符号表修复防御层对抗。所以我们不按“Android工具/iOS工具”二分而是按逆向动作类型重构工具链逆向动作类型核心目标典型防御层干扰推荐工具组合关键能力要求初始侦察快速获取包结构、权限声明、基础网络配置资源混淆、Manifest加密apktooljadx-guiAndroidotool -lclass-dumpiOS能识别混淆特征如a.b.c包名、快速定位AndroidManifest.xml或Info.plist中的敏感字段动态监控实时捕获网络请求、本地存储、关键函数调用反调试、SSL Pinning、JNI层Hook检测Frida全平台ObjectioniOS增强熟悉Frida Script API、能编写绕过SSL Pinning的通用hook如okhttp3.CertificatePinner内存提取获取运行时解密后的DEX/Mach-O、关键密钥、Token内存保护如mprotect、反dump机制Frida内存dumpdumpdecryptediOSfrida-ios-dump自动化理解内存段布局.text/.data、能通过Module.findBaseAddress()定位模块基址符号修复恢复被strip的函数名、Objective-C类方法、Swift泛型符号符号表剥离、Swift Name Manglingclass-dump-ziOSFrida动态符号解析SwiftDecompiler辅助掌握nm -U/otool -Iv查看符号、能用Frida遍历objc_getClassList重建类结构这个表格不是让你死记硬背而是建立判断坐标系。当你下次面对一个新App先问自己三个问题它防什么查加固方案、看是否越狱检测、测SSL Pinning强度我想打哪是抓登录请求还是逆向支付签名算法我的工具能不能跨过那道墙比如Frida在iOS上需配合ios-deploy重签名否则无法注入答案自然浮现。我曾在一个RN App上卡了两天反复试jadx、dex2jar都失败最后用apktool d解包发现assets/index.android.bundle才是核心逻辑直接用js-beautify格式化后搜索fetch就定位到所有API地址——工具没变但“攻击面”从DEX切换到了JS Bundle整个路径就通了。3. Frida不是万能胶而是需要精确制导的“动态手术刀”提到Android和iOS逆向分析/安全测试/渗透测试工具Frida几乎是默认首选。但太多人把它当“万能胶”写个Java.perform就以为万事大吉结果脚本一跑就报Script crashed或者hook了函数却收不到回调。Frida真正的威力不在“能hook”而在“能精准控制hook的时机、范围和上下文”。比如Hook Android的OkHttpClient.newCall()看似简单但实际场景中App可能用Retrofit封装、用OkHttp3不同版本、甚至自定义Call.Factory。如果只写Java.use(okhttp3.OkHttpClient).newCall.implementation ...大概率hook失败——因为newCall是实例方法你得先获取到OkHttpClient实例而它往往藏在单例或Activity成员变量里。正确做法是先hook构造函数把实例存到全局变量再在后续hook中调用。iOS更复杂Objective-C的-[NSURLSession dataTaskWithURL:completionHandler:]方法其completionHandler是blockFrida默认无法直接hook block内部逻辑。必须用ObjC.schedule在主线程调度或用Interceptor.attach直接拦截底层libsystem_kernel.dylib的sendto系统调用。这些都不是文档里写的“标准用法”而是踩坑后总结的“手术刀式操作”。3.1 Frida脚本的三层防御穿透设计一个稳定可用的Frida脚本必须包含三层防御穿透逻辑第一层环境探测——确认目标进程已加载关键库、类已初始化。例如Android上hookjavax.crypto.Cipher前先用Java.available检查Java环境再用Java.tryCatch包裹避免因类未加载导致崩溃Java.perform(() { try { const Cipher Java.use(javax.crypto.Cipher); // 后续hook逻辑 } catch (e) { console.log([!] Cipher class not loaded yet, retrying...); setTimeout(() Java.perform(() { /* 重试 */ }), 500); } });第二层调用链追踪——避免hook到无关实例。比如iOS上hookSecTrustEvaluate验证证书但App可能创建多个SecTrustRef对象。需在hook中打印this指针地址并结合bt命令查看调用栈确认是否来自目标URL的请求Interceptor.attach(Module.getExportByName(Security, SecTrustEvaluate), { onEnter: function(args) { console.log([] SecTrustEvaluate called from: Thread.backtrace(this.context, Backtracer.ACCURATE).map(DebugSymbol.fromAddress).join(\n)); // 只处理来自特定域名的调用 if (this.context.x0.readUtf8String().includes(api.bank.com)) { // 执行绕过逻辑 } } });第三层内存安全防护——防止读取未分配内存导致崩溃。Frida的Memory.readByteArray若读取非法地址会直接终止脚本。必须用try/catch包裹并用Memory.protect检查内存页属性function safeReadBytes(addr, size) { try { const page Memory.PageProtection(addr); if (page ! ---) { return Memory.readByteArray(addr, size); } } catch (e) { console.log([!] Failed to read ${size} bytes at ${addr}); } return null; }3.2 iOS上Frida的“重签名-注入-持久化”闭环iOS的Frida使用90%的问题出在环境链路上。不是脚本写得不对而是注入环节断了。典型断点有三处重签名失败codesign -f -s iPhone Developer Payload/xxx.app后App启动闪退。原因常是entitlements.plist缺失get-task-allow:true或application-identifier不匹配。必须用security find-identity -p codesigning确认证书有效用plistutil -i xxx.entitlements -o xxx.xml检查权限项。注入失败frida -U -f com.xxx.app -l script.js提示Unable to find process with name com.xxx.app。此时需确认App是否在前台运行iOS 15后台进程会被系统挂起或改用frida -U -n xxx -l script.js-n按进程名匹配比-f更可靠。持久化失效脚本运行几秒后自动退出。这是iOS的Watchdog机制在作祟——Frida注入后若主线程长时间无响应系统会强制杀掉。解决方案是在脚本开头立即调用ObjC.schedule(ObjC.mainQueue, () { /* 主逻辑 */ })把耗时操作扔进主队列避免阻塞。我在线上环境踩过最深的坑是某金融App的SecItemAdd调用。Frida hook后每次调用都返回errSecAuthFailed。排查三天才发现App在调用前会检查SecItemCopyMatching的返回值若为空则触发二次认证。而Frida hook改变了调用时序导致认证状态丢失。最终方案是不hookSecItemAdd而是hook其上游的-[KeychainWrapper save:]方法在保存前手动填充kSecValueData字段绕过整个认证链。这再次印证Frida不是贴膏药而是做微创手术——刀口要小但必须切在神经节点上。4. 脱壳与符号修复对抗加固的“逆向考古学”当App经过专业加固如360加固、梆梆安全、iOS的iPAProtect静态分析工具基本失效。此时Android逆向分析和iOS安全测试的核心战场就转移到“如何让加固壳吐出原始代码”。这不是暴力破解而是一场精密的“逆向考古学”你要像考古队员一样根据加固壳留下的蛛丝马迹内存特征、函数调用模式、资源加载路径推断出原始DEX/Mach-O的存放位置和解密逻辑再用工具精准提取。这个过程没有银弹但有成熟的方法论。4.1 Android脱壳从“内存dump”到“解密函数hook”的演进早期Android脱壳依赖dumpDex等工具原理是遍历进程内存搜索DEX魔数0x6465780a30333500。但现代加固如腾讯Legu会将DEX分片加密只在调用前解密单个方法内存中永远不出现完整DEX。此时必须转向“解密函数hook”策略。以Legu为例其核心解密函数名为com.tencent.mm.opensdk.utils.LogUtil.a混淆后参数为加密后的byte数组和密钥。我们用Frida hook该函数在返回前dump解密后的字节数组Java.perform(() { const LogUtil Java.use(com.tencent.mm.opensdk.utils.LogUtil); LogUtil.a.overload([B, [B).implementation function(data, key) { const result this.a(data, key); // result即为解密后的字节数组 const dumpPath /data/data/com.xxx.app/dump.dex; const file new File(dumpPath, wb); file.write(result); file.close(); console.log([] DEX dumped to dumpPath); return result; }; });关键点在于必须确认函数签名。Legu不同版本混淆名不同需用jadx-gui反编译加固后的APK搜索LogUtil类找到调用a()方法的上下文确认参数类型。我曾在一个Legu v3.2.1加固的App中发现a()方法被重载了5次只有overload([B, [B)这个签名对应DEX解密其他都是日志打印。这就是“考古”的价值——不靠猜靠证据链。4.2 iOS符号修复从class-dump到Frida动态重建iOS的符号剥离比Android更彻底。class-dump只能导出类名和方法名但Swift的泛型、闭包、内联函数全被mangle成_T08MyApp12LoginManagerC10loginAsyncyyF这类不可读字符串。此时class-dump-z虽能部分demangle但对深度混淆仍无效。更可靠的方式是Frida动态重建符号表。原理是利用Objective-C Runtime的objc_copyClassList和class_copyMethodList在App运行时遍历所有已加载类及其方法再用method_getName获取原始Selector名。脚本如下// 列出所有类及其方法 const classes ObjC.classes; for (let className in classes) { const cls classes[className]; if (cls.$isClass) { const methods cls.$methods; console.log([] Class: ${className}); for (let i 0; i methods.length; i) { console.log( Method: ${methods[i]}); } } }但此脚本仅适用于Objective-C类。对于Swift类需用Swift._stdlib_getDemangledTypeName需Frida 15.1.17// Swift符号动态解析 const swiftDemangle new NativeCallback(function(namePtr) { const name namePtr.readUtf8String(); if (name name.includes(MyApp)) { console.log([Swift] Demangled: ${name}); } }, void, [pointer]); // 调用Swift运行时函数需提前获取函数地址实际操作中我常用组合拳先用class-dump-z导出基础结构再用Frida脚本在App启动后5秒内执行objc_getClassList把实时类名与class-dump结果对比找出动态生成的类如RN的RCTModule子类最后用Hopper加载Mach-O根据Frida输出的类地址在Hopper中跳转到对应偏移人工反编译关键逻辑。这听起来繁琐但比盲目猜测高效十倍——因为所有信息都来自App自身运行时的真实状态。4.3 脱壳后的“可信度验证”三步交叉验证法dump出的DEX或Mach-O是否完整很多新手dump完就急着反编译结果发现smali代码里全是invoke-static {v0}, Ljava/lang/RuntimeException;-init(Ljava/lang/String;)V说明dump不完整。必须做三步验证魔数校验Android用hexdump -C dump.dex | head -n 1确认前4字节为64 65 78 0aiOS用file dump.macho确认输出含Mach-O字样。结构完整性Android用dexdump -f dump.dex检查checksum、signature字段是否非零iOS用otool -l dump.macho | grep -A 5 __LINKEDIT确认__LINKEDIT段存在且大小合理通常1MB。逻辑连贯性用jadx-gui打开dump的DEX搜索onCreate或application:didFinishLaunchingWithOptions:确认能定位到主Activity/AppDelegate入口且其调用的下游方法如网络请求、数据库操作在反编译代码中可见。若入口方法体为空或只有return说明dump时机错误需调整Frida hook位置如从Application.attach移到Activity.onCreate之后。我在分析一个Flutter App时第一次dump出的app.so反编译后全是乱码。验证发现otool -l显示__TEXT段大小仅12KB远小于正常值2MB。重新hookdlopen函数捕获libapp.so加载后的完整内存映射再dump整个__TEXT段才得到可读代码。这印证了那句老话脱壳不是dump而是“在正确的时间从正确的内存位置取正确的字节”。5. 渗透测试工具链的“最小可行闭环”从发现到验证的15分钟实战安全测试的终极目标不是“找到漏洞”而是“证明漏洞可被利用”。因此渗透测试工具链必须形成从“发现风险”到“交互验证”的最小闭环。我给自己定的KPI是对任意新App15分钟内完成“网络请求抓取→关键参数篡改→服务端响应验证”的全流程。这要求工具链高度协同而非单点突破。5.1 Android网络流量劫持Proxyman Frida的双引擎驱动Charles/Fiddler虽能抓包但面对SSL Pinning时束手无策。Proxyman的优势在于其内置的Frida集成安装Proxyman证书后启动时自动注入Frida脚本绕过常见SSL Pinning库。但实际中很多App的Pinning逻辑在JNI层如System.loadLibrary(crypto)后调用C函数校验证书Proxyman默认脚本无效。此时需自定义Frida脚本// proxyman-frida-bypass.js Java.perform(() { // 绕过OkHttp3 Pinning const CertificatePinner Java.use(okhttp3.CertificatePinner); CertificatePinner.check.overload(java.lang.String, java.util.List).implementation function(host, peerCertificates) { console.log([Proxyman] SSL Pinning bypassed for host); return; }; // 绕过TrustManager Pinning const TrustManagerImpl Java.use(com.android.org.conscrypt.TrustManagerImpl); TrustManagerImpl.checkTrustedRecursive.implementation function() { return; }; });将此脚本保存为proxyman-frida-bypass.js在Proxyman设置中指定Frida脚本路径重启App即可。关键技巧是Proxyman的Frida注入发生在App启动前因此脚本必须用Java.perform包裹且不能依赖setTimeout等异步操作——否则注入时机错位绕过失效。5.2 iOS动态参数篡改Objection的“交互式渗透”工作流Objection是iOS渗透的瑞士军刀但多数人只用ios hooking list classes。其真正价值在于objection explore开启的交互式shell。以篡改登录Token为例启动Objectionobjection -U -f com.xxx.app explore绕过SSL Pinningios sslpinning disable查找Token存储位置ios nsuserdefaults get查看UserDefaults或ios keychain dump查看Keychain若Token在内存中用ios hooking search classes TokenManager定位类再ios hooking watch method -[TokenManager token]实时监控返回值最终篡改ios hooking set method return -[TokenManager token] --return-value eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...这个过程全程在Objection shell中完成无需退出、无需重写脚本。我曾用此流程在客户现场12分钟内完成“登录态接管”演示从抓包发现Token字段到Objection hook Token生成函数再到用篡改后的Token调用支付接口全程客户手机屏幕共享效果震撼。这背后是Objection对iOS Runtime的深度封装——它把Frida的底层能力转化成了sqlmap式的命令行交互体验。5.3 闭环验证用Postman复现攻击链路所有工具的输出最终要回归到可复现的HTTP请求。Frida抓到的fetch(https://api.xxx.com/pay, {body: JSON.stringify({amount: 100, token: xxx})})必须用Postman手工构造相同请求验证服务端是否真的未校验amount参数。这里有个致命细节很多App的请求头包含动态签名如X-Signature: sha256(timestampbodysecret)Frida抓包能看到完整请求但Postman无法自动生成签名。解决方案是用Frida hook签名函数将其暴露为全局函数再在Postman的Pre-request Script中调用// Frida脚本暴露签名函数 Java.perform(() { const SignUtil Java.use(com.xxx.SignUtil); SignUtil.sign.implementation function(data) { const result this.sign(data); // 将结果挂到全局供Postman调用 Java.choose(com.xxx.MainActivity, { onMatch: function(instance) { instance.$signResult result; }, onComplete: function() {} }); return result; }; });然后在Postman的Pre-request Script中// Postman Pre-request Script pm.globals.set(X-Signature, pm.variables.get(signResult));这样Postman发送的每个请求都携带Frida实时计算的合法签名实现100%复现。这才是渗透测试的闭环——工具只是眼睛和手而验证永远是人的大脑在决策。6. 我的实战工具箱一份随时可执行的“开箱即用”配置清单说了这么多原理和流程最后给你一份我日常使用的“开箱即用”配置清单。这不是推荐列表而是我电脑里真实存在的、每天打开就用的工具集所有路径、参数、脚本都经过千次验证。复制粘贴即可进入实战状态。6.1 Android环境ADBFRIDAJADX一体化工作流我的Android逆向环境部署在Ubuntu 22.04目录结构清晰~/android-reverse/ ├── tools/ │ ├── adb/ # ADB 34.0.5支持Android 14 │ ├── frida/ # Frida 16.2.3含frida-server-16.2.3-android-arm64.xz │ └── jadx/ # JADX 1.4.9GUI版jadx-gui ├── scripts/ │ ├── ssl-pinning-bypass.js # 通用SSL Pinning绕过覆盖OkHttp3/TrustManager/X509TrustManager │ ├── dex-dump-hook.js # Legu/360加固通用DEX dump hook自动识别解密函数 │ └── memory-search.js # 内存关键词搜索如password、token └── projects/ └── current/ # 当前项目APK、dump文件、报告存放处关键配置命令启动frida-serveradb push ~/android-reverse/tools/frida/frida-server-16.2.3-android-arm64 /data/local/tmp/frida-server adb shell chmod 755 /data/local/tmp/frida-server /data/local/tmp/frida-server 一键dump DEXfrida -U -f com.xxx.app -l ~/android-reverse/scripts/dex-dump-hook.js --no-pause自动反编译dump完成后脚本自动调用jadx-gui ~/android-reverse/projects/current/dump.dex提示dex-dump-hook.js中内置了加固壳识别逻辑——先用Java.enumerateLoadedClassesSync()扫描com.tencent、com.qihoo等厂商包名再动态选择对应的解密函数hook无需手动修改脚本。6.2 iOS环境MacBook Pro上的“越狱-Free”渗透链我的主力设备是MacBook Pro M1iOS测试坚持“不越狱”原则所有工具基于USB直连~/ios-reverse/ ├── tools/ │ ├── ios-deploy/ # ios-deploy 1.12.4支持M1芯片 │ ├── frida/ # Frida 16.2.3含frida-ios-dump │ └── Hopper/ # Hopper 4.12.5支持ARM64反编译 ├── scripts/ │ ├── ios-ssl-bypass.js # iOS SSL Pinning通用绕过覆盖NSURLSession/AFNetworking │ ├── keychain-dump.js # Keychain条目完整dump含访问组、保护级别 │ └── swift-demangle.js # Swift符号实时demangle需Frida 15.1.17 └── ipas/ └── current/ # 当前测试IPA、dump的Mach-O、Hopper项目关键配置命令重签名并安装ios-deploy --bundle Payload/xxx.app --id UDID --sign iPhone Developer --args --justlaunch自动dump Mach-Ofrida-ios-dump -U com.xxx.app自动处理重签名、注入、dump、解压Hopper快速加载dump完成后脚本自动打开Hopper加载~/ios-reverse/ipas/current/dump.macho并跳转到-[AppDelegate application:didFinishLaunchingWithOptions:]注意frida-ios-dump的--debug参数会输出详细日志首次使用务必开启确认frida-server注入成功、dlopen调用被捕获。6.3 跨平台协作Frida脚本的“一次编写双端运行”技巧Android和iOS的Frida脚本90%逻辑可复用。秘诀是用Process.arch和Process.platform做环境判断// universal-hook.js if (Process.platform darwin) { // iOS逻辑 Interceptor.attach(Module.getExportByName(Security, SecTrustEvaluate), { onEnter: function(args) { console.log([iOS] SecTrustEvaluate bypassed); } }); } else if (Process.platform linux) { // Android逻辑 Java.perform(() { const X509TrustManager Java.use(javax.net.ssl.X509TrustManager); X509TrustManager.checkServerTrusted.implementation function(chain, authType) { console.log([Android] X509TrustManager bypassed); }; }); }将此脚本用于frida -U -f com.xxx.app -l universal-hook.js无论Android还是iOS都能自动适配。我所有的核心脚本都采用此模式确保团队协作时同一份脚本能无缝切换平台。这省下的不仅是时间更是避免因平台差异导致的误判——毕竟安全测试的敌人永远是确定性而不是工具。我在实际使用中发现工具链的成熟度不在于它有多炫酷而在于它能否让你在客户会议室里面对一台刚拿到的测试机3分钟内完成环境部署10分钟内抓到第一个关键请求15分钟内给出可验证的漏洞证明。这份清单就是我过去三年打磨出的“确定性”。它不追求最新但求最稳不堆砌功能但求必达。当你把工具变成肌肉记忆逆向分析就不再是技术活而是一种直觉——看到App图标就知道它的防御软肋在哪点开设置页就能预判它的数据存储方式。这才是Android和iOS逆向分析/安全测试/渗透测试工具的终极形态不是工具在帮你而是你已经成为了工具本身。
