37

I've developed a Perl script that has a confidential business logic.

I have to give this script to another Perl coder to test it in his environment. He may try to extract the logic in my program. So I want to make my script very hard to understand.

Any suggestions?

codaddict
  • 445,704
  • 82
  • 492
  • 529
  • 19
    1) It's Perl, not PERL. 2) Good luck. This is impossible. A language as intricate as Perl has so much obfuscation potential, and so many more script kiddies who will know every single dark corner of this obfuscation potential. Your best bet is to write it in machine code and distribute the binary with XS linkage, but in the end, nothing you do will really slow down anyone who wants to understand your code. – Chris Lutz Dec 11 '09 at 04:35
  • 14
    Keep in mind that whatever you choose, an approach like this: http://search.cpan.org/~jjore/B-Deobfuscate-0.20/lib/B/Deobfuscate.pod Could very likely succeed in undoing your work. – Ben Regenspan Dec 11 '09 at 04:41
  • 7
    @Chris Lutz: Script kiddies are, by definition, not good programmers. – user359996 Oct 12 '11 at 22:06
  • 3
    Obfuscation is an origin Perl feature :) – Samuel Dauzon Jul 23 '15 at 15:53

6 Answers6

126

I suggest that you get this person and his management to sign a legally enforceable agreement that forbids all forms of reverse engineering, and any other means of gaining access to the stuff you want to protect.

Obfuscation cannot protect you against a determined attempt to reverse engineer. It is theoretically and practically impossible.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
44

Don't try to obfuscate your Perl. You're wasting your time there. I show plenty of people how to break that sort of stuff in Mastering Perl just so they won't try to do it.

Have you considered implementing the sensitive stuff in C and shipping a pre-compiled binary with a Perl interface? It's relatively easy to do and has the same effect without relying on a clever trick. The determined, skilled person can still reverse engineer it, but that's true for any solution. You do have to compile the library for each platform, but if this stuff is important enough to protect, it important enough to charge enough to people to use it.

Alternatively, put the sensitive stuff behind a web service so they never get the code.

One clever tactic I've seen involves a file that is tailored to each client, whether through formatting or content. This serves as something like a low-grade watermark using banal code, comments, or docs. Find that curious text sequence and you know the source of the leak.

The business answer is to not give the program to people you don't trust, or to make the penalties stiff enough to discourage it.

brian d foy
  • 129,424
  • 31
  • 207
  • 592
9

First, let me say that you're barking up the wrong tree. What you want to do is the wrong approach for many reasons.

Second, check out Filter::Crypto (and PAR::Filter::Crypto). Read the whole manual before your start.

tsee
  • 5,034
  • 1
  • 19
  • 27
7

Use Acme::Bleach to bleach the code clean. Then obfuscate the resulting bleached code. However, any encoded/obfuscated code can be decoded, as the Perl interpreter has to decode it anyway.

ЯegDwight
  • 24,821
  • 10
  • 45
  • 52
Alan Haggai Alavi
  • 72,802
  • 19
  • 102
  • 127
3

You could look at perlcc. It doesn't guarantee correctness, but it should do alright if you're not doing anything too funky in your scripts.

Anon.
  • 58,739
  • 8
  • 81
  • 86
  • 14
    -1 Perl bashing is an appropriate pastime for comments, but answers should be informative, and relatively unbiased. Also, `perlcc` is still experimental and may not work and should be used with extreme caution, and not for production code. And that won't really stop someone who's determined. – Chris Lutz Dec 11 '09 at 04:39
  • 3
    Retracted the -1, but `perlcc` is still a poor solution (to an admittedly unsolvable problem, so no penalty for trying). – Chris Lutz Dec 11 '09 at 04:57
  • 8
    Nah, don't worry about it. The original version deserved downvoting, and the rep doesn't matter. – Anon. Dec 11 '09 at 05:20
2

On OSX at least, they provide three great commands:

parl
par.pl
pp

parl - convert a par file into an executable binary that doesn't need Perl or other modules to run

par.pl - make par files from your perl scripts

pp - compile a perl script into a binary (but it still requires perl)

Not certain if these are available for Windows or Linux.

One interesting thing I noticed was that when I used a command in my compiled perl script to indicate the current working directory, it was the same thing as the directory of my new binary executable. I would have thought that it would have have uncompressed something into /tmp and run it from there, but that wasn't the case.

Volomike
  • 23,743
  • 21
  • 113
  • 209
  • 1
    in `perl` these are the `App::Packer::Backend` interface & are available in Alpine Linux as `perl-par-packer` https://pkgs.alpinelinux.org/package/edge/community/x86_64/perl-par-packer – Stuart Cardall Jun 25 '18 at 19:24