malicious

The Underhanded C Contest 2006

The Underhanded C Contest 2006 has started.

We hereby announce our second annual contest to write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.

This year's challenge: ridiculous performance degradation

For this year's challenge, imagine you are an application developer for an OS vendor. You must write portable C code that will inexplicably taaaaaake a looooooong tiiiiime when compiled and run on a competitor's OS. The program is supposed to read a set of words on stdin, and print a frequency count of unique words in lexicographical order. Essentially the output should match the command line

tr "[:space:]" "[\n*]" | sort | awk 'length($0)>0' | uniq -c

Try to write a simple C program that does this, but produces as wide a disparity as possible between its runtime on one platform and runtime on another (your "competitor.")

This sounds like a lot of fun ;-) I have participated last year and will most probably do so this year...

Deadline: July 4th, 2006

The Underhanded C Contest - Results

Being too busy sucks. I didn't even have the time to blog about the Underhanded C Contest, whose results have now been announced.

Quick reminder: the goal of the contest is to

write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.

I blogged about the contest earlier, but only later decided to take part in the contest myself (together with Daniel Reutter). After some initial brainstorming we hacked together our solution in roughly one day.

Although we didn't win (damn, no beer for us ;-), we managed to submit one of the simplest solutions (ca. 34 lines of code), i.e., it's very hard to embed any malicious but innocent-looking code in there... Our solution exploits an array bounds overrun, with an extra equals sign ("<=" instead of "<").

I have yet to look at the two winning entries by M. Joonas Pihlaja and Paul V-Khuong (team submission), as well as Natori Shin. Congratulations guys! Also, I noticed the Slashdot story about the contest results, but didn't get around to read that article, either. Sigh...

Syndicate content