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.
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.
+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.
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);}
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.
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.
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.
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
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
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!
38 comments
[ 6.7 ms ] story [ 111 ms ] threadEdit: This one is fun to look at too: http://www.ioccc.org/2012/hamano/hamano.c
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
Apparently so. Wow.
http://web.archive.org/web/20040602202609/http://homepages.c...
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.
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.
Obfuscated C And Other Mysteries by Don Libes
http://www.amazon.com/Obfuscated-Other-Mysteries-Don-Libes/d...
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.
I'm specifically thinking of libpng, but I'm sure one could think of other meaningful examples.
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.
Having said that :-), if the entry has merit on its own and not just because of the external dependency, then it might "win".
This contest is great. I'm so glad it's happening regularly again :)
Sorry about the commit messages. Think of them as part of the obfuscation ;)
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.
Manual: http://uguu-archive.appspot.com/homura/manual.html
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...
IOCCC is back!
Check this out
These are also the winners for "language you currently hate" clear code contest.