Re1
首先ida反编译main函数会报错,这个一般是程序中有花指令导致的。
因为main函数比较大,用提示成功字符串定位到最后的汇编代码,向上翻翻便看见出问题的代码。
双击该地址,可以发现ida将这段数据解析成了代码且最上面有一个设置的条件绝对跳转跳过了执行下面的错误带代码,这里可以直接把jnb改成jmp,并把下面垃圾代码nop掉。
继续向上翻又可以看见如下的花指令:不断跳转到下一条指令,统统nop掉即可。
1 | from ida_bytes import * |
然后我们就可以反编译了。
先看到对输入的处理:
开始判断了flag长度范围[12, 45],然后判断格式是否是WMCTF{}
接着申请了576字节大小的空间block,并把输入的除去格式(WMCTF{}外)的前4个字节以如下方式填入block
再把输入的除去格式(WMCTF{}外)的4-20字节填入block+530开始的位置。
最后就是将剩下的输入以_@#?!&-$+为区分,分别进行不同的处理。其中输入是hex形式,先把每4个hex转化两字节数据后,再用第一字节作为index,第二字节作为数据对block进行操作。
下面再看加密部分:
首先sub_7FF79BD33960()函数也是加了上面所说的花指令,去除后看到伪代码,用CRC算法生成256个4字节数据:
1 | __int64 sub_7FF79BD33960() |
然后对前4字节填充的block,用CRC生成的256个4字节数据,经过移位,异或运算生成4个4字节数据后与硬编码的数据比较:
最后使用最开始在block填充的0xDEAD改变vars88,vaes84, vaes80, v58后作为密钥对除去WMCTF{}格式外输入的4-20字节进行2个xtea加密。
下面开始解密:
首先用z3将vars88,vaes84, vaes80, v58四个值就求出来:
1 | from z3 import * |
再用上面4个数据依次爆破出对应的4字节明文数据:
1 |
|
用满足前4字节的测试输入WMCTF{Hah41111111111111111}输入程序,然后在xtea加密前取出密钥:
但用这个密钥解密密文怎么都不正确。。还测试了自己的xtea解密好几遍,这里卡了好一会。
后面确定肯定是密钥的问题,但输入的前4字节是满足要求的,密钥是通过前4字节明文算出来的。但注意这里的密钥还用开始在block填充的0xDEAD的经过了变换的。这让我想到我忽略了输入的(WMCTF{}格式外)20字节后处理,开始闲麻烦懒得看直接跳过了。
所以问题现在应该就出在了有两个字节数据对密钥的影响。
爆破这2个字节,从解密结果中看像是flag的片段的:
1 |
|
可以看到yOu_L1kE,满足要求的两个字节是0xb7 0xad
然后解密2段密文再按一定顺序拼接一下得到:_D0_yOu_L1kE_It!
现在就是去求_@#?!&-$+对应的处理函数怎么才能将*((_WORD *)Block + 273)的0xDEAD的改为0xB7AD。
输入为hex,4字节为一组转化为2个byte,第一个byte是index,第二个byte是data
根据要求推算出这样一个顺序是满足b要求的:
首先@对应的处理函数将block[256] = 0xFE。注意下面是char a2,所以传入0xFF就是-1了,因此满足输入为:@FFFE
然后#对应的处理函数将block[528] = 0x20,因此满足输入:#0F20
最后-对应的处理函数将block[527] = 0xB7,也是我们最后的终点。因此满足输入:-11B7
可以看到上面要能执行最后的*(_BYTE *)(a1 + 530 + a2) = a3;要求是(*(unsigned __int16 *)(a1 + 528) % 16) == 0,(unsigned int)(*(unsigned __int16 *)(a1 + 528) / 16) < 3
用这2个限制爆破得到:
1 | for i in range(0xff) if i%16 == 0 and i/16 < 3] a = [i |
而我们的index为17且index<*(unsigned __int16 *)(a1 + 528),所以满足要求的就只有最后的32了,故上面#对应的处理函数要将block[528] = 0x20。
最后将我们的所有输入拼接起来得到flag:
WMCTF{Hah4_D0_yOu_L1kE_It!@FFFE#0F20-11B7}
Re2
jadx打开app,可以看到关键在native层。
到so文件找到JNI_Onload
其中,上面的JNI_Onload根据sub_7079FF9BBC函数的返回值注册不同的函数。
看到sub_7079FF9BBC:它通过查看/data/local/su是否存在,也就是判断我们的运行环境中有没有root
所以JNI_Onload是根据运行环境是否root注册不同的函数来执行。
接着我把程序在root与非root手机运行来看一下,root下运行随便输入后显示:fake branch,而在非root的手机上运行随便输入后显示:failed,please try again!!!,以此可以得出,我们要分析的非root才注册的函数。
然后也去看了一下root下注册的假流程:经过上面一些加密后最终都是返回同一个字符串。
查看返回的字符串,发现并不是字符串数据,从交叉引用发现.init_array中一些初始化函数对其进行了解密。
并且.init_array中初始化函数动态解密了程序中很多数据:
对上面假流程返回的字符串异或0x6d解密后得到:fake branch
再看到正确分支流程:先异或解密一些数据后注册了如下的函数。
1 | jstring __fastcall sub_7079FF9134(JNIEnv *a1, __int64 a2, __int64 a3) |
先简单静态分析一下,开始是判断输入的长度是否为32。
然后sub_7B4933FE80函数读取某个文件内容经过对比后返回一串字符串:
后面接着对上面获取到的字符串进行如下赋值:
其实就是在其末尾加上flg
1 | len = strlen(init_key); |
接着sub_7B49340934函数传入两个参数,其中的sub_7B49340820函数用了传入的一个参数串进行aes的密钥扩展:字节替换(但是这里的sbox是替换过的),移位,轮常数异或。44/4 = 11,这也说明了是aes_128,因为密钥11组。
再是将另外一个参数存放在扩展密钥的尾部:
接着的sub_7B49340E6C函数也是很明显的aes_128_cbc加密,sub_7B4934097C中清晰的初始轮(轮密钥加),重复轮(字节替换,行移位,列混合,轮密钥加),最终轮(字节替换,行移位,轮密钥加)结构:
最后sub_7B49340624函数rc4加密,但多异或了0x50:
所以整体上本题的加密就是aes_128_cbc与rc4,麻烦的是数据部分,如aes的密钥,iv,rc4密钥与密文等。因为开始说了在.init_array中进行了很多数据的解密,我在静态分析看到的大多数数据都是没有解密的。那我们现在要么对分析到的数据找到引用修改的.init_array中的函数按照相同的运算逻辑手动patch修改;要么就是把程序调试起来,分析起来会简单很多。
这里我选择了动态调试。
首先将AndroidMannifest.xml中的android:extractNativeLibs=”false“改为true或者删掉,默认为true。因为这个如果为false会让我们在调试时找不到so
然后因为我们调试的断点要断在JNI_OnLoad中(方便把注册的函数修改为正确的分支),那我们必须在程序还没执行System.loadLibrary(“native-lib”);之前就断下来,所以要程序要以调试模式启动。
首先我尝试了ida+jdb的组合:
运行环境中root模式启动好相应的服务程序,转发端口到本地。(停止转发端口:adb forward –remove tcp:端口号
或
adb forward –remove-all)使用am命令以调试启动app:adb shell am start -D -n come.wmctf.crackme111/.MainActivity
ida在JNI_OnLoad中下好断点,然后找到app对应的进程后附加,接着F9运行
打开ddms,用附加让app运行起来:jdb -connect com.sun.jdi.SocketAttach:hostname=127.0.0.1,port=8700
但是这样做在jdb附加app就报如下的错误。这好像是我手机的原因?
我使用jeb来附加app同样也是报错,这都是在我先用IDA附加了进程的情况下,接着我尝试发现先jdb或jeb附加再IDA附加是可以的,但这样程序已经运行过System.loadLibrary(“native-lib”);了。
而还有一个方法,我们可以使用jeb附加调试断在System.loadLibrary(“native-lib”);之前再用IDA去附加进程呀。
然后成功断在JNI_OnLoad中,在正确分支下好断点,修改检测环境是否root的返回值为false,但是这个在native层运行完JNI_OnLoad函数回到java层的时候app又崩溃了。
最后干脆直接改so得了,就是把根据检测运行环境是否有su的返回值后的条件跳转改一下。
上面修改完后,把app重编译一下,然后普通的附加调试就好了。这也是调试本程序最简单的方法,上面绕了一大圈😂。
现在再看一下内存中解密后的数据,一目了然:
看到上面静态分析说的sub_7B4933FE80函数用fopen()打开了一个系统文件,现在调试过去发现原来是进程的状态信息:
再看到后面要匹配的内容。
自己手动查看一下:
接着直接调试到最后看获取的结果,就是要获取TracerPid:字段那一行的内容加上flg,而app正常不调试运行这个TracerPid是0的,所以这里获取的正确值为:TracerPid:\x090\x0Aflg
接着看到下面与上面的静态分析结合可以知道:程序中aes_128的key:TracerPid:\x090\x0Aflg iv:0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xA, 0xB, 0xC, 0xD, 0xE, 0xF
再就是这个aes加密的sbox果然是替换了的,正常的sbox开头为:0x63, 0x7c, 0x77, 0x7b
最后看到剩下的rc4加密,从传入参数看到密钥是Hello from C++
下面开始解密。
首先rc4解密:
直接把输入的aes加密结果与最终经过rc4结果都提取出来异或一下得到异或序列,再将其与真正的密文异或一下得到真正的aes加密结果:
1 | 0xA4, 0xCD, 0xDA, 0x34, 0xA9, 0xE8, 0xFF, 0x48, 0xD6, 0x74, 0xE7, 0x0F, 0x71, 0xF7, 0xED, 0xB7, 0xC2, 0xA8, 0xE1, 0xE1, 0x0E, 0x2D, 0xD0, 0x8D, 0xF8, 0x20, 0x0E, 0x85, 0x1D, 0xBC, 0xC1, 0x61] s = [ |
然后aes解密:
将之前自己写过的aes_cbc加解密中的sbox替换为程序中的,rsbox简单对sbox求一下逆,最后解密即可:
1 | //aes.h |
1 | //main.cpp |
最后解密得到:wmctf{e78ce1a3ac4be37a96e27e98c}