> 直接搜索sign参数匹配的出来的结果太多了,一时间不好区分哪个是真的。于是使用getSign为前缀搜索

> 运气不错搜索到一个native方法 前缀也是getSign的方法名,打开这个类。找下引用位置进一步确认下是否为计算sign的类

> 最终在BaseApplication里面找到这个类引用，可以确定这个就是计算sign的类

frida hook这个方法得到结果如下:

> 根据hook结果稍加分析大概知道各个参数代表的意义:

>context：上下文对象

>str：url路径

>str2：请求body信息

>str3：55a9c688729bb118  为KEY 16位长度,且每次请求都固定

>str4：android 为平台

>str5：版本号

> 查看源码大概得出str3 的为installationId生成规则是UUID 随机16位长度,在app第一次安装的时候创建保存在缓存中.

> 1.第一步当然是补环境了:

> 需要补充返回一个application对象,偷个懒想从AbstractJni 这里copy一份

> 重新运行一下又报错了,这个错是找不到对应的methodId、于是想着把Application换成Activity也可以,毕竟Activity也是可以获取Application对象的

> 重新运行就没问题了,接下来继续报错补环境,返回apk的路径。很简单

> 图上这个返回刚开始不知道传具体什么参数,于是打算看看源码。结果没有反编译出来具体的函数实现。于是用frida hook了这个方法拿到图下的返回 

> 第一个参数为：app安装目录  第二个参数为META-INF 目录 第三个是RSA

> 既然这样就直接返回RSA公钥了

> 继续补充环境

> 继续补充环境,需补充如下

> 继续补充环境,从反编译的源码中copy 一份objectToBytes方法即可然后构造ByteArray返回即可

> 运行报错，还缺少环境

> 重新继续补充环境 这部分环境补充比较简单 直接上最后运行结果

> 黑盒调用没问题了,接下来开始分析sign具体是怎么生成的。全部代码如下:

ida导入so 包  export导出中找到sign生成方法  截图如下:

F5生成伪代码

根据方法的具体逻辑修改了下方法名称 方便直观查看。初步观察是讲传入参数通过key=value 的方式拼接起来

通过unidbg的执行日志中也可以发现这点

接下来开始从函数返回的地方开始往上分析,单独调用执行返回如下:

st=1648374072802&sign=8102aefd41782d405174725cd433c5a0&sv=111

从上可知要分析的为st 、sign、sv这个三个值

1.st生成分析:生成一个时间戳 长度为13位的 用于计算sign

2.sign的生成:

分析伪代码找到sign的生成方法为sub_126AC,该方法上面的伪代码都是一些拼接字符串的操作,就是把入参拼接起来。

> 接下来开始unidbg hook该方法

> 然后开启无尽的S 单步执行往下走当程序走到switch判断时 发现bl指令跳转到sub_10de4函数  多次在这个位置debugger 到 发现 到 sv =111 走的是 case 2   还遇到过sv = 110 走的是case 1 、这部分我们只分析为2的情况也就是走sub_10DE4,至于为啥呢？就是因为这后面走的加密算法看起来简单些 像md5 

> 查看下函数sub_10de4入参,hook该函数

> 打印mr1,为一串固定的字符串

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课