首页 > 代码库 > 利用Unicorn和Idaemu辅助解决Geekpwn SecretCode
利用Unicorn和Idaemu辅助解决Geekpwn SecretCode
在前面的些文章里，我提到了怎么交叉编译Unicorn-engine，以及在windows上使用Unicorn python bindings进行分析程序。这一次我介绍下如何使用Unicorn-engine和Idaemu来解决一个ollvm混淆的android逆向，也就是Geekpwn SecretCode 150。
拿到题目，java的代码很简单，用户输入一个数字，程序调用native方法Java_net_bluelotus_tomorrow_easyandroid_MainActivity_stringFromJNI来进行验证。使用IDA打开so，发现代码经过了o-llvm混淆，控制流非常复杂。
这个时候如果直接逆的话，难度很大，所以我在这里借助了idaemu来对某些函数模拟执行，然后通过函数的输入和输出来猜测函数的功能。首先要知道的是，一个double类型的数据是要两个寄存器存储的，使用的是IEEE 754标准将数字存放到寄存器当中。直接对Java_net_bluelotus_tomorrow_easyandroid_MainActivity_stringFromJNI进行f5，可以看到里面除了复杂的控制流外，调用了几个别的函数，比如aeabi_dadd，fixdfsi，浏览函数列表的时候还发现了f0, f1, f2, f3函数，只从这几个函数名上就知道这是用户写的函数，并且在Java_net_bluelotus_tomorrow_easyandroid_MainActivity_stringFromJNI也发现调用了f1和f2，f2又调用了四次f0。
根据名字我大概觉得aeabi_dadd是浮点数的加法，我先google了aeabi_dadd 和fixdfsi，知道了fixdfsi是将浮点数转换为整数。我使用了idaemu模拟了几次aeabi_dadd，证实了自己的看法。用到的部分脚本如下：
a = Emu(UC_ARCH_ARM, UC_MODE_THUMB)#0xBFF0000000000000#add -1def aeabi_dadd(f): for i in f: p = struct.pack(‘>d‘,i) arg0 = int(binascii.hexlify(p[4:]),16) arg1 = int(binascii.hexlify(p[:4]),16) arg = [] arg.append(arg0) arg.append(arg1) arg.append(0) arg.append(0xBFF00000) r0 = a.eFunc(0x4188, None, arg) r1 = a.curUC.reg_read(UC_ARM_REG_R1) value = (r1<<32)|r0 print ‘handling: ‘+ str(i)) result = hex(value)[2:-1].rjust(16,‘0‘) print(result) result = binascii.unhexlify(result) print(‘final result: ‘ + str(struct.unpack(‘>d‘,result)[0]))aeabi_dadd([1,2,4,100])
通过这段脚本的运行，我知道了j_j___aeabi_dadd(*(__int64 *)&in, 0xBFF0000000000000LL);就是将输入的浮点数进行减一操作。通过这个方法，我也知道了j_j___aeabi_dadd(v3, 0xC1D0000000000000LL);的作用，就是将输入的浮点数进行减去1073741824操作。
通过这几个函数的分析，我知道了用户输入的数据首先减去1然后减去四个1073741824，最后将其从浮点数转换成整数。转换成整数后，我看到这个整数传到了f2里面，因此，我现在要用Idaemu来模拟一下f2，用到的代码如下：
def f2_1(i): arg = [] arg.append(i) r0 = a.eFunc(0x1984, None, arg) return r0def walkf2(start, end): i=start while i<end: print(str(i)+ ‘ ‘+ str(f2_1(i))) i+=1walkf2(0,200)
通过这段脚本的运行，我发现在0到200之间，只有5，11，101，191的返回结果是1，而其他的返回结果都是0，我就在google上搜索序列5，11，101，191发现这是四胞胎素数的序列，所以我就猜测f2则是判断数字是不是四胞胎素数。进入f2后，我发现了4处对f0的调用，因此我又对f0进行了模拟，发现f0则是判断输入的数据是不是素数，对f0的四次调用恰好印证了f2则是用来判断是不是四胞胎素数。用到的脚本：
def f0_1(i): arg = [] arg.append(i) r0 = a.eFunc(0x1430, None, arg) return r0def walkf0(start, end): i=start while i<end: print(str(i)+ ‘ ‘+ str(f0_1(i))) i+=1walkf0(0,30)
我也同样的尝试去模拟f1，但是并没有发现规律。接下来，我开始动态地调试这个程序，发现虽说表面上看控制流很复杂，但是有相当大一部分是固定的跳转，而且Ida调试Android经常会遇到SIGILL，很不方便，我就想着如果把程序运行过程中的trace给log下来，然后进行静态的分析。用到的一些脚本如下：
a = Emu(UC_ARCH_ARM, UC_MODE_THUMB)a.setTrace(TRACE_CODE)a.setTrace(TRACE_FileLOG)def StringFromJni(i): print ‘handling: ‘+str(i) i += (1+1073741824*4) p = struct.pack(‘>d‘,i) print binascii.hexlify(p) arg0 = int(binascii.hexlify(p[4:]),16) arg1 = int(binascii.hexlify(p[:4]),16) print ‘arg0: ‘+hex(arg0) print ‘arg1: ‘+hex(arg1) arg = [] arg.append(0) arg.append(0) arg.append(arg0) arg.append(arg1) r0 = a.eFunc(0x1C44, 0x1F7A, arg) print(‘return: ‘ + hex(r0))#StringFromJni(500227331)StringFromJni(5)
脚本完成后，会生成tracelog文件，里面存放了所有的执行过程的指令。下一步我们就可以直接开始进行分析了，对着tracelog和IDA进行分析。因为很大一部分分支比较的代码是无用的，而且有一部分是已知函数的执行序列也是无用的，所以在看tracelog的时候把这些删除的话大概只剩下100多行，分析着还是蛮快的。无用的指令序列一般是下面这种形式的：
1760 LDR R0, =0x61CB0C05 R0: 78d3a2ea;1762 CMP R1, R0 R1: 275f3da1; R0: 61cb0c05;1764 BGT loc_17D2
我初步在代码里看到的是：假设输入的是x，记subdone = x-1-4*1073741824，在代码分支里判断的有subdone是不是一个四胞胎素数，根据判断的结果将一个局部变量A置为0或1，以及subdone-1有没有大于500000000，根据判断的结果将一个局部变量B置为0xB29C1529（大于500000000）或者0x91CD6A9B（小于500000000），然后让i从1开始一次求i的平方知道i的平方大于subdone-1，当subdone-1存在平方根的时候，会用到局部变量B。我尝试通过hook的方式，在当要使用变量B的时候将变量B修改为0xB29C1529，则这个时候通过验证。
通过上面的推理与理解，我们可以得出：subdone是一个四胞胎素数，subdone要大于500000000，subdone-1要有平方根。根据此，我写了一个C语言的程序来爆破这个数字，顺利得到该数字，即512116901，所以输入为：512116901+1+1073741824*4=4807084198。Flag就是flag{hohay3f4nmop}。
其实我并没有很严格地逆清楚这个算法，但是通过Idaemu和Unicorn的帮助，我可以通过模拟运行产生tracelog的方式来进行分析，里面有些推测，但是算是合理的推测。
c语言的源代码：http://files.cnblogs.com/files/wangaohui/secretcode.zip
idaemu：https://github.com/36hours/idaemu 我在其基础上进行了些修改，使其能将指令序列记录到文件中，并且以一种友好的方式记录寄存器的值
利用Unicorn和Idaemu辅助解决Geekpwn SecretCode