安卓端某音乐类 APP 逆向分享(一):协议抓包

脱敏说明：本文涉及的应用均以「目标音乐APP」和「某短视频APP」代指，不指向任何具体商业产品。文中截图仅用于技术原理说明，不包含任何账号、密钥或敏感用户数据。

一、背景介绍

协议抓包往往是安卓应用逆向分析的第一步。拿到一个陌生 App 时，通常不知道从何入手，而抓包恰恰能快速揭开它与服务端之间的通信细节。

分析的结果一般分为两种情况：

• 协议清晰可见：参数和请求头都是明文，可以直接编写爬虫程序模拟请求，无需深入逆向。
• 协议存在加密字段：需要进一步逆向 App，定位加密参数的生成位置，还原加密算法，构造出合法的加密参数后，爬虫程序才能正确模拟通信。

常见的防抓包策略

为了阻止逆向分析人员进行协议抓包，现代安卓应用通常会设置一道或多道防线。常见的防抓包策略包括：

此外，少数技术积累深厚的大厂还会基于 TCP 自定义私有数据收发协议，使通用抓包工具完全无法解析报文内容。

本文以某音乐类 APP（下文简称「目标音乐APP」）为例，演示如何逐步识别并绕过其防抓包策略，完成协议抓包。

二、目标音乐APP 的防抓包策略：路由直连

2.1 现象观察

在手机上配置好 Charles 代理后，正常情况下能捕获目标应用的全部 HTTP/HTTPS 流量。然而打开目标音乐APP后，Charles 的请求列表中没有任何条目，但 App 本身可以正常播放、搜索，说明它与服务端的通信过程根本没有经过 Charles 代理，而是两端直接通信。

这种绕过系统代理的防抓包策略通常被称为路由直连（Route Direct）。

2.2 原理溯源：http.route.default-proxy

将目标音乐APP 反编译后，在代码中搜索关键字 http.route.default-proxy，可以找到如下相关代码：

上图中的代码表明，App 在构建 HttpClient 实例时，主动将 http.route.default-proxy 参数设置为不使用任何代理进行路由寻址。Apache HttpClient 在读取到该参数后，会在路由计算阶段直接忽略系统代理配置，所有请求均通过系统 TCP 栈直接送达服务器。

补充说明：http.route.default-proxy 是 Apache HttpComponents（旧称 Commons HttpClient）中的一个路由参数键。当其值被设置为 null 或特定的「无代理」标记时，HttpClient 的 DefaultRoutePlanner 在计算请求路由时不会将系统代理纳入考量，即便操作系统层面配置了 HTTP/HTTPS 代理，也会被跳过。这与在系统层面「完全绕过代理」的效果一致。

三、抓包方案：Postern 全局代理

3.1 思路

路由直连的本质是「App 主动不走代理」。要让 Charles 能捕获这些流量，必须在更底层的网络层强制将所有流量重定向到 Charles，而不依赖 App 自身的配置。

Postern 是一款支持 Shadowsocks/SOCKS5/HTTP 等协议的安卓代理工具，其核心机制是在设备上建立一个 TUN/VPN 虚拟网络接口，在 IP 层拦截所有出站流量并进行转发。无论 App 层面如何设置，流量在到达真实网卡之前都会被 Postern 接管，从而实现全局透明代理。

3.2 配置步骤

在 Postern 中，将代理服务器设置为 Charles 监听的地址和端口（例如电脑局域网 IP + 8888 端口），规则配置为匹配所有流量转发至该代理：

配置要点：

• 代理类型：选择 HTTP 或 SOCKS5（Charles 两种均支持）
• 代理地址：Charles 所在电脑的局域网 IP（手机与电脑须在同一 Wi-Fi 下）
• 代理端口：Charles 监听端口，默认 8888
• 规则：设置为「匹配所有流量」→「通过上述代理转发」

3.3 抓包效果

配置完成并启用 Postern 后，目标音乐APP 的全部通信协议均被转发至 Charles，可以看到完整的请求与响应内容：

此时可以清晰地看到 App 与服务端之间交换的 API 接口、请求参数、响应数据，为后续的协议分析和爬虫编写奠定了基础。

四、本章小结

目标音乐APP 采用了路由直连这一防抓包策略，但防护强度相对有限。对于逆向分析人员而言，只需借助 Postern 将 Charles 设为全局代理，即可轻松绕过，完成协议抓包。

整体流程可用如下示意图概括：

附录：SSL Pinning 机制深入解析

在介绍完路由直连的绕过方案后，有必要对比另一种防护强度更高的策略——SSL Pinning（证书固定），以便读者理解不同防抓包策略在难度上的本质差异。

A.1 SSL Pinning 是什么

SSL Pinning（也称 Certificate Pinning / 证书固定）是一种将服务器端 SSL/TLS 证书的指纹（或公钥哈希）硬编码到 App 内部的安全机制。当 App 发起 HTTPS 请求时，除了完成常规的 TLS 握手外，还会额外执行一步本地校验：

收到服务器证书       │       ▼与 App 内置证书指纹对比       │  ┌────┴────┐匹配        不匹配  │         │继续通信    立即中断连接

当手机配置了 Charles 代理时，TLS 握手返回给 App 的证书是 Charles 自签名证书，而非服务器真实证书。SSL Pinning 检测到指纹不一致，随即中断连接，导致 Charles 捕获不到任何内容。

与路由直连的本质区别：路由直连是「流量根本不经过代理」，用全局代理可以绕过；SSL Pinning 是「流量经过了代理，但 App 在应用层主动校验证书合法性」，全局代理无法解决，必须对 App 本身进行修改。

A.2 某短视频 APP 的 SSL Pinning 实现特点

某短视频 APP 的 SSL Pinning 实现有以下几个特点，使其格外难以绕过：

1. 实现在 Native 层：校验逻辑位于一个动态链接库（.so 文件，如 libssl_native.so）中，而非 Java/Kotlin 层。Native 代码无法用常规的 Java Hook 框架（如 Xposed）轻松拦截。

2. 多处分散实现：校验逻辑可能分布在 .so 文件的多个位置，难以通过全局搜索一次性定位所有检查点。

3. 需要二进制 Patch：必须找到校验逻辑在汇编层面的具体指令，通过修改二进制文件将校验结果强制设置为「通过」。下图展示了 libssl_native.so 中其中一处证书校验位置的汇编代码，以及对其进行 Patch 的效果：

二进制 Patch 的核心思路：找到执行证书比较的函数，将其返回值强制改为「校验通过」（通常是将条件跳转指令 bne/beq 改为无条件跳转 b，或将比较结果直接写死为 0/1）。

A.3 常见绕过思路对比

对于某短视频 APP 这类防护强度较高的场景，通常需要结合 IDA Pro / Ghidra 静态分析定位校验函数，再配合 Frida 动态调试验证，最终通过二进制 Patch 或持久化 Hook 实现绕过。