No... I created but didn't release B::Obfuscate. I have released B::Deobfuscate though. I'm thinking of working on a project to make deobfuscating perl especially easy by providing a nice environment with interactive symbol renaming. I'm also thinking of doing some static analysis so that symbols used as filehandles perhaps get named that or some such.

All this should tell you is that there is determined resistance to helping you make other's lives harder.

I don't know if this is what you are looking for, but Damian Conway has a couple entertaining modules such as Acme::Morse (which converts your program to morse code) and Acme::Bleach(which converts your programs to series of spaces and tabs, IIRC). These a most definately for fun. Please explain more about why you want to do this so we can better address your question.

HTH

Please do a Super Search do find out why people hate answering questions like these. The topic has come up a lot of times already.

See e.g. Closing Perl Source (quote from a reply: Oh good grief, not again) and the discussion at perl2exe - no more secrets. There is even a FAQ entry: How can I hide the source for my Perl program?.

-- Mike

--
just,my${.02}

It's theoreticly very difficult to get right. In fact, I don't think you can do it without compiling your own version of perl.

• If perl can decrypt the code, then all the information to decrypt should be there.
• You can set breakpoints inside perl.
• -MO=Deparse will see through source filters.
• You can set environment vars to load deparse even if argv gets filtered.

Makeshifts last the longest.

This is probably a bad approach, but I can't personally see why so maybe wiser monks can inform?

What if... the CGI is just a wrapper program? It takes the parameters, passes them along to another PERL script which does the real processing and returns a nice long HTML string. The CGI program receives the string, prints it back to the browser and... presto! Code is hidden! There will be a cost in maintenance complexity and in performance. But, aside from those issues are there any hidden "gotcha" issues that make that approach unwise?

Read How can I hide the source for my Perl program?. If someone can read the source of your CGI script, they can read the source of the script that the CGI calls (meaning they have access to the system via a means other than the web browser).

The FAQ you listed didn't seem to say anything about that, did I miss it?

Either way, can't you get around that by calling the script via backticks (``) or through a system call? If you call a C program via system or backticks does that reveal the object-code to the calling script too?

-Tats

Let's see if I got the requirements down:

• Command line encrypter [sic]
• Encrypt it with no problem

Given that the OP's requirements did not specify that the resultant output of the command line encrypter must be able to be interpreted, I present...

#!/usr/bin/perl
use strict;
use warnings;

my ($final, $rot);

$_ = shift;

open (INFILE, $_) || die "Can't open $_: $!";

while (<INFILE>) {
    foreach (split //) {
        if (/[a-m]/i) {
            $rot = 13;
        } elsif (/[n-z]/i) {
            $rot = -13;
        } else {
            $rot = 0;
        }
        $final .= chr(ord() + $rot);
    }
}
close(INFILE);

print $final;
[download]

Cē