本文为看雪论坛优秀文章
看雪论坛作者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