-
-
[原创]GeekChallenge2023 rainbow——使用动调快速解决简单的ollvm控制流平坦化
-
发表于: 2023-11-28 22:15
-
0x01 查壳
拖进die，发现是elf64位程序，存在ollvm混淆。
0x02 ida静态分析
看到ida-view里的程序控制流长成这样，确信是控制流平坦化无疑。尝试使用d810插件去混淆，但是效果不佳。但是仔细观察伪C代码，还是能看出不少信息。
1 2 3 4 5 6 7 8 9 | v15[0] = 0x627B44508E415865LL;v15[1] = 0x847D6C49547E4A57LL;v15[2] = 0x4877646060955B4FLL;v15[3] = 0x622D3C689F7B4D7DLL;printf("Have you brought an umbrella? A storm is approaching! Input your flag:");__isoc99_scanf("%s", flag); //此处进行过重命名v14 = strlen(flag);v18 = v14;v10 = 570694771; |
联系后续代码，很容易确定v10为控制分发器跳转所用的变量，v15中存放的是加密后的密文（flag[v11] != *((char *)v15 + v11)），v14、v18一开始都被赋值为输入字符串的长度。跟一下这两者的交叉引用，v14的看不出来啥，v18的稍微有点意思：if ( v18 != 32 )，再跟一下这一条分支v10所对应的值的变化（-1827231476），确定此处是对输入flag的长度进行了校验，即flag的长度为32位。
1 2 3 4 5 | if ( v10 == -1827231476 ){ printf("Oops!Check your input length\n"); exit(0);} |
再跟一下flag的交叉引用，发现有价值的还剩下这么两处：
1 2 3 4 | if ( v10 != 192938442 ) break;flag[v13] += 18;v10 = -1820900952; |
1 2 3 4 | if ( v10 != 453066685 ) break;flag[v12] ^= v12;v10 = 525757283; |
一处是自增18，一处是异或，两处加密逻辑都较为简单，可以考虑用动调的方式手撕。
0x03 开始动调
在伪C代码界面对两处涉及修改flag的地方下断点（flag[v13] += 18;、flag[v12] ^= v12;flag[v12] ^= v12;）ida动调ELF的一般流程在此不再赘述。
启动程序后，输入32个（确保过长度校验）0（ascii码值为0x30）
然后关注栈上flag数据的变化。可以发现先是每隔两位就+18，然后再遍历flag，每一位异或上下标。写成伪C可以是这样：
1 2 3 4 | for(int i=0,i <32,i++){ if (i%3 == 0)flag[i] += 18; flag[i] ^= i;} |
那么解密脚本也就顺理成章：
1 2 3 4 5 6 7 8 9 10 11 12 13 | enc = [ 0x65,0x58,0x41,0x8E,0x50,0x44,0x7B,0x62, 0x57,0x4A,0x7E,0x54,0x49,0x6C,0x7D,0x84, 0x4F,0x5B,0x95,0x60,0x60,0x64,0x77,0x48, 0x7D,0x4D,0x7B,0x9F,0x68,0x3C,0x2D,0x62,]flag = []for i, ch in enumerate(enc): if i % 3 == 0: flag.append(chr((ch ^ i) - 18)) else: flag.append(chr(ch ^ i))print("".join(flag))# SYC{TAke_1t_3asy_Just_a_STart!!} |
0x04 总结
诚如某位大佬所说的，”技巧只会增加手撕的时间“，对于一些函数较少、对数据的操作较清晰的混淆程序而言，按部就班地去混淆或者通过汇编、伪C还原程序原始逻辑可能没有在关键代码上下断点然后通过动态调试观察数据的变化来得快。
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
