HITCON 2022 - Meow Way
Reverse-engineering like the meow way!
We are given a Windows 32-bit executable that we can load into Ghidra. In the initial peak into the main, we can see the following
(*DAT_0040544c)(iVar3,iVar3 >> 0x1f,iVar3,iVar3 >> 0x1f,0xc4,0,&local_10,&local_10 >> 0x1f);
iVar2 = iVar3 + 1;
(*DAT_004053a8)(iVar2,iVar2 >> 0x1f,iVar2,iVar2 >> 0x1f,0x16,0,&local_10,&local_10 >> 0x1f);
iVar2 = iVar3 + 2;
(*DAT_004053b4)(iVar2,iVar2 >> 0x1f,iVar2,iVar2 >> 0x1f,0x8e,0,&local_10,&local_10 >> 0x1f);
iVar2 = iVar3 + 3;
(*DAT_004053f0)(iVar2,iVar2 >> 0x1f,iVar2,iVar2 >> 0x1f,0x77,0,&local_10,&local_10 >> 0x1f);
iVar2 = iVar3 + 4;
(*DAT_00405448)(iVar2,iVar2 >> 0x1f,iVar2,iVar2 >> 0x1f,5,0,&local_10,&local_10 >> 0x1f);
iVar2 = iVar3 + 5;
(*DAT_004053fc)(iVar2,iVar2 >> 0x1f,iVar2,iVar2 >> 0x1f,0xb9,0,&local_10,&local_10 >> 0x1f);
iVar2 = iVar3 + 6;
(*DAT_00405400)(iVar2,iVar2 >> 0x1f,iVar2,iVar2 >> 0x1f,0xd,0,&local_10,&local_10 >> 0x1f);
iVar2 = iVar3 + 7;
(*DAT_00405410)(iVar2,iVar2 >> 0x1f,iVar2,iVar2 >> 0x1f,0x6b,0,&local_10,&local_10 >> 0x1f);
iVar2 = iVar3 + 8;
(*DAT_004053f8)(iVar2,iVar2 >> 0x1f,iVar2,iVar2 >> 0x1f,0x24,0,&local_10,&local_10 >> 0x1f);
iVar2 = iVar3 + 9;
<continuing..>
It looks cryptic, but after a quick look, those DATA_00405XXX are function pointers. After cleaning it a bit more we can obtain the following code
flag = argv[1];
(*ptrF1)(flag,flag >> 0x1f,flag,flag >> 0x1f,0xc4,0,&local_10,&local_10 >> 0x1f);
pcVar2 = flag + 1;
(*ptrF2)(pcVar2,pcVar2 >> 0x1f,pcVar2,pcVar2 >> 0x1f,0x16,0,&local_10,&local_10 >> 0x1f);
pcVar2 = flag + 2;
(*ptrF3)(pcVar2,pcVar2 >> 0x1f,pcVar2,pcVar2 >> 0x1f,0x8e,0,&local_10,&local_10 >> 0x1f);
pcVar2 = flag + 3;
(*ptrF4)(pcVar2,pcVar2 >> 0x1f,pcVar2,pcVar2 >> 0x1f,0x77,0,&local_10,&local_10 >> 0x1f);
pcVar2 = flag + 4;
(*ptrF5)(pcVar2,pcVar2 >> 0x1f,pcVar2,pcVar2 >> 0x1f,5,0,&local_10,&local_10 >> 0x1f);
pcVar2 = flag + 5;
(*ptrF6)(pcVar2,pcVar2 >> 0x1f,pcVar2,pcVar2 >> 0x1f,0xb9,0,&local_10,&local_10 >> 0x1f);
pcVar2 = flag + 6;
(*ptrF7)(pcVar2,pcVar2 >> 0x1f,pcVar2,pcVar2 >> 0x1f,0xd,0,&local_10,&local_10 >> 0x1f);
pcVar2 = flag + 7;
(*ptrF8)(pcVar2,pcVar2 >> 0x1f,pcVar2,pcVar2 >> 0x1f,0x6b,0,&local_10,&local_10 >> 0x1f);
pcVar2 = flag + 8;
(*ptrF9)(pcVar2,pcVar2 >> 0x1f,pcVar2,pcVar2 >> 0x1f,0x24,0,&local_10,&local_10 >> 0x1f);
pcVar2 = flag + 9;
<continuing..>
We can see that each call is done for each character of the flag, and at the end we compare the output of those with a predefined byte buffer in the binary.
iVar3 = memcmp(&::flag,argv[1],0x30);
To find the flag, we need to analyze those functions under ptrFXX. Let's take a look at one of them (f8). We need to see the assembly as the decompilation yields an empty one (just return).
undefined __stdcall f8(void )
00403468 6a 33 PUSH 0x33
0040346a e8 00 00 CALL LAB_0040346f
00 00
LAB_0040346f:
0040346f 83 04 24 05 ADD dword ptr [ESP],0x5
00403473 cb RETF
The retf is suspicious here. And the whole call and ADD dword ptr[esp] action is weird too. What's happening here is the switch to execute 64-bit code and modification of the return pointer via [esp], instructs to continue execution just after the retf opcode. Since the binary is 32-bit and this is Ghidra's mode of operation, if we decompiled the next few bytes, we would have them wrongly presented. Just for the sake of learning, let's see them:
00403474 48 DEC EAX
00403475 31 c0 XOR EAX ,EAX
00403477 65 48 DEC EAX
00403479 8b 40 60 MOV EAX ,dword ptr [EAX + 0x60 ]=>DAT_0000005f
0040347c 48 DEC EAX
0040347d 0f b6 80 MOVZX EAX ,byte ptr [EAX + 0xbc ]
bc 00 00 00
00403484 67 8b 4c 24 MOV ECX ,dword ptr [SI + 0x24 ]
00403488 1c 83 SBB AL,0x83
0040348a e0 70 LOOPNZ LAB_004034fa+2
0040348c 67 89 01 MOV dword ptr [BX + DI],EAX
0040348f 85 c0 TEST EAX ,EAX
00403491 75 18 JNZ LAB_004034ab
00403493 67 8b 7c 24 MOV EDI ,dword ptr [SI + 0x24 ]
00403497 04 67 ADD AL,0x67
00403499 8b 74 24 0c MOV ESI ,dword ptr [ESP + 0xc ]
0040349d 67 8b 4c 24 MOV ECX ,dword ptr [SI + 0x24 ]
004034a1 14 67 ADC AL,0x67
004034a3 2a ?? 2Ah *
LAB_004034a4:
004034a4 0e PUSH CS
004034a5 80 f1 f7 XOR CL,0xf7
004034a8 67 88 0f MOV byte ptr [BX],CL
LAB_004034ab:
004034ab e8 00 00 CALL LAB_004034b0
00 00
LAB_004034b0:
004034b0 c7 44 24 MOV dword ptr [ESP + 0x4 ],0x23
04 23 00
00 00
004034b8 83 04 24 0d ADD dword ptr [ESP ],0xd
004034bc cb RETF
004034bd c3 RET
It's looking weird, isn't it? Now, let's use Capstone to generate 64-bit assembly:
xor rax, rax
mov rax, qword ptr gs:[rax + 0x60]
movzx rax, byte ptr [rax + 0xbc]
mov ecx, dword ptr [esp + 0x1c]
and eax, 0x70
mov dword ptr [ecx], eax
test eax, eax
jne 0x1037
mov edi, dword ptr [esp + 4]
mov esi, dword ptr [esp + 0xc]
mov ecx, dword ptr [esp + 0x14]
sub cl, byte ptr [esi]
xor cl, 0xf7
mov byte ptr [edi], cl
call 0x103c
mov dword ptr [rsp + 4], 0x23
retf
ret
It makes more sense now. If we checked all the other functions, they would have the same structure with different values used in the xor and the initial operation being either sub or add. We can work with that variety quite easily.
What we are still missing is what values are being passed and used. We can see the procedure references [esp + 4], [esp + 0xc] and [esp + 0x14]. From the code, we can easily deduce the [esp + 4] and [esp + 0xc] are the destination and source buffers, respectively. But what is [esp + 0x14]? It's the fifth argument, and we can see from the call-site (*ptrF8)(pcVar2,pcVar2 >> 0x1f,pcVar2,pcVar2 >> 0x1f,0x6b,0,&local_10,&local_10 >> 0x1f); it's this magical constant value of 0x6b. I think we have all the ingredients to cook up the final script.
From the binary, we can extract the final bytes, located at 0x405018. Magic values are not separated by the same byte interval, but we can locate them by the marker bytes. If we encounter \x6a\x68 or \x6a\x6a starting from offset 0x835 in the binary, the next byte is our magic value.
Functions are a bit trickier, but they can also be located by the marker bytes, \x83\x04\x24\x05\xcb. We could check the bytes but since I already had capstone in place, I've used textual representation to determine if we have add or sub. The last part is to extract xor value from the function, but it can also be done in a similar fashion. To calculate the original value, we can use the following formula:
if 'add' in op:
flag.append(((result[j] ^ secret) - calls[j]) & 0xff)
if 'sub' in op:
flag.append((calls[j] - (result[j] ^ secret) ) & 0xff)
And that's all. Final script:
from capstone import *
result = bytes.fromhex('9650cf2ceb9baafb53ab73dd6c9edbbceeab23d616fdf1f0b975c328a2747de327d5955cf57675c98cfb420ebd51a298')
calls = []
data = open('meow_way.exe','rb').read()
start = 0x835
while True:
if data[start] == 0x6a and (data[start+2] == 0x68 or data[start+2] == 0x6a):
calls.append(data[start+3])
if len(calls) == 0x2f:
break
start += 1
j = 0
flag = []
start = 0
functions = []
while True:
if data[start:start+5] == b'\x83\x04\x24\x05\xcb':
functions.append(start+5)
if len(functions) == 0x2f:
break
start += 1
md = Cs(CS_ARCH_X86, CS_MODE_64)
for addr in functions:
CODE = data[addr:addr+0x44]
opcodes = []
for i in md.disasm(CODE,0x1000):
opcodes.append(format("%s\t%s" %(i.mnemonic, i.op_str)))
op = next(filter(lambda x: 'byte ptr [esi]' in x, opcodes), None)
xor = next(filter(lambda x: 'xor\tcl' in x, opcodes), None)
secret = int(xor.replace('xor\tcl, ',''),16)
if 'add' in op:
flag.append(((result[j] ^ secret) - calls[j]) & 0xff)
if 'sub' in op:
flag.append((calls[j] - (result[j] ^ secret) ) & 0xff)
j += 1
print(''.join([chr(x) for x in flag]))
And the flag:
hitcon{___7U5T_4_S1mpIE_xB6_M@G1C_4_mE0w_W@y___}