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...

Freedom Is Not Having To Ask Permission

Did you ever wonder why you're involved in the Free Software community? What makes you spend all this time on programming, patching, packaging, documenting, bug-fixing, and generally improving Free Software? What keeps you motivated?

Dave Neary of the GNOME project has a very good explanation: Freedom.

Free software taught me that I could learn and grow without someone telling me that I could.

Freedom is not having to ask permission.

Just Ten Minutes Without a Test

This is what happens to you, if you try to perform too many code changes at once. It's usually better to perform small, incremental changes and run your unit tests (hopefully many) after each of them to check if you messed up.

I don't want to even think about cases where you don't have any test cases at all. In such a case, debugging nightmares are preassigned.

I'm currently involved in multiple Ruby projects where I make extensive use of unit testing. Ruby ships with a built-in, easy to use unit testing library called Test::Unit, so you really don't have any excuse for not unit testing your code.

Syndicate content