PREVIOUS  TABLE OF CONTENTS  NEXT 

The 0th Annual Obfuscated Perl Contest

Felix S. Gallo

Are you renowned for your excessive, belligerent tersity? Are you a misunderstood genius who writes Perl code that looks like it's been run through MD5? Or are you just plain evil and ornery enough to write code that's so grotesque that other people pale in fear?

At last, you have a socially acceptable creative outlet: the 0th Annual Obfuscated Perl Contest!

You are invited to participate in a contest to determine who can write the most incomprehensible, unreadable, confusing, horrific, amusing and interesting Perl code.

There are four categories. You can enter as many as you like, but may only submit 2 (two) pieces of code per category.

The categories:

  1. BEST FOUR-LINE SIGNATURE

    This award is for the best piece of Perl code that fits into 4 (four) lines of 76 (seventy-six) characters of ASCII code (not counting end-of-line newlines).

  2. MOST POWERFUL

    This award goes to the piece of Perl code which does the most with the least. The limit on bytecount is 1024 characters, not including whitespace.

  3. MOST CREATIVE

    This award goes to the most stunningly intriguing and/or ridiculously hilarious combination of obfuscation and functionality. The limit is 2048 bytes of Perl code, not including whitespace.

  4. BEST 'THE PERL JOURNAL'

    In the fine 'Just another Perl hacker' tradition, this award is given to the best code which generates the words 'the perl journal'. Case and context are not important. The limit is 2048 bytes of Perl code, not including whitespace. Winning entries will be featured on future front covers!

In addition to these four categories, the judges will award one applicant the coveted 'BEST OF SHOW' award, a certificate suitable for framing or, imaginably, hiding.

RULES:

  1. All programs must successfully run under perl5.002.

  2. Programs may only use the functionality included in the basic perl5.002 tarfile found on CPAN. No modules, patches or extensions beyond those in the standard distribution are available.

  3. Programs will be run on the judges' choice of platforms. The only guarantees about these platforms are that their perl interpreters pass all tests, they have at least 4 megabytes of memory, and they have at least 1 meg of available disk space.

  4. Submitted programs remain the credited property of the author, but may be duplicated and disseminated freely by TPJ.

  5. All programs should be uploaded via FTP to work.media.mit.edu in the directory incoming/tpj by July 15, 1996. The tar archive must contain the following items:

    a. The program.

    b. A README file which provides attribution (including the applicant's e-mail address) and tells which category the program is for. (Note: it's recommended that you provide no information about how the program works in the README file).

    c. A SOLUTION file which explains how the program works (Note: in the event a program wins, the SOLUTION file may be edited and published). The tar archive should be named

    <YOUR_NAME>.<CATEGORY_NUMBER>.<SUBMISSION_NUMBER>.tar
    For example, my second submission to the best signature category would be Felix_Gallo.1.2.tar.

    Entries not submitted in this fashion might result in confusion, hassle, and entries getting lost, so please try to abide.

    Entries will not be accepted via e-mail.

  6. The winners and their winning submissions will be announced in issue #3 of The Perl Journal, in comp.lang.perl.announce, and on various web sites.

HOW IT WORKS

The judging will work in three phases.

In the first phase, the judges will examine the code carefully without running it in order to qualify its aesthetics. Any code that's completely understandable at this point will probably not win.

In the second phase, the judges will run the code, examine the output, and then look at the code again in light of its output.

In the third phase, the judges will dissect the code with filters, debuggers, and whatever else they can think of, attempting to determine how it works. Any code that's still incomprehensible at this point will probably win.

If the judges are stumped by the end of the third phase, they'll turn to the SOLUTIONS file you've helpfully included in your distribution and attempt to use that to reverse engineer the code.

HINTS AND SUGGESTIONS

Judging obfuscation and what's 'cool', 'neat' or 'best' is a subjective process. However, here are some general guidelines which might help you design your entry.

Overuse of one particular obfuscation method risks being tedious. Entries which demonstrate breadth, range and knowledge are likely to beat entries which rely on repeated parlor tricks.

Being clever and humorous is good. As an example, a past winner in the Obfuscated C contest (our pale, weaker cousin) formatted his code in the shape of a maze; the program read its own source code in and implemented an ASCII 3-D maze walking program.

Being surprising and deceitful is very good. Bonus points are awarded for obfuscated code which is not only syntactically obfuscated, but semantically obfuscated - code which appears to do one thing but does another is deemed extremely devilish.

Being poetic is also very good.

Entries needn't contain a #!/usr/bin/perl (or equivalent), unless they use nonobvious command-line switches. Neither the #!/usr/bin/perl nor the command-line switches will count toward the character limits.

Programs which purposefully crash machines or cause system problems tend to be unamusing, so please consider saving them for the Perl System Destroyers' contest.

Here's a tiny example which would not win in any of the categories, but which demonstrates a couple of now well-known obfuscation techniques. It's in the public domain, for what that's worth.


@^T = qw, 3( 2 9 6) ;
21_PENGUINS, and print map {(1c((split//=>\"\"=>")[$^T>1])..__)[$_]}@^T

Example analysis and judging thought process:

@^T is a small red herring; although it looks like some sort of Perl special variable, it's not (that would be $^T.) Not particularly clever, but at least standardly so. qw uses comma as a quoting character, so the fake parentheses, semicolon, newline and trailing _PENGUINS are an attempt to hide a numeric array composed of (3, 2, 9, 6, 21). The judges would instantly run pattern analysis software on this sequence in phase 3, so this is not well hidden enough. Fairly clever, though. The idea of apparently starting a line with

21_PENGUINS, and print map

is poetic, so that's worth something.

split//=> is famous by now, having been used on comp.lang.perl.misc, so this is mildly derivative and obvious.

The use of a scalar reference as a string in \"\"=>" is fairly well hidden behind a wall of semantic misdirection. We'll call this clever, especially once we find out that we're using the letter 'c' from that reference to prime an alphabet generator.

The use of $^T is humorous and misdirectional considering the use of @^T.

The semantics of ..__ are interesting, neat, and somewhat unexpected. Bonus points for the fact that __ appears special and then unspecial but turns out to be special.

Disappointingly, the output is minimal, uninspiring and extremely obvious. The program doesn't do anything remarkable or surprising.

SO THERE YOU HAVE IT

Please submit early and often, and encourage anyone you know who might be interested to do the same.

Although Perl has taken some hard knocks as being a write-only language (and this contest could be construed as an unabashed celebration of that fact), the intent of this contest is to demonstrate Perl's tersity and power, while at the same time giving the creative and demented minds of the Internet's legions a fun, intriguing playground. So have fun!

Although we won't accept any entries via e-mail (FTP only, as above), questions regarding this contest or its rules should be directed to

  perl-journal-contest@perl.com

We look forward with some trepidation to seeing your code!

__END__


PREVIOUS  TABLE OF CONTENTS  NEXT