注:只做了reverse方向的题目。从2月3日HGAME CTF开始到2月8日的VNCTF再到2月9日的N1CTF Junior,长线作战使得此时已经有些乏力了,三道逆向题目中,第一道(easy-re)由于缺少root过的arm架构安卓手机,在艰难分析手撕ollvm后因发现关键值需要动态调试获取而望洋兴叹,只得作罢…
Reverse方向:
5mc:
反编译观察main:
1 | int __fastcall main(int argc, const char **argv, const char **envp) |
发现了一个SMC的加密,然后就是比较了,密文为[0x5B, 0x2D, 0xE9, 0x66, 0xED, 0x39, 0x90, 0x23, 0xAF, 0xDA, 0xEB, 0x2E, 0xD1, 0x0D, 0xBB, 0xBD, 0x57, 0x52, 0x02, 0xB0, 0xBA, 0x9D, 0x52, 0xFA, 0x67, 0xEE, 0xA3, 0x85, 0xA9, 0x84, 0xE2, 0x6F],动态调试着重看SMC部分,发现SMC部分的代码一共执行16次,且函数一共有许多种(有点像VM),执行逻辑为:
01 02 03(5,3) 04(1,7) 01 02 03(2,6) 04(4,4) 01 02 03(5,3) 04(3,5) 01 02 03(6,2) 04(7,1)
列出这些函数,第一种:
1 | __int64 __fastcall sub_1FC33450000(__int64 a1, __int64 *a2) |
动态调试得到对照表:[0xB0, 0xF0, 0x21, 0xCF, 0xF2, 0x04, 0x3A, 0x68, 0x84, 0x7B, 0x39, 0x86, 0x36, 0x87, 0x9B, 0xF7, 0x3D, 0x18, 0x1E, 0x61, 0x1B, 0x2E, 0x6C, 0xDF, 0x2C, 0xAE, 0x65, 0x9D, 0xEB, 0x2F, 0xDA, 0xF4, 0xDE, 0xCA, 0x56, 0x92, 0x75, 0x3B, 0x62, 0x45, 0x06, 0x3C, 0x52, 0x33, 0x6E, 0x25, 0xCE, 0xA3, 0xD2, 0x44, 0xA1, 0x4A, 0x58, 0xB1, 0xA0, 0x2A, 0x47, 0x0A, 0x02, 0xAF, 0x50, 0xC3, 0xDC, 0xEA, 0xE5, 0x0D, 0x67, 0x91, 0xE1, 0x51, 0xE3, 0xC1, 0xAA, 0x95, 0x5C, 0x79, 0x72, 0x1C, 0x3F, 0xB8, 0xE8, 0x1F, 0xFF, 0x7A, 0x73, 0x26, 0x54, 0x9E, 0xED, 0xA9, 0x41, 0x20, 0xEF, 0xA6, 0x48, 0x97, 0x4F, 0xD4, 0xBB, 0x23, 0x66, 0xD9, 0xE4, 0x0B, 0x30, 0x15, 0xD7, 0x6B, 0x19, 0xCD, 0xC4, 0x08, 0xB4, 0xC8, 0x14, 0xFD, 0x7F, 0x28, 0x0E, 0x05, 0x0F, 0x4B, 0x6F, 0xF5, 0x90, 0x76, 0xBF, 0x60, 0xE7, 0x24, 0x78, 0x6D, 0x71, 0xA8, 0x43, 0xB5, 0x0C, 0x31, 0xF9, 0xA2, 0x9C, 0x99, 0xF6, 0x2D, 0xDB, 0xB7, 0xC9, 0x85, 0x81, 0x03, 0x64, 0x1D, 0x07, 0x34, 0x5A, 0xBD, 0x37, 0x4C, 0xA7, 0x5F, 0x46, 0xE9, 0x35, 0x93, 0x8D, 0xA5, 0xFB, 0x42, 0x01, 0xC2, 0x17, 0x12, 0x1A, 0x77, 0xC6, 0x53, 0x83, 0x4D, 0xB2, 0x10, 0x2B, 0xF8, 0x88, 0x6A, 0x3E, 0xD0, 0x7C, 0x63, 0x40, 0x27, 0xBE, 0xD5, 0x38, 0xD1, 0x74, 0xB6, 0x57, 0x94, 0xAB, 0x8A, 0xB9, 0xBC, 0x7D, 0xB3, 0x96, 0x7E, 0xFC, 0xAD, 0x22, 0x4E, 0xFA, 0xE0, 0xCB, 0x8B, 0xEE, 0x32, 0xA4, 0x16, 0xFE, 0x5B, 0x13, 0xDD, 0xC0, 0x9A, 0x5E, 0x8E, 0x29, 0xF3, 0x8F, 0x49, 0xE6, 0x9F, 0xF1, 0xC5, 0x70, 0x55, 0x8C, 0x11, 0xCC, 0x5D, 0xEC, 0x00, 0xAC, 0x89, 0xD3, 0x82, 0x69, 0xD6, 0xBA, 0xD8, 0x59, 0x98, 0x09, 0x80, 0xE2, 0xC7]
继续往后看第二种加密:
1 | __int64 __fastcall sub_1FC33450000(__int64 a1, __int64 a2) |
动态调试得到第二个对照表:[0x13, 0x1F, 0x10, 0x1D, 0x01, 0x0D, 0x07, 0x15, 0x08, 0x06, 0x16, 0x00, 0x0F, 0x0C, 0x02, 0x05, 0x0E, 0x03, 0x12, 0x04, 0x18, 0x14, 0x1A, 0x1C, 0x1E, 0x19, 0x09, 0x1B, 0x11, 0x0B, 0x17, 0x0A],接着看第三个加密:
1 | _BYTE *__fastcall sub_20367C90000(__int64 a1, __int64 a2) |
同理得到第三、四个表:[0x7D, 0xB7, 0x24, 0x7E, 0xC3, 0x6B, 0xBD, 0xD8, 0x7F, 0x13, 0x6E, 0x0F, 0x43, 0xCD, 0x6B, 0xCF, 0x18, 0x4F, 0x26, 0x18, 0x12, 0x2A, 0x7E, 0x9B, 0x27, 0x4C, 0x33, 0x67, 0x40, 0xC9, 0x9E, 0xC4] 和 [0x91, 0xDB, 0x9F, 0x5F, 0x26, 0x27, 0xD6, 0xA8, 0xBF, 0x41, 0x16, 0x79, 0xDE, 0x73, 0x16, 0xF8, 0x1E, 0xBA, 0x6A, 0xBE, 0xC6, 0x12, 0xB2, 0x39, 0x9E, 0xF3, 0x12, 0x4E, 0x02, 0x1C, 0xE2, 0x43],看第四个加密:
1 | _BYTE *__fastcall sub_20367C90000(__int64 a1, __int64 a2) |
发现和第三个相比变化不大,到第七个函数的时候是第三种改了改参数:
1 | *(_BYTE *)(a1 + i) = (*(_BYTE *)(v4 + i) ^ *(_BYTE *)(a1 + i)) + v3[i]; |
也是同类型的,这里不再分析,第八个函数同理:
1 | *(_BYTE *)(a1 + i) = *(_BYTE *)(v4 + i) ^ (*(_BYTE *)(a1 + i) + v3[i]); |
由于类型基本一样,这类可以分成两种:一种是先异或后加和,一种是先加和后异或,编写解密脚本:
1 | #第一种加密方式 |
输出:
1 | F# D4 data: bytearray(b'?F1\xee\x0f\xd0\x1f\xa1\xe9=\x85\x9f\xcd\xd8\xa0\x19\x95\xac\xbd\x82\x89\xd2\xa5\xad\xf6H\xd0W\x92o\r0') |
则flag为:flag{Master_of_5mc_XoR_aDD_r0r!}.
df5:
查看main:
1 | int __fastcall main(int argc, const char **argv, const char **envp) |
发现函数结构和5mc很相似,flag密文为:[0x65, 0x3E, 0x43, 0xB8, 0xBA, 0xDB, 0xF6, 0x88, 0x25, 0x1B, 0x28, 0xC7, 0xC0, 0x54, 0xA6, 0x4A, 0x90, 0x37, 0xBC, 0x29, 0x41, 0xAA, 0x28, 0xDB, 0x9A, 0x59, 0x63, 0x9E, 0x4B, 0xCF, 0x2E, 0x41],但极其诡异的是加密方式的选择由输入的值来决定:输入值从第0个索引开始遍历,计算该值按位与3的值并调用函数列表v28中的这个索引对应的函数,带入输入值和一些数组的偏移量进行加密,加密之后的结果又决定了下一个值该使用哪个加密,若加密非单字节加密,则基本上无解,先将这四个加密函数反编译,先看索引为0的函数:
1 | __int64 __fastcall sub_7FF7BB5410E0(unsigned __int8 *a1, __int64 *a2) |
发现这个函数等效的就是上一题的S盒替换,并且动态调试查看发现S盒也没有改变,再看索引为1的函数:
1 | __int64 __fastcall sub_7FF7BB5412A0(char *a1, __int64 a2) |
发现这个函数也是上一题的打乱函数,并且打乱用的对照表也没变,再看索引为2的函数:
1 | __m128i *__fastcall sub_7FF7BB541610(const __m128i *a1, __int64 a2) |
发现还是上一题的加密方式,是其中的第三种,但是移除了最后的位移动,再看索引为3的函数:
1 | char __fastcall sub_7FF7BB5416B0(_BYTE *a1) |
发现这部分补齐了位移动,只不过换成了定值3,至此四种加密方式已经解析完毕,但困难的是获取这四种加密方式的顺序,仔细考虑后发现,如果解密后对应字符按位与3的值不符合要求,则证明不是这种解密,基于此编写解密脚本:
1 | #第一种加密方式 |
运行脚本:
1 | Encrypted flag: b'e>C\xb8\xba\xdb\xf6\x88%\x1b(\xc7\xc0T\xa6J\x907\xbc)A\xaa(\xdb\x9aYc\x9eK\xcf.A' |
得到flag:flag{Ea5y_enCrypt_And_decrYpt!!}.