The -d option is disabled when you use the decrypt template from the Filter module at CPAN. At least this seems to be safe from the perl debugger. This is is the code that does the disabling on the decrypt.xs file:

#ifdef DEBUGGING
    /* Don't run if compiled with DEBUGGING */
    croak("recompile without -DDEBUGGING") ;
#endif

. . .

/* make sure the Perl debugger isn't enabled */
if( PL_perldb )
    croak("debugger disabled") ;
[download]

The -d option is disabled when you use the decrypt template from the Filter module at CPAN

Good move.

Try hitting it with perl -MO=Deparse file.pl and see what you get. Deparse uses the internal compiled structure, maybe you'll get lucky? with that. I don't know if you'll be able to run the B:: modules without the debugger (I've never compiled perl without it) so I'm just guessing here :)

/brother t0mas

If it was my job to hack this then I'd core dump the process and use the debugger on that. Either that or become root save the process memory etc.

Any way you choose it will be hackable - this kind of copy protection does not work!

It's still useful. You still lock your car in a parking lot, don't you? Besides most users won't have a clue as where to start hacking it.

It's just about making it hard for the majority to tamper with it.

Then it's also a way of stating that they (in this particular case) are not yet authorized to look at the code.

Certainly I lock my car in the car park - but I then take key with me ;-)

With this sort of software 'protection' you are leaving the key in the software - rather like leaving the key of your car in the exhaust/tail pipe. It is security by obscurity.

Apologies for the rant, but this is one of the areas that I feel strongly about - it isn't possible to copy protect digital media like this, be it DVD discs, audio, books or programs (to name 4 media with high profile cracks).

If you supply the key with the media (or with the software that decodes the media) you haven't added any security only obscurity. To have real security you need to pass the key seperately, eg on a dongle, smart card, my PGP key exchange etc, and you need to individually encrypt each item.

While you are right that this not going to work as a form of copy protection, you seem to miss the point that strong copy protection is not what is being asked for. All that our brother wants is to be sure that it is a pain in the ass for anyone who wants to get to the source. The idea is that if you make it hard enough they are less likely to try.

As long as you don't leave your keys in your car, I'll think twice about spending the time to steal your car.

oren

What version and platform are you using perl with? There were several perl2c and perl2exe projects floating around the net for awhile.

I believe perl used to have a command line switch that would dump the compiled perl byte code which could then be run. I never used it, so I'm not sure if it works, I just remember reading it somewhere...

Ah yes, here it is in the perlrun page:
-u causes Perl to dump core after compiling your script. You can then in theory take this core dump and turn it into an executable file by using the undump program (not supplied). This speeds startup at the expense of some disk space (which you can minimize by stripping the executable). (Still, a ``hello world'' executable comes out to about 200K on my machine.) If you want to execute a portion of your script before dumping, use the dump() operator instead. Note: availability of undump is platform specific and may not be available for a specific port of Perl. It has been superseded by the new perl-to-C compiler, which is more portable, even though it's still only considered beta.