企业官网建设流程全解析

第一次接触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 动态分析相对静态分析的价值

静态分析和动态分析不是替代关系，更像两种互补的侦察方式。静态分析适合看整体结构和控制流，动态分析适合捕捉运行时真实行为。很多场景下，静态分析会卡在混淆和加固上：类名和字段名全都变成无意义的字母，字符串加密，控制流被打散。这时候你很难单纯靠读代码还原出逻辑。而动态分析是另一条路——你直接看函数在真实环境里被谁调用、传了什么参数、返回了什么结果，这些数据是绕不开的。

这里有一个对比表，是我每次给新人解释时都会贴的：

在实际项目中，我一般先用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架构，选错了直接跑不起来。

把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的版本是B，A和B差太多时，连接会报类似“incompatible version”的错误。

再强调一次，版本匹配原则很简单：

• PC端frida --version显示多少，设备端就放相同版本的frida-server。
• frida-tools的版本不需要和frida模块一致，它只是命令行的封装。
• 如果后面用到gadget，gadget的版本也要保持一致。

权限不足的问题也常见。比如启动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的模拟器。

三种模式的对比：

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_nativeEncrypt：

function 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 常见反调试与应对思路

关于反调试，常见的手段有这些：

我在处理这些检测时，最常用的是两个思路。第一是在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 连接失败类问题速查

连接失败是新手遇到最多的报错，常见的有这几种：

排查连接问题，我习惯按顺序走：先看设备在不在、再看端口通不通、再看进程有没有跑、最后看版本对不对。走到一半就急着换方案，往往会原地打转。

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脚本统一管理多个session：

processes_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 版本不一致、权限不足等具体报错

镜像State：PC端frida模块是16.x，设备端frida-server是15.x，那么几乎必然出现连接报错。处理方式就是下载匹配版本，重新推送。

权限不足的另一个坑发生在模拟器上。有的模拟器不开root，adb shell进入的用户权限不足，frida-server起不来。这时要么换一个能开root的模拟器，要么走gadget方式。我偏好在真机上调试，毕竟环境更贴近实际。

还有一个小问题，我在过程中遇到过脚本里用了console.log但没有输出。多半是Frida脚本的console没有正确映射到PC端终端。确认命令是否加了-l参数，以及是否在Java.perform里包裹了代码。未包裹的话，脚本可能在注入早期就报错退出，控制台什么都没显示。

最后再分享一点个人体会：逆向分析的实战能力，其实来自大量重复性的踩坑。第一次连不上frida-server，会懊恼半天；到后来，眼睛一扫报错信息就知道是哪一类问题。我给自己的工具链定了三个原则：版本统一、脚本模板化、遇到复杂逻辑先抓堆栈和参数。很多新手朋友喜欢一上来就背API，觉得会背诵就行，其实Frida这套东西，最靠谱的学习方式就是反复跑、反复打印、反复观察输出，记录的坑多了，分析速度自然就快了。希望能帮你少走一点弯路。