Subject: The Perl Journal contest #2: Obfuscated Perl
From: [email-masked] (Jon Orwant <[email-masked]>)
Date: 22 Apr 1996 10:15:14 GMT
Newsgroups: comp.lang.perl.announce,comp.lang.perl.misc

Announcing ...

                      T H E  Z E R O T H  A N N U A L

               O B F U S C A T E D   P E R L   C O N T E S T

          http://work.media.mit.edu/the_perl_journal/contest.html

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 
Zeroth 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 
    The Perl Journal and the judging committee.

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_HERE>.<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 {(lc((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 first 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 do not accept any entries via e-mail (ftp only,
as above), questions regarding this contest or its rules
should be directed to [email-masked]

We look forward with some trepidation to seeing your code!

Felix Gallo
The Perl Journal