Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Hiding your Script

by perl_devel (Friar)
on May 30, 2005 at 11:22 UTC ( #461759=perlquestion: print w/replies, xml ) Need Help??

perl_devel has asked for the wisdom of the Perl Monks concerning the following question:

Hi, Is there a way to restrict your script been seen by others Like in java you have .class file where the extracted jar file with class file alone is sufficient to run an application. so the user cannot view the code. Similiarly is there any way to attain code security? Regards P.B.Sathish Kumar

Replies are listed 'Best First'.
Re: Hiding your Script
by bart (Canon) on May 30, 2005 at 11:33 UTC
    A Java .class file isn't actually safe, decompilers like Jad can turn them back into Java source.

    That said: no, in principle, there's no proper way to "obfuscate" perl source so nobody can read it. There are joke modules, like Acme::Pony which can baffle newbies, but perl source has to be deobfuscated before perl can run it, and it's possible to insert a handler that prints out the deobfuscated source at that point.

    Packagers like perl2exe, PerlApp and maybe even PAR can help easing distributing your perl application while somewhat hiding the source, but using them to really hide your source will likely be a disappointing experience. You can search (including on this site) on how perl2exe programs can be decompiled, and diotalevi wrote a module to assign reasonable names to modules of which the names have been rendered meaningless, as a response to an announcement of a program to obfuscate your source.

    Experts would say: "use a proper license", and "Only crappy perl programmers really ask about hiding their source, likely out of shame of what they charge a lot of money for."

Re: Hiding your Script
by eyepopslikeamosquito (Bishop) on May 30, 2005 at 12:48 UTC
Re: Hiding your Script
by wazoox (Prior) on May 30, 2005 at 11:32 UTC
    Short answer : No.
    Longer answer :you may find some code obfuscation scripts, or use PAR or similar tools to package your scripts and make them not directly "human readable". However it's useless, because it will be very easy to break.
    Don't be fooled by java .class packages too : they aren't at all secure, and there are a large number of "reverse-compilers" to make source code from java bytecode. If you want to "protect" your code (what for? from who?) use pure compiled languages : C, C++, Pascal...
      If you want to "protect" your code use pure compiled languages : C, C++, Pascal...

      Even pure compiled languages can be decompiled or at least disassembled... that's how they are cracked. The only real solution for "code security" would be something like paladium, adding to the CPU the capability to run encrypted binaries.

        Yes, but you can use some tools to prevent debugging at runtime, encrypt the code, etc. This sort of "armoring" is quite common among the best computer viruses and makes disassembling really a hard time :)
Re: Hiding your Script
by salva (Canon) on May 30, 2005 at 11:29 UTC
    Similiarly is there any way to attain code security?

    do you think class files give you any "code security"? have you ever tried any of the Java decompilers out there? because you should, they are pretty good!!!

Re: Hiding your Script
by chas (Priest) on May 30, 2005 at 12:48 UTC
    There are some interesting comments about this in the description of Filter::Crypto (somewhat along the lines of bart's comments.) See specifically here and the "warning" section.
Re: Hiding your Script
by perlhaq (Scribe) on May 30, 2005 at 22:39 UTC
    It depends greatly on where the code is being executed.

    If it's on a server that you control, and nobody else has root access, then you can do things to make it virtually impossible for any regular user on that machine to view your code. Some OS's have better facilities for doing this than others. For instance, on OpenBSD you can set very restrictive file permissions:

    chown root.wheel
    chmod 111
    And then regular users can still execute that script, but they can't read it with 'cat' or any system call that does open() on that file (in fact you can't even run it as "perl", it can only be run when invoked directly like "./"). However, an advanced user would still be able to retrieve your code from the memory, using ktrace & kdump. But this opportunity can be closed with OpenBSD's systrace utility. Then the only way the user can view your code is if he manages to obtain root access, a very unlikely scenario on an OpenBSD machine...

    But if the code is being executed on the user's machine, where he has root or admin privs, then there's very little you can do to protect it. It then basically comes down to how technically savy the user is, and how badly he wants your code. If you set the bar high enough (with source filters, encryption, and general obfuscation techniques), then it's quite possible the "technical illeterates" (ie, most people) won't be able to access it, and most true hackers won't care to invest their time to do so. But it still only takes one guy to crack it and distribute the code...

Re: Hiding your Script
by zentara (Archbishop) on May 30, 2005 at 17:04 UTC
    In addition to what everyone has said, I wouldn't even run a precompiled binary unless It comes from a big, well known company. With all the trojans and backdoors out there, why take a chance on trusting some unseen, unknown person who says their script is "fun to run" and is safe? If you want people to use your script, don't encrypt it. If you don't want people to run your script, don't distribute it.

    I'm not really a human, but I play one on earth. flash japh

      While that's sound advice, I do have a question - do you scour the source code to every app you download, compile, and install, prior to doing so? If so, you must not run any X server - it took me about 50 hours to get my P4-3.2GHz processor to compile KDE 3.3, nevermind actually having me, the human, try to read and comprehend it!

      At some point, you need to decide who to trust. Big, well-known companies are one thing, but who's to say that something you downloaded off SourceForge doesn't have some back door in it, in plain sight? Especially if you download the tarball, and the tarball doesn't match what's in CVS, it can get difficult to prove later if the project becomes big.

      Paranoia is just paranoia if it's also impractical. ;-)

        Well that is why I said.."coming from a big company or organization". We are all taking chances when we run a complex operating system, which we don't fully comprehend line by line. But that is the benefit of "Open Source Software". I am fairly confident, that some geek somewhere, will discover abnormalities if they can be discovered. If they can't be discovered, then we at risk. There is no gaurantee of computer security.

        We are all at the mercy of the c libs. How do we know that the NSA isn't "grooming and promoting college professors" who are willing to hide a few special complex backdoors, who will have expalnations to cover up the secrets. Maybe there are a few geeks out there, who have discovered them, and all their posts are reflected back to them, (so they think they are getting out), but in actuality are deleted and never seen by the world?

        All you can do is be "diligent". I don't use KDE. Before I compiled and installed Xorg's X Server, I googled for comments about it, and I watch my system for suspicious files and sockets opening. So far, it seems clean.

        When I was starting out, I trusted the big companies like SuSE to do the checking and compiling for me. But as you know, all the big distros are now being bought out by big corporations. Since I know that the big corporations are the "hand-maidens" of the military industrial complex, I have become more suspicious about the "complexities" which they introduce to linux. Now I pretty much run a "linux from scratch" installation.

        The nice thing about linux, is you don't have to run as root, so you can run things as a "low-priviledged user" and see what they do, without impacting your system. Of course, there are always the secretive things the network engineers may be doing, so it pays to do a tcpdump of your network connections every now and then. That is what bothers me the most. When I log onto my ISP, I am in a Peer-2-Peer level connection, and they may have a way to connect, bypassing the firewalls.

        BUT ALL THAT SAID......I probably would run a precompiled package from a reputable website, like SuSE, or Redhat, etc. Otherwise, ( and almost always) I compile everything myself. Even though I don't understand all the c code, at least I HAVE THE EVIDENCE IN HAND, in case the code is malicious.

        Now I would NOT even bother to run any encrypted perl script, unless I personally knew the author, or the author has also provided the source code.

        P.S. It goes for the hardware too. How do we know that each motherboard (or cpu) dosn't emit a signal, which can be received by "government equipment". Dosn't it make you wonder why it's illegal to put your computer into a "Faraday cage", which defeats "tempest". Or why it's so hard to get promoted in the "engineering ranks" of computer designers? We are at the mercy of the designers, who all must pass the "MI-complex security investigations". And it's not so much that they are worried about your background, they want to make sure you can be forced to "keep the secrets".

        I'm not really a human, but I play one on earth. flash japh
      So you're saying that you trust Microsoft more than, say, Activestate or Stonehenge?
        Oops, I thought it was understood that Microsoft is "the Evil Empire", not " a big company or organization". :-)

        I do not trust Microsoft at all, their record of conspiring with the NSA is on the public record, and "Bill Gate's rise to power and dominance" is very suspicious, considering the crappy quality of the Windows Operating System. Therefore, I consider Bill Gates to be the "puppet" of the NSA, which explains it all.

        I'm not really a human, but I play one on earth. flash japh
Re: Hiding your Script
by mattr (Curate) on May 31, 2005 at 06:36 UTC
    I remember a PAR presentation online (maybe Autrijus') in which he suggests putting one critical module on a remote server. However in addition to liability resting on your neck now, it isn't secure and can be read by the user or admin if they really wanted to read it. What is your security need? Do you mean "can't be stolen and resold", "they have to pay", "has to be liscensed per user", "Don't want them to see my dirty code", "want to encrypt server traffic", "want to protect passwords and credit card numbers", or what? If the person running the server is your enemy, the answer is no. But you can do some secure things in perl i.e. regarding webapps.
Re: Hiding your Script
by Anonymous Monk on May 31, 2005 at 18:44 UTC
    Hi, Is there a way to restrict your script been seen by others


    Adding "use Acme::Bleach;" to the start of your program will do the trick.

Re: Hiding your Script
by san25872 (Initiate) on Jun 01, 2005 at 09:20 UTC
    Well, I use perl2exe to hide my code. Even if you assume that there is always somebody who can crack your hidden code but still, it is always better to lock the door than keeping it open for all. - Sandeep

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://461759]
Approved by Corion
Front-paged by Old_Gray_Bear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2021-10-19 09:33 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (76 votes). Check out past polls.