19、网络协议逆向：抓包工具（Wireshark, Fiddler）基础、分析HTTP/HTTPS请求、定位加密函数
说到逆向工程，网络协议这块儿是绕不开的坎儿。你想想看，现在哪个应用不上网？哪个App不跟服务器通信？说白了，搞懂它在网上传了什么、怎么传的，你就抓住了这个软件一半的命脉。
我个人习惯，拿到一个目标程序，第一件事不是反编译，而是先抓包。为什么？因为网络通信是最容易暴露逻辑的地方。你不需要跟复杂的汇编代码死磕，只需要看看它发了什么请求、收到了什么响应，很多秘密就自己跳出来了。
19.1 抓包工具选哪个？Wireshark vs Fiddler
这两个工具我都用了十年以上。简单说下区别：
| 工具 | 定位 | 擅长 | 不擅长 |
|---|---|---|---|
| Wireshark | 全流量分析 | TCP/IP、底层协议、非HTTP流量 | HTTPS解密需要额外配置 |
| Fiddler | HTTP/HTTPS代理 | Web请求调试、断点修改、自动响应 | 非HTTP协议基本抓不到 |
我在项目中遇到过这样的情况：一个桌面客户端，用自定义的TCP协议通信。Fiddler完全抓不到，Wireshark一开，数据包清清楚楚。反过来，如果是分析一个网页或移动App的API接口，Fiddler的断点功能能让你爽到飞起。
19.2 Wireshark基础操作——别被密密麻麻的包吓到
很多新手打开Wireshark，看到满屏的包就慌了。其实不用怕，你只需要掌握几个核心操作：
- 选择正确的网卡——抓WiFi就选WiFi网卡，抓有线就选以太网卡
- 设置过滤条件——这是最重要的技能
- 追踪流——把乱糟糟的包还原成完整的对话
常用的过滤表达式，我列几个你马上就能用的：
# 只看HTTP请求
http
# 只看某个IP的通信
ip.addr == 192.168.1.100
# 只看某个端口
tcp.port == 8080
# 组合过滤：HTTP且包含"login"
http and http.request.uri contains "login"
# 只看POST请求
http.request.method == "POST"嗯，这里要注意：Wireshark的过滤语法是它自己的，跟编程语言不一样。你刚开始可能会觉得别扭，但用多了就习惯了。我曾经花了一下午才定位到一个问题，最后发现是过滤条件写错了——把 ip.addr 写成了 ip.src，漏掉了回包。
19.3 Fiddler——HTTP/HTTPS调试神器
Fiddler本质上是一个代理服务器。它坐在你的浏览器和互联网之间，所有请求都得经过它。这意味着它可以：
- 查看完整的请求和响应头、体
- 修改请求再发出去（断点功能）
- 模拟各种响应（比如返回404、超时）
- 解密HTTPS流量
我个人最喜欢Fiddler的一点是它的断点调试。比如你看到一个App发送了加密数据，你想看看如果改掉某个参数会怎样。在Fiddler里设置一个断点，请求到达时停住，你随便改，改完再放行。这种"中间人"的感觉，真的很爽。
配置Fiddler解密HTTPS也很简单：
Tools -> Options -> HTTPS
勾选 "Capture HTTPS CONNECTs"
勾选 "Decrypt HTTPS traffic"
点击 "Actions" -> "Trust Root Certificate"第一次配置的时候会弹出一个安全警告，点确定就行。Fiddler会安装一个根证书到你的系统里，这样它就能解密你本机的HTTPS流量了。
19.4 分析HTTP/HTTPS请求——从抓包到定位关键逻辑
好了，工具准备好了，现在我们来实战。假设你正在逆向一个登录功能，抓到了以下请求：
POST /api/login HTTP/1.1
Host: app.example.com
Content-Type: application/json
User-Agent: MyApp/1.0
{
"username": "test",
"password": "a1b2c3d4e5f6..."
}看到这个 password 字段了吗？它明显不是明文。那问题来了：这个加密是在哪里做的？
我的分析思路是这样的：
- 先看请求头——有没有自定义的Header？比如
X-Sign、Authorization这些，往往藏着加密逻辑的线索 - 再看请求体——加密参数的名字、格式，能帮你判断用了什么算法
- 最后看响应——服务器返回了什么？错误信息里可能暴露加密方式
举个例子，有一次我抓到一个App的请求，发现它每个请求都带一个 sign 参数，值是一串32位的十六进制字符串。我一看就知道，这八成是MD5。为什么？32位、十六进制，MD5的典型特征。后来反编译验证，果然如此。
19.5 定位加密函数——从抓包到代码
抓包只是第一步。真正的难点在于：你看到了加密数据，怎么找到生成它的代码？
我的方法分三步：
- 第一步：确定加密时机——是在发送请求前加密的，还是收到响应后解密的？通过断点调试可以确认
- 第二步：搜索关键字符串——在反编译的代码里搜索
password、sign、encrypt这些关键词 - 第三步：跟踪调用链——找到加密函数后，看它被谁调用了，参数从哪里来
我曾经逆向过一个金融类App，它的所有请求都加密了。我抓包看到请求体是一串Base64编码的数据。解码后是乱码，说明还有一层加密。我在反编译的代码里搜索 Base64，找到了编码的地方。再往上追，发现它调用了 AESUtil.encrypt() 方法。嗯，AES加密，密钥从哪里来？继续追，发现密钥是从服务器下发的，存在SharedPreferences里。
你看，从抓包到定位加密函数，其实就是一个"顺藤摸瓜"的过程。你不需要一开始就搞懂整个加密流程，只需要找到那个"藤"——也就是加密数据的生成点，然后一步步往上摸。
19.6 本章知识体系
下面这张图总结了本章的核心逻辑，你可以对照着梳理一下自己的思路：
说白了，网络协议逆向就是"抓包→分析→定位→验证"的循环。你抓到的包越多，看到的模式就越清晰。我刚开始做逆向的时候，一个简单的登录请求要分析好几天。现在？十分钟就能定位到加密函数。不是因为我聪明，而是因为我踩过的坑够多。
嗯，今天就先聊到这儿。工具装好了，过滤条件会写了，加密函数知道怎么找了——剩下的就是多练。找个你常用的App，抓抓它的登录请求，看看能不能找到加密逻辑。相信我，第一次成功定位到加密函数的感觉，真的很爽。