Being involved in a development of a large commercial software using the mod_perl platform made me look for an effective way of hiding the source code... from the usual non-perl users. The reason for that is that the software (www.opentill.com) is going on the market soon and I have been asked by my partners to look at making the software source code unreadable. I've been using a modified Filter::Decrypt for all other parts - a normal Tk scripts that are running on the terminals... but I couldn't do that with the mod_perl program, because mod_perl doesn't support source filters. I've tried (successfully) a simple obfuscation... but that's not good enough. Playing arround I found that there is a way of encrypting the source code under mod_perl (using Filter::Decrypt)... and that's if you move all the source code to a module and encrypt the module. This is a solution to the problem and I just wanted to share my thoughts here with you. Any comments are welcome.

AN UPDATE...

The reason why I am encrypting the source is because the source has got a key generator which creates the initial installation key. Then the company selling is providing an unlock key accordingly. The software can not be copied to another computer, because the installation key will change. That all is simple thing to crack, but not so simple if your source code is somehow invisible/hidden.


Thanks a lot for all your comments!
  • Comment on using source filter with mod_perl scripts

Replies are listed 'Best First'.
Re: using source filter with mod_perl scripts
by wazoox (Prior) on Jun 06, 2006 at 12:59 UTC
    Simple and easy : dont' do it, forget about it, it doesn't work and it doesn't offer any protection.
    Even if your application is unreadable, it won't prevent anyone from copying it and use it, even if you rewrite it in C. Nobody cares about your code anyway, as long as they have the application and can use it (how many people do you know who bought their copy of Photoshop with good money?).
    If you're looking for the definite solution against piracy, I have bad news for you : there isn't any. So don't try harder to find a good answer to a bad question.
    PS: A super search about "hiding code" or "hiding source" will provide you with many similar discussions.
      It actualy doesn't finish there. The installer is taking a fingerprint of the current system hardware and generating an installation key which must be accompanied with a unlock / activation key provided by the support people. This key works for this hardware / installation id only. The key is stored inside the encrypted source code - which is done by the same encrypted source code... It's working 100% without problem. I've done some tests... it is practicaly very difficult for someone to copy the code - "just like that". Glad that I heard your reply makes me feel good.
        Well, kudos for the challenge, but all this encryption stuff was probably quite a lot of work, and I don't think it will bring your company any additional customer... So it's probably actually a net loss from a business point-of-view :)
Re: using source filter with mod_perl scripts
by derby (Abbot) on Jun 06, 2006 at 13:46 UTC

    BTW ... I'm sure you'll have lots of happy customers with the open branding + source obfu. Also tell your marketing folks Flash is not open sourced.

    -derby
Re: using source filter with mod_perl scripts
by Juerd (Abbot) on Jun 08, 2006 at 09:10 UTC

    For any Perl code to be executed, be it source, optree, or bytecode, at some point you can deparse it. It's not worth the trouble.

    But I am always intruiged by this kind of request. The major question that pops up is: why do you want to hide your code?

    • Hiding Perl code does not prevent copying
    • Hiding Perl code does not increase product value
    • Hiding Perl code costs a lot of time for investigation
    • Hiding Perl code will not buy you any extra customers
    • Hiding Perl code means you will probably not receive patches
    But there's one thing left:
    • Hiding Perl code hides the code (really!)
    And that's very important iff your code is an ugly piece of crap. But if this is the case, again, hiding the code isn't the proper solution...

    Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }

Re: using source filter with mod_perl scripts
by ambrus (Abbot) on Jun 06, 2006 at 13:55 UTC

    Make the program a short shell script and put the actual code deeply buried in the lib directory.

Re: using source filter with mod_perl scripts
by demerphq (Chancellor) on Jun 09, 2006 at 08:47 UTC

    If you really want to secure Perl code I would say you would have to hack the perl binary. Of course you would be in a licensing jungle in that a lot of commonly used modules are released under the GPL and not under PAL, so you'd have problems there. And if you allowed the user write access to _any_ such source then they would have an opportunity to bypass your security measures and use deparse to recreate the code. So IMO a properly secured Perl based application A) isnt going to use the normal Perl exe, and B) is probably going to be functionally crippled to the point where id be curious if it would be worth it.

    IMO a lot of the more intelligent businesses are going to want source code level access anyway, so I dont really see the point. Of course there are enough stupid companies that wont that you could probably make a business out of it anyway.

    ---
    $world=~s/war/peace/g

Re: using source filter with mod_perl scripts
by radiantmatrix (Parson) on Jun 14, 2006 at 19:47 UTC

    I think it's interesting that a lot of people are taking this as a question in the form of "is this a good idea?" I agree with almost everything said above about how code obfuscation/encryption/"compilation"/etc. is largely a waste of time when it comes to actually protecting anything.

    However, I want to point out two things:

    1. All of those very good reasons not to hide code mean nothing if your boss requires you to do the hiding. Gripe, complain, present well-reasoned arguments on why it's a bad idea, but at the end of the day, you may still have to do the dirty.
    2. Trade secret law requires "due care" from an organization in protecting a secret, or it loses its "trade secret" status. If there's some method in the code that the org wants to keep others from using, it has two choices: patent or obfuscate1. Since software patents are evil, I'd rather see them obfuscate. Yes, it's broken, but it's probably enough to show that you tried to protect your secret.

    In summary, avoid code-hiding techniques whever possible; but, when it's strictly necessary, I say use something as lightweight as possible. I'm curious what kind of performance hit is incurred by using Filter::Decrypt in this context...

    {1}: copyright doesn't apply here, as that only protects the particular expression of an idea, not the idea itself.

    <radiant.matrix>
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet