周杰伦 12/23/2023, 10:00:06 PM
文章分类 Android安全 阅读数 : 45 阅读时长 : 6分钟
【Android安全-新版某手app sig3算法分析】此文章归类为:Android安全。
众所周知该app请求头中有个sig3算法。该算法的主要实现在libksgmain.so中,在java层通过JNICLibrary类中的doCommandNative方法进行调用,从而计算出sig3值。本次分析的app版本是 11.11.10.34366
该so用到了跳转表来计算函数的真实地址,在分析之前需要对so去花处理。这里不再赘述,感兴趣的读者可以参考我之前的文章理解其花指令修复。
用unidbg跑一下,可以快速定位到doCommandNative函数地址在0x46435,doCommandNative函数根据java层传入的指令号,执行相应的逻辑,hook 可以发现sig3对应的指令序号在10418。 那么我们主要关注的地方是该case分支,如下图,是该case分支的一部分。 hook一下sub_41594函数,发现第二个参数的前24个字节就是最后的sig3值。 继续向上查看v496(sig3)值的生成。在for循环中 v496 和 v156进行异或处理,才是最终的sig3,而v156是在do while循环中计算出来的,可以看出v156的结果是v496前23个字节的和。基于上述分析,我们可以hook出未进行异或之前的sig3值,也就是v496.在适当的位置hook拦截一下未进行异或之前的v496值,如下图所示。 通过多次hook分析发现,v496的数据组成如上图,其中最复杂的是数据e0c281e3数据的生成。下一小节,将对e0c281e3数据的生成算法进行描述。
那么问题又转移变成了如何生成9bd618...数据。经过追踪发现,该数据的生成是调用了sub_290A0. 在sub_290A0 中又调用了sub_28858来生成9bd618...数据。hook一下看看输入数据是什么, 下面的1010数据看上去是不是很像aes的使用的填充方式。记得c8084856...这个数据,后面会继续跟踪。继续看sub_28858 函数,下面是它的部分逻辑代码。在这里我花的时间较长,最初以为这是魔改aes算法,一只在考虑trace还原算法。但是最终发现这是白盒aes,还是要感叹一下功底不足,应该早就识别出来的。猜测是白盒aes的理由如下:1.输入数据有填充(符合aes加密的特征)2.hook发现了v27包含了aes的常量特征2.v26,v27是很大的数组。(符合白盒aes的查表操作) 针对白盒aes直接上dfa攻击还原出aes密钥即可,这里不再描述细节。紧接着问题继续转移为c8084856...这个数据的生成。追踪数据发现,该数据的生成在 继续跟进去分析,sub_23d30,hook一下发现输入是java层传入的明文数据。 返回值 至此,只要还原出sub_23d30就能得到c8084856...数据了。如下是该函数的逻辑部分,其中出现了0xBB67AE856A09E667LL,这是sha256的特征值。 显然,这大概率是sha256算法了。事实上,该算法不是简单的sha256,而是在其中做了两次标准sha256,此外,数据还拼接上了salt。(这里需要trace分析一下)
经过上述分析,sig3的新版算法已经被还原出来了,主要是sha256 + 白盒aes + crc32。其中没有涉及到算法的魔改,对比小红书魔改了aes以及md5,分析难度会好多了,回头有时间再说说小红书shield算法,难度更大一点。libksgmain.so分析难度较大的地方主要是:1.so进行了花指令混淆。2.白盒aes。写在最后,文章篇幅有限,很多细节没有具体展开。本文章仅做学习参考,如侵权,联系我删除。
更多【Android安全-新版某手app sig3算法分析】相关视频教程:www.yxfzedu.com