CTF Writeup - TUM CTF Teaser - selftest (Rev 10)

• Name - selftest
• Category - Reverse Engineering
• Points - 10
• Description - Baby's 1st
• Binary - Download here

This 64-bit ELF was the easiest of the RE lot. The binary is given to us but to get the flag we need to netcat, suggesting that the key is not embedded in the binary itself. Let's connect to it and try our luck:

Command Prompt

C:\>ncat 1.ctf.link 1060 some_random_stuff :( C:\>

No surprises there. Let's look at it under IDA.

It's easy to see where we need to end up to manage to get the flag. Also, this confirms that the key is not in the binary. The following is the beginning of the program:

The first block tells us that our input is interpreted as hex and is ORed with RSI, which is 0x8000000000000000. The second block takes this number and creates a character-count map of it. For example let's say we input c0ffee, this is then ORed with 0x8000000000000000, which results in 0x8000000000c0ffee, giving us the following character-count map:

With this pinned out, we take a look at the validation routine.

The validation loop operates on the character-count map in reverse order and does the following:

1. If the byte read is 0x00, jump to the next one.
2. If the byte read is not 0x00 and is equal to the character it represents, jump to the next one.
3. If the byte read is not 0x00 and is NOT equal to the character it represents, FAIL.

Simply put, an input string is valid if the occurrences of its bytes are equal to the bytes themselves. Keep in mind that OR 0x8000000000000000 might mess up the string. This means that the following are all valid strings:

• 8888888 (There's 7 of them because RSI starts with 0x8000000000000000)
• 18888888
• 13338888888

Trying the first one out:

Command Prompt

C:\>ncat 1.ctf.link 1060 8888888 hxp{g00d_m0rning_r3v3r53r5} :) C:\>