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. | [reply] |
|
|
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.
| [reply] |
|
|
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 :)
| [reply] |
|
|
|
|
|
|
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.
| [reply] |
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...
| [reply] |
Re: using source filter with mod_perl scripts
by ambrus (Abbot) on Jun 06, 2006 at 13:55 UTC
|
| [reply] |
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
| [reply] |
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:
- 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.
- 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.
| [reply] |