in reply to Re^2: Blending perl and C (two approaches)
in thread Blending perl and C (two approaches)

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.

  • Comment on Re^3: Blending perl and C (two approaches)