利用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 -1
def 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])
View Code

    通过这段脚本的运行,我知道了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 r0

def walkf2(start, end):
    i=start
    while i<end:
        print(str(i)+ ' '+ str(f2_1(i)))
        i+=1
walkf2(0,200)
View Code

    通过这段脚本的运行,我发现在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 r0
def walkf0(start, end):
    i=start
    while i<end:
        print(str(i)+ ' '+ str(f0_1(i)))
        i+=1
walkf0(0,30)
View Code

    我也同样的尝试去模拟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)
View Code

     脚本完成后,会生成tracelog文件,里面存放了所有的执行过程的指令。下一步我们就可以直接开始进行分析了,对着tracelog和IDA进行分析。因为很大一部分分支比较的代码是无用的,而且有一部分是已知函数的执行序列也是无用的,所以在看tracelog的时候把这些删除的话大概只剩下100多行,分析着还是蛮快的。无用的指令序列一般是下面这种形式的:

1760 LDR     R0, =0x61CB0C05            R0: 78d3a2ea;
1762 CMP     R1, R0         R1: 275f3da1; R0: 61cb0c05;
1764 BGT     loc_17D2
View Code

    我初步在代码里看到的是:假设输入的是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 我在其基础上进行了些修改,使其能将指令序列记录到文件中,并且以一种友好的方式记录寄存器的值

原文地址:https://www.cnblogs.com/wangaohui/p/5925368.html