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?"
This is such a frequently asked question that there's even a faq in the documentation that is distributed in almost every single perl distribution.
perldoc -q 'hide the source'
If that's not simple enough, then see the thread on perlmonks.org about it.
If you still think that obfuscating the source code is going to gain your company anything, then I doubt anyone really wants to see your code at all. (You don't happen to work for Blackboard, do you?)
http://www.donarmstrong.com
If you are giving root access to the machine to students, you do not need to put your preciousss perl application on the same machine. In fact, you need to NOT put it there, because even if you obfuscate it, encrypt it, or compile it, it's possible to reverse the process. Obfuscated code can be analyzed and understood, plus it's going to take some real talent and time if you want to do it right, so it's expensive. Encrypted code needs to be decrypted before it can be executed. Compiled code can be decompiled.
You might use something like a BSD Jail or some other kind of server virtualization, so it merely looks like your software is on another machine. If it is really important that this program remains your dirty little secret, don't put it on a machine which you don't control. Really.
But if you really want to put it on the same machine, try compiling it into a binary, and not draw any attention to it, to avoid people getting curious about it. Still, if someone finds it and takes enough of an interest in it, all bets are off.
I suffer from attention surplus disorder.
Why don't you install yourself a nice Kernel with grsecurity.
Using it's permissions system, you can allow root to login and do whatever you'd like, you but can set grsec so that only certain other groups/systems are able to view/run etc your perl code.
The permissions system is very configurable and it's a steep learning curve with not a real lot of documentation. But playing with it for a few days should get you all figured out.
Using grsec it's possible to allow root to login and really do zero damage, it's a great system. I don't think any Linux box should be allowed on the 'net without this patch! There are other systems (SeLinux) that offer the same sort of thing, so if GrSec isn't quite what you need be sure to look at the others.
Using a system like this means all those "they have root forget about it" isn't true anymore, you can configure it so root can do very little damage to the working system, but still have access to edit all those files the normal pleb user accounts can't.
Tim
Perl is already Tolkienized -- just look at the start of every source file!
More seriously, you can save the internal representation, but it's easy for someone skilled to turn that back in to mostly-readable source code. You don't even lose the variable names; Perl keeps them around. (For globals, you have to -- you always have to do a symbol lookup. Lexicals don't have symbolic access; the compiler turns these into indexes into pads attached to the internal representations of code objects. However, these lexical pads do keep the variable names around as they're important for error messages, among other things.)
(Guess who just wrote about lexical pads in a Perl book not more than ten minutes ago?)
how to invest, a novice's guide
There are people selling such things for Perl, the first to spring to mind is perl-obfus carried upon Freshmeat.
That is slated pretty thoroughly over at Perl Monks.
I wonder how many people have paid for this .. umm .. fine product?
<p>Yeah, this is called a source filter. There are a large number of them on the CPAN. They're all done for fun-related purposes, mostly humor. Some examples include ACME::Bleach (the program is encoded entirely in whitespace), or ACME::Buffy (for vampire fans), and ACME::Eyedrops (my personal favorite, and different from the others in that the module doesn't have to be installed on the system where the code is to be executed; it produces code that abuses (severely) the regular expression engine to accomplish what the original code accomplished).
</p>
<p>However, none of these will prevent someone with full access to the system, who understands Perl, from being able to reverse the process and demangle the code to obtain it in the form the interpreter sees. And yes, there's a performance hit, although with most of them (notably excepting Eyedrops) it's upfront (when the program is first launched), not continuous (thoughout the execution of the program), so it's not as bad as you might think.
</p>
Cut that out, or I will ship you to Norilsk in a box.
Alternatively you can try LIDS. One of the many features of LIDS is ACLs that are applicable to root as well. Configuring LIDS section of their FAQ gives a number of interesting examples of putting a heavy "lid" on access to the system, while keeping it useable.
Root for learning is a great idea but these days give people their own virtual machines. Bochs, User-Mode Linux, and a variety of other solutions are out there.
Besides, most students have PCs and they can install Linux on their boxes if they want to. Maybe you can negotiate a university license for VMWare or MS's VirtualPC so they can have both MS-Windows and Linux up concurrently in their own dorms.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Give them root on a XEN machine, not the primary box. Allow them to access you perl code in whatever fashion it was intended.