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?"
CHMOD?
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.
..and it's called "Perl". You don't need to do anything at all for your code to be unreadable.
Nobody can read it anyway!
But seriously, if you provide root access to the system, what good is a Perl obfuscator/encryptor/compiler going to do? Nothing can really stop someone with a will and enough free time from decrypting the code.
If it's for learning and people have root, why put it on this server if you don't want people to learn from it?? Still want to do it? Move this perl code to another box and call it via RPC.
My second though was permissions. Why do the students need root access? Couldn't you make some new account that had permissions to do anything but access that one directory?
My last thought is a sandbox (or I think the BSD concept of a Jail is the same idea). If you were to run Linux on Linux (Xen, or just some other sandbox, maybe even chroot) then you could give them root, while keeping them out of the true root.
It's a tough situation. Does it really have to be on that server? You can't stick it on a new server your company buys for the purpose and donates (what is more important, My last idea (a bit extreme, I would think) would be to modify the Perl interpreter to run the perl code through a decryption algorithm first (so the source on disk would be encrypted so it couldn't be read). With open source software, there is no reason this isn't possible (would hurt performance though).
Does Perl support some kind of tolkenizing? When you run a Python script you get the .pyo (I think) file that is basically the cached compiled Python byte code. Can you do that with Perl? It isn't perfect (can be disassembled back into Perl, but without variable names, etc) but it is better than plain text.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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
That's nonsense, don't listen to this guy.
Look, just to show how nice we are, why don't you upload it to my FTP server, give me the root password and IP of this machine, and I'll take care of the rest.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
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.
It sounds like you're a bit confused, if the people are supposed to have access to learn, then why are you denying them access to learn from this script. It sounds like you really just shouldn't have this script on there, as was said before, you should move it elsewhere and call it remotely.
But MOST IMPORTANTLY, I wouldn't put anything of value or importance onto a machine where uni students have root access. If you remote call, whose to say they won't break the call, if you obfuscate, whose to say that they won't just break the script or delete or replace it. It just seems silly...
Perhaps you should give them access to a root-like group, then not put this file in that group. I think you problem is that you want more complex permissions then you've relegated yourself to having.
http://monkeyserver.com --- weeeeee
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
The problem with Perl is that it's an interpreted language. That is, you need an interpreter to read the code and then run it. And if the perl binary can read the code, then so can you.
An obfuscator could work, but then someone could easily nuke the program, or just generally mess with it.
Honestly, I think it's a retarded idea to begin with. First, drop ALL the root access, no excuses. Add stuff back in with Sudo as needed, giving each command careful review. Then, rewrite your app to work with suidperl, and run that with setuid root, or with sudo.
That's the technical answer. But honestly, why are you afraid of them looking at your code?
Don't thank God, thank a doctor!
This sounds like such a BAD setup: security through obscurity (in Perl?!), basic inability to understand root. After all, if hackers can reverse-engineer DVD software to decrypt all movies, your Perl script doesn't stand a chance. And I bet you're putting a password in it!!
:) Modify the script to load once, delete the file, and respond to requests. See perldoc -q 'hide the source'.
But assuming you know what you're talking about, it's an interesting puzzle.
Read-only as root? Mount a write-protected media. CD, floppy, USB dongle. Some hard drives let you set a write-protect jumper. Or you could go with that modified kernal that someone else mentioned here.
Obfuscating Perl? Install a Sony rootkit!
Everyone is entitled to his own opinions, but not his own facts.
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
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.
[boggle]
You're as bad as all the damn proprietary software vendors who try to prevent people from examining their compiled code in a hex editor or decompiling it.
Why do you want to do this? Is the code proprietary? Does the code contain security sensitive information?
If the latter, then jeez, that's just plain piss poor design. In the case of the former, just put a license warning in the code. It's impossible to "protect" overall design and algorithms anyway.
You can obfuscate the code of course, but really, that's just an exercise in futility.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
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.
<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.
> Those dudes had a fairly nasty pack/unpack decryption sequence in their pay webmail system
> that I never got around to cracking.
A student who knows Perl and has a long weekend on his hands can buzz through that sort of thing with ease, or a student with a bit less Perl knowledge could post it on the Perlmonks Obfuscated Code section and claim it's "unbreakable", practically guaranteeing it would be broken within fifteen minutes. (Deobfuscation is a recreational activity for some people, and obfuscated Perl code is incredibly susceptible to it, especially if the obfuscation is automatic, as with the sort of thing you're talking about; in fact, for someone who's reached the point of thinking in Perl, obfuscated Perl code is almost easier to read than normal code in another language (such as C).)
Cut that out, or I will ship you to Norilsk in a box.
Perl is already Tolkienized -- just look at the start of every source file!
What, do you have to run it on a Tolkien Ring network instead of Ethernet?
"One Ring to rule them all,
One Ring to find them,
One Ring to bring them all
And in the darkness bind them."
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.
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
Give them root on a XEN machine, not the primary box. Allow them to access you perl code in whatever fashion it was intended.