逆向某平台分析过程指导

本文为看雪论坛优秀文章
看雪论坛作者ID：那年没下雪

1、charles抓包分析报文 

登录和注册发送验证码都带有⼀个sign字段。

其他参数都为固定参数 ⽐如请求图中的：

只有这个sign每次都是变化的，那我们就开始分析这个sign。

① 先查apk是否加固 查询发现没加固。 

② 直接上jdax打开apk，能正常反编译。

③ 发现网络框架使⽤的okhttp。

因为使⽤的okhttp框架那么自然直接搜索OKhttpClient 在哪被初始化 jadx直接搜索到。

看名字猜测应该是网络核心父类，接着按x找到相关引用类找到：

看名字就猜到了http相关的⼯具类，接着继续找关键字sign，因为网络相关的类都在framework包下的 helper⼦⽬录中所有随便翻翻找到⼀个。

打开⼀看找到app相关的native⽅法都在这类中定义按x找到相关引用的类中 有⼀个。

看方法名就猜到了应该是计算sign的⽅法，打开看果然是：

计算⽅法为: 

① 调用buildSignRequestParams(str,map)方法将请求参数赋值给hashMap，并将hashMap中的值按照 key进⾏排序，重新赋值给map。

② 遍历排序后的hashmap的取出value进⾏拼接传递给buildSignValue()⽅法，调⽤native⽅法⽤frida Hook这两个⽅法调⽤也证明了这两点:

③ 接下来开始分析native方法 getServerApi() 找到使用的so 包为libNativeHelper.so。

扔到ida看导出函数发现是jni动态注册没找到getServerApi()这个⽅法，接下来使⽤unidbg进行分析 call_jni_onload 后找到偏移地址0x12795。

在ida中G 跳转到偏移地址。

查看sub_4DF0函数F5⽣成伪代码。

阅读代码修改原有的字段名称。祭出大杀器unidbg Hookz。

多次调用方法发现入参为⼀串固定字符串值,先暂定它为加密因子吧！hook伪代码中的strcat(参数1,参数2)。

参数1为之前调⽤java 层 native方法中请求参数排序后的value 字符串，参数2位固定的加密因子将两个字 符串拼接后⽣成新的待加密串。 

接着分析 sub_4538(&v20)函数。

这个4个常量 在结合sign的⻓度为32 很明显的可以猜到使⽤的MD5加密，具体在往下看。 分析sub_4564()函数：

hook函数sub45F4函数 得到的入参为 md5标识和待加密串，接着点进去查看这个函数具体实现：

最终hook这两个函数都没发现⽣成具体的sign值 加密串也没有最终被修改 于是随⼿拿之前得到的加密串去做个MD5发现直接就跟sign⼀样 所以⼤概得出这个sign算法就是标准的 MD5。