If the point of the OP's exercise is to avoid exposure of the perl source code, then storing the decrypted program as a file anywhere in the user's disk space would defeat the purpose.
Having the script change its "name" in the process table (by setting $0) would not be sufficient protection. Anyone savvy enough to figure out that a perl script is being run from a disk file can search the disk for recently created files and potentially find the perl source code. So the point is to avoid saving the program to a disk file.
UPDATE: Having said that, of course, there is a work-around that might supply some level of protection:
- The C program decrypts the perl script, stores the clear-text source code as a file, and issues a system call to execute the script.
- The perl script begins with unlink $0; -- at the point where this step is executed, the script is already in memory, so the disk file is no longer needed. The exposure as a disk file lasts for just a fraction of a second.
Even with that, though, the sort of trick demonstrated by dave_the_m below can be tweaked to reveal the source code -- e.g. replace /usr/bin/perl with a shell script that launches the given perl script using the perl debugger. (I haven't tried it, but this or something similar is bound to be possible and not that hard to do.) | [reply]
[d/l] |
Your and dave_the_m's responses to the effect of "trying to hide the source is futile and probably wouldn't have good results even if you succeed" are absolutely correct, as the movie and music industries have spent many millions (if not billions) of dollars proving. I was just correcting the OP's claim that he can't exec the decrypted code because then it would show up in the process table.
As to the possibility you mentioned of looking for recently-created files, that could be defeated by the Perl code immediately unlinking itself on startup, which in turn could be defeated by a user savvy enough to locate the appropriate inode and undelete the file, which could be defeated by the Perl overwriting itself before unlinking, so the user renames perl to perl-real and replaces it with a program which copies the source (whether supplied in a file or on the command line) into a new file before passing it on to perl-real, and on and on it goes, wasting a lot of both the developer's and the users' time until either the developer or all of the users give up. Given that developers are generally vastly outnumbered by their users, it's a pretty safe bet that, in the end, the users will win that battle of attrition.
| [reply] |
Unlink is only useful if you make sure the sectors the temporary file existed on in disk were also overwritten. Otherwise the user could just recover the deleted file.
| [reply] |