快手7.5版本sig参数逆向分析
前几天发了一下相同标题的文章,当时比较匆忙,因为是第一次在吾爱写文加发文,只是想试试吾爱的发文感觉而已,不想点了发送,就把“满满”是图片的文章发了出去,也让很多读者觉得莫名其妙,在这里,给大家道歉了,这次重新给大家来个正式的分析文。 主要分析步骤 - Jadx1.1.0结合Jeb1.0静态分析
- Ida pro7.0静态分析+还原
1.Jadx部分我们需要分析的是sig参数,所以直接在jadx中搜索是否有相关的引用 当然,由图可见,搜索sig的结果非常多,所以我们换个思路,因为sig很大可能是“sig”这样带引号的存在格式(不排除有其他的形式),所以我们再来搜索下“sig”
 没错,结果确实少了很多,由搜索结果可见,两个跟view相关,三个跟push服务相关,明显就不是,因此,我们只要分析第一个和最后一个就好,现在我们进入最后一个的具体代码看看 代码由于jadx自身的原因,导致有些代码没有编译好,不过也是能看到大致的逻辑,调用了一个方法计算出了r6,并把r6赋值给了r8,也就是sig参数,为了直观点,我们再利用jeb来看下 2.Jeb部分我们已经在jadx中知道了具体的代码位置,直接找到相关代码处,tab键转化为更加直观的java代码

可以看到,sig参数是由CPU.getClock的方法调用的,我们再进入具体的方法代码中查看

由图中可知,getClock的方法是native方法,有libcore.so文件引入,下面就开始继续分析libcore.so文件 3.Ida部分相信so文件你们都会有方法直接拿到的吧,这部分就不细说了,打开ida之后第一步当然是通过Exports的tab页查看是否有相关函数导出,我们可以看到,有CPU_getClock的方法存在,这个命名方法是由Java_类名_方法名组成,所以就是图中这个方法

我们直接进入方法内部查看,可以看到,图中__unwind的大括号内就是具体的方法汇编代码

为了方便查看,我们F5切换到伪代码界面,加上导入jni.h头,F5刷新,更新JNI Env参数等操作,嗯,逻辑已经清楚多了

我们可以看看具体逻辑,首先由两个判断,判断cpu_inited、cpu_cnt的值是否存在,这两个判断没有逻辑可言,我们可以跳过,当然,读者们也可以跳进方法内部去看,调用的都是些系统方法,我们直接从if(!cpu_cnt)之后的大括号内的逻辑来看,经过一些byte数组相关的转化,来到了第一个由自定义函数得到的值--v12,v12是由sDecryptedText方法得到的,我们进入方法看看

可以看到,v12值对应的地址是6074,v12的值是个固定值,大家可以具体深入sDecryptedText方法内部看看,这里我们直接使用frida来hook出v12的值,上代码和运行结果
 frida hook的逻辑大概是: 先拿到so的基地址->加上我们之前拿到的6074的偏移量->利用frida memory的方法读地址的指针,拿到了v12的值 下面接着分析,过了v12之后,我们可以看到三个比较明显的地方,首先是j_cpu_clock_start->j_cpu_clock_x->j_cpu_clock_end,cpu和clock这两个字符和方法很像,看来具体的加密逻辑就在这里面,接下来看

先进入j_cpu_clock_start看

由黄字部分进具体的代码查看

这个方法初始了一些变量,下面看看j_cpu_clock_x方法,这个方法是主要写加密逻辑的地方,我们先看看它的调用图

比较清晰,接着看代码

定义了一些变量之后,发现调用了sub_1EF4方法,进去看代码

结合之前的代码来看,有点MD5的感觉,上代码验证下可发现,确实是加salt之后的md5,代码如下
|