I'm kinda annoyed that the judge completely misread my entry. I had it so that data was leaked out of a function that could not possibly leak data, via a malloc side-channel attack (ala HeartBleed).
Instead it got judged as being a 'simple buffer overflow'.
Someone below asked what makes this different from the Obfuscated C contest. In this contest, the idea is to make code that looks very clean and innocent. Entries that hide their behavior in weird ugly macros or just general C complexity are not really in the spirit of the contest. I tried to make my entry very clean so that there is obviously no malicious code anywhere in it.
SPOILERS. If you want to see if you can spot the tricks, do not look at this page; it only contains solutions, it doesn't contain the programs themselves!
Interesting. I think "pio" is the onomatopoeia for tweet in Japanese too. It's the noise cash registers at Tokyo's Inageya supermarkets make when you use their points card.
Is that really backwards? The contest is "underhanded", not evil. Underhandedness can be used for good or evil, and it is good that this year's contest reminds entrant of that.
Yeah, that really spoiled the fun for me. I wanted to read through and see if I could spot the tricks myself, but it keeps giving the answers before even showing the code that the trick is in!
Or just more interested in our field of digital sorcery. Either way, I agree it's good to see more women in these things. Having different types of people makes things more interesting. And often more surprising. :)
haha, the winning entry is pure genius! It was so difficult to follow, and the code that produces the bug is only viewable if you examined the macro expanded source code - and the macro used _all_ look like functions, so a casual code reviewer probably won't recall them being macros in the first place.
Yes, all decent C/C++ IDEs (Eclipse, Visual Studio, CodeBlocks) use different syntax highlighting for macros and functions. The problem with nested macros like this is a common bad programming practice, highlighted here in the C/C++ FAQ : https://isocpp.org/wiki/faq/inline-functions#inline-vs-macro...
To do that you need to do quite a bit of what the compiler does. For example, you need to know the include search paths, which can get modified by compiler flags, and you need to know what flags got set on the command line, for example to discriminate debug from release builds or to specify C99 compliance.
So, you basically need an IDE to do robust C syntax coloring.
I have personally never come across this. Moreover, "common" C editors are vanilla vim and emacs, which don't actually know what's a macro and what's a function without customization (ctags &c).
For that kind of code analysis one wants more detailed information about the source file, like an AST, but Stallman has forbidden that level of detail to be exportable from gcc, and more recently squashed efforts at deeper emacs/clang integrations, both on ideological grounds.
I'd also imagine that since the contest is framed as getting around code reviews the code would be inspected using some other source code display tool. These tools certainly wouldn't do any kind of context-sensitive reasoning.
In this contest, you are to intentionally insert a difficult-to-detect bug into otherwise legible code. In the obfuscated C contest, you are writing obfuscated code.
Why is it underhanded to let out people whose government has locked them in cages? Sounds like freedom to me. Now where's the nearest maximum security prison...
Instead it got judged as being a 'simple buffer overflow'.
Grrr.