CryPerl.

[fenLisesi]

Greetings, wise ones (humbled, as always, at your presence)

I was wondering how difficult it would be to spike Perl a bit -- for whatever ghastly reason -- with some compiled-in encryption capability that would allow encrypted source files to be decrypted on the fly and in memory only. Let's call such a crypto-capable Perl, for reference here, CryPerl (as no doubt the mere idea would bring tears to the eyes of many a Perl veteran). When compiling CryPerl (actually, when compiling Perl with the hypothetical cry switch), it would tell me the key with which to encrypt my source files. Let's say we use the pgp paradigm and call this the public key. The private key would be built into the CryPerl binary and very difficult to discern by studying that binary. You would start your script #!/usr/local/bin/cryperl The rest of that script, and your modules if you like (but not other people's modules, unless they specifically allow such use) would be encrypted. CryPerl should be easily able to detect whether a script or a module is plaintext, and if so, invoke plain old Perl. If if finds an encrypted file, it would decrypt it, only in memory, and invoke regular Perl on the decrypted form. The offender would then be able to distribute her own particular version of cryperl and her encrypted scripts and modules and be damned for eternity.

Update: Would it be possible for cryperl to disable Deparse and friends? To make myself clearer, I am trying to pipe-dream about something that the p5p guys would implement. if enabled during perl build, cryperl would be one of two binary outputs of the perl build process (the other one being regular perl). Could underground Deparsing activity conceivably be blocked -- by design, by p5p people -- for cryperl (NOT regular perl, which the perl build would also produce as usual)?

Update: (after a few messages with some very helpful monks) cryperl would not support -d or -M.

Update: Thanks for all the feedback in replies and messages.

[imp]

I haven't experimented with it, but perlfilter discusses this.

Update - did a super search

Here are a few relevant nodes:
• Source Filters
• Hiding your Script
• obfuscating source code
• Concealing Perl Code
• simple encryption for perl files
• Protect source code
• Perl Obsfucate Or Encrypter
• Closing Perl Source
• Here is a commercial obfuscator
• perl2exe - no more secrets
• Protecting perl source code

[tilly]

It would be very easy to do badly.

The documentation for require discusses how to put subroutine references in @INC. All that you'd have to do would be to replace all of the entries in @INC with subroutine references to capture module loading, then load the code you wanted to run (decrypting if need be).

The reason why I say that this would be doing it badly is that there are two obvious holes. The first is that hiding the private key in the binary is far easier said than done. You can hide it, but it isn't that hard for determined people to try to find it. The second is that it is fairly easy in plain old Perl to do a dump of your memory image. Rummage through that and you'll find all sorts of interesting stuff - I believe including complete copies of the source code that Perl loaded.

But it would suffice to keep out casual observers.

[jdtoronto]

It's an interesting idea, but much discussion over the past couple of years seems to indicate that it is not totally feasible. I have had an interest in obfuscating source code in the past, and in a way I still do, as I have a commercial product (Win32 Perl/Tk) which my client would like to protect. Right now we use PerlAPP from ActiveState to package the thing into a single exe file, and we have a DLL of our own which contains some encrypted information.

We also have a fairly sophisticated authentication and registration mechanism, and the logs have shown us that while people certainly try to authenticate the one copy a number of times, no-one has yet succeeded. I doubt it is through lack of ability, but more because the people wanting bootleg copies just won't pay the hackers enough for them I suspect.

Maybe if we had a killer app that was wanted by hundreds of thousands of users, the situation might be different. But right now it is hard for me to justify spending what might turn into tens of thousands of dollars of development time, placing us in a proprietary environment with all the maintenance headaches that would involve, to prevent a few $1500 thefts.

jdtoronto

[diotalevi]

Deparse is a translator from the compiled/executable form of perl back to strings. You can't prevent it from functioning. It's just code reading data.

[dtr]

Hiding cryptographic keys is apparently quite a difficult thing to do. I am told by people who know about these things that locating cryptographic keys is actually really easy - you just look for areas in your file/disk with very high entropy - which will either be compressed files, encrypted files, or keys.

However, the fundimental flaw in your system is that perl itself needs to be able to read your source files somehow. Once you allow that, there are any number of techniques to allow someone to read it.

[wazoox]

Another caveat : while it would be feasible (through tremendously hard work, though) by patching perl source code, the Perl licence demands that you provide the source of the provided binary anyway to the users.