|
Re: Alternative for perlcc
by syphilis (Archbishop) on Oct 04, 2008 at 10:28 UTC
|
The usual replacement for perlcc is the 'pp' utility available in PAR::Packer.
But as far as I know, perlcc did not provide any encryption capabilities ... and nor does pp.
Give pp a try and see if it gives you what you want.
Cheers,
Rob | [reply] |
Re: Alternative for perlcc
by ikegami (Patriarch) on Oct 04, 2008 at 09:31 UTC
|
It's rather useless to encrypt software since you need to supply the decrypter and the key along with the software to be able to execute it.
| [reply] |
|
|
Yes, and no. True, it's impossible to hide what's being run by the "machine" (in this case, the Perl runtime), but what's being run by the machine isn't necessarily what's being maintained by humans.
As a simple example; suppose you have a well written, maintainable program written in awk; but instead of distributing that, you distribute the output of a2p. Assuming a2p works correctly, the resulting program will work identical as the one that was developed, but the cost of the customer to modify the program goes up. I remember playing a text-adventure game somewhere in the late '80s. Getting stuck somewhere, I decided to look at the source code - it was written in C, and I knew C. Except that the game was originally written in Fortran, from Fortran machine translated to Algol, before another compiler compiled it C. Theoretically, I could have found the solution, I had the source. In practice it was quite well hidden; the cost to find it was just too high.
And that's often what the entity requesting "encryption" or "hiding of source" wants. They want to increase the cost of reverse engineering the program. It's the same reason you lock your house; you don't say "well, any lock can be picked, so it's useless to lock my house". Locking increases the cost needed to break in your house, reducing the chance someone breaks in.
Now, in the case of Perl programs, if it's your business model that you should hide the source of your programs, you would have been better off with a different language. I don't know of any tools out there that really hide your source (and with source, I mean the code that's being maintained by the developer, which isn't necessarily the code that's run by the customer). But I'm sure the B:: modules contain enough machinery to write a perl2perl compiler that makes it quite hard to reverse engineer the original source. And don't look at me to help writing such a thing. I don't think you ought to hide your source.
| [reply] |
|
|
| [reply] |
|
|
++++++++ If one could re-vote, you would have gotten 14 votes at the same time now. Man, don't get me started on DRM... :-)
[]s, HTH, Massa (κς,πμ,πλ)
| [reply]
[d/l] |
|
|
its not that useless: by hiding the source you declare that your sources are not subject for other people to look at.
I am not a lawyer, but IMHO this could be a good argument for lawyers and so the intentions to hide your sources could hide your sources from honest people.
| [reply] |
|
|
vkon: it is completely useless, and counterproducent.
Honest people (the Client$) that could benefit from taking a look at the source code won't be able to do that. But then again, they wouldn't (being honest and all) redistribute your program, either, nor modify it (if you stated that they are not allowed to). The Client$ lose, you lose.
Dishonest people will disassemble it, recover the (even if somewhat obfuscated) source, and do as they please. The bad guy win, you lose.
So, (IMHO of course) there is absolutely no sensible reason to obfuscate your source code, unless if it's so ugly that you are ashamed of it.
WRT good argument for lawyers: a good, explicit copyright license (even a restrictive one) is a better argument for lawyers than source code obfuscation. Something like:
(C) 2008 MassaCorp
This is proprietary and confidential information
you received from MassaCorp. This program can be
run by The Client$ Corp on its computers A, B and
C, but all other rights are reserved. Particularly,
no copies at all can be done without MassaCorp's
explicit, written, authorization, and no
modifications can be done to this program
by anyone that is not an authorized MassaCorp
technician. Any warranties not present in your
maintenance contract are null and void.
does everything an obfuscation scheme does protection-wise, and opens the door for litigating (your own clients?! think SCO) if necessary. You can even watermark versions of the source code (randomly change some $h->{a} with $$h{a} and log which changes went to which client) to find bad-faith people.
[]s, HTH, Massa (κς,πμ,πλ)
| [reply]
[d/l]
[select] |
Re: Alternative for perlcc
by andreas1234567 (Vicar) on Oct 06, 2008 at 08:33 UTC
|
| [reply]
[d/l] |
Re: Alternative for perlcc
by daveola (Sexton) on Oct 26, 2010 at 20:07 UTC
|
| [reply] |