【实战】某小程序加密算法及sign签名逆向

原创文章web安全渗透技术

原创声明：转载本文请标注出处和作者，望尊重作者劳动成果！感谢！

前言：前面分享了小程序动态调试的方法，本文找了一个小程序来具体实战操作一下，如何调试出加密算法以及sign值。

小程序抓包/解包

小程序抓包/解包过程不多说，可参考以前文章：https://www.yuque.com/jammny/ioh9u7/uiqq3lr8ws47tt55
测试过程优先尝试逆向还原源码，一方面可以检测敏感信息泄露风险，另一方面代码比较直观。

抓包查看数据包加密情况，发现请求和数据包均使用了加密，猜测可能使用了对称加密算法。sign值可能是用于检验请求包内容是否存在一致性。

虽然通过解包我们拿到了小程序的源代码，但是有时候静态分析目标的加密算法是不容易的，因为目标可能使用了非标准的加密算法或者使用了多重嵌套的加密算法。建议使用动态调试+静态分析的组合，快速定位数据加密和验签逻辑。

定位加密算法

先打开小程序调试工具，添加一个xhr断点，定位到请求发包的位置。

如果想从响应包解密入手，可以通过F9步骤调试，一步一步进入到加密函数位置。
如果想从请求包加密入手，可以直接在右侧看调用栈（Call Stack）的内容，一个一个点击调试。
我习惯看调用栈定位加密算法逻辑，省略中间过程，我定位到了目标调用AES加密算法的函数内容：

通过分析，我发现目标程序嵌套了两层AES算法，第一个AES算法仅用于解密第二个算法的aeskey值，实际上数据加解密调用的是第二个AES算法。

因此我们需要先把第二个AES算法的key解出来，通过代码分析可知目标使用的加密模式为：

key：Z3xk2#S9nQk(U%bA

iv：Z3xk2#S9nQk(U%bA

模式：CBC

填充：默认Pkcs5/Pkcs7

编码：Base64

解出key：eb87XfLf9dB245b3

将key带入第二个算法，就可以成功接触请求包数据内容：

通过autoDecoder插件，配置好参数，可以自动化完成数据加解密：

分析sign值

sign值得作用就是为了检验数据的完整性，如果仅改变请求内容的数据，不同步修改sign值，会造成后端验签失败。

本次案例中得sign值比较简单，就在加密算法得下面可以找到。正常情况下，通过搜索请求头Sign值的关键字也是可以定位到相关函数的。

通过分析sign值由四个部分拼接而成：

1. 固定字符串："saas"
2. 时间戳
3. 格式化的uuid字符串
4. POST请求内容的md5值（POST请求才需要这个部分）

最后return返回三个参数：timestamp（时间戳）、nonce（随机生成的uuid值）、sign（AES加密后的sign值），思路清晰，写个js脚本验证一下：

将对应的验签值全部替换后，服务端成功响应：

接下来可以根据需求编写生成sign值得自动化脚本，这个以后有机会再写。END

以前数据加解密和验签的场景，比较经常出现在金融行业的系统上。不过现在随着等保业务的开展，也越来越多系统数据包存在加密传输了。

原文始发于微信公众号（Fighter 安全）：【实战】某小程序加密算法及sign签名逆向