少量虚假控制流混淆后的算法还原案例

看雪论坛作者ID：Avacci

（题外话：先恭喜高研班学员咸鱼炒白菜拿到远超3W的offer！）

目标apk输出的结果和第一题很像：

Java层也几乎一样：

Sign1函数在Native层中和之前一样是在JNI_OnLoad方法中通过RegisterNatives方法动态注册。在sub_11088方法中可以定位到相关代码。

还是用一样的脚本，获取sign1代码的实际偏移地址：

Sub_10618方法的代码结构和第一题有相似之处，于是打算由结果开始倒推分析。

根据经验，变量V20中应该存有结果字节数组。

V20由v22格式化后得到，而v22是通过sub_17030方法生成。

Sub_17030的第一个参数由前面的sub_16248方法生成。

那就直接hook sub_16248和sub_17030两个方法。当然hook之前还是先固定好传入的字符串内容。

由结果可以看出，先调用sub_16248方法，将随机字符串进行处理。得到的结果
‘d5 d6 92 3c a6 bf 4f 04 bc dc 6b 26 50 f8 c7 e9’就是第一题md5哈希后的结果。

而sub_17030是将哈希后的结果再次处理，得到‘ce c6 a6 4a 75 a2 d2 b7 90 6b d8 51 e9 73 ca a7’。

先确认下sub_16248是否和之前的md5一样。Sub_16248调用了sub_15B68。

其中关键代码为：

Sub_1510C疑似md5_update，hook一下。果然第一部分还是相同的内容，第二部分就是随机的字符串。

存储第一部分字节内容的地址为0x420F0。静态查看时内容与运行时不一致。运行时才是需要的内容，可以判断是运行时进行了解密操作。

根据交叉引用，定位到运行时进行解密操作的代码位置：

因为这部分产生的内容不变，暂且就不深入分析了。直接回过头分析sub_17030方法。

Sub_17030内部实现分为两部分，分别进行逐字节操作：

这部分静态分析稍微有点吃力，就尝试用stalker打印指令流来分析。

在课上的脚本上稍作更改后，对sub_17030进行hook。

同时，固定传入的字符串。（这里为了与后续的迭代计数器区分，输入字符串换成了’ fedcba9876543210’）

再次点击按钮，就可以得到一长串指令流了。

回到sub_17030的实现，它分为①和②两部分。

部分①处汇编指令为：

随便取一个地址”0x171f0”，去前面导出的指令流中搜索，发现没有执行到。

而部分②的汇编指令是可以搜索到的，说明执行到了。

这么看，估计部分①是虚假控制流。实际执行的只有部分②的指令。那么就只用看部分②的指令了。 

部分②反编译后的第一条语句为：

Index & 0xf对应的汇编指令为：

在指令流日志中搜索所有执行AND操作时index的值，发现从0x0开始递增到0xf。猜测就是index迭代计数器。

V18指向0x35F50。

其初始化的值为：

整个第一行语句用处就是从0x35F50处逐字节取值。取字节对应的汇编指令为：

可以搜索所有取到的字节值。

发现和初始化的值一致，说明没有后续的处理。

第二条语句：

后半部分的(index ^ 0xFFFFFFF8) & index 相当于对index作mod 8处理。然后再将结果作为索引从0x42180处逐字节取值。这部分汇编为：

0x42180处的初始化值为：

而日志中打印的所取出的值和初始化的值不同。

应该是在前面的解密函数里做了解密操作，因为结果是固定的（0x65, 0x39, 0x66, 0x30, 0x33, 0x34, 0x32, 0x61），没有深究。

第三条语句就是一系列的字节操作，后面算法还原时直接照着抄一下就行：

第四条语句是将第三条语句生成的结果与输入字符串做逐字节操作，也可以照搬一下。

根据刚才的分析写还原代码：

用相同的参数进行调用：

 可以得到与sign1算法相同的结果：

再hook一组参照组：

运行得到的结果也相同。

看雪ID：Avacci

https://bbs.pediy.com/user-home-879855.htm

*本文由看雪论坛 Avacci 原创，转载请注明来自看雪社区

# 往期推荐

公众号ID：ikanxue

官方微博：看雪安全

商务合作：[e-mail]

球分享

球点赞

球在看

点击“阅读原文”，了解更多！