The constraint that I have right now is that a program (e.g.,executable) needs to leave my hands...

... then there is no reliable technical solution. Obfuscation only keeps out the least determined. Anyone sufficiently determined such that contractual means (or even common courtesy) are insufficient to work with you appropriately will find obfuscation trivial to overcome.

Your best option is to work only with people you find trustworthy.

Your second best option is not to distribute software to anyone.

There are a few tools that do this, my favorite is Acme::Bleach, but they are all reversible and you should give up the quest as early as possible. Choose apache to prevent your customers from seeing the code and you're done.

Have you super-searched obfuscation? There are many nodes on Perl Monks on this topic, full of reasons why it's a bad idea and cannot be reliably done. It's also a FAQ.

Just a while ago, shmem "broke" the obfuscation of perl2exe, without breaking much of a sweat, apparently.

If, as you indicate, the IP is being shipped to the people who aren't supposed to get at it - game over. Since users still have complete control over the computers they use, they can control and inspect exactly what their computer is doing. It may be painful, tedious or inconvenient, but if a program is running on your machine, you can always get at the details.

You say have to ship the executable - perhaps there's a way to separate out the "IP" part of it and make it available remotely? Or do you consider your entire program to be sensitive?

plz see archived obfuscator discussions

There's nothing new to add ...

I have a Perl Program containing IP that needs to be protected.

Ambiguous: Is it the Perl that needs to be protected and the script also happens to contain intellectual property or is it the IP inside the script that needs protection?

No, nevermind the ambiguity. It's not the real issue.

The real issue is how to protect some idea, procedure, brainstorm, or whatever that's incorporated in your code.

As I'm sure you're aware, IP protection is conventionally provided by patents, copywrite and similar legal mechanisms ... or by eschewing those (so there's not a public record of your 'secret' and keeping a hard lockdown on the IP (ie, having the money to successfully sue anyone you suspect of stealing the secret and the resources to identify at least most of the violators.

As asserted above and in your previous node, obfuscation doesn't constitute a lockdown; in fact, presents only a trivial hinderance to discovery. And if your IP has significant value, then the cost of hiring a cracker/reverse-engineer is inconsequential compared to the value of the information.

Bottom line -- as suggested above -- forget about obfuscation! Forget about compilation. Forget about almost any other alternative, at least until you ask an attorney about legal possibilities rather than blowing them off with a remark like "copyrighting, licensing, etc, are not enough (or applicable)....

Update: Para 2,3,& 4 added for clarity.

since copyrighting, licensing, etc, are not enough (or applicable)

If the normal legal remedies are insufficient for your protection, I think perhaps you should be asking yourself:

What on earth am I doing working for/with this client/company/agency?

What's not being said specifically, and which I am guessing that you don't understand, is that once the program is running on your computer, no matter what obfuscation/encryption/compression/etc you have applied to it, it will necessarily have been undone in order for the computer to read and execute the instructions.

At that point, you can use a hardware-assisted debugger to capture all the code. It may be in assembly, and a huge pain to reverse-engineer, but it can be done. At some point there will have to be a coherent representation of your program that can run, and it is this runnable copy that can be examined.

In addition, whatever obfuscation/encryption/compression/etc you have applied to your code, you got it from somewhere else, and therefore someone else can figure out how to undo it and get the original code out of the executable, or at least a bytecode image, and you're still undone. This is what people were trying to explain in your first thread: that even if you convert the Perl to C, you can reverse-engineer the C. If you compress it, someone can uncompress it. If you obfuscate it, someone can unobfuscate it.

Consider encryption, such as used by the military or intelligence communities. It's not enough to have a good code because they all know that eventually you can break any code. The real key to secure communication is not only to use a good code, but to try your hardest to prevent anyone from seeing or even being aware of the communication.

In the end, as other, smarter people than me have pointed out, if you don't want someone to get hold of your code -- don't ship it to them!!!

In all fairness, I'm sure you or your company have a legitimate business problem you're trying to solve. Obfuscate the specifics, if you must, but try laying out exactly what part can and what part can't fall into the wrong hands. Is it the entire program? It is an algorithm? The only thing you can do to a program to make it unreadable is delete it (yeah yeah, secure wipe it). If you can run it, you can read it, and therefore the code can be gotten at.

But what are the skills of the wrong-handed people in question? I guarantee some of the folks on here can break your code, but can your clients/customers? If you were to obfuscate the code and compile it to bytecode in a compressed executable, would that be sufficient? 'Cause that's easy. Can it run from a server? Can it be run as a service, for that matter?