http://www.perlmonks.org?node_id=299050

snowfalcon has asked for the wisdom of the Perl Monks concerning the following question:

I'm using perl on unix and want to make the content of perl scripts unreadable when being in a production environment. More or less the compile to exe idea. Apart from disabling read/execute access to a file, I am looking for a way to "compile" the script in a matter, so that the content of the script is unreadable for anyone but the script itself should still give the desired output. Any ideas? I'm looking for an easy to implement solution without making too many adaption to the current environment.

Replies are listed 'Best First'.
Re: simple encryption for perl files
by Corion (Patriarch) on Oct 14, 2003 at 08:36 UTC

    Hello and welcome to the monastery, snowfalcon!

    This topic comes up often, and Super Search holds a trove of many interesting attempts to hide the source code, for example Closing Perl Source and Can you prevent MO=Deparse.

    The common and most renowned way to hide your source code from the prying eyes of the public is Acme::Bleach by master wizard and crocodile wrangler Damian Conway.

    There are also deobfuscators, for example Acme::Floral and B::Deobfuscate by diotalevi.

    Update: Added examples found via Super Search, fixed module names

    perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ; # The $d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider ($c = $d->accept())->get_request(); $c->send_response( new #in the HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' # web
Re: simple encryption for perl files
by davido (Cardinal) on Oct 14, 2003 at 08:36 UTC
    See the Obfuscation section for details on rendering functional programs illegible. You get bonus points for doing it by hand, without the aid of unPerlish mechanisms.

    If that's not quite what you had in mind, check out the Q&A section: How do I compile my script so that it becomes a standalone executable?, or perlfaq3: "How can I hide the source for my Perl program?" Or see the responses to Protecting Perl Code and Source Hiding. Then wake up and remember this is Perl.

    If you plan to figure out a scheme for hiding your source, be sure that any use of CPAN modules in your program meets the requirements of the modules' licenses. Though the modules are available to all who comply with the licensing, remember that they wouldn't be available to you if their authors had ventured down the "hide the code" road. Even Perl's source code is readily available to the world, so long as the license is respected. I am pleased that Larry and gang didn't take the Gates approach to language design. ;)

    Update: Re-edited final paragraph to better capture the spirit of tilly's followup message's suggestions.


    Dave


    "If I had my life to do over again, I'd be a plumber." -- Albert Einstein
      Please don't tell people to not use any CPAN modules in a plan like this. The authors of CPAN modules each get to choose their own license, and people choose to contribute open source code under different terms for different motivations. Even if you are outraged at a given possible use, you don't get to retrofit your opinion onto other peoples' code. It is their work.

      Instead tell them that they must (both morally and legally) respect the CPAN authors' right to choose their own license, and be sure that if any CPAN code is included, that it is included in a way that meets the license on that code.

      For instance Larry Wall clearly doesn't mind if people embed Perl into proprietary programs. The Artistic License, which he wrote, goes out of its way to make it extremely explicit that this is OK so long as you aren't trying in any way, shape, or form to create any confusion about what Perl is. This is not an accidental oversight on his part, and you have no right to be outraged at people taking him up on his offer.

      While I haven't had the pleasure of meeting Larry Wall, I would summarize my impression of his opinion as, The best way to help others to learn to be nice is to be nice to them first, and besides, it's nice to be helpful.

      Incidentally this point underscores why the open source and free software movements really are different. The free software folks (Stallman, etc) believe that non-free software is an injustice. Therefore it is never OK. By contrast open source arguments say that it makes sense for lots of reasons to make software free, but don't close the door to saying that it is OK to make other software proprietary, and don't phrase anything in moralistic terms. Attempting to project the values of one onto the proponents of the other will almost always mislead you about what that person is saying or cares about.

Re: simple encryption for perl files
by castaway (Parson) on Oct 14, 2003 at 08:44 UTC
    /me throws in another link or two.

    Closing perl source,
    perl2exe - no more secrets

    ..
    And many many more.. really, if you want to produce compiled code, or hide what you're doing (for whatever reason), you shouldn't be using Perl.

    C.

Re: simple encryption for perl files
by strat (Canon) on Oct 14, 2003 at 09:41 UTC
    A free alternative to perl2exe is PAR which I use a lot, e.g.
    pp -o outfile.exe infile.pl # or under windows only, e.g with Tk (to remove the dos window) pp --gui -o outfile.exe infile.pl

    Best regards,
    perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

Re: simple encryption for perl files
by snowfalcon (Initiate) on Oct 14, 2003 at 08:56 UTC
    Ok thnx, I see that I was too lazy :)
Re: simple encryption for perl files
by vek (Prior) on Oct 15, 2003 at 00:48 UTC

    And then there's always perlcc as well.

    -- vek --