无需逆向工程，利用算法助手快速破解移动应用加解密与签名验证

这是一次海外的众测项目，主要测试目标是 App 和管理后台。由于我开始测试的时间比较晚，越权类漏洞的提交名额已经满了，因此我暂时放弃了漏洞可能较多的管理后台，将主要精力放在了 App 端的安全测试上。

首先，让我们进行抓包分析，初步了解应用的通信情况。

从抓包结果可以看出，当前面临两个主要问题：一是响应体被加密，二是请求体疑似带有签名验证。想要进行深入测试，必须解决这两个问题。首先，我们需要确认签名验证是否真实存在。拦截一个请求，修改其请求体内容，观察 App 的反应。

这里我们随机修改几个参数。

修改后，应用弹出提示。将其翻译后，意思是“请求无效”。这表明签名验证很可能不是摆设，请求体中的所有参数应该都参与了签名计算。

面对这种情况，该怎么办呢？我本身并不精通逆向工程。

别着急，我们可以使用一款强大的工具——算法助手。这款工具能帮助我们在不进行复杂逆向工程的情况下，分析应用的加解密和签名逻辑。

进入算法助手后，勾选目标 App，并启用相关的算法分析、设备环境模拟等功能。

然后点击右上角的“重启 App”按钮，使配置生效。

此时，我们再次查看 Burp Suite 捕获的加密响应包。将加密结果复制出来，粘贴到算法助手的搜索框中，即可搜索到相关的算法调用日志。

点击任意一条日志查看详情。

可以看到，算法助手已经清晰地给出了 AES 解密所需的所有参数（密钥、IV等），并且这些值看起来是固定的，并非随机生成。很好，现在只剩下签名算法需要破解了。用同样的方法，将请求包中签名的值复制到算法助手里搜索。

从日志可以看出，签名内容是由整个请求体加上一个随机码（nonce）计算得出的。这个随机码肯定会在请求包中携带，否则服务器无法验证签名。我们在请求头中搜索一下，看看是哪部分。

很明显，是由 X-Timestamp 和 X-Nonce 这两个请求头参与生成的。至此，验签和加解密算法所需的所有参数都已齐备。下一步就是编写脚本，让 Burp Suite 能够自动解密响应体，并对修改后的请求体重新进行签名。

这里用到了 Burp Suite 的 Galaxy 插件。最终实现的效果如下，这极大提升了渗透测试的效率。

同时，由于可以自动重新签名，使得爆破、遍历、参数替换等攻击行为能够自动化进行，这为我们后续发现漏洞奠定了基础。

首先发现的是一个请求频率限制绕过漏洞。在测试过程中，当请求次数超过一定阈值后，服务端会统一返回“请求太多”的错误。我主要考虑了以下三种可能性：

1. 基于请求源 IP 进行限制。
2. 基于请求头中的 Deviceid 字段进行限制。
3. 基于多个参数复合生成的指纹进行限制。

我首先测试了修改 Deviceid 的值，但未能绕过限制。
第三种情况不太好猜测具体是哪些参数，所以我优先测试了基于 IP 限制的可能性。在 Burp Suite 中设置一个上游代理，并通过全局规则来动态修改出口 IP，然后再次发起请求，发现限制被成功绕过。

既然提到了伪造 IP，那么 X-Forwarded-For (XFF) 头注入漏洞就不得不测试了。我们直接尝试添加一个自动修改 X-Forwarded-For 请求头的配置，测试后发现可以绕过频率限制。这样，第一个漏洞就成功到手了。

（由于撰写本文时漏洞已修复，以下使用报告中的截图进行说明）

现在，阻碍我们进行爆破测试的三个主要问题都已解决：

1. 请求体自动重签。
2. 响应体自动解密（用于判断爆破是否成功）。
3. 请求频率限制绕过。

接下来，我们自然要测试登录处的短信验证码爆破漏洞。直接开始操作。我们在自动解密脚本中加入了生成随机 IP 地址并赋值给 X-Forwarded-For 头的功能，以利用上述的 XFF 漏洞绕过请求限制。

很好，又一个任意账号接管的漏洞到手。后续由于时间关系，没有继续深入挖掘。这次测试也相当于在工作之余赚了笔外快。

通过这次实战，我们可以看到，借助合适的工具链和分析方法，即使不深入逆向工程，也能有效完成对移动应用安全机制的测试。如果你对这类移动应用安全测试技术感兴趣，欢迎在云栈社区与更多安全研究者交流探讨。