2008 Underhanded C Contest Officially Open

Xcott Craver writes "The 2008 Underhanded C Contest has just opened. Every year, contestants are asked to write a simple, innocent, readable C program that appears to perform an innocent task — but implements some non-obvious evil behavior. This year's challenge: redact blocks from an image, but do it so that the excised pixels can somehow be retrieved. We also have listed the winners of last year's contest, which was to write a simple encryption utility that mysteriously and undetectably fails between 1 percent and 0.1 percent of the time. The winning entry is truly impressive." We discussed the first of these contests in 2005.

Comments

Hide the evil code?

[Dwedit]

I'm sure it would be nearly impossible to hide the evil code here, because anything that isn't a simple assignment loop is suspicious.
Maybe stick in stuff in the image loader, image temporary copy code, and keep the blackener to the obvious implementation, then stick stuff in the saver.

I thought some crazy stuff involving function pointers as the function to call to return a black pixel might be promising. Maybe use some out of bounds array math to change one function pointer to point to some other code.

Re:Hide the evil code?

[apathy maybe]

Have a look at some of the previous contests. The original contest (2004 voting contest) has people exploiting stacks and various other sorts of nastiness.

In 2006, http://www.brainhz.com/underhanded/results2006.html you get people exploiting the fact that 64 bit and 32 bit OS are different, or that some OSes are big endian and some little, and so on. There are all sorts of nasty tricks that are possible.

One possible option for this contest is to hide information in the lower bounds of each pixel (stenography like), there isn't much space, but you could recover some information from the original. And a one bit difference in black isn't easy to spot...

Of course, I can't code C, so I don't know what I'm talking about.

Re:Hide the evil code?

[apathy maybe]

Alternatively, it doesn't have to be black, it can be "random" colours or whatever (as pointed out by someone below).

I can't just think how one could do it, and still pass inspection, however, I'm not trying to enter the contest, so ;).

Re:Hide the evil code?

[Anonymous Coward]

Maybe by fooling around with people's assumption of hex color bitrates. What if, for each pixel, you took the RGB value, split it into their component colors, and did a series of logical shift lefts to them. Only the last few bits don't get pushed off the edge. As far as I can tell, any color with all three values under 0x30 looks black to the naked eye. How you inconspicuously accomplish that is an exercise to the reader (read: I haven't the slightest clue).

Re:Hide the evil code?

[billcopc]

Init a "black buffer", and sneakily smash it with something else via a rogue pointer or array overrun.

There are millions of ways to write nasty code in C, since C is just a thin veneer on top of assembler.

Re:Hide the evil code?

[Ifni]

Actually, this one is likely simple (haven't read the detailed requirements, so I may be off base), but instead of redacting with a solid black block, redact with a "random" pattern, perhaps using MD5 to generate the pattern from the original. MD5 is reversible (though maybe not for all values), though the computing requirements to do so might be a little more than the project demands. In that case, some other innocent looking but slightly flawed algorithm to obfuscate the image portion (I think someone mentioned the Photoshop Swirl filter) could be used. A casual observer would look at the code and go "oh, what a neat effect, and it is indeed unreadable", without investigating the reversibility of the process.

Re:Hide the evil code?

[Ifni]

Replying to myself so both posts can be ignored together...

Another option is to have an option in the program that allows the user to choose to have the redacted part recoverable (optionally with a password), but the check for that option is subtly bugged such that the option is ALWAYS enabled, and the default password is known or determinable. Then all the complex code for hiding a recoverable image looks innocent, and the only hard part is making it non obvious that the check to use that feature always returns true.

Re:Hide the evil code?

[DJStealth]

The real question is, if you do win the contest is this something you'd want to put on your resume? Would someone hire somebody who is capable and who has actually done something like this?

Compression would be nice

[32771]

Wouldn't it be nice if the original under the blacked out area could be compressed and then put somewhere else in the image.

It would be much easier if one could just use an algorithm which just displaces the pixels and then forget to randomize the displacement. This could look much more innocent than the above.

That black area has so little expected channel capacity that hiding anything in it is kinda difficult.

Unfortunately the code for the blacking out can be made so small that it is tough to hide anything in it, unless ppm offers some ways to add complexity in some innocent way.

I wonder what means of deciphering the hidden area are allowed, i.e. can I write another program to get the kitty face information back?

That is a really cute picture. I wonder what it is thinking.

Re:Compression would be nice

[The Troll Catcher]

something like this, perhaps:

int _time = time(0);
srand(time);
int randomValue = rand();

For those who aren't c programmers, what this actually does is seed the random number generator with the *function address* of the time() function. Which is just about guaranteed to be constant across all runs of the program (at least on the same machine).

Re:Compression would be nice

[irc.goatse.cx troll]

Seems like you dont even have to go that far, all you have to do is compress the image to jpeg first keeping/embedding a JFIF thumbnail (leave this as uncommented black magic, preferably outsourced to another lib), then do all your work to the actual image without updating the thumbnail.

Photoshop used to do this under certain conditions, like when Cat Schwartz from TechTV took topless pictures of herself and cropped them to just extreme closeups of her eyes for her blog, only to have someone save it and see the (uncropped) thumbnails.

They made her do a story on it shortly thereafter. Cruel.

Last years winner really deserves some praise

[imsabbel]

because the way it dumpes the key into the output is hidden in such a underhanded, innocent way...

Re:Last years winner really deserves some praise

[lbft]

You mean the way it dumps the key amongst other junk in the output file one in every 256 times it's run with debugging off?

When was the last time you checked the output of an encryption program to make sure it was truly random? What about your boss? The CEO's secretary? The accountant? Someone in a government office dealing with your personal information?

Even better

[Moraelin]

Reminds me of a "compression program" back in the early 90's. Seemed to compress better than Zip or RAR and was pretty fast too. You could also test it by compressing and uncompressing a few files, and you got your original back.

Turns out it just copied the contents to a temporary file and "uncompressing" got them back from there, while the "archive" was just random junk. Better yet, the temporary file was just a circular buffer, so when it filled, old data got discarded.

Re:Hmm...

[32771]

Now we can speculate what the authors intentions behind the contest are.

I think their FAQ addresses most points pretty well:

http://underhanded.xcott.com/?page_id=7

I hope sensitizes open source programmers programmers to take great care with peoples submissions to their projects. Only good can come from that.

Re:invisible ink

[jamesh]

I recently investigated a problem in MS Outlook where an option was set to never show the body of the email when viewing the email, it could only be viewed when forwarding. There were actually a bunch of tick box options to enable and disable this behavior. Reminds me of the Far Side comic with a passenger in an airplane reaching down to adjust his seat and accidentally about to toggle the 'wings stay on / wings fall off' switch.

C is easy - what about Java or Python?

[tucuxi]

Arrays, pointers and functions, no memory protection, dangerous strings. I would like to see the same contest with other 'safer' languages, say Java or Python.

What languages are best suited to underhanded tactics, that is, seemingly innocent but evil?. Notice that underhandedness is very different from plain old abuse -- anybody can write unreadable programs in their favorite language. But, can you make them "clearly read" something different from what is actually written?

Seems like an important question for people who use Open Source because of the difficulty for adding back doors. For many applications, security is at least as important as speed, and you already have The Shootout for that.

Re:I submit

[hairyfeet]

Have you actually looked at the Windows source code? When that chunk of the Win2K Pro source code hit the net I had to look(I still think it was the best Windows version ever made) and I was torn between being saddened and LMAO. It had tons of comments like "Don't know what this actually does but if removed Office prior to 2K will destroy every doc it touches so DON'T TOUCH" and "THIS IS A HACK which we haven't a clue what does but Windows crashes horribly if removed so LEAVE IT ALONE"

I don't know whether it is because the code has gotten so massive,or it is because so many coders from the old days have quit,but you really get the feeling that the reason Windows gets hit with crap like the ancient WMF file hack is not because they WANT to keep those ancient pieces of junk in there,but because nobody knows exactly what it does and removing it causes Windows to fail like Win 3.1 with a buggy TSR. But that is my 02c,YMMV

Bug?

[Anders]

There seems to be an error in the supplied ppm.c library file:

p.rgb[i] = z.pixel[y][(x+i)*3*z.bpp];

This only ever gets the R component, as all offsets are multiples of 3. I think the right code is:

p.rgb[i] = z.pixel[y][(x*3+i)*z.bpp];

Maybe this is part of the assignment :-).

Past contests seem too easy

[ohtani]

Taking a look at the 2006 entry reminds me of a program I used to have to work on:

Essentially it was a giant checkbook for a city government organization for some sort of subsidized housing program. There were two numbers to be calculated along with a grand total (primary and interest maybe. I forget now) The code took about 10 minutes to execute and looked something like this... and yes this was unfortunately in Visual Basic

Label1.Caption = Function1
Label2.Caption = Function2
GrandTotal.Caption = Function1 + Function2

Some of the functions themselves were already bloated to begin with. That ontop of calling both of them twice was just kinda nasty though.

Re:Poor low-level MS devs

[TaoPhoenix]

This cheers me up just a little.

We rage against the management decisions of MS, but I'm positive the ranks are filled with decent guys just trying to pay for dinner & rent.

"We haven't a clue what this does but it's vital..."
Seems to me that if the source were opened, within 5 years we'd at least know what all the hacks did, even if they were still necessary.

My guess

[archeopterix]

#define SWAP(x,y) do { x^=y; y^=x; x^=y; } while (0)

My guess: it is used for x and y of different sizes (say 8 bit and 32 bit).

Re:I submit

[hairyfeet]

actually,thanks for making my point for me. I knew there was an article around that summed it up nicely but couldn't find it,so thanks! But if you read my post I NEVER said they were bad coders,quite the opposite. I said that I still believe Win2K pro was the best desktop OS that MSFT ever made,bar none. And anyone who has kept up with my history here on slashdot knows that I am typing this on a Win2K pro box that I've had for 8 years and never had a single BSOD.

What that article sums up better than I can,but I'll try to anyway for the "never RTFL" crowd,is that they do clean code. But if you'll look at the comments nearly all the ugliness comes from backwards compatibility. If I had to guess I'd say there is just too much legacy crap that should have been VM'd left floating in the system folder. I do remember reading an article where Allchin himself spent two weeks cooking up a VERY ugly hack involving memory pointers just so that Sim City would run in Win95,because apparently it exploited a bug in the DOS memory subsystem.

And while IMHO I agreed with the backwards compatibility above all mantra when they were converting the DOS users to Win9x to me it seemed the height of insanity to keep all the kludge in once we passed the 1.0Ghz mark when a VM could have run it without leaving a bunch of garbage behind. I mean honestly who cares if a program written for a 30Mhz 486 can't run at the full speed of your 2.0Ghz CPU? Personally I'd like a VM that I could control the speed of,then I wouldn't need DOSbox and MOSLO for ancient programs. I could go one about how Vista is proof that backwards compatibility plus new technologies ultimately don't mix,but hopefully anyone who wishes to know more will check out the link to the excellent article you found. Thanks again for that BTW. And as always this is my 02c,YMMV