'Protecting' Perl Code? 106
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?"
I know chmod! (Score:3, Funny)
Re:I know chmod! (Score:2)
Re:I know chmod! (Score:2)
Or he could try a Perl obfuscator. I never used one for Perl though.
Re:I know chmod! (Score:4, Funny)
People have written perl obfuscators? Why? I've never seen perl code that needed an obfuscator.
Re:I know chmod! (Score:3, Funny)
Comes standard with every unix install.
man 1 cat
Re:I know chmod! (Score:1)
My Turn!
Re:I know chmod! (Score:2)
Re:I know chmod! (Score:2)
Re:I know chmod! (Score:1)
Not in Perl, you'd need SuidPerl... (Score:4, Insightful)
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?
Re:Not in Perl, you'd need SuidPerl... (Score:1)
The bazillions of cracks out there for games and applications written in C++ imply, to me, that this problem is not limited to interpreted languages.
If your computer can run something - anything - then it can be deciphered by any sufficiently motivated human, period. There is only one "solution" in sight for those who are de
Re: (Score:2)
Re:I know chmod! (Score:2)
The first, root can remount the filesystem.
The second, I've actually never seen ONLY execute. I've seen disallowing only execute though.
Re: (Score:2)
Re:I know chmod! (Score:2)
Re:I know chmod! (Score:2)
So, I write a hacked version of NFS. I take allowed machine off the network (since I'm root). I clone its mac, I have its SSH keys (since I'm root), I set up with identical IPs and what not. My hacked version of NFS downloads the code and now I have it.
I don't see a way that they can do this aside from obfuscation, with modern technology. Even crypto requires the file to be decrypted to execute (something that I attended a talk on
Re:I know chmod! (Score:1)
Re:I know chmod! (Score:2)
Re:I know chmod! (Score:1)
Re:I know chmod! (Score:2)
But you can write a setuid/setgid program in C and have that C program exec the perl interpreter as a user/group that can read the script. Assuming your wrapper is properly coded (I've gotten root on a large server due to the wrapper using gets...), you should achieve the desired effect. This technique doesn't apply to this article, though, because the person you're trying to hide stuff from is root. Root can install a rootkit (heh) and bypass any protections he wants to.
Dr. Greene once said (Score:3, Interesting)
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.
Re:Dr. Greene once said (Score:1)
Re:Dr. Greene once said (Score:2)
Re:Dr. Greene once said (Score:2, Informative)
There are people selling such things for Perl, the first to spring to mind is perl-obfus [freshmeat.net] carried upon Freshmeat.
That is slated pretty thoroughly [perlmonks.org] over at Perl Monks.
I wonder how many people have paid for this .. umm .. fine product?
Perl comes with an obfuscator by default.. (Score:5, Funny)
Re:Perl comes with an obfuscator by default.. (Score:3, Interesting)
#!/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;
Why protect Perl code? (Score:2, Insightful)
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.
Goes against the machine's purpose (Score:5, Insightful)
Not Possible, Permissions, Jails/Sandboxes, Others (Score:5, Insightful)
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.
Re:Not Possible, Permissions, Jails/Sandboxes, Oth (Score:3, Informative)
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, th
Tolkienized? (Score:3, Funny)
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."
Re:Not Possible, Permissions, Jails/Sandboxes, Oth (Score:2, Informative)
<p>Yeah, this is called a source filter. There are a large number of them on the CPAN. They're all done for fun-rel
Change your business (Score:2)
I'd re-consider allowing such open access to root.
Re: (Score:1)
Closed Source? (Score:1, Insightful)
MOD PARENT DOWN (Score:2, Funny)
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.
ADJE webmail (Score:2)
Beyond that, make the perl script on the box be a wraper that lwp's a request to your box and spits out the output as a cgi.
Re:ADJE webmail (Score:2, Insightful)
> 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 obfusca
Heard of B::Deparse? Time to learn. (Score:5, Informative)
perldoc -q 'hide the source'
If that's not simple enough, then see the thread on perlmonks.org about it. [perlmonks.org]
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?)
Me thinks we have a fool.... (Score:1)
Re Viewing - me thinks this fool is trying to implement security by obscurity. Why else this silly request?
Re Editing - of course if you have root access you can edit *anything*. Of course if you turn it into a binary, they won't be able to directly edit it, but they could reverse engineer it, re-create it, and edit that. Why stop them? Me thinks this fool wants security by obscurity.
Re:Me thinks we have a fool.... (Score:1)
Repeat after me (Score:2)
Re-examine your need (Score:4, Informative)
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.
Re:Re-examine your need (Score:1)
Considering the fact that we're discussing it on
Giving those students root... (Score:2)
Its Perl... (Score:1)
How much safer can it get?
Gregor
well (Score:2)
if you want to give them root and prevent them definitively from reading it, you're going to need to come up with a better plan.
with a debugger (which i presume they'll have and understand, since these are obviously CS students of some flavor) they'll be able to attach to the process with an all-seeing-eye, so running it on the system where they've got root is just not what you want.
depend
Re:well (Score:1)
Re:well (Score:2)
>the script to another mounted filesystem
>and edit it all they want.
But, at least then they can't modify the original copy, which in some interpretations is what the article poster is actually worried about. (Not my own interpretation.)
At least, they can't modify the original copy once you've use epoxy and some kind of watermark to keep them from simply replacing it with a similar looking CD.
At least, until they replace the system's CD drive with an loop device
What are these students learning anyway (Score:2)
If it was a systems program, well it probably wouldn't have been written in perl, lets be honest.
AI? If the students can't learn about the algorithm, it's not much use.
Theory? What will you prove about a black box perl script?
conflict of ... ideas? (Score:4, Insightful)
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.
Re:conflict of ... ideas? (Score:2)
Re:conflict of ... ideas? (Score:2)
GrSecurity (Score:4, Informative)
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
LIDS (Score:2, Informative)
Depends (Score:2)
You're screwed. (Score:1)
-1 Flamebait (Score:1)
Um (Score:2)
Perl Packager... (Score:2)
Re:Perl Packager... (Score:1)
Remote execution / client-server (Score:2)
here's a way, regardless of the language (Score:2)
b) in perl source, modify all control symbols to other control symbols. e.g. "-" treated as "+", "+" treated as "@", etc.
c) make a script to modify your code's control symbols with the same mapping and obfuscate all variable names to randomly generated ones
d) run the obfuscated script on obfuscated perl
by the time they'll decode everything that version of your code will be outdated
Re:here's a way, regardless of the language (Score:1)
And, quite aside from that, modifying perl is completely unnecessary for that; anyone who knows much Perl could do it trivially with a source filter.
Assuming the poster is competant.. (Score:2, Insightful)
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 mod
SELinux (Score:2)
RPC (Score:1)
2) put it on secure machine (without "public" accounts)
3) write client to use your "web service" and put it on university server.
4) done
some suggestions (Score:2)
Activestate's PDK (Score:1)
use Module::Crypt; (Score:1)
#!/usr/bin/perl -w
use strict;
use lib '/home/vservers/modules';
use Module::Crypt;
CryptModule(
name => 'NCM::Crypttest',
file => '/home/vservers/crypttest/maedls.at/Crypttest.pm'
);
Best protection (Score:3, Interesting)
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
It's in the FAQ (Score:4, Insightful)
[boggle]
*Sigh* (Score:2)
- What does the code do? Why is it important it is protected?
- Do these students actually need root access, or is it just management laziness on your/your companies/the universities part?
- Would these students actually care enough to bother doing anything with this code?
- Have you considered a jail/sandbox/some kind of secure system e
uhm, that's just plain stupid (Score:3, Insightful)
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.
Another way around this (Score:2, Interesting)
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 c
Proxy, proxy, proxy... (Score:2)
If they have root on that system, they can read anything on that system, and that's the end of it. You can hide it/obfuscate it N different ways, but they're all fixable -- in order to run it on that box, the perl text (or some equivalent transformation) has to
Perl Compiler? (Score:2)
Convert it to Morse code (Score:1)
Not really, but check out Filter::decrypt (Score:2)
You can use Filter::decrypt or similar to encrypt the source, but if someone's really determined, they can you the B:: modules to look at the opcodes and convert it back to Perl.
Let learners use UML or Bochs (Score:2, Informative)
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.
Re:Let learners use UML or Bochs (Score:2)
I run 98SE with it.
thats quite freaky (Score:2, Interesting)
Python obfuscation thread at comp.lang.python [google.co.uk]
petantik.blogsome.com [blogsome.com] - A Lucid Look at Reality
Lateral Thinking (Score:2, Informative)
No perfect solution (Score:2)
However it could be copied verbatim and it would still work.
As with all other things perl, see CPAN [cpan.org] and perlmonks [perlmonks.org] for more information.
- Paul
perlcc -B file (Score:1)
This however only applies for
But no one can stop you from including all your pm's into one
Ugly but usable.
I've never gotten the perlcc to binary (only to bytecode) to work with modules.
Re:perlcc -B file (Score:1)
Just use obfuscators for renaming symbols in your code, there is no other way.
Well, it's obvious. (Score:1)
"The first time you run a program under Acme::DonMartin, your source code is magically transformed into Don Martin cartoon sound effects. [...] This can also be construed as a security feature. It is expected that a hacker will be laughing too hard to be able to recover the source code."
SUMMARY: Using obfuscators is the only option! (Score:1)
1. perlcc to compiled code doesn't work for compiling to C for most of code (and generates 5-10Mb of C code that compiles for 10 minutes by gcc) and result doesn't work almost all of the time. Output of 'perlcc -B' can be reversed using B::Deparse..
2. ActiveState PerlApp just extracts all your project's files to a temporary directory during execution of your "compiled" code. Just copy them from there, with all comments and documentation. S