To be frank, with any language its impossible. It may be boring to point out, but any computer program eventually tells a CPU to do something, and that can always be intercepted and monitored. So the issue is not "Can we prevent people from reverse engineering our code" but rather "can we make it difficult enough for them to do that they probably won't try, and even if they do the most likely wont suceed, at least not for all of it". Can the later problem be addressed? Probably it can be made fairly difficult. Many people consider perl2exe and similar stuff to offer a signifigant advantage. You could probably contrive some mechanism using encryption and a morphed perl binary to make it somewhat difficult. Source filters might stop the idly curious. Etc.

Ultimately however if someone with physical access to a machine wants to know whats running on the machine they can always find out.

--- demerphq
my friends call me, usually because I'm late....

Indeed. In fact it's easier in perl than many other languages since it runs on a high-level interpreted VM... and B::Deparse is so very good.

I'm sceptical about encryption/copyright protection. As long as you control the machine, there are always ways around it, since the un-encrypted product has to show up somewhere on your computer anyway.

The best solution would be to write your own parser/compiler/interpreter, probably. Which is probably beyond the company that came up with this. And it's still not a guarantee for full code protection.

The only way these schemes can be made practically impossible to work around (for mortals like me, that is ;) ), is by coming up with hardware implementations, so that the data can be encrypted from the content provider all the way through uhm... speaker, processor, soundcard, whatever's appropriate. And even then there are still ways to re-route the signal or grab the memory.

So no, I don't think it's reliable in a technical way. But legally, that's a different matter. You clearly had to break the encryption to get access to the code, so you showed 'malicious' intentions and probably broke the EULA or whatever agreement, too.

IMHO, this is both a technically stupid and morally ridiculous way of protecting IP rights (note: I'm pretty pro opensource software)... But I comfort myself with the idea that it's going to fail anyway.

Abigail

IANAL, but I have the distinct feeling that if the source for the modifications were not released (update: and the differences were not documented), such would be a violation of perl's license.

You'd be wrong. The PAL allows this type of thing.

--- demerphq
my friends call me, usually because I'm late....

I pointed out the other day the ability to release encrypted Perl source using a decrypting Perl source filter ('perldoc perlfilter' on your local system). The fact that it still really is source (just encrypted) and is still run through normal Perl compilation/execution paths means it still can be intercepted as some other monk(s) so astutely pointed out. But it's not a bad start. It at least prevents casual source viewing. You'd have to work some to get back to the real source state.

Could you encrypt the source using public/private key cryptography?
--
Microsoft delendum est.

Of course you can. The object here is the difference between making life hard for the source-code thief and making things (practically) impossible. If the program "just runs" but is otherwise unreadable then you've just throw up some obstacles for an attacker to work around. This is true regardless of what language you used to implement your program - C, perl, Visual Basic, whatever.

The other idea is that using the program requires some form of secret to unlock it. This doesn't really work for the environment you specified since the program must ultimately be unlocked for use on the potentially hostile computer. You could use some form of encryption to prevent all access to something but once you've allowed something to be decrypted ... the game is over. Or... you could view encryption as yet another technical barrier for use in preventing the clients from accessing the source — just another hurdle.

---

Seeking Green geeks in Minnesota

Ofcourse this has been done ages ago :)

Filter::CBC

Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur.

As others have pointed out, you can't make it impossible, but you can try to make it hard. One of the entries in the Obfuscated Perl Competition a year or two back was an automatic obfuscation engine. The people running the competition commented that its output beat their attempts at automated deobfuscation. Something along those lines might be attempted.

However, it might be just as effective to use lawyers as your copy protection mechanism.

 --jonadab

Run it through Acme::Bleach, hand it to the PHB, and tell him that the job is done. He'll never know the difference.

----
Invent a rounder wheel.

The process is:

1. create your perl script
2. encrypt it
3. stick it into a header

print "Hello World!\n";
print "This is an example of encrypting a perl\n";
print " script and not having the source directly viewable\n";
[download]

The encryption "engine":

#!/usr/bin/perl -w

use strict;
use Crypt::CBC;
use Data::Dumper;

local*FH;
open(FH, 'hello.pl');
my $plaintext;

while (<FH>) {
    $plaintext .= $_;
}
close FH;

my $cipher = new Crypt::CBC('hey jude!');
my $ciphertext = $cipher->encrypt_hex($plaintext);

for (my$i=0;$i<length($ciphertext);$i++) {
    print "\n" if ($i%30 == 0);
    print substr($ciphertext, $i,1);
}
[download]

And now the header:

#!/usr/bin/perl -w

use strict;
use Crypt::CBC;
use Data::Dumper;

my $ciphertext;
while (<DATA>) {
    chomp;
    $ciphertext .= $_;
}

my $cipher = new Crypt::CBC('hey jude!');
my $plaintext = $cipher->decrypt_hex($ciphertext);

print "Plaintext\n";
print "---------\n";
print "$plaintext\n\n";

print "Eval:\n";
print "-----\n";
eval $plaintext;

__DATA__
52616e646f6d4956b1de8bd854dc4f
7137bd168ab1271410ce41442407f1
aa99ff61f79b89ba7ecfca35f283f7
cd5623b70aca91aedaef5a6bb1a7f5
343e40d1973d41720dab8105623d86
d0ed903db80073d57f8148ad799647
b947ae386b327dc61488d6e16392c6
9d623d1ac1f7fd0c767f182225ce6b
66a05c247903a2321e8a737bb3da4a
fb5cf611dacbed89347997ab2db220
b1df993e95e7e0729405d84261bad4
[download]

The result:

[coolness@ryszard encrypt]# ./header.pl 
Plaintext
---------
print "Hello World!\n";
print "This is an example of encrypting a perl\n";
print " script and not having the source directly viewable\n"

Eval:
-----
Hello World!
This is an example of encrypting a perl
 script and not having the source directly viewable
[download]

Out of interest i ran it thru deparse and found:

[coolness@ryszard encrypt]# perl -MO=Deparse header.pl 
BEGIN { $^W = 1; }
use Crypt::CBC;
use Data::Dumper;
use strict 'refs';
my $ciphertext;
while (defined($_ = <DATA>)) {
    chomp $_;
    $ciphertext .= $_;
}
my $cipher = 'Crypt::CBC'->new('hey jude!');
my $plaintext = $cipher->decrypt_hex($ciphertext);
print "Plaintext\n";
print "---------\n";
print "$plaintext\n\n";
print "Eval:\n";
print "-----\n";
eval $plaintext;
__DATA__
52616e646f6d4956b1de8bd854dc4f
7137bd168ab1271410ce41442407f1
aa99ff61f79b89ba7ecfca35f283f7
cd5623b70aca91aedaef5a6bb1a7f5
343e40d1973d41720dab8105623d86
d0ed903db80073d57f8148ad799647
b947ae386b327dc61488d6e16392c6
9d623d1ac1f7fd0c767f182225ce6b
66a05c247903a2321e8a737bb3da4a
fb5cf611dacbed89347997ab2db220
b1df993e95e7e0729405d84261bad4
header.pl syntax OK
[download]

One thing i noticed while developing the above code was the last few characters of the source perl script seem to be gobbled up, resulting in the eval failing.. unfort, i dont have the time right now to fix it...

HTH

Update: and then there is always Filter::CBC - props to beatnik

Yes, but this kind of encryption is hardly secure. You'll notice that the key to decrypt the code is included in the engine. A potential code-stealer has simply to find the key in the engine, apply it to your code, and he's in.

In the end, encryption of applications just isn't possible, because the key must somehow accompany the application. Yet an encrypted application isn't truly encrypted if it contains its own key...

yup, no argument about that.

How about using Perlcc or a commercial equivalent to create a binary for the application ?

Just a tongue-tied, twisted, earth-bound misfit. -- Pink Floyd

Doesn't this somehow violate the Perl license? Certainly it defeats the spirit of it, doesn't it?

Or am I just naively confusing Perl with opensource?

</action>

Good question. Read #6 of The Perl Artistic License. Basically, code fed to Perl is not covered under the same license as Perl itself. It's up to the author.

I have used one piece of purchased Perl software that encrypted this way. They only encrypted their code -- not modules provided by Perl; not modules written by others and pulled from CPAN.

As for the spirit ... depends on how much of an Open Source zealot you really are I guess. Certainly it would offend RMS. I'm less of a zealot so my spirt was not offended.

Makeshifts last the longest.