OK, write support for the rest part of features, and then test the result
with a lot of real multi-module apps (ensuring the obfuscated version not only works, but exactly as original), fix bugs in B::Deparse and
in your patch, and start testing again. Then write docs. That's where remaining 99+ hours will be spent. Good luck.
As for recently registered domain name - so keep away from all startups and
come back to them after 1 year of product life then.
Re: Re: Here is a commercial obfuscator
Replies are listed 'Best First'.
That diotalevi was able to whip that patch up in 1/2 hour indicates that "obfuscation" by variable renaming is not useful at all. One could create a similar patch that renames those variables back. Eg I select a piece of code which contains an interesting algorithm (do you really think anyone would care to reverse engineer a whole software package?), and first replace the variables with var1...varN. Then, as I grasp the meaning, I replace the names one by one by something sensible. It's really not much effort. That is, if you have the time to do an easter-egg hunt for bugs/special features in other people's code.
By the way, why are you still staying anonymous? You are expressing strong opinions, which is perfectly alright, but it would be easier to take you more seriously if one could associate a name with the posts.
Also, in what way are you affiliated with stunnix.com?
Keep in mind my example is a bit too simple - it needs a way to exempt some symbols including those provided by perl, desired configuration variables anything exported by modules. It should be 100% safe to stomp all over pad variables - I'm a little leery of the globals because other things may attempt to do strange and untoward things which would be broken by renaming it out of the way. So its not perfect but its flaws are well known and can be corrected with a minimum of effort.