本文详细剖析了快手APP中sig3参数的生成机制，从JNI层的函数追踪入手，逐步揭示了sig3算法的工作原理及实现过程。文章还介绍了如何使用frida和trace工具来辅助逆向分析。
最近要做一些数据分析，所以来研究一下快手的sig3参数的来源！
sig3参数的定位 入口
1、Jni_Onload 定位doCommandNative函数位置
RegisterNatives函数位于sub_88F4中。
sub_c060为doCommandNative.
初探sub_c060函数.
起初看到sub_c060函数时头皮发麻，ollvm混淆的太乱太美观，导致ida f5都巨慢，查找交叉引用，结合frida一步步的确定目标函数。sub_c060->sub_26BB8->sub_3AE54->sub_3AAF8->sub_3F920->sub_3E550.
hook sub_3E550函数看结果.
使用frida hook该函数，结果如下：
抓包的结果如下：
可以看到sub_3E550函数的返回值是sig3算法部分结果，并且该函数调用了两次，第一次是要加密的内容，第二次是一个base64的值。下一步开始还原该算法。
sub_3e550函数部分片段如下:
点击dword_9e338查看
很明显这是sha256算法的常量表，该函数是sha256的变形。话不多说，开始调试。
用肉丝姐的反调试rom直接附加，成功断下。
开始愉快的trace之旅。
通过框选区域发现，a3是来自a2.a方法，且str2通过上方代码得知是sig签名结果，b2是一个url，但是执行了b()可能进行了一些处理，这里暂时先不管b2数据是什么，先最终到最终a调用的地方。
最后根据trace文件成功还原该算法。
除了ida trace之外还可以使用unicorn进行trace，个人认为unicorn trace的结果要比ida trace的结果好分析一些。
继续跟进
frida hook sub_3fda4结果如下：
可以看到，经过sha256算法的返回值在经过这个函数，把sub_3FDA4 函数的结果在经过base64之后在进行base64就是sig3算法的部分值。同样，trace之后进行还原。
这两个位置的值，是读取图片的数据之后加密获得的，具体没去跟，因为同一个版本这个值不会变所以dump出数据就行，有兴趣的可以去跟下。至此sig3算法的部分还原完成。
6、剩余部分算法还原。
sig3后面的部分已经还原，但前面部分并没有， 经过一系列的查找，确定算法位置为sub_24404
与当前时间戳异或一个值后进行进行加密。
3、算法验证
看下图 python源码 运行结果
计算sig3
计算sig 参数这个比较简单。
然后使用fiddler模拟请求成功，出数据！大功告成，至此 sig3和sig已经全部搞定转了python源码。
扫一扫
3600
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
