从证书抓包到签名算法还原：一次 Android App 接口逆向分析记录

在移动端数据采集与渗透测试中，Android App 的接口逆向往往是一场“猫鼠游戏”。随着 App 安全机制的升级，简单的明文抓取早已成为历史，取而代之的是层层加密与签名校验。本文将以一次真实的 App 逆向分析为例，完整复盘从突破证书校验、抓包分析到最终还原签名算法的全过程。

一、 突破证书校验与抓包分析
逆向的第一步永远是信息收集。在常规抓包中，我们常会遇到 App 拒绝联网或返回异常的情况，这通常是 App 内置了 SSL Pinning（证书绑定）机制。针对这一情况，我们需要在 Root 环境下配合 JustTrustMe 或 SSLUnpinning 等 Xposed 模块来绕过证书校验。

成功绕过证书校验后，使用 Charles 或 Reqable 等抓包工具即可捕获网络流量。在过滤出目标接口后，我们会发现请求头或响应体中通常包含类似 sign、x-nor-signature 等加密字段。此时，初步的抓包分析已经为我们提供了两个关键线索：一是加密字段的具体名称，二是请求参数与响应密文的格式特征。

二、 静态反编译与代码定位
带着抓包获取的关键字段名，我们进入静态分析阶段。首先检查 APK 是否加壳，若未加壳，可直接使用 Jadx 或 JEB 打开 APK 文件。

在 Jadx 中，最直接的定位方式是全局搜索抓包得到的加密字段名（如搜索文本 x-nor-signature 或 sign）。通过追踪搜索结果，我们通常能定位到网络拦截器（Interceptor）或加密工具类中。例如，在追踪 createNonceHeaders 方法时，我们可以清晰地看到 App 是如何将时间戳（epoch）、设备 ID（appInstallationId）和请求路径（path）作为入参，传入核心加密函数的。

如果 App 进行了严重的代码混淆，直接搜索可能失效。此时可以借助“算法助手”等工具，通过 Hook javax.crypto.Cipher 的 doFinal 方法来反向定位加密逻辑，或者通过查看调用堆栈来寻找网络请求相关的类。

三、 动态 Hook 调试与验证
静态分析只能提供逻辑框架，要验证算法并获取真实的密钥，必须引入动态调试。我们通常使用 Frida 或 Xposed（如 YukiHookAPI）进行 Hook 测试。

针对静态分析找到的核心加密函数，编写 Frida 脚本 Hook 其入参和返回值。在手机上触发相应请求后，对比 Frida 控制台打印的参数与 Charles 抓包中的密文。如果两者完全一致，说明我们准确找到了加密入口。对于响应体加密的情况，我们同样可以 Hook 解密函数，直接拦截并打印出解密后的明文 JSON 数据，从而验证数据流转的完整性。

四、 算法分析与代码还原
在确认了加密函数的输入输出后，最后一步便是算法还原。通过阅读 Jadx 反编译出的 Java 源码，分析其加密逻辑。

在实际案例中，开发者常采用“套娃”式的多重加密来增加逆向难度。例如，先对版本号进行 HMAC-SHA256 运算，再将结果与第二个参数进行第二次 HMAC-SHA256 运算，最后将结果进行 Base64 编码。理清这一逻辑后，使用 Python 编写对应的加密脚本，传入相同的参数，若生成的签名与抓包结果一致，则标志着签名算法还原成功。

从抓包到算法还原，Android 接口逆向不仅是技术的较量，更是逻辑推理的过程。掌握这套标准化的分析流程，面对再复杂的 App 加密机制，也能做到抽丝剥茧，迎刃而解。