Mark, I'm about to release a commercial application that I've been developing in perl and put in some time and research on this subject before starting. I wrote and use the simple obscurer that you refer to and find it works pretty well in my case. I'm going to rely on that. I agree that it would be nice to be able to deal with identifiers across package boundaries but haven't been willing to spend the extra time to get it--it starts to look like the point of dimishing returns. Can you get someone at your former dot.com to put it on CPAN or make it available commercially?
You can also hash your code to protect it against simple meddling, and accidental or misguided changes, a technique used and recommended by a number of people in several forums. Neither of these, as Greg noted, will protect against determined piracy. I like the attitude espoused by most shareware authors I've talked to--do the simple, easy things for protection and spend the rest of your effort making a better app for your customers--you'll be farther ahead in the end. Or, as one Latin pundit put it, "Non illegitimiti carborundum"-don't let the bastards grind you down. WebEvents is one perl app being sold, apparently quite successfully, by a local firm, without any obscuring at all. (A BU spinoff--maybe Sean knows more about them.) Others I've found give you the perl, in clear text, only after you've paid, sometimes with a simplified version for trial use. All in all I concluded that you don't need absolute security for commercial success with perl code. I'd be interested to hear what others think. Now if you're writing for NSA or DOD, that's another matter. In-line encryption all the way, but it will cost you in performance. Jim ----- Original Message ----- From: "Mark Aisenberg" <[EMAIL PROTECTED]> To: "mongers of perl" <[EMAIL PROTECTED]> Sent: Thursday, February 21, 2002 11:42 AM Subject: RE: [Boston.pm] obfuscation/compiler/summary Thanks Simon. You're the man! I suspected as much, so at a previous company (a dotcom-ish venture that went nowhere), we developed our own source code obfuscator which we used before compiling. It worked pretty well, but unfortunately I don't have any rights to the code so I can't share it with anyone. Any news on how well, if at all, the ActiveState packager obfuscates? Writing an obfuscator is an interesting intellectual exercise. It's pretty easy to delete comments, eliminate whitespace, and change local variable names and subroutine names, of course, but it gets complicated when you start dealing with variables and methods that are exported around. You can even take it into the spy-versus-spy realm by inserting code that never executes, changing variable and routine names to misleading strings rather than random line noise strings, substituting round-about calculations for constants, overloading operators, etc. I'm surprised that someone hasn't released a module to auto-obfuscate. I guess it shows that not many people are using Perl to generate distributable commercial applications. Or maybe it shows that people know that obfuscation is not good security, and that we need a true Perl compiler instead. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Simon Cozens Sent: Wednesday, February 20, 2002 8:05 PM To: mongers of perl Subject: Re: [Boston.pm] obfuscation/compiler/summary Mark Aisenberg: > I've also sent Simon some EXEs, packaged with > perl2exe. It'd be interesting to see which > packager provides better obfuscation. Well, that didn't take too long. Again, I'm worried about giving too much away because of DMCA concerns, but I wouldn't rate perl2exe too highly as a source hiding mechanism. Or at all, in fact. Gah. In fact, now I've seen how it's done, I'm kicking myself for not getting it sooner. Mark, you confused me by compiling print "hello world"; when I subconsciously expected print "hello, world\n"; Am I right? And your source file begins #!perl use strict; use CGI::Carp('fatalsToBrowser'); use DB_File; use Fcntl; use HTML::TokeParser; use Storable qw(freeze thaw); use MLDBM; -- It's a testament to the versatility of the human mind that we're so able to compensate for our own incompetence. - Darrell Furhiman
