Hacker News new | past | comments | ask | show | jobs | submit login
International Obfuscated C Code Contest Winners (ioccc.org)
182 points by lelf on Oct 17, 2012 | hide | past | favorite | 37 comments



Tromp's entry is amazing.

Source: http://www.ioccc.org/2012/tromp/tromp.c

Spoiler: http://www.ioccc.org/2012/tromp/hint.html

It's based on a minimal implementation of Binary Lambda Calculus: http://en.wikipedia.org/wiki/Binary_lambda_calculus


Did he invent Binary Lambda Calculus as well?!?


"Binary lambda calculus is a new idea introduced by John Tromp in 2008"

Apparently so. Wow.


He actually first mentioned the idea as early as 2004:

http://web.archive.org/web/20040602202609/http://homepages.c...


>Tromp's entry is amazing.

It really is, which leads me to wonder how difficult it would be, to deobfuscate this into code that can be understood by the average programmer?

At least in terms of being able to say what it does, without being told.

While most would probably regard security through obscurity as bad practice, perhaps there are practical uses in certain contexts.


John asked me to review his entry prior to submission, and we had some ongoing discussion as he worked through his revisions. He initially pointed me to a "minimally obfuscated" version to analyze. I'd say it took me a good hour or so to feel like I had a pretty good understanding of its workings, and even then I still wasn't clear on some details of the I/O model and a couple other things.

Most of the evolution from that point was finding ways to reduce the code size, then finally reformatting into a lambda. I credit John for not succumbing to gratuitous obfuscation, nor gratuitous use of macros to shave bytes. I suggested to him at one point to consider reducing the entire program to a single loop. He didn't think it would be shorter and pointed out that he had made a similar transformation in an earlier IOCCC entry of his, his infamous maze program, so I believed him and didn't go through the effort to verify for myself.


When you are talking about mid to high level security, you assume that your adversary is not an average programmer, but rather a train security analasyst. A major part of that field is looking finding vulnurabilities in machine code. Based on the statement "Obfuscation is due entirely to conciseness" in the author's hint, it sound like he did not use any techniques that would have a significant effect on the generated machine code.


We hope you enjoy the 21st IOCCC results - we enjoyed judging the entries.

If you have any feedback on the competition for the Judges, please contact us using the details at http://www.ioccc.org/contact.html

Thanks. SimonC.


Just curious, since you're handy to ask: How do the judges view code that depends on external (but cross-platform and FOSS) libraries? Only Xlib is specifically mentioned in the rules.

I'm specifically thinking of libpng, but I'm sure one could think of other meaningful examples.


I don't know the official policy, but anecdotally, I won with an entry that used libperl back in 2000: http://www.ioccc.org/years.html#2000_dlowe


I love this bit of history from the hint :)

Aside: history... Larry Wall wrote the original Perl in 1986-87, the same two successive years he won the IOCCC. I hope this program helps you to realize that this was no fluke - that Perl and Obfuscation are as inseparable as, say, camels and humps.


The fact that it won for "worst abuse of the rules" doesn't help your point much. :-)


Generally we don't like lots of external dependencies. External libraries do change over time - would such an entry work 10 years from now? The judges do use and test the entries using different operating systems. What will operating systems look like in 10 years?

Having said that :-), if the entry has merit on its own and not just because of the external dependency, then it might "win".


FWIW, if anyone is curious to see the process of building my entry ("Conway's game of death") I just made the repo public: https://github.com/dlowe/death

This contest is great. I'm so glad it's happening regularly again :)


I've also posted the history (or, "scratchpad") of my winning code (2012/kang) to Gist: https://gist.github.com/3909337 (possible spoilers ahead)

Okay, it is quite cryptic and a bit unorganized (as I frantically updated the code as I saw any optimization opportunity), but it may be interesting to see how the code is gradually shorten.


Process of building my entry is mostly in spoiler.html.gz. For your viewing convenience, it's also here: http://uguu-archive.appspot.com/nyaruko/edit.html


This is really awesome, thank you for sharing it.


How did you record that?


A VIM script snapshots the file every so often, and another program turns the recording into HTML. Package for both is here: http://uguu.org/arc_homura.html

Manual: http://uguu-archive.appspot.com/homura/manual.html


Fantastic. Thanks :)


A lot of your commit messages don't make any sense. Is there any point at which the program was fully functional but non-obfuscated?


More-or-less yes. I started compressing and obfuscating the code after https://github.com/dlowe/death/blob/7fcbcabb9f69bf0cdfff4651...

Sorry about the commit messages. Think of them as part of the obfuscation ;)


There's actually a book that covers some of the old contest winners:

Obfuscated C And Other Mysteries by Don Libes

http://www.amazon.com/Obfuscated-Other-Mysteries-Don-Libes/d...


My all time favorite is Wesley's code in 1992 that prints world map (found through A to Z of C):

             main(l
        ,a,n,d)char**a;{
    for(d=atoi(a[1])/10*80-
   atoi(a[2])/5-596;n="@NKA\
  CLCCGZAAQBEAADAFaISADJABBA^\
  SNLGAQABDAXIMBAACTBATAHDBAN\
  ZcEMMCCCCAAhEIJFAEAAABAfHJE\
  TBdFLDAANEfDNBPHdBcBBBEA_AL\
   H E L L O,    W O R L D! "
     [l++-3];)for(;n-->64;)
        putchar(!d+++33^
             l&1);}


Care to share the output also (for those who don't have a C compiler handy)? Thanks!



Screenshot mentioned there too.. in 2nd page http://guideme.itgo.com/atozofc/ch13.pdf


+1 for this book - I rarely see it mentioned when it comes to C books. Reminds me of van der Linden's C book in that it uses non-traditional examples to illustrate concepts.


Fun fact: David Madore, co-author of the conspiratorial contest, actually didn't mean to obfuscate his code.

The winner page: http://www.ioccc.org/2012/grothe/hint.html

The source in french: http://www.madore.org/~david/weblog/2012-10.html#d.2012-10-1...


deckmyn.c is my favorite. That's beautiful source code.

Edit: This one is fun to look at too: http://www.ioccc.org/2012/hamano/hamano.c


hou.c is kind of neat too. Looks like a big blob, but actually forms an image via cunning use of syntax highlighting.


Is it supposed to be Kyubey? I pulled it up in vim, but the syntax highlighting didn't expose anything for me.


It is. Though it only works well if you use it like this: ./hou ansi.txt hou.c


Seems to be the same John Tromp of the Computer Go bet. http://dcook.org/gobet/


Wow, John accurately predicted the year computer Go would beat him, 15 years in advance, and made a $1000 by being slightly conservative. Nice long bet!


Amazing entries.

These are also the winners for "language you currently hate" clear code contest.


I must admit I was disappointed in last year's contest winners, namely their general focus. I thought maybe something had been lost in the years the contest was not running. But these entries are great! Binary lambda calculus? Top notch.

IOCCC is back!

Check this out

  { echo one;echo two;echo tres;}|./kang
   result: the sum in hex




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: