当前位置：首页 > news >正文

Frida实战Android协议分析：从Hook到算法还原完整指南

news 2026/7/17 2:03:17

1. 项目概述：从“抓包”到“协议分析”的认知升级

看到这个标题，很多朋友的第一反应可能是：“哦，不就是用Frida去Hook某个App的登录或者请求，把加密参数打印出来吗？” 如果你也这么想，那说明你可能还停留在“抓包破解”的初级阶段。我干了十多年移动安全，可以很负责任地说，“协议分析”和“抓包破解”之间，隔着一整个逆向工程的深度。

抓包破解，目标往往是单一的：找到那个关键的sign参数怎么算的，或者把token解出来。这就像你只想拿到一把钥匙开门。而协议分析，你要做的是理解整座建筑的安保系统：钥匙（加密算法）是怎么造的？门禁（认证流程）有几道？报警器（反调试、环境检测）装在哪里？以及，不同房间（业务接口）之间的通信规则是什么？这是一个系统性工程。

这次我们要聊的，就是用Frida这个“瑞士军刀”，去完成一次完整的Android应用协议分析实战。这不仅仅是技术炫技，更是理解一个现代App如何保护其数据资产、如何进行客户端与服务器对话的核心视角。无论是做安全评估、爬虫开发，还是单纯想深入理解移动应用架构，这套方法都能给你带来实打实的提升。文章最后，我也会分享一些压箱底的实战心得和避坑指南，并准备了一份小福利。

2. 环境搭建与工具选型：打造你的分析工作台

工欲善其事，必先利其器。一个稳定、高效的分析环境，能让你在后续的逆向过程中事半功倍，避免很多莫名其妙的错误。

2.1 核心三件套：Frida、ADB与模拟器/真机

Frida：这是我们绝对的主角。它是一个动态代码插桩框架，简单说，就是能在App运行时，像打针一样把我们的代码“注射”进去，从而监控、修改其行为。别被“动态”吓到，它的Python脚本接口对新手非常友好。

注意：Frida分为服务端（frida-server）和客户端（frida-tools）。服务端需要运行在你的Android设备（模拟器或真机）上，客户端则安装在你的分析电脑上。很多新手卡在第一步，就是因为没搞清楚这个关系。

ADB (Android Debug Bridge)：这是连接电脑和Android设备的桥梁。所有向设备推送文件、执行Shell命令、端口转发都靠它。确保你的ADB版本不要太旧，并且设备已开启“开发者选项”和“USB调试”。

测试设备：优先推荐Root过的真机。性能稳定，行为最接近真实用户环境。如果条件有限，模拟器是第二选择。这里有个关键点：请使用Android 7.0 (API 24) 或更高版本的系统镜像。低版本系统（尤其是5.1、6.0）的frida-server可能会遇到各种兼容性问题，比如注入失败、进程崩溃等，对于新手而言这是巨大的劝退坑。像雷电模拟器、夜神模拟器都支持高版本Android，直接选用即可。

2.2 Frida环境部署详解

安装客户端：在你的电脑（假设是Windows/Mac）上，打开命令行，执行pip install frida-tools。这会把frida、frida-ps、frida-ls-devices等命令行工具装好。
部署服务端：
- 去Frida的GitHub Releases页面，根据你设备的CPU架构下载对应的frida-server。现在大部分手机都是arm64，模拟器可能是x86_64。
- 下载后，解压得到一个名为frida-server-xx.x.x-android-xx的文件，我们把它重命名为frida-server（方便输入命令）。
- 使用ADB推送到设备：adb push frida-server /data/local/tmp/
- 进入设备Shell并启动它：
```
adb shell su # 获取Root权限 cd /data/local/tmp chmod 755 frida-server # 赋予执行权限 ./frida-server & # 后台运行
```
验证连接：新开一个电脑命令行窗口，执行frida-ps -U。如果能看到设备上运行的进程列表，恭喜你，环境搭建成功！

2.3 辅助工具：让分析更高效

Jadx/Ghidra：静态反编译工具。在动态分析前，先用它们看看目标App的Java/Kotlin代码大概结构，找到你感兴趣的类和方法名。Jadx速度快，适合快速浏览；Ghidra更强大，能处理复杂的混淆和Native代码。
Burp Suite/Charles：抓包工具。用于观察App的网络请求和响应，直观地看到协议的上层表现。配合Frida，可以绕过SSL Pinning（证书绑定）进行抓包。
Objection：一个基于Frida的命令行工具，封装了很多常用功能（如绕过SSL Pinning、内存搜索、执行命令），可以作为快速测试的补充。

环境搭好了，我们就要开始思考，面对一个陌生的App，从哪里下第一刀。

3. 协议分析的核心思路与策略拆解

直接上手就Hook，很容易在浩瀚的代码海洋里迷失。一个清晰的策略能指引你快速定位到关键代码。

3.1 由外而内：从网络流量切入

这是最经典的入口。先用抓包工具抓到App的某个关键请求（比如登录、获取主页数据）。你会看到请求的URL、Headers、以及一个可能被加密的Body。

关键线索：
- URL和Path：可能对应后端某个Controller或API路由。
- Headers：重点关注Authorization、X-Sign、X-Timestamp、User-Agent等自定义字段。这些往往是客户端生成的。
- Body：如果是JSON，观察结构；如果是二进制或乱码，那肯定被加密或编码了。

你的第一个分析目标，就是找到生成这些Headers中签名（Sign）和加密Body的代码位置。

3.2 关键方法定位的四大技巧

字符串搜索：在Jadx中，直接搜索抓包看到的特征字符串，比如URL的一部分、某个固定的Header值（如User-Agent里的特定标识）。这常常能直接定位到构建请求的代码附近。
堆栈回溯法：这是Frida动态分析的杀手锏。我们不需要知道确切的类名，可以先Hook一些Android系统级的网络相关API。例如，Hookokhttp3.OkHttpClient的newCall方法，或者更底层的java.net.HttpURLConnection的getOutputStream。当App发起网络请求时，我们的Hook脚本能打印出即时的调用堆栈（Stack Trace）。这个堆栈就像一份“犯罪现场地图”，清晰地展示了从你的业务代码，一步步如何调用到系统API的完整路径。顺着这条路径往上找，很快就能定位到业务层的加密或签名方法。
类名/方法名推测：根据经验，签名或加密类常包含Sign、Encrypt、Crypto、Security、HttpUtil、Network等关键词。利用Jadx的搜索功能，全局搜索这些词。
主动调用探测：如果你通过静态分析怀疑某个类或方法是干这个的，可以用Frida写个脚本，主动去实例化那个类，调用可疑方法，传入一些测试数据，看输出是否符合你的预期。

3.3 面对混淆的应对策略

现代App普遍会进行代码混淆，类名和方法名都变成了a.a、b.b.c这种无意义字符。

不要慌：混淆只影响名称，不影响逻辑和字符串常量（但字符串也可能被加密）。
关注“不变”的东西：
- 系统API调用：无论怎么混淆，它调用MessageDigest.getInstance(“MD5”)、Cipher.getInstance(“AES/CBC/PKCS5Padding”)的代码是不会变的。你可以Hook这些系统加密类的方法。
- 方法特征：一个计算签名的方法，其输入参数很可能包含请求的URL、参数Map、时间戳等；其返回值很可能是一个String或byte数组。通过参数和返回值类型可以辅助判断。
- 调用链路：混淆不改变调用关系。通过堆栈回溯法找到的调用链，即使每个节点都是混淆的，你也能理清它们的执行顺序。

思路清晰了，接下来我们就进入真枪实弹的Hook实战环节。

4. Frida Hook实战：解剖一个签名函数

假设我们通过抓包，发现每个请求都有一个X-Sign的Header，值像是一段Hex字符串。通过字符串搜索或堆栈回溯，我们定位到了一个疑似的方法：com.example.obfuscated.a.b(String str1, String str2)。

4.1 编写基础Hook脚本

我们来写一个Frida Python脚本，挂钩这个方法，打印它的输入和输出。

# hook_sign.py import frida import sys # 定义我们的JavaScript Hook代码 jscode = """ Java.perform(function () { // 定义要Hook的类和方法 var targetClass = Java.use("com.example.obfuscated.a"); // Hook 指定的方法。注意参数类型要和实际匹配。 targetClass.b.overload('java.lang.String', 'java.lang.String').implementation = function (str1, str2) { // 调用原方法前，打印入参 console.log("[*] com.example.obfuscated.a.b() called!"); console.log(" str1: " + str1); console.log(" str2: " + str2); // 调用原方法，获取结果 var result = this.b(str1, str2); // 打印结果 console.log(" result: " + result); console.log(" result (hex): " + bytesToHex(result.getBytes())); // 返回结果，确保App正常运行 return result; }; // 一个将字节数组转为Hex字符串的辅助函数 function bytesToHex(bytes) { var hex = []; for (var i = 0; i < bytes.length; i++) { var current = bytes[i] & 0xff; var hexCode = current.toString(16); if (hexCode.length < 2) { hexCode = "0" + hexCode; } hex.push(hexCode); } return hex.join(""); } }); """ def on_message(message, data): if message['type'] == 'send': print(f"[*] {message['payload']}") else: print(message) # 连接到设备并附加到目标进程 process = frida.get_usb_device().attach('目标App包名') # 替换为实际包名，如 com.example.app script = process.create_script(jscode) script.on('message', on_message) print('[*] Hook脚本加载中...') script.load() sys.stdin.read() # 保持脚本运行

运行这个脚本：python hook_sign.py。然后在手机上操作App，触发网络请求。如果Hook成功，你会在控制台看到对应的输入输出。

4.2 深入分析：参数与算法

现在，你看到了str1和str2的内容。它们可能是：

str1: 排序后的请求参数字符串。
str2: 一个固定的密钥或当前时间戳。

result就是计算出的签名。接下来需要分析这个方法内部的逻辑。你可以：

进一步Hook内部方法：在b方法内部，它可能调用了MessageDigest.update()、Cipher.doFinal()等。可以继续Hook这些方法，看具体的数据流转。
查看返回值类型：如果结果是String，可能是Hex或Base64；如果是byte数组，可能就是原始的哈希值。
模拟计算验证：根据打印的输入，尝试在Python或JavaScript中，用常见的算法（MD5, SHA256, HMAC）模拟计算，看能否得到相同的结果。这是确认你分析是否正确的关键一步。

4.3 处理复杂场景：Native层加密

越来越多的App将核心加密算法放在Native层（C/C++代码），通过JNI调用。如果你发现Java层的签名方法只是一个“外壳”，内部调用了native String doEncrypt(String data)，那么战场就需要转移到so库。

定位so库：在Jadx中查看类的静态初始化块static {}，通常有System.loadLibrary(“crypto”)这样的语句，这就是加载的so库名。在App的lib目录下找到对应的libcrypto.so。

使用Frida Hook Native函数：这需要一些C和ARM/汇编的基础。你可以使用Frida的Interceptor.attach来Hook so库中的导出函数。关键步骤是找到函数的准确地址，这可能需要分析so的导出表。

// Hook Native函数示例 var baseAddr = Module.findBaseAddress("libcrypto.so"); var funcAddr = baseAddr.add(0x1234); // 假设的函数偏移地址 Interceptor.attach(funcAddr, { onEnter: function(args) { console.log("[*] Native doEncrypt called!"); // args[0], args[1]... 对应参数 // 可以打印内存内容 console.log(hexdump(args[0])); }, onLeave: function(retval) { console.log("[*] Native doEncrypt returned."); console.log(hexdump(retval)); } });

工具辅助：使用Ghidra或IDA Pro反编译so库，分析doEncrypt函数的逻辑，结合Frida的动态打印，理解其算法。

5. 协议还原与模拟：从分析到实现

分析的目的不是为了看，而是为了用。当我们理解了签名算法和加密流程后，下一步就是脱离App，用Python或其他语言重新实现这套协议。

5.1 重构签名算法

根据Hook得到的信息，用Python还原算法。例如，如果发现是MD5(参数1+密钥+时间戳)：

import hashlib import time def generate_sign(param1, secret_key): timestamp = str(int(time.time())) raw_string = param1 + secret_key + timestamp # 注意编码，通常使用UTF-8 m = hashlib.md5() m.update(raw_string.encode('utf-8')) return m.hexdigest() # 使用 sign = generate_sign("sorted_params", "your_secret_key_from_hook") print(f"X-Sign: {sign}")

5.2 处理加密请求体

如果请求体被加密（如AES），你需要还原出：

密钥（Key）和初始向量（IV）：它们可能是固定的，也可能是动态生成的（如从服务器获取）。通过Hook相关函数获取。
加密模式：通常是AES/CBC/PKCS5Padding。
数据格式：加密前，数据可能是JSON字符串，也可能是某种二进制协议（如Protobuf）。

还原后，你的Python代码应该能生成和App一模一样的加密数据。

5.3 构建完整的请求客户端

将还原的签名和加密函数，与requests库结合，构建一个能模拟App通信的Python客户端。

import requests import json from your_crypto_module import generate_sign, encrypt_body class AppClient: def __init__(self, base_url, secret_key): self.base_url = base_url self.secret_key = secret_key self.session = requests.Session() # 可以在这里设置一些固定的Headers，如User-Agent self.session.headers.update({ 'User-Agent': 'Dalvik/2.1.0 (Linux; U; Android 11; ...)', 'Content-Type': 'application/json; charset=UTF-8' }) def make_request(self, api_path, params): # 1. 生成签名 sign = generate_sign(params, self.secret_key) # 2. 构建Headers headers = { 'X-Sign': sign, 'X-Timestamp': str(int(time.time())) } # 3. 加密请求体 (如果需要) raw_body = json.dumps(params) encrypted_body = encrypt_body(raw_body) # 4. 发送请求 url = self.base_url + api_path # 注意：如果body被加密，Content-Type可能需要改变 response = self.session.post(url, data=encrypted_body, headers=headers) # 5. 解密响应 (如果需要) decrypted_data = decrypt_body(response.content) return json.loads(decrypted_data)

这个客户端一旦调通，就意味着你完全掌握了该App的客户端协议，可以用于自动化测试、数据采集或安全审计。

6. 进阶挑战与对抗：那些年我们踩过的坑

实战从来不会一帆风顺。App的开发者们也会采用各种手段来增加分析难度。

6.1 反调试与Frida检测

这是最常见的对抗手段。App会尝试检测自己是否被调试或注入。

常见检测点：
- 检查调试器连接：android.os.Debug.isDebuggerConnected()
- 检查TracerPid：读取/proc/self/status或/proc/self/task/pid/status，查看TracerPid字段是否为0。
- 检查Frida特征：检测frida-agent.so等文件、特定端口（如27042）是否开放、特定内存映射等。
绕过方法：
- Hook检测函数：直接HookisDebuggerConnected()等方法，让其返回false。
- 修改内存数据：使用Frida的Memory.writeAPI，直接修改/proc/self/status在内存中的映射，将TracerPid写为0。
- 使用定制版或隐藏Frida：修改frida-server和frida-agent的文件名、端口号，抹去特征。社区有一些工具可以帮助做这件事。
- 使用“强隐藏”模式：一些高级的Frida脚本或工具（如objection的android hide命令）可以尝试隐藏这些痕迹。

6.2 代码混淆与虚拟机壳

除了简单的类名混淆，还有更高级的保护：

控制流扁平化：打乱代码执行顺序，增加静态分析难度。动态分析（Frida）不太受影响。
虚拟机壳（VMP）：将关键代码转换为自定义的字节码，在私有虚拟机中执行。这是目前最强的保护之一。对付VMP，动态分析几乎是唯一途径，但Hook点变得极其难找，可能需要深入分析VMP引擎本身。这已经属于高级逆向范畴。

6.3 协议动态化与端云协同

最头疼的情况是，密钥、算法甚至协议结构都不是写死在客户端的。

动态密钥：每次启动从服务器获取，或者根据时间、设备信息动态计算。
算法抽离：核心算法逻辑以脚本（如JS、WASM）形式下发，在客户端沙盒内执行。
端云协同：最关键的签名步骤放在服务器端，客户端只负责传输原材料。这种情况下，客户端协议分析只能走到“收集原材料”这一步，无法完全还原。

面对这种情况，我们的策略需要调整：从“完全还原”转向“协议理解与漏洞挖掘”。重点分析客户端收集了哪些信息（设备指纹、传感器数据、用户行为）作为“原材料”，这些信息的收集方式是否存在隐私泄露或伪造的风险？客户端与服务器端的信任边界在哪里？是否存在逻辑漏洞，比如可以重放请求、篡改原材料顺序等？

7. 实战心得与安全边界

最后，分享几点干了这么多年总结出来的心得，这些在官方文档里可找不到。

心态比技术更重要：协议分析像解谜，90%的时间在寻找和试错，10%的时间在收获成功的喜悦。保持耐心，善于从失败（崩溃、无输出）中提取信息（错误日志、崩溃地址），每一个异常都是线索。
记录一切：建立一个分析笔记。记录你尝试过的Hook点、观察到的现象、猜测和验证结果。好记性不如烂笔头，尤其是当分析中断几天后再回来时，详细的笔记能让你快速恢复上下文。
由简入繁，逐步深入：不要一开始就想着Hook整个加密流程。先从最外层的、最明显的网络请求构造器开始Hook，打印堆栈，一步步往里追。像剥洋葱一样，一层层深入。
理解业务逻辑：最好的逆向工程师，也是半个业务专家。尝试理解这个App在做什么，这个请求是为了完成什么用户操作。业务逻辑能帮你推测代码逻辑，比如“登录”后必然要“保存会话”，那么接下来找SessionManager相关的类就很有方向。
法律与道德底线：这是我们从业者必须时刻绷紧的弦。协议分析技术是一把双刃剑。
- 授权测试：仅对你拥有合法测试权限的App进行分析（如公司内部产品、你个人开发的App、明确提供漏洞奖励计划的产品）。
- 学习与研究：以学习移动安全技术、研究防护方案为目的，对公开的App进行技术探索，是业界通行的做法，但绝不能将分析成果用于任何非法、侵权或破坏性活动，包括但不限于制作外挂、恶意爬虫、盗取用户数据、攻击服务器等。
- 尊重知识产权：分析过程中接触到的代码、算法是开发者的智力成果。我们的目标是理解其原理和实现，而非复制窃取。
- 关注数据隐私：在分析过程中，可能会接触到模拟的用户数据或设备信息。这些数据仅应用于技术验证，并应立即销毁，不得留存或泄露。