混淆解密_使用IDA trace来还原ollvm混淆的非标准算法

本文为看雪论坛优秀文章

看雪论坛作者ID：pass_

这是3W班9月的题目。 题目使用ollvm混淆算法。 通过题目我掌握了IDA trace的使用方法，并灵活使用frida及调试等方式来获得中间状态来完成题目。 但是对常见算法不够熟悉，导致恢复了整个base64。这个工作量实际是可以省下的。 先拖进IDA看看，不是能简单逆向出来的。先上trace。   拿到trace的log后，尝试从输出往前找。本次的输入输出如下： 按输出的字符搜索，经过几次尝试后，可定位到sub_7F0FA11764:loc_7F0FA1198C行就是生成输出的指令。和输出是完全一样的。 先看一下output[0]是怎么计算的。 分以下3步： 1、从一个0000007F0FA39010地址中的0x15偏移中取出一会字节。我直接静态看这个地址的值与取出的值是不对的，观察了init array，发现有大量的解密操作，估计在里面做了解密，我动态调了一下，得到0000007F0FA39010这个数组的值为：”0123456789-_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”，此时值可以对应上了。 2、0x15的的计算是0x55>>2得到。 3、而0x55是从0000007F0F7CFDA0地址的0偏移中取出。0000007F0F7CFDA0暂时不知道是什么，暂称为middle数组。 为了便于计算，需要先得到这个middle数组的值，这个用trace不大好看，我在IDA中二进制逆向跟踪一下。其实就是sub_F04C的第一个参数a1。 大概看一下整体的流程，在Java_com_kanxue_ollvm_1ndk_MainActivity_UUIDCheckSum这个函数中，input经过sub_1029c函数，生成v19。而v19就是一直透传到sub_F04C函数的a1。 为了证明sub_F9B8的v19的值与sub_F04C的值是一样的，我写frida脚本hook一下并打印内存，确实是一样的。 因此整个流程就比较清楚了，input处理成middle，再处理成output。 第一次trace没有把这个参数记录下来，为了能更好地验证，再trac