Re: Encrypting source code :(

[RonW]

A PAR file is a Zip file. The executable created by pp is a self-extracting Zip file with an auto-run feature.

In theory (I haven't tested this), you could create a PAR with pp, unzip it to a temporary location, then re-zip it with a password. Make sure the new Zip file has the extension .par

Then do: pp -o myprog myscript.par

If that works the way I think it does, pp will do something like cat extractor myscript.par >myprog

(On MS Windows, it would be something like copy /b extractor.exe+myscript.par myprog.exe)

Assuming that works AND the extractor supports encrypted Zip files, running myprog will ask for the password needed to decrypt myscript.par then extract and run normally.

If that doesn't work, you can use 7zip to create encrypted, self extracting archives. I don't recall the details, but there are options to specify the extractor to use (you want the "installer extractor") and the command you want the extractor to run. You will need to unzip your PAR file before creating the self-extracting archive, otherwise it will be the PAR file that gets extracted and not the files inside it.

(Note: The "installer extractor" doesn't actually install anything. It expects the command you tell it to run to do the actual installing. In your case, the command will be to run your program. After your program exits, the extractor will delete the files it created during the extraction phase.)

[bliako]

RonW, the first method did not work, it does not ask me for a password but it exits silently instead. I couldn't find whether pp "extractor" code can be user-specific and couldn't see where in PAR modules the extractor code is. Any pointers on that welcome.

For the second method you suggested, it should work but I am in Linux and still looking for 7z's "extractor.exe" linux-equivalent. But it looks like it is going to fly... alternatively, following your model, I can always make a self-extracting archive linux-style, I am the only one needing to run this, as I do not trust this code with hosting companies. But if a hosting company has a wizard who could sneak onto the temp extracted PAR files, then let it be, it's not the end of the world.

thanks,bliako

[kschwab]

It doesn't solve your problem, but if you decide to roll your own solution, you might want to look at this node. I did that after reading this thread because I was curious how something like what you're asking for would work.

[bliako]

kschwab, I have seen what you posted here: Encrypting Source Filter. Thanks!

It makes very clear what one has to do to achieve what I wanted, re: encryption and file contents eval. Also, by asking for a password to decrypt, it avoids saving the password in the file (like Module::Crypt does) which would be plain trivial to extract even without brute-forcing!

Based on your example, I will try to roll my own solution which will address one more concern I have: including (own) modules. All by specifying a single password. And also add a feature to load from net as well as from local file. I wanted to make the spec clearer in my mind before leaving an answer to your post.

On the other hand, I do not want to make too much noise out of this, maybe even placing this post was too much AFAIC, because I see code encryption like administrating hemlock for treating a very special case but can soon spread into mass hysteria.

The only weakness to this method is that one can attach to the script process and make a memory dump. With all modules loaded in memory, it would be easy to figure out the encrypted code and its structure. But if a hosting company takes such an effort to peek on my code then I would lick my wounds and put it on my CV!

bw, bliako

[RonW]

It's a trade-off between complexity and using short lifetime temp files. Even using a source filter to on-the-fly decrypt encrypted Perl source will leave traces of the unencrypted source on the target system. I don't know how much risk bliako is willing to tolerate.

[RonW]

Offhand, I can think of 2 other possibilities:

Use pp to create the executable without encryption, then encrypt the result. To run the program, create a program or script that decrypts the encrypted executable, runs it, then cleans up.

If there is an acceptable Perl installation on the target system, use pp to create a PAR file, then encrypt the PAR file. In that case, create a program to decrypt the PAR file, run it. then clean up.

[bliako]

Thanks RonW, I finally resorted to something like this but with my own 'PAR' which is basically a tar file with encrypted modules, which are decrypted in memory and eval'ed

UPDATE: some discussion on module eval'ing regarding this issue: use of already eval()ed module (from string)

[Anonymous Monk]

Cant do that