Slashdot Mirror
'Protecting' Perl Code?
An anonymous reader asks: "Ok, so here is the scenario: my company has some software that is used internally and it is written in Perl. We now need to put this code on a server that has 'public' access (it's a university machine). We provide root access to the system for the purpose of learning, but we need to keep the code from being viewed or edited. Is there anything to do besides the 'perl2exe' and the ActiveState compiler? How effective are those really at protecting code?"
You could scambling the code un-readable uncompiled.
One of my professors told me a story about how he once worked with a guy that mantained a project. To help keep his job he would always submit the code scrambled with all names of variables and functions seemingly meaningless. He showed him this one day and asked, "How can you read this?" He said, "I can't. I write the code, put the source through a filter program and then submit the result. If they need someone to fix it or read it or improve it, they will have to go through me." This was back in the early 80's.
The best protection for any kind of application you hand over to a customer is a clear license agreement stating what is allowed and what not, together with a good lawyer. It is probably the best way to make the lawyer write the license agreement together with you.
Just as a good hint for you and your customer(s), you may digitally sign your code with a private key (using PGP or similar). Refuse any kind of support when the signature validation fails, i.e. the code is modified. Think of it as a "warranty void if seal broken" in code. Don't check the signature in the code, this is just stupid. The first step of modifying your code would be to remove the signature checker. The signature checker is a separate application on your computer(s) that you do not give away. It may be just a simple shell script using PGP and your public key.
Don't even think about encrypting your code, this is plain stupid. Your application needs to know how to decrypt the code, and the decryption engine must be unencrypted to run. So with a minimal modification of the decryption engine, your customer can read your code anyway. A binary decryption engine (XS in Perl) is not directly readable, but it makes the job just a little bit harder. There are decompilers out there.
Tux2000 <- gave away 100.000 lines of code to paying customers, multiple times
Denken hilft.
The only non-stupid reason this MUST be on the machine is that it is required that these users be permitted to run it, on this machine.
If it is on the machine, root shall be able to read it. If it is possible to execute it, the method of easily decrypting it is present on the machine.
Place it on another machine, executeable only through a network interface, thus making your program itself purely a "black box".
Example 1: Your program is an encryptor, and it takes a key and a data file.
The interface code could be as simple as a shell script that reads the key and filename, and uses a restricted ssh key (on application hosting server, the key is tied to a specific commandline) to transfer the file to a staging location on the application server through scp, run the command, and retrieve the resulting file.
Example 2: Your program passes down a directory tree and creates new files related to existing files.
Simplest solution is like example 1 - script tars up the directory tree and feeds it through ssh to an untar and calls your program on the new remote tree - it could even be a pipe then - you feed your tar directly to a script on the other end that picks a staging location, untars the stream, runs your program on the tree, and sends back the result as a new tar stream. Obviously, it wouldn't be a true stream since the output wouldn't even start until sometime after the completion of input.
If the tree is too big, you put a modified version of your command on the remote that does only the secret part, and a modified version that's publically available to do the obvious part, and outsource the secret work, again through restricted ssh keys.
Example 3: Your program really is a pipe.
You provide a script on your end that just execs an over to that other box with a restricted ssh key limited to running only your command, and runs it.
In my solutions, ssh is a theme - because I don't know the environment, and go with the most secure and flexible solution using service that's likely already approved. For many tasks, you could wrap your stuff up as a cgi script and call it through wget. Maybe write it to listen on a socket and be a plain old service on the box that you control.
If the customer insists that the program itself be present on a box to which he has privileged access and rejects all solutions that don't include that condition, he wants the code. Both of you drop the charade and start negotiating based on that fact.
I just posted on comp.lang.python asking about available protection schemes for python code
Python obfuscation thread at comp.lang.python
petantik.blogsome.com - A Lucid Look at Reality
OK, but that doesn't mean you CAN'T take explicit action to make it even MORE unreadable.
#!/usr/bin/perl
use strict;
use warnings;
($,,$",$_,@_)=reverse qw(164 163 165 112),",\n",split '','\ ';
my $music='Art';
my($swing,$rock)=q
s/hacker/performer/; # another creator of art...
my $blues=~/^.(\w+).*#\s(\w+)/;
my $jazz=substr((grep m($music)=>qx($^X$,-v))[$[],$?,scalar @_);
my $pop=eval qq("\\@_");
print $pop, $rock, $jazz, $swing;
print;
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;