|Do you know where your variables are?|
I've seen that again, today. A co-worker asked me, "hey, inside that debian package there are some executables of which I don't know what the heck they are doing. They look like compiled perl. Can you have a look?" I did.
Please point anybody using perl2exe for "code hiding" or "license enforcement" to this node.
(yes, this is crude and could be refined...)
That's all... fire up your editor with the file bar and search for #!perl.
Now delete all above the first line, seek to the where the next binary stuff starts, delete from there to end.
Done, main script extracted. The rest is just as easy.
At the root of any file inclusion, any source text compilation, there's eval. And it's string eval. For eval to be able to eval something, that must be plain perl source code, even if it is a decompiling function of some sort for other chunks to transform. So there you have it. When Perl_pp_entereval is called, the source code is somewhere in memory as a string to be fed to the perl parser and lexer. And memory can be dumped and the dump examined.
It is utterly futile to use perl2exe for code hiding or license enforcement purposes.
I don't post this trivial piece to incite code stealing, but rather - to prevent developers from choosing the wrong proceedings based on failed principles. I have this to tell them:
A successful business is based on the mutual trust between you and your customer. A rightful license isn't a terrible EULA which denies you doing this or that, risking draconian measures doing otherwise, but a mutual trust seal which cannot be gained cheating one of the parties. Your best way to show trustfulness is integrity, which in my book reads as respecting the long term Open Source Effort of all those who created perl and their endeavour in letting others participate, which you counter concealing your source code from the eyes of your trustful customers.Your better best way to show your integrity is transparency in your proceedings. And I, as a customer, would appraise being able to study the source of any product of yours which runs on my computer. If the result of those studies leads to approval, it will deepen our relationship as vendor and customer.
Lastly, to you, perl2exe. Much has been written that you don't claim to make source code inaccessible, that you don't claim you are able to enforce licenses and such - well I say: be honest. You can't because perl doesn't. Then say so. Otherwise, get off my lawn.
update: Again, please don't get me wrong. I don't want to talk down this tool - it might be a wonderful packager, simplify your packaging tasks, allow for cross-compiling and anything else it claims: I don't know, I have never used it. But the sentence "You can ship the exe file without having to ship your perl source code" goes against the camel's hair, and it insinuates that you can hide the source.
Indigostar should state on their website "while you don't have to ship your source code in separate files, be aware that perl2exe is unsuitable to hide code, and it should not be used for that purpose."
In reply to Uncool Use Of Perl: perl2exe. decompile quick steps by shmem