Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security Programming IT News Technology

2008 Underhanded C Contest Officially Open 160

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.
This discussion has been archived. No new comments can be posted.

2008 Underhanded C Contest Officially Open

Comments Filter:
  • I submit (Score:5, Funny)

    by Anonymous Coward on Saturday June 14, 2008 @04:26AM (#23790179)
    The Microsoft Windows Operating System, pick your version.
    • Re:I submit (Score:5, Funny)

      by Rhapsody Scarlet ( 1139063 ) on Saturday June 14, 2008 @05:15AM (#23790379) Homepage

      Um, hello? Simple? Readable? Seemingly innocent? Does any current version of Windows manage to fulfil even one of these criteria?

      • Re:I submit (Score:5, Funny)

        by dotancohen ( 1015143 ) on Saturday June 14, 2008 @05:51AM (#23790517) Homepage

        Um, hello? Simple? Readable? Seemingly innocent? Does any current version of Windows manage to fulfil even one of these criteria?

        Post the Windows source code and we'll tell ya.
        • Re:I submit (Score:4, Funny)

          by Anonymous Coward on Saturday June 14, 2008 @06:14AM (#23790593)

          Post the Windows source code and we'll tell ya.
          A rare moment when a goatse.cx link would be appropriate.
        • Re:I submit (Score:5, Insightful)

          by setagllib ( 753300 ) on Saturday June 14, 2008 @06:20AM (#23790601)
          Microsoft has already released a fair part of Windows' source as the "Research kernel". Surprisingly enough it's not bad, but it takes more than clean code to make a clean operating system.
          • by 0xygen ( 595606 )
            Yet somehow, I have not seen it leaked yet; in contrast to the Windows 2000 source code...

            Shame - I would actually like to have a look at the current MP scheduler.
            • What do you mean, leaked?

              http://www.microsoft.com/resources/sharedsource/licensing/researchkernel.mspx [microsoft.com]

              It's not exactly SourceForge but it'll get you the source.

              I don't know if that'll have the current MP scheduler though.
              • by 0xygen ( 595606 )
                I had looked there when it was first announced, and disappointingly it will not get me the source.

                You have to be from a registered academic institution which has signed up for the program, and the downloader has to be a teaching representative of the institution.

                To quote the page:
                "Use of the Windows Research Kernel requires academic affiliation with an accredited institution of higher education and direct involvement in teaching and/or research, such as being academic faculty members, system or lab administ
        • Re: (Score:3, Interesting)

          Comment removed based on user account deletion
          • Re:I submit (Score:5, Funny)

            by Tubal-Cain ( 1289912 ) on Saturday June 14, 2008 @09:14AM (#23791273) Journal

            When that chunk of the Win2K Pro source code hit the net I had to look...
            And where do you live again?

            --The IP Police
          • Re:I submit (Score:5, Informative)

            by Hal_Porter ( 817932 ) on Saturday June 14, 2008 @10:35AM (#23791819)

            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've seen that code and what you wrote is FUD and bullshit

            http://www.kuro5hin.org/story/2004/2/15/71552/7795 [kuro5hin.org]

            Despite the above, the quality of the code is generally excellent. Modules are small, and procedures generally fit on a single screen. The commenting is very detailed about intentions, but doesn't fall into "add one to i" redundancy.

            There is some variety in the commenting style. Sometimes blocks use a // at every line, sometimes the /* */ style. In some modules functions have a history, some do not. Some functions describe their variables in a comment block, some don't. Microsoft appears not to have fallen into the trap of enforcing over-rigid standards or universal use of over-complicated automatic tools. They seem to trust their developers to comment well, and they do
            .

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

  • by jacquesm ( 154384 ) <j@wwAUDEN.com minus poet> on Saturday June 14, 2008 @04:28AM (#23790189) Homepage
    This is actually a feature in 'word'...
    • Re:invisible ink (Score:5, Interesting)

      by jamesh ( 87723 ) on Saturday June 14, 2008 @06:01AM (#23790551)
      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.
  • by darekana ( 205478 ) on Saturday June 14, 2008 @04:31AM (#23790201) Homepage

    encryption utility that mysteriously and undetectably fails...
    Debian OpenSSL?

    (sorry, couldn't resist, I know they've suffered enough already)
    • Even better (Score:5, Interesting)

      by Moraelin ( 679338 ) on Saturday June 14, 2008 @05:04AM (#23790339) Journal
      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.
      • WIC (Score:5, Funny)

        by Saiyine ( 689367 ) on Saturday June 14, 2008 @06:31AM (#23790647) Homepage
        Wavelet Intelligent Compressor. And it was intellingent, indeed. It had a compression scheme so good it could compress its own .wic files down from megs to bytes. But what do you mean with "random junk", do you mean my .wic based backups could be in trouble????
  • Hide the evil code? (Score:5, Interesting)

    by Dwedit ( 232252 ) on Saturday June 14, 2008 @04:44AM (#23790261) Homepage
    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.
    • by Ethan Allison ( 904983 ) <slashdot@neonstream.us> on Saturday June 14, 2008 @04:53AM (#23790287) Homepage
      That's what makes this so interesting.
    • by apathy maybe ( 922212 ) on Saturday June 14, 2008 @05:04AM (#23790335) Homepage Journal
      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 [brainhz.com] 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.
      • by amRadioHed ( 463061 ) on Saturday June 14, 2008 @05:28AM (#23790427)

        One possible option for this contest is to hide information in the lower bounds of each pixel (stenography like)
        Sure that's easy without the source code, but how do you make setting black to something other than 0 look innocent in your source code? There's the rub.
        • Re: (Score:2, Interesting)

          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 ;).
        • You can set it to zero. That's fine but you would have to use stenography to place what was supposed to be in the black box inside the rest of the picture. Perhaps through a 'faulty' watermarking routine.
        • Re: (Score:2, Funny)

          by linal ( 1116371 )

          One possible option for this contest is to hide information in the lower bounds of each pixel (stenography like)
          Sure that's easy without the source code, but how do you make setting black to something other than 0 look innocent in your source code? There's the rub.
          Just lie really well in your comments?
        • Re: (Score:3, Interesting)

          by billcopc ( 196330 )
          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.
          • The trouble is, once you trick C into overflowing into the black buffer, how do you inconspicuously ensure that the data that goes into it still "looks" black?

            I was able to successfully keep the color data by converting each RGB triplet to 16 bits of color, then distributing them across the image in the bottom two bits of each pixel. It's pretty much impossible to tell visually that there's any extra pixel data stored in the redacted image, and the restored image looks almost identical to the original.

            When
      • by Anonymous Coward on Saturday June 14, 2008 @05:31AM (#23790433)

        Of course, I can't code C, so I don't know what I'm talking about.
        You should have begun your post with this line. Then I'd know not to listen to you. :-)
      • by Heian-794 ( 834234 ) on Saturday June 14, 2008 @10:21AM (#23791743) Homepage

        "One possible option for this contest is to hide information in the lower bounds of each pixel (stenography like)"

        Pedantry, I admit, but it's steganography that hides the information in that way. Stenography would be copying the RGB values on a piece of lined yellow paper.


        • Is that an idea?

          Make a routine that appears to copy the values (for retrieval by your own code) but accidentally/nastily hides information in the process of copying?
        • by OldManAndTheC++ ( 723450 ) on Saturday June 14, 2008 @03:41PM (#23794261)
          And then of course there is Steganosaurus, the carnivorous dinosaur that employed stealth. It could hide in plain sight by making itself look like a large fern or shrub, and then leap onto its unsuspecting prey, snapping its victim's neck in one bite of its massive jaws.

          "Scientists" tell us that the dinosaurs died out millions of years ago, but I think that Steganosaurus could still be with us today, having adapted to our modern world by mimicking small cars, or photo kiosks, or landscaping equipment. And that is why I tell my wife that I refuse to touch the lawnmower until she can prove that it isn't really a steganosaur.
      • Hate to be pedantic, but I think the word you're looking for is "steganography [wikipedia.org]"

        stenography == the action of taking dictation
      • ...lower bounds of each pixel (stenography like),
        I doubt writing very quickly (stenography) is going to help the coders. Steganography is much more likely to be useful.
    • by Ifni ( 545998 ) on Saturday June 14, 2008 @12:42PM (#23792679) Homepage
      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: (Score:3, Interesting)

        by Ifni ( 545998 )
        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 alway
      • Re: (Score:2, Informative)

        by Argilo ( 602972 )
        MD5 is reversible only if you know in advance that the input value was chosen from a relatively small set of possibilities. The recent attacks on MD5 do not reverse it; they just find "collisions", i.e. pairs of inputs that hash to one and the same value.
    • I think a good way would be to overlay the image with one of those red bordered "CENSORED" stamps. Assuming you allow for the rotation and scaling of the overlay, someone of sufficient skill and patience would be able to code in the transformations on the "CENSORED" stamp in such a way as to encode the original image within it.

      Now normally you'd only need to write to the image, but reading the original pixels could be done under the guise of antialiasing the edges, for example. With a seemingly innocuous
    • by Ken_g6 ( 775014 )

      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.

      One thing I thought of was that you could edit the image in-place to prevent copies leaking data on whatever disk you're using. Furthermore, you could write the negative of the section you're blackening before blackening or randomizing it, ostensibly to make data recovery harder. That gives you an excuse to do slightly more complicated stuff - but I'm not sure how to use it. Anyone who thinks up a good excuse for bit shifts will probably win this thing.

      Actually, if they were using PPM-P3 [wikipedia.org], in-place blacke

  • by 32771 ( 906153 ) on Saturday June 14, 2008 @04:57AM (#23790303) Journal
    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: (Score:3, Informative)

      by 32771 ( 906153 )
      Just found the following in their faq:

      "For the 2008 contest: what does âoeblocked outâ mean?

      It means those pixels are apparently replaced with non-image. It can mean overlaying a black rectangle, or any colored rectangle, or a pattern, or random noise. As long as it appears to remove those image pixels, thatâ(TM)s fine."

      Very good!
      • by jamesh ( 87723 ) on Saturday June 14, 2008 @06:58AM (#23790737)
        So it could be sufficient to replace the image with something that the inspector doesn't _want_ to look at. Sort of like a "somebody else's problem" solution. Your code would pass inspection because it would appear to have overlaid the original part of the image with the hardcoded image stored in code (the unsightly image), but there would be a bug which only copies every second pixel or something. Anyone looking at the redacted image wouldn't notice that the original data is still visible simply because they would have to look at the unsightly image too closely. They'd just rubber stamp the solution and say it passed, and then go and lie down for a bit.

        Alternatively, you could go the opposite way instead and use an image which would distract the attention of the inspector enough that they wouldn't notice. Something with breasts would probably do it.

        Can I have my $100 gift certificate now?
      • by irc.goatse.cx troll ( 593289 ) on Saturday June 14, 2008 @01:11PM (#23792909) Journal
        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.
        • Ha! I remember those photos. Do you know where I can find a clip of her doing the story on it? It sounds hilarious. I checked youtube, but couldn't seem to find it.
    • Nothing in the contest description says that the remainder of the image must remain untouched, so you could e.g. distribute the contents of the blocked out region steganographically. Also, what the previous poster said: blocked out doesn't necessarily mean blacked out.
      • Re: (Score:2, Insightful)

        by RKThoadan ( 89437 )
        The real challenge isn't how to do it, but how to do it so that someone who is reading your code doesn't realize the data is still available. That's the really tricky part.
        • It really depends on the judges idea of obvious. You could write a very simple program to XOR each pixel in the rectangle with a randomly defined constant so the data and display would look scrambled. However it's fairly well known that XOR'ing pixels a second time with the same value will unscramble it.
          • It really depends on the judges idea of obvious. You could write a very simple program to XOR each pixel in the rectangle with a randomly defined constant so the data and display would look scrambled. However it's fairly well known that XOR'ing pixels a second time with the same value will unscramble it.

            Using XOR was my first thought, as well. As you say, it's relatively well-known that XOR is reversible. What is less well-known, or more plausibly deniable, is a convoluted logical expression that evalu

    • It's so obvious after OpenSSL problems. You make random data, but "forget" to seed the generator. Or seed it with some value which should be time, but is in fact known value.
      • Re: (Score:2, Interesting)

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

      • How about a timestamp encoding that forgets that 2008 is a leap year?

  • by imsabbel ( 611519 ) on Saturday June 14, 2008 @05:03AM (#23790327)
    because the way it dumpes the key into the output is hidden in such a underhanded, innocent way...
    • Re: (Score:2, Interesting)

      by lbft ( 950835 )
      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?
  • ...a job, giving them full expression for their nefarious skills, at a well known software company in a north-western US state, where they can join a massive team of (unconsciously) underhanded coders.
  • by tucuxi ( 1146347 ) on Saturday June 14, 2008 @06:36AM (#23790663)

    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 [debian.org] for that.

  • This is scary (Score:4, Insightful)

    by LaughingCoder ( 914424 ) on Saturday June 14, 2008 @07:24AM (#23790813)
    OK, it is generally believed that OSS is inherently secure because so many eyeballs can examine and vet it. But as this contest shows, it is possible to include backdoor behavior "in the source for everyone to see" without it being discovered. Oh, and note to self, don't download any open source image editing software in the future ...
    • No one (competent) claims that the fact the source is open alone makes it 100% guaranteed to be secure. Debian's done a wonderful job of reminding everyone of this not to long ago. However it does increase the chance that any problems - purposeful or otherwise - are caught sooner than if no source code was available to anyone but the original coders. Debian's done a wonderful job of reminding everyone of this, too. Open source software is more likely to be secure with more eyes looking at the code, but
    • Re:This is scary (Score:5, Insightful)

      by Haeleth ( 414428 ) on Saturday June 14, 2008 @09:40AM (#23791451) Journal

      OK, it is generally believed that OSS is inherently secure
      No, that's a popular strawman argument used by opponents of OSS. There have been enough vulnerabilities found in OSS that it is trivially obvious that any such claim is false, and no serious OSS proponent would dream of saying any such thing.
      • Are we creating the anti-strawman?
        -It's generally believed that OSS is inherently secure, however we've found that...
        -No! Strawman! OSS is an insecure piece of crap!
        -Liar! OSS rocks! It has no flaws at all!

        (thus we make the other guy defend our POV)
    • as this contest shows, it is possible to include backdoor behavior "in the source for everyone to see" without it being discovered.

      That's one way to look at it.

      Another way to look at it is that this is a (somewhat whimsical) way to test the limits of hiding malicious code in open-source code. This contest, in a sense, is part of the transparency and security of the open-source method. Everyone knows that you can quite easily hide malicious code in a closed-sourced project. But this contest gives the open

      • And you really better not install any closed-source image editing software, since finding malicious code in that case is a thousand times harder.

        As this contest proves, and as anyone who has debugged code where you have the source AND a debugger and you still have difficulty finding the misbehaving code knows, the probability that code has unexpected or, worse, undesired behavior is very high, whether open or closed source. On this, I think, we can agree.

        Everyone knows that you can quite easily hide malici

    • I'm looking at the Runner up entries in the the 2007 contest. In these they use an "Xor" Swap trick, which is a way of swapping two bytes in place without having to create a temporary storage element:

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

      The terse explnantion says this some how poisons the RC4 encryption.

      I don't get it. Is the Swap doing something else besides swapping? when does it fail? I'm not getting it

      • My guess (Score:4, Interesting)

        by archeopterix ( 594938 ) on Saturday June 14, 2008 @12:14PM (#23792507) Journal

        #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).
      • I'm looking at the Runner up entries in the the 2007 contest. In these they use an "Xor" Swap trick, which is a way of swapping two bytes in place without having to create a temporary storage element: #define SWAP(x,y) do { x^=y; y^=x; x^=y; } while (0) The terse explnantion says this some how poisons the RC4 encryption. I don't get it. Is the Swap doing something else besides swapping? when does it fail? I'm not getting it

        It is called as SWAP(A[<stuff>], A[<other stuff>]);. What will it do when "stuff" == "other stuff", ie &x == &y?

      • Re: (Score:3, Informative)

        Hi,

        Ask yourself what SWAP(a[j],a[k]) does when j==k.

      • Re: (Score:3, Informative)

        Comment removed based on user account deletion
  • by Stavr0 ( 35032 ) on Saturday June 14, 2008 @07:42AM (#23790863) Homepage Journal
    courtesy of crazy Japanese censorship laws. Google for gmask or see examples at Lecture on masking [vector.co.jp] (Yes, it's SFW)
  • Some people have had some rather disappointing experiences with that one.
  • Bug? (Score:4, Interesting)

    by Anders ( 395 ) on Saturday June 14, 2008 @09:22AM (#23791317)

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

    • Re:Bug? (Score:5, Informative)

      by Xcott Craver ( 615642 ) on Saturday June 14, 2008 @09:39AM (#23791441)

      This was indeed a bug; we fixed it after several people pointed out the mistake.

      Interestingly, this demonstrates the effectiveness of "many eyes" in an open source project, even if the contest demonstrates the limitations of informal source inspection.

  • Easy (Score:4, Funny)

    by StormReaver ( 59959 ) on Saturday June 14, 2008 @10:05AM (#23791633)
    Seemingly innocent code...that mysteriously and undetectably fails up to 1% of the time. What's the big deal? This sounds like any given day at work for me.
  • 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
  • How about this:

    declare places_to_block(constant)(array)(global)

    Function (copy places_to_block to a temporary buffer to "find the size")
    Function (screw up the garbage collection by using the wrong error catch)
    Function (abuse printf to copy the wrong number of bits to collect for entropy
    Function (Block_Places(places_to_block))(use entropy to copy "random" noise over the places to block))
  • Too easy (Score:3, Funny)

    by ObjetDart ( 700355 ) on Saturday June 14, 2008 @11:13AM (#23792079)
    utility that mysteriously and undetectably fails between 1 percent and 0.1 percent of the time


    Pfft. I don't see what the big deal is. Just about every app I've ever written does this.

  • Their definition of "blacked out" for the 2008 contest allows colored rectangles or "random noise" replacing the part of the image to be blacked out. The latter would allow doing something like a crypting of the chunk of the image (in the guise of creating random pixels, of course). In that case, everything could be fully restored; no need to just hide things steganographically in a few low bits of black or anything.

    (Of course, the challenge of making the program appear to be doing something else is a key
    • All you would have to do is have an improperly seeded random generator. The SSH business would be good. Extra points if you actually *use* that code. Even better if you document where you got the code from, but "forget" to get the latest version from CVS. Then, all you have to do is transform the bits in some fashion with the random values (instead of overwriting them). Then, all someone needs is the blacklisted SSL keys to completely restore the original image.

news: gotcha

Working...