Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Obfuscate my perl code

by milestone
on Oct 27, 2000 at 18:16 UTC ( #38815=perlquestion: print w/ replies, xml ) Need Help??
milestone has asked for the wisdom of the Perl Monks concerning the following question:

Hi I am seeking your wisdom in obfuscating my code, so i can hand it out to one of our customers. I do not want to make it really secure, i just want to make it a little harder for him to read the source. I have spent over 2 hours looking on your site for some scripts, which will automatically obfuscate my code, but could not find any Please help me out. A true Perl fan.

Comment on Obfuscate my perl code
RE: Obfuscate my perl code
by merlyn (Sage) on Oct 27, 2000 at 18:22 UTC
    Please read the section about compiling in perlman:perlfaq3. In general, you probably won't get much sympathy from the Open Source Community to help you hide source code. Good luck on your own, but you're swimming against the tide.

    -- Randal L. Schwartz, Perl hacker

Re: Obfuscate my perl code
by Fastolfe (Vicar) on Oct 27, 2000 at 18:23 UTC
    I don't know of any scripts to do this automatically, because it's generally considered pretty silly. Your code is copyrighted by yourself (unless you did it for them, in which case they own it and the copyright, obfuscation or no), and so long as you set down the terms of the license to your customer (being careful not to infringe upon any licenses for code you've included in your application, such as GNU or the Artistic license), they are bound to do with your software what you let them do. If they do not, sue them and revoke their license.

    If you're still bent on trying to obfuscate the code for whatever reason, you'll just have to go about it by hand.. Change all of your variable names to, like, $a1, $a2, $a3, etc., remove white space and indentation, and perhaps encrypt static strings (via a simple XOR algorithm) so that it's difficult to read.

    Finally, if you want to get real nasty about it, encode your script (via XOR or RSA if you feel it's necessary), put it in an __END__ block, and read/decode/eval on the fly.

    Before you go through all of that work, though, ask yourself why you need this obfuscated. Perl code must be distributed in source form. It's not possible to keep people from figuring out how you do it. In the US at least, copyright and contract law (license) should offer you enough protection so that you don't have to worry about silliness like this.

      you keep saying that any work done for a third party on a hired basis devolves the copyright to the third party. this is not the case under current U.S. law as i understand it.

      for a work to be a "work for hire", it needs either to be created by an employee in the course of execution of his official capacity, or by an independent contractor.

      in the case of an independent contractor, written agreement is still necessary for the transfer of copyright to take place. such work does not automatically become the property of the client.

        It depends upon the nature of the work involved. If he's hired as a programmer for a company, 99% of the time, this involves him turning over any license/title/copyright to the company he's working for. If this is a customer wanting to license something he's written/writing/will write, by all means keep the copyright and just license out the work.

        Most people, however, working with a 'programmer' title for a company, have no claim over the work they're producing. It belongs to the company.

        And again, this is all subject to the terms of the contract and whether or not he's working for an employer, or providing a solution to a customer, etc.

      What do you mean do it by hand? He's got perl :-) It shouldn't be too challenging to put together some perl that will go through and replace $counter with $a1 and then track the relationships. So when you want to send out your code you just run it through your translator.
      If you want to obfuscate, have variables that consist of 1's and l's (that's a digit and a lowercase letter). Same for function's.
Re: Obfuscate my perl code
by kilinrax (Deacon) on Oct 27, 2000 at 18:24 UTC
RE: Obfuscate my perl code
by Malkavian (Friar) on Oct 27, 2000 at 18:27 UTC
    The thought of a script to auto obfuscate kinda gives me the chills.
    To do that kinda thing safely, the auto script would have to work out the functionality of your program, and replace elements of it on the fly, while maintaining logical and functional integrity.
    Sometimes, I have a hard enough time reading through some of the code there trying to work out what the whole thing does.. I'd hate to program something that did it automatically.. Tho, I think I'd have a lot of respect for someone that managedit.. :)

    Malk
      That leads me to one question:
      Does anyone of You know a case where the obfuscated code runs faster than the original???
      I mean would there be a practical and pragramatical reason to check for this also??
      Have a nice day
      All decision is left to your taste
        Doubtful.. I would imagine they run just the same. If all you're doing is changing the appearance of the code, variable names, etc., the parser isn't going to have any problem with it, and the resulting bytecode will be indistinguishable. If, however, you're encoding your strings, doing some unusual looping or whatever, you're going to incur some slight penalties if a lot of work normally done at compile time is going to be done (esp. repetitively) at run-time. It all depends on how you go about doing it.
        Ever read any really highly optimized code? In assmebly perhaps? Some methods like intentionally overflowing, stuff like that? Passing pointers in odd ways. Lots of stuff like that makes code almost unreadable, but can make it MUCH faster. Look at the goto statement! I have heard of old computers that move through data structures quickly by cycling to the end of drum memory, and then cycling foward one to arrive at the head again. Try a full time job maintaining old code, designed on old machines. Almost impossibly to read, but HIGHLY tuned and INCREDIBLY efficient. They used to fit everything in less than 16K on high end computers, and did some pretty crazy cramming to make it work.

        Just Another Perl Backpacker
Re: Obfuscate my perl code
by AgentM (Curate) on Oct 27, 2000 at 19:20 UTC
    Actually, in one Perl book (now which one was it...?), a module that patterns over the script which must be decoded by an included library is mentioned. This is actually the purpose of Filter and its subclasses. Decide on which one you need. They work great- I know my clients well enough not to trust them with sources- I have the same thoughts as you. The best part of Filter is that you don't have to go through and change various stuffs to make code ununderstandable- just send it through and it's unreadable. I'm surprised no one mentioned it- it is mentioned in the big blue book.

    While it's not impossible to crack, it'll sure put a damper on "quick-code-stealing" stuff. Of course, Perl(or interpreted languages in general) are not best for provided source code restrictions since the source is included with every copy. One thing you may try is Malcolm's perl compiler- he's still working on it, though, I hope.

    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
But WHY???
by tedv (Pilgrim) on Oct 27, 2000 at 20:15 UTC
    I guess I don't really understand why you wouldn't want them to know what the source code looks like. I mean, they're the users. If you don't want them doing things that are in your opinion "bad", you chose the wrong language. Remember that perl is all about providing options and serving others. When we start writing code that gives users fewer options, that doesn't serve them any, and "what good is it then?"

    By the way, I don't think you could write a program that flawlessly obfuscates any piece of perl code using variable substitution because that could caus major soft referencing problems. Solving that problem is (probably) reducable to Turing's Halting problem, which is best left alone.

    -Ted
Re: Obfuscate my perl code
by elwarren (Curate) on Oct 27, 2000 at 20:20 UTC
    perl2c project? perl2exe on winnt?

    You could always encrypt your code and store it in your script. Then the script could unencrypt it, write it out to a file, and then execute that file. Incredibly insecure though...
RE: Obfuscate my perl code
by Adam (Vicar) on Oct 27, 2000 at 20:29 UTC
    The problem with using a scipt to obfuscate your code is that a script can only do things like change variable names, remove comments, remove whitespace and un-needed parens. But the real trick to obfuscation is using side-effects (documented and un-documented) and cleverly named variables (like $= and $;). Plus obfuscated code often uses comments to distract the viewer. Thats all rather hard for a computer to think out.

    And of course, all the person on the other end needs to do is run your code past the Deparser, and take the resulting code and insert appropriate whitespace and variable names. Failing all that, they could just post it here and someone is more then likely to post an explanation.

    My suggestion is to embed your code (and the Perl Interpreter) into a C program and compile it. This is the best way to prepare code for distribution. (And even that can be decompiled.)

      eh? What would embedding perl in c accomplish? The perl is still stored as strings- uncompiled. That would end up as zero difference to a hacker. perhaps you meant to refer to Malcolm Beattie's perl compiler which would do a much better job of assembler obfuscation, which is really the trick for ALL commercial software.
      AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
Re: Obfuscate my perl code
by Anonymous Monk on Oct 27, 2000 at 21:54 UTC
    The reason noone mentioned Filter* AgentM is that most of the folks here are Open Sourcerers like Merlyn who routinely give away source and documentation that far exceeds, I'm sure, the quality of any encrypted source code you can find. It's up to you of course, you do what you've got to do, but I reccomend you open up your source. Can you type "perl -MO=Deparse"?
RE: Obfuscate my perl code
by InterGuru (Sexton) on Oct 27, 2000 at 22:54 UTC
    If you are worried enough to spend money* you can use Per2Exe at http://www.indigostar.com/perl2exe.htm (Windows and various Unices ) ($149) or http://www.indigostar.com/perl2exe.htm for ActiveStates Perl Development Kit for Windows only ($95) . I use the latter and am satisfied. You can get a 3O day trial copy of ActiveState. *You have already spent more than $149 of your own time. Joe Davidson
RE: Obfuscate my perl code
by Octavian (Monk) on Oct 28, 2000 at 00:30 UTC
    you said you just want to make it a little harder...well, the most annoying thing I have found and the easiest is just to remove all the return characters in the code, with the exception of the first line, perl works just fine with no return chars ;)
Re: Obfuscate my perl code
by Anonymous Monk on Oct 29, 2000 at 07:03 UTC
    Well.. I did find this on freshmeat:

    RJ's Perl Obfuscator

    I have not personally tried it out, not having any need to add extra obfuscation to my already messy code, but it might do what you need. According to the appindex record it randomizes subroutine and variable names, removes whitespace, tabbing and comments from your code.

      arg. I used that script on a simple script trying to impress an intern with "perl power." If I remember correctly, the script changes all of your strings as well.
Re: Obfuscate my perl code
by mitd (Curate) on Oct 30, 2000 at 02:32 UTC
    As AgentM pointer out Filter is the best way to go there is a an excellent article in TPJ, Volume 3, Number 3(#11) Fall 98, on how to use the Filter class.

    To those who believe this is swimming against the popular tide I say 'Hockey Pucks'.

    We often use Rot13 or XORbit7 to protect our code. We do this so that code we have guaranteed cannot be easily tampered with.

    The customer still gets source code, but as separate distribution from production code.

    mitd -- Made in the Dark
    'My favourite colour appears to be grey.'

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://38815]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2014-08-23 18:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (176 votes), past polls