这是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没有把这个参数记录下来，为了能更好地验证，再trace一次，并且写一个frida脚本，把这个a1地址的值取出来 。

脚本关键部分如下：

这次有input, middle，以及output的值了。

仍然从后往前恢复，先把middle转换成output部分恢复了。

发现这部分有4个规律，分别按模4，按余数为0，1，2，3来处理。其中为0部分上面已经大概恢复了。这4个规律大同小异，按trace来恢复就行了，不一一细讲，其中对middle下标的处理有点小trick，我被卡了一下。

看sub_F04C的伪码其实可看出来，每次index是加3的。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课