Cedric’s Cruft

Disclaimer for legal people: “I” and “me” are nicknames in this blog post. They refer to a person who may or may not be me, myself, or I.

During the HITB conference (Hack In The Box) in Amsterdam last week, a Capture The Flag challenge was organised. Six categories were available of which you could solve challenges: Web, Binary, Network, Crypto, Misc and Special. Together with Kinine and Flunk, team hDs secured a 7th place in the CTF ranking.

Binary analysis is not exactly the field I feel most comfortable at right now, but it has certainly captured my interest lately. The binary for the first challenge we were confronted with (bin100), simply outputted a lyric line once every second. After a certain amount of time (too long), the binary will eventually display the solution.

Download the binary: bin100.elf

Analysing the binary

Here’s an overview of a strings run on the binary. It may not seem like many lyrics, but they’re just repeated over and over again. The line “OK YOU WIN. HERE’S YOUR FLAG: “, is not actually followed by the solution we’re looking for (would be a bit too easy, wouldn’t it). So how do we get the actual key?

Time is of the essence, so let’s get going (literally, you’ll see). First, we ran the binary through IDA Pro to see which function names are in there. Here you see an overview of .symtab and some externally imported functions from GLIBC:

Not much interesting. It seems like the whole program’s functionality has been compiled into the single main() function. Some functions from the standard library are being called (time, srand, putchar, sleep, rand). The main function consists of a gazillion branches.

GDB jumping

Here you see an excerpt of two locations that were of specific interest: 0x4007E8 and 0x400803.

The first (0x4007E8) seems to display a key, while the second (0x400803) seems to output our flag. Let’s try jumping to those addresses using GDB:

It was a long shot, but the outputted flag is still garbage when we jump to 0x4007E8. Jumping to 0x400803 immediately segfaults. Not what we want.

Overriding time() and sleep()

We then proceeded by attaching a debugger and follow the program flow dynamically. You can do as such using gdbserver and remotely attaching to the process with IDA’s Remote GDB Debugger tool. Doing that, revealed that the lyric lines were being looped (no surprise there). At the end of each iteration the line is printf’ed, followed by a call to the sleep() function. The special characters you see in the screenshot are the music symbols.

At first thought you would want to NOP the sleep() function, or replace the MOV edi, 1 by MOV edi, 0 to disable the sleep function. This is not possible because the program keeps track of the elapsed time, and the needed key to output the flag relies on this time (correct me if I’m wrong). Since time is limited and my knowledge of assembly isn’t all that great, another approach was taken rather than trying to analyse the file any further.

What if you could fake both the sleep calls and elapsed time, tricking the program into thinking it has actually slept for the required number of seconds? You can do that by overriding GLIBC’s sleep() and time() functions very easily: create a C file that contains the functions you want to override, and make them have the same signature. Just increment the time with one second on every sleep() call, without invoking the underlying sleep() function. Then compile it into a shared object and preload it using the LD_PRELOAD trick. When you’d run the binary, the sleep function will be NOP’ed, while it still increases the elapsed time.

In the above screenshot, you can see the C file being compiled into a shared object and then preloaded. It does all the necessary iterations, followed by the printout of our flag, p4ul_1z_d34d_1z_wh4t_th3_r3c0rd_s4ys!

NOP’ing the printf statements

For the attentive readers: you don’t see any lyric lines because we NOP’ed the aforementioned foregoing printf calls (printing all the lines takes a lot of time).
This can be done in IDA (although definitely not its best developed function), by first undefining the instruction call ___printf_chk in 0x7B7 (0x4007B7 if you like). You can then use the patch function (Edit > Patch > Change byte), and replace the call with 0x90, which is a NOP. Newer IDA versions don’t display the Patch submenu at this moment, but you can bring it back by editing idagui.cfg and setting DISPLAY_PATCH_SUBMENU = YES. Then produce a DIF file (File > Produce file > DIF), and patch your binary with it. It doesn’t work with the Unix patch utility, but you can use this gist.

That seems rather difficult for applying a simple patch. Surely there are better solutions (comments are welcome). You could just as well use a hex editor. P.S. A nice tool that can also help you getting the correct assembly for your instruction, is radare2.

Download: original bin100.elf binary, printf patch file, patched bin100.elf binary, time.c preload