48位 __NS_sig3 算法分析还原

# 前言
众所周知该app请求头中有个sig3算法。该算法的主要实现在libksgmain.so中，在java层通过JNICLibrary类中的doCommandNative方法进行调用，从而计算出sig3值。本次分析的app版本是 11.11.10.34366
# so分析
该so用到了跳转表来计算函数的真实地址，在分析之前需要对so去花处理。这里不再赘述，感兴趣的读者可以参考我之前的文章理解其花指令修复。
https://bbs.kanxue.com/thread-278103.htm
## 1.doCommandNative 算法解析
用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数据的生成算法进行描述。

## 2.核心加密算法分析
查找分析发现e0c281e3值是调用sub_11144函数生成的。
 
hook该函数，发现入参1是一段9bd618开头的字节数组：
 
此外，入参2是入参1字节数组的长度。
重点来了，入参3的数据如下：
 
谷歌搜索一下特征值，可以发现0x04c11db7是CRC32的特征值。
 
感兴趣的可以验证一下，事实上sub_11144（CRC32）是根据输入数据9bd618...（长度24）计算出校验码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。
写在最后，文章篇幅有限，很多细节没有具体展开。
本文章仅做学习参考，如侵权，联系我删除。