第一次接触Frida是我在分析某个内部测试App的登录流程时。静态反编译出来的代码东一块西一块混淆得一塌糊涂关键加密逻辑像隔了一层雾。后来有个朋友说别只盯静态试试动态注入。那是我第一次真正把Frida跑通——脚本注入进程实时打印加密函数的输入输出十几分钟就把整个流程理清楚了。从那以后Frida就成了我Android逆向工作流里离不开的常驻工具。Frida本质上是一个轻量级的hook框架核心能力是让脚本直接跑进目标进程动态地调用、修改、跟踪Java层和Native层的逻辑。抓包、算法定位、自动化解密、脱壳辅助、反调试对抗它都能干覆盖面相当广。这篇文章围绕Frida从环境搭建到动态分析的完整链路展开适合刚开始接触Android逆向的朋友也适合想了解Frida自动化分析思路的开发者。我会按照自己平时调试时最顺手的操作方式来写尽量少讲虚的多放能直接上手的步骤。1. 项目概述与整体思路先搞清楚Frida到底在干嘛1.1 Frida的核心原理注入、改写与回调Frida的架构可以粗略分成三块跑在目标设备上的frida-server、跑在PC端的命令行工具与Python绑定、以及通过JavaScript语法写的hook脚本。每次调试的时候PC端通过网络或USB通道和设备上的frida-server通信frida-server再把脚本注入到目标进程里执行。你可以把Frida理解成给手机App装的一个实时探针。进程在跑、内存里的数据在流动Frida可以随时在旁边看还能伸手改。跟静态反编译那种“把书撕开看字”的思路不同Frida是“跟着跑步的人一起看路线”看到的东西是活的准确得多。它默认用ptrace机制把代码注入进程然后和进程内的Agent建立通信通道之后你在PC端写的JavaScript就能在目标进程内部运行调用进程自己的函数、读内存、拦截调用全部实时生效。有个细节容易让人困惑Frida脚本运行时的回调是异步的。比如你在脚本里调用Java层的函数其实是通过Frida自身的Bridge层转成消息发给主线程去执行再异步把结果拿回来。理解了这一点后面遇到脚本卡住、回调不触发的时候排查思路就会清晰不少。1.2 动态分析相对静态分析的价值静态分析和动态分析不是替代关系更像两种互补的侦察方式。静态分析适合看整体结构和控制流动态分析适合捕捉运行时真实行为。很多场景下静态分析会卡在混淆和加固上类名和字段名全都变成无意义的字母字符串加密控制流被打散。这时候你很难单纯靠读代码还原出逻辑。而动态分析是另一条路——你直接看函数在真实环境里被谁调用、传了什么参数、返回了什么结果这些数据是绕不开的。这里有一个对比表是我每次给新人解释时都会贴的维度静态分析动态分析分析对象smali、Java伪代码、so文件反汇编运行中的进程状态与行为核心工具jadx、GDA、IDA、GhidraFrida、调试器、抓包工具对抗混淆较弱被抹黑后就难读强直接观测真实调用获取真相间接推断直接观察参数与返回值上手成本需懂字节码与汇编慢脚本语法简单快局限性逻辑复杂时容易漏需要目标真正跑起来在实际项目中我一般先用jadx看一遍整体结构知道大概有哪些类、哪些方法然后用Frida动态验证关键部分。两者配合起来效率比单打独斗高很多。1.3 Frida能覆盖的典型场景Frida的应用场景大概可以分成五类。第一类是接口与数据结构还原比如App的私有协议参数怎么生成、某个头部字段怎么拼接。第二类是算法定位与还原比如找到加密函数、打印明文和密文、拿到key和iv。第三类是Native层调试hook so文件里的导出函数查看传入的JNI环境参数。第四类是脱壳辅助在运行时把内存中已经加载并且解密了的dex文件dump出来。第五类是自动化测试与爬虫把Frida脚本写成服务批量跑接口、批量验证数据。这五类场景最常用也最容易上手的是第二类。所以文章后面会用一整节讲实战案例演示怎么从抓包到定位加密入口再到主动调用还原算法。2. 环境搭建PC端、移动端与版本管理2.1 Python端与frida-tools的安装宿主机环境准备很简单只要电脑上有Python和pip直接安装就行pip install frida-tools装完之后在命令行里敲frida --version能看到一串版本号。这里有个重要概念frida-tools是命令行工具包它依赖的frida模块才是真正和frida-server对接的组件。很多安装教程只提一句“pip install frida-tools”但忽略了底层frida模块的版本后面连接时就会出现版本不匹配的报错。我习惯先把版本信息确认好frida --version这个命令输出的就是当前PC端frida模块的版本。记住这个数字后面下载frida-server要选相同版本。补充说一句如果你用的是虚拟环境注意保证Python环境路径没问题。不同项目共用一个全局环境容易互相污染建议为Frida单独建一个venv。2.2 设备端frida-server的部署目标设备上需要跑一个frida-server进程它是与PC端通信的“网关”。下载时要注意CPU架构选错了直接跑不起来。设备类型常见架构对应文件名关键词主流手机arm64arm64-v8a或arm64老款32位手机armeabi-v7aarm模拟器x86_64x86_64或amd64把frida-server推送到设备上然后设置执行权限并启动adb push frida-server /data/local/tmp/ adb shell chmod 755 /data/local/tmp/frida-server adb shell su /data/local/tmp/frida-server 启动后不要关闭终端或者用nohup挂到后台。真机上如果root权限给了frida-server就能枚举所有进程没root的话只能操作当前用户权限范围内的内容很多分析场景会受限。有个小技巧我会把frida-server改名成随机的字符串比如fdserv再放到/data/local/tmp下。因为很多App的反调试检测会按名字查找frida-server进程改名能降低被发现的概率。虽然不绝对但总比把默认名字暴露在外面省心。2.3 USB连接与端口转发的坑设备端、PC端都准备好了下一步是建立连接。最传统的方式是用USB线连接然后执行adb命令确认设备在线adb devices接着做端口转发。frida-server默认监听设备上的27042端口PC端就是通过这个端口通信的adb forward tcp:27042 tcp:27042转发完成后用以下命令测试PC端能否看到设备上的进程frida-ps -U-U的意思是USB设备。如果能看到进程列表说明环境已经通了。输出了类似“PID 名字”的列表就可以用frida-ps -U -a查看设备上所有已安装应用。这里有个季节性踩坑USB连接有时候会不稳电脑休眠一次后再执行frida-ps大概率会报连接失败。多拔插一次USB重新执行adb forward就行。模拟器环境更特殊有的模拟器有几个不同的adb端口要选对运行中的那一个。2.4 常见错误版本不一致与权限不足环境搭建阶段有一半的坑都集中在版本不一致上。PC端frida模块的版本是A设备端frida-server的版本是BA和B差太多时连接会报类似“incompatible version”的错误。再强调一次版本匹配原则很简单PC端frida --version显示多少设备端就放相同版本的frida-server。frida-tools的版本不需要和frida模块一致它只是命令行的封装。如果后面用到gadgetgadget的版本也要保持一致。权限不足的问题也常见。比如启动frida-server时没带root执行frida-ps -U可能能看到进程但加载脚本的时候报“failed to list processes: permission denied”。这种情况去确认当前终端是否真有su权限或者frida-server是否运行在root状态。3. 核心技能用Frida脚本Hook Java与Native逻辑3.1 注入目标进程的三种姿势Frida提供三种注入方式分别是attach、spawn和gadget。attach模式附加到已经运行起来的进程上。特点是快速目标进程已经跑完初始化逻辑你可以直接hook现有类。缺点是启动阶段的方法可能已经执行完了想观察启动逻辑就抓不到。spawn模式是冷启动目标App并注入。它在进程刚开始加载的时候就介入适合分析App启动流程、早期初始化、存活检测等逻辑。命令格式是frida -U -f 包名 -l 脚本.js-f表示通过spawn模式启动。gadget模式是直接改App安装包把frida的so文件塞进去。它适合非root环境但重打包涉及签名问题操作复杂度更高。我平时在root环境下主要用前两种gadget更多用于特殊场景比如没有root的模拟器。三种模式的对比注入方式是否需要root是否能观察启动阶段典型命令attach是否frida -U 进程名spawn是是frida -U -f 包名 -l 脚本gadget否是修改so并重打包3.2 Hook Java方法Java.use与implementation这是Frida最常用的操作。目标App里有一个类com.example.demo.MainActivity里面有个加密方法encrypt(String input)。用下面这段脚本就能把它的参数和返回值都打印出来Java.perform(function () { var target Java.use(com.example.demo.MainActivity); target.encrypt.implementation function (input) { console.log([*] input input); var result this.encrypt(input); console.log([*] result result); return result; }; });这段脚本做了三件事通过Java.use拿到目标类把encrypt方法替换成我的实现在实现里调用原始方法并打印数据。注意包名、类名、方法名必须与App内一致区分大小写。我遇到最多的问题是方法名写错或类名写错Frida会直接报ClassNotFoundException。还有一种情况是方法存在但签名不匹配尤其是方法重载时必须用overload来指定具体类型。处理重载的标准写法var target Java.use(com.example.demo.Cryptor); target.aesEncrypt.overloads.forEach(function (overload) { overload.implementation function () { var args Array.prototype.slice.call(arguments); console.log(args: args.join(, )); return this.aesEncrypt.apply(this, arguments); }; });overloads能拿到该方法的全部重载版本然后分别给每个重载设置implementation这样不管外部调用的是哪个版本都能被统一拦到。打印参数时用arguments对象收集所有入参是最稳妥的方式。3.3 常用API枚举类、选择实例、修改返回值有些时候目标对象不是一个静态调用需要先找到实际运行的实例。Java.choose可以遍历在堆中存活的对象Java.perform(function () { Java.choose(com.example.demo.CacheManager, { onMatch: function (instance) { console.log(found instance: instance); console.log(current key: instance.getCacheKey()); }, onComplete: function () { console.log(scan done); } }); });这个API在处理动态生成的类时特别好用。App里的某个数据结构不是单例可能生成了好几个对象用Java.choose都能枚举出来然后挑一个实际正在使用的对象来观察。修改返回值也很常见。比如某个App有个会员判断方法isVip()想在分析时把它当作vip处理直接target.isVip.implementation function () { return true; };但这里提醒一句修改返回值影响的是当前进程下的运行状态并不能真正改掉服务器端的鉴权逻辑。分析过程中临时改变客户端行为是可以的但别把这当最终手段该还原协议还是得还原协议。3.4 深入Native层Interceptor与导出函数很多App的核心逻辑会移到so文件里Java层只留一个native方法外壳。这时需要直接对Native函数下手。假设目标so是libdemo.so里面有一个导出函数Java_com_example_demo_MainActivity_nativeEncryptfunction hookNative() { var lib Process.findModuleByName(libdemo.so); if (!lib) { console.log(libdemo.so not found); return; } var addr Module.findExportByName(libdemo.so, Java_com_example_demo_MainActivity_nativeEncrypt); if (addr) { Interceptor.attach(addr, { onEnter: function (args) { console.log(arg0: args[0]); console.log(hexdump(args[1])); }, onLeave: function (retval) { console.log(ret: retval); } }); } } setImmediate(hookNative);注意native方法的第一个参数是JNIEnv*第二个是jobject真正的业务参数从第三个开始。所以在外层看到args[0]、args[1]是JNI指针不要误当作业务参数。hexdump(args[1])打印的是JNI层传入的字符串或对象地址对应的内存内容要结合参数含义去看。如果函数没被导出可以在Process.findModuleByName拿到模块基址后加上静态分析得到的偏移量var base Process.findModuleByName(libdemo.so).base; Interceptor.attach(base.add(0x1234), { onEnter: function (args) { console.log(hexdump(args[0])); }, onLeave: function (retval) { console.log(ret: retval); } });偏移量可以在反汇编工具里查计算时注意是相对模块基址的偏移别直接用绝对地址。3.5 主动调用与伪造参数动态拼出你想要的密文Hook只是实时观察还有一种场景是主动调用。比如你想验证某个加密算法的key和iv直接让目标App生成一段加密结果不必手动复刻算法逻辑。Java.perform(function () { var Cryptor Java.use(com.example.demo.Cryptor); var result Cryptor.aesEncrypt(password123, 0123456789abcdef, 0123456789abcdef); console.log(custom plaintext - ciphertext: result); });这里直接调用目标App自己的方法参数是我们自己构造的返回值就是正确算法下的密文。这个技巧在还原算法时极其有用不需要把AES密钥和iv硬编码到脚本里只需要在App运行环境内完成一次真实加密。使用Java.use主动调用静态方法时可以直接调如果是实例方法通常会先Java.choose拿到一个实例再在这个实例上调用目标方法。有些实例构造方法私有化了不方便直接new用Java.choose找一个存活实例是最简单的。4. 实战案例定位加密函数并自动化解密4.1 从接口数据到加密入口的定位思路我用一个虚构的“模拟项目X”来演示项目里有一个内部测试App登录框输密码后请求体长这样{ username: test, password: 9f617e53734dcae8e7f31c1a3b27eb4c9d6b4f8db8a5c3f8ab9d7c6e }密码那串是16进制很明显不是明文。常规的抓包工具只能看到这个结果但看不到加密过程。于是定位思路变成找到处理“密码加密”的方法。我习惯先静态粗略扫一遍看有没有类似Cipher、encrypt、md5、sha这样的关键词如果静态看不懂就直接用Frida批量hook所有常见的加密入口。第一个突破口通常是javax.crypto.Cipher。几乎所有的对称加密都会经过getInstance、init、doFinal这几个方法。直接hook它们的调用就能抓到算法类型、key和iv。4.2 快速定位加密算法hook敏感方法加调用堆栈写一个脚本把Cipher的几个关键方法都拦下来Java.perform(function () { var Cipher Java.use(javax.crypto.Cipher); Cipher.getInstance.overload(java.lang.String).implementation function (transformation) { console.log([*] Cipher.getInstance: transformation); var result this.getInstance(transformation); return result; }; Cipher.init.overload(int, java.security.Key, java.security.spec.AlgorithmParameterSpec).implementation function (opmode, key, params) { console.log([*] Cipher.init opmode: opmode); console.log([*] key class: key.getClass().getName()); if (params) { console.log([*] params: params); } return this.init(opmode, key, params); }; Cipher.doFinal.overload([B).implementation function (input) { console.log([*] doFinal input: hexdump(input)); var result this.doFinal(input); console.log([*] doFinal result: hexdump(result)); return result; }; });让App正常登录一次控制台输出会直接告诉我们算法是AES/CBC/PKCS5Padding密钥长度多少iv是什么明文和密文分别长什么样子。想进一步确认调用方是谁可以打印Java层调用栈var exception Java.use(java.lang.Exception); throw exception.$new(stack trace);在所有被hook的方法里插入这句话Frida就会把你的脚本伪装成一个异常抛出从而打印出执行栈。根据栈里的类名和方法名能快速找到真正的加密业务逻辑。4.3 还原key、iv并主动调用验证拿到key、iv之后不要急着写代码跳出App上下文。先在Frida里主动调用一遍确认自己掌握的参数是真的。Java.perform(function () { var Cipher Java.use(javax.crypto.Cipher); var SecretKeySpec Java.use(javax.crypto.spec.SecretKeySpec); var IvParameterSpec Java.use(javax.crypto.spec.IvParameterSpec); var key [0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38]; var iv [0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68]; var cipher Cipher.getInstance(AES/CBC/PKCS5Padding); cipher.init(1, SecretKeySpec.$new(Java.array(byte, key), AES), IvParameterSpec.$new(Java.array(byte, iv))); var result cipher.doFinal(Java.array(byte, [112, 97, 115, 115, 119, 111, 114, 100, 49, 50, 51])); console.log(ciphertext hex: JSON.stringify(result)); });如果输出的密文和抓包里看到的密文一致说明算法和参数都定位正确了。到这里这个案例的核心目标——还原加密流程已经完成。4.4 用Python编写自动化hook脚本批量输出日志命令行里右键复制控制台输出太费劲尤其当hook点很多、日志满天飞时。我更推荐用Python端接收Frida脚本里send()出来的数据统一写入文件。Python端示例import frida import sys script_code Java.perform(function () { var Cipher Java.use(javax.crypto.Cipher); Cipher.doFinal.overload([B).implementation function (input) { send({type: input, data: Array.from(input)}); var result this.doFinal(input); send({type: output, data: Array.from(result)}); return result; }; }); def on_message(message, data): if message[type] send: print([*] message: {}.format(message[payload])) else: print([*] other: {}.format(message)) device frida.get_usb_device() session device.attach(com.example.demo) script session.create_script(script_code) script.on(message, on_message) script.load() sys.stdin.read()send()把JavaScript对象传给Python端Python端在on_message里接收并处理。这样可以把日志实时写入文件、对特殊事件计数或者直接对接后续的自动化脚本。我在做批量分析时这个组合比直接在控制台里翻日志高效得多。5. 动态注入与脱壳处理加壳App的高级思路5.1 壳的常见形态与Frida的切入点很多商用App不直接给你看dex里的真实代码而是先用壳把原始dex加密运行的时候再解密到内存中。静态反编译拿到的是壳的加载逻辑看着没太大价值。Frida的优势在于它是在运行时做操作。当App启动后壳完成解密内存里已经有了完整的dex文件结构。Frida扫一遍内存找到dex文件头dex\n035\0这类魔数把数据dump下来就是还原后的原始dex。这个过程听起来简单但有几个坑壳可能有内存校验检测到内存被读取后会崩溃也可能是抽取加固部分方法体在运行时才填充还可能是VMP加固核心逻辑被搬到了解释器里dump出来的dex里只有壳指令。5.2 用Frida-DEXDump做内存扫描联网搜Frida-DEXDump这个工具时网上有一堆脚本原理基本一致枚举分配过的内存区域搜索dex魔数验证结构再按区域dump。我常用的是命令行方式python dump.py -f com.example.demo -d dump_output/-f指定包名-d指定输出目录。它会自动等待App启动扫描进程内的dex。执行过程中App一般会正常运行某些壳可能检测到异常需要关掉一些反调试或者用Spawn模式启动。dump完成后把导出的dex文件扔回jadx或GDA里看。这里要提醒dump出来的文件可能包含多个dex有的是原来的无用代码有的是真正的业务dex需要根据包名和类名仔细辨认。5.3 常见反调试与应对思路关于反调试常见的手段有这些反调试手段原理常见应对思路检测frida-server进程名查找进程列表里是否有frida-server改名、隐藏进程名检测默认端口27042连接这个端口看是否有回复端口重定向检测TracerPid查看/proc/self/status里的TracerPid值hook该文件读取逻辑检测D-Bus协议连接27042端口并发送特定字符串看frida特征开启Frida的本地端口复用配置定时器检查时间差突变说明被调试修改时间检查逻辑或绕过计时器我在处理这些检测时最常用的是两个思路。第一是在spawn模式下更早介入——在壳的检测逻辑还没跑起来之前就hook住检测函数把检测结果改掉。第二是给frida-server做进程隐藏比如改名加端口转发让检测逻辑找不到明显的Frida特征。但说句实话反调试对抗是没有终点的。一个版本的App检测逻辑升级脚本就得跟着调整。分析过程中不断试错是常态别指望有一套万能方案。5.4 防止frida-server特征被检测的小技巧如果目标App只是做了简单的进程名检测把frida-server改名就能躲过去。但如果App检测端口或者检测D-Bus协议的握手特征就需要更细致的处理。更彻底的做法是使用Frida的gadget模式把注入行为转换成App主动加载了一个so文件。这个场景下没有独立的frida-server进程很多基于进程特征的检测会失效。不过gadget需要重打包App并绕过签名校验成本更高我只在目标App确实有较强检测意识时才用。不管哪种对抗方式都要明确边界脱壳和反调试对抗应当只用于自己拥有授权或者合法分析范围内的问题。这是我做逆向分析的底线。6. 常见问题与排查技巧实录6.1 连接失败类问题速查连接失败是新手遇到最多的报错常见的有这几种报错信息可能原因排查思路Unable to connect to remote deviceUSB没连上、adb旋转了、frida-server没启动adb devices先确认设备重新adb forward检查frida-server进程Failed to spawn: unable to connect to frida-serverfrida-server版本与PC端frida模块不一致统一版本重新推送Error listing processes: permission denied没有root权限确认su重新以root启动frida-serverunable to find process with name包名或进程名写错用frida-ps -U -a列出实际进程名排查连接问题我习惯按顺序走先看设备在不在、再看端口通不通、再看进程有没有跑、最后看版本对不对。走到一半就急着换方案往往会原地打转。6.2 spawn模式失败与类加载时机用spawn模式启动App经常遇到加载脚本时报怪错。几个典型情况第一App启动时崩溃。可能是壳检测到Frida直接杀掉进程。这时需要延迟注入或者绕过检测点。第二启动时脚本执行时机不对。目标类还没加载Java.use就会失败。第三App多进程启动spawn注入到的进程不是目标进程。类加载时机是最容易理解的坑。Java层类不是一开始就全部加载的Frida脚本如果跑得太早Java.use一个还没加载的类当然会报ClassNotFoundException。解决办法是在脚本里轮询等待Java.perform(function () { var loaded false; Java.enumerateLoadedClasses({ onMatch: function (className) { if (className.indexOf(com.example.demo.MainActivity) ! -1) { loaded true; } }, onComplete: function () { if (loaded) { doHook(); } else { setTimeout(arguments.callee, 100); } } }); });或者更简单一些用Java.deoptimizeEverything()和Java.openClassFile等高级API在类加载后手动初始化但逻辑上会复杂一些。6.3 注入后找不到目标类怎么办已经进入App很久了脚本还是提示找不到类。这时候先去确认类是否真的已经在内存里。用Frida自带的能力枚举一下Java.perform(function () { Java.enumerateLoadedClasses({ onMatch: function (className) { if (className.indexOf(demo) ! -1) { console.log(className); } }, onComplete: function () {} }); });如果列表里确实没有目标类说明该类尚未加载。可以尝试主动触发一次相关页面让App静态初始化这个类或者用反射方式加载但安卓环境下类加载路径较复杂没有现成类对象时需要自己拼接ClassLoader。多数情况下触发页面是最省事的手段。还有一种情况目标类被加固或混淆了类名不完全是我们从静态代码里看到的名字。这时只能靠运行时代码特征或者访问某资源时的调用栈来定位。6.4 多进程App如何处理很多商用App会拆成多个进程比如单独的网络进程、推送进程、页面UI进程。使用frida-ps -U看到的进程名常常不止一个。如果你的目标逻辑跑在子进程里而attach或spawn的是主进程自然hook不到任何东西。处理方式是在启动命令里先用-fspawn主进程再把脚本attach到目标子进程。如果逻辑在主进程之外的稳定进程也可以直接frida -U 进程名 -l 脚本.js来附加。有条件的话还可以用Python脚本统一管理多个sessionprocesses_to_attach [com.example.demo, com.example.demo:network] sessions [] for proc in processes_to_attach: session device.attach(proc) script session.create_script(script_code) script.load() sessions.append(session)这样就能同时hook多个进程观察跨进程的通信和数据流。6.5 版本不一致、权限不足等具体报错镜像StatePC端frida模块是16.x设备端frida-server是15.x那么几乎必然出现连接报错。处理方式就是下载匹配版本重新推送。权限不足的另一个坑发生在模拟器上。有的模拟器不开rootadb shell进入的用户权限不足frida-server起不来。这时要么换一个能开root的模拟器要么走gadget方式。我偏好在真机上调试毕竟环境更贴近实际。还有一个小问题我在过程中遇到过脚本里用了console.log但没有输出。多半是Frida脚本的console没有正确映射到PC端终端。确认命令是否加了-l参数以及是否在Java.perform里包裹了代码。未包裹的话脚本可能在注入早期就报错退出控制台什么都没显示。最后再分享一点个人体会逆向分析的实战能力其实来自大量重复性的踩坑。第一次连不上frida-server会懊恼半天到后来眼睛一扫报错信息就知道是哪一类问题。我给自己的工具链定了三个原则版本统一、脚本模板化、遇到复杂逻辑先抓堆栈和参数。很多新手朋友喜欢一上来就背API觉得会背诵就行其实Frida这套东西最靠谱的学习方式就是反复跑、反复打印、反复观察输出记录的坑多了分析速度自然就快了。希望能帮你少走一点弯路。