French readers may be interested in my last article published in GNU/Linux Magazine 197 (October 2016). It explains in details the main tricks I used when I wrote my IOCCC 2015 winning entry.

The source code

Thanks again to Tristan, Pierre, Henry, Timothy, Elodie and Colin. You helped me make the trickiest parts much easier to understand!

The source code of IOCCC 2015 winning entries have been published recently. My source code is here.

Quick start

You can compile prog.c using gcc -o prog prog.c and start playing with the resulting binary (I tested in on Ubuntu and FreeBSD).

It looks like this:

Running ./prog

This actually demonstrates the interactive mode.

Alternatively, you may specify the input data (e.g. echo 'hello' | ./prog). In this case no prompt is displayed and the rendering starts immediately.

The program uses the braille patterns range of the unicode standard: this allows to consider each terminal character as a tiny 2x4 bitmap.


The program is obfuscated in various ways. Let me explain the most unusual one.

At some point, the program swaps file descriptors 0 (usually stdin) and 1 (usually stdout). This is achieved using dup() and close() function calls. As a result, functions such as printf(), puts(), write(1, ...) will write to stdin instead of stdout. Depending on the way you start the program, writing to stdin may succeed or not:

  Command Line Stdin is… Writing to stdin will…
(A) $ ./prog current tty (same as stdout) succeed!
(B) $ ./prog < file.txt file.txt (opened read-only) fail.
(C) $ echo test | ./prog the pipe (opened read-only) fail.

In the code, the program always tries to print the 2 chars of the interactive prompt, using write(1,"> ",2). It succeeds in case (A) and fails silently in case (B) or (C).

This is how is handled the interactive vs non-interactive modes. The program actually always acts the same, but a complex side effect of the file descriptors swapping makes it behave differently depending on how you started it.

What’s next?

For more details about secret features or obfuscation aspects you can check out the hints file which compiles judges’ comments and my own explanations.

I also recommend looking at the other winning entries, some of the authors have been very imaginative!

These last few years, I have been working on an experimentation platform called WalT. From the user point of view, a WalT platform is a set of remotely managed nodes where you can deploy an operating system (so-called WalT image), run a distributed experiment, and collect experiment logs.

WalT architecture

WalT relies on docker for easy packaging, modification, and sharing (on the docker hub). of WalT images. The sharing aspect makes experiments easily reproducible. Nodes are low cost single-board-computers (Raspberry Pi B/B+, support for other hardware should come soon). The WalT platform is itself very easily reproducible (it is made of low cost components, free and open source software, and installation is automated). You can set up your own in a few minutes.

You can get more info on the WalT website. We presented WalT at a seminar recently, our talk material (pdf file and two videos) is available on the resources page.

The International Obfuscated C Code Contest (IOCCC) started in 1984. Candidates have to propose a C program doing something interesting in the most obfuscated way possible. (There are a few rules to follow, most notably limits abouts the source code size.)

I first heard about this contest many years ago, I think it was around 2003, because Fabrice Bellard (author of qemu, tcc, some maths-related things, etc.) mentions on his website he won it in 2002. Looking at the winning entries, I was really impressed.

This year, I decided to give it a try myself. And this was apparently a good idea!

The source code and related comments of the winning entries for 2015 are not published yet. They should be published in a few weeks.

I wrote a tool called debootstick that was just accepted in Debian: see here.

Thanks to Alessio Treglia for mentoring!

debootstick allows to generate bootable systems (i.e. LiveUSB systems) easily. For example, debootstick can be used to turn a docker image into a bootable USB.

The other tools of this kind cannot be used in this kind of scenario because their process includes the generation of the OS content. On the contrary, debootstick takes a directory containing such an existing system as input. This makes debootstick good at collaborating with other tools (debootstrap, docker, etc.).

You can get more info about debootstick on its github page and wiki.