HITCON 2021 – mercy

Recently we(retirees) played Hitcon and mercy was the challenge I solved during the competition, and this is how I did it. At first, I checked the file and saw raw binary data, which I didn’t find interesting, but after a while, my teammate sent a link of legitbit^[1]https://blog.legitbs.net/2017/10/clemency-showing-mercy.html and said he thinks it should be a cLEMENCy challenge. I searched to find out more and skip reading the whole documentation and details. Josh Watson‘s blog post^[2]https://blog.trailofbits.com/2017/07/30/an-extra-bit-of-analysis-for-clemency/ gave me a good perspective about it. After checking the resources, I chose the IDA with Chris Eagle‘s plugin^[3]https://github.com/cseagle/ida_clemency that was handy and easy to use:

After checking the instructions, I used documentation to understand the code. It seemed almost easy and straight to understand. Enter the check_flag function and return with TRUE to capture the flag.

Analyzing the check_flag function showed a function which seemed to initialize something in a loop of 512, then a block with some arithmetic and logic things, and then a check for some data with 27 (probably the flag), and some compare sequences which seemed correct flag against hardcoded one to me.

I used the clemency-emu^[4]https://2017.notmalware.ru/89dc90a0ffc5dd90ea68a7aece686544/clemency.tar.bz2(Official from legitbs) to run the program thru clemency-emu -s ./mercy, it said Error during IO init: unable to read flag file, so I created flag file and filled it with hitcon{1234567890123456789}. This was the result of the program:

At first, I didn’t notice what happened after some trial error understood the non-Ascii string is NO\n actually (it's 9-bit and middle-endian). I thought it was possible to implement a timing attack(something like that) on the challenge because it showed the execution time, which means more time on correct char, but after spending the time on this theory, it failed, and I gave up. There was no way but debugging. I started clemency-emu to debug the file. Here is the command list:

Useful commands for me were bp, bd, db, dt, t, g, and wt while checking the code flow with IDA. I traced the whole lines, bp, and bd until 0x60B4. It was where we met what we needed:

It reads the input flag from R08, then XOR it to 0x17f, loads R09 from somewhere in memory, adds the XOR result to 0(which was another memory), and finally stored the result to R09:

What was 0x17F? It was a table of numbers created right after we entered on check_flag function at 0x5F19, this block repeated 512 times to create the table:

Fortunately, it didn’t change by modifying the input data. So, we can save them by setting a breakpoint on 60BA where the program wants to XOR input data with the key:

Here is the full dumped key:

0x17f, 0x183, 0x193, 0x60, 0x4a, 0x1f6, 0xbc, 0xe, 0x103, 0x12f, 0x1d3, 0x1e1, 0xa3, 0x130, 0x15a, 0x175, 0x7, 0x162, 0x159, 0x129, 0x93, 0x1be, 0xcc, 0x16b, 0x2, 0x22, 0x27

Then, we had to find the correct sequence of data. 60E4 was the first comparison routine, then 60FB, and so.
What I did was fix the content of the memory before each comparison. I always preferred the quick and easy(even if it took much time!) way 😛

After collecting the correct data, I wrote a python script to bruteforce the flag:

key = [
	0x17f, 0x183, 0x193, 0x60, 0x4a, 0x1f6, 0xbc, 0xe, 0x103, 
	0x12f, 0x1d3, 0x1e1, 0xa3, 0x130, 0x15a, 0x175, 0x7, 0x162, 
	0x159, 0x129, 0x93, 0x1be, 0xcc, 0x16b, 0x2, 0x22, 0x27
	]

dat = [
	0x117, 0x101, 0x0e8, 0x0eb, 0x110, 0x0a8, 0x16f, 0x1a7, 0x10e, 
	0x02d, 0x1e2, 0x166, 0x1fa, 0x103, 0x03f, 0x186, 0x1bc, 0x111, 
	0x071, 0x189, 0x02d, 0x1b8, 0x060, 0x16f, 0x1d2, 0x031, 0x05e
	]

flag = 'h'
for idx, c in enumerate(key):
	for c in "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+_-{}":
		if (((ord(c) ^ key[idx]) + dat[idx-1]) & 0b111111111) == dat[idx]:
			flag += c
print flag

#hitcon{6d0fe79f2179175dda}

clemency ctf hitcon