> On Tue, Jul 29, 2003 at 11:17:27AM +0100, Edward Wildgoose wrote: > > However, if you package up stuff with the activestate thing then the > > perl script file is at least moderately well hidden, for example there > > is only one useful reference on google on how to reverse engineer it, > > and the method appears to be inapplicable for the latest version. (It > > is certainly beyond anyone who is not at least extremely keen to look > > inside) > > Run a debugger. Break right after perl_parse. Dump the OP tree > and feed it to B::Deparse. I have verified this method's validity > with the author of PerlApp. :-)
Well, I'm not a complete clutz, however, this is probably beyond me, certainly not without getting familiar with a debugger and working out exactly how to find which chunk of code is the OP Tree, etc. I *would* be interested in knowing a little more about how it is done for curiousity, but please send any thoughts offline to me, etc and *NOT* to the list where it is archived and easily accessible. The point is, and this is just a personal opinion, but clearly just about anything *can* be done, but frequently the ability to actually *do* so rests with only a relatively few people. I see little advantage in making the information on how to break into obfuscated code easily available - the information is of low value to those who want to obfuscate and of high value to those who want to de-obfuscate. (I think the debate on whether people should write closed source code in the first place is moot, because the clever people here already know that they can extract the code whenever they like, all we are doing is preventing the script kids from easily doing this as well) > > There are many hackers quite easily capable of reverse engineering > > this, and I have no intention of aiming at them, however, if one can > > prevent a customer opening it up in winzip then this is a step > > forward... (if you see what I mean) > > Here we agree with each other. A plugin is planned during 0.7x as: > > - Allow multiple (layered) ones via cmdline > - Takes either /path/to/command (piped to it) or > Foo::Bar::funcname (which automatically does a "require Foo::Bar") > > Currently, I'm inclining to use "pp -F" / "pp --filter" for this > function. Suggestions welcome. Hmm, I think it perhaps comes down to how flexibly one can hide the decode key? It might be nice to add a few thin veneers of security by having the decode key NOT in an easily obtainable (static) location. This is even more useful if you are adding licence key type functionality (don't want it too easy to write a decode program which can crack any PAR app, *try* and make people have to break it "per executable". I guess it will always be possible to decode the decode layer, then stop the debugger, then use that knowledge to decode the rest... Perhaps an optional (and chargable) set of native code decoders available from "autrijus.org" would be a future option... Thanks for listening Ed W
