A stream of consciousness follows...
Management's requirements are funny.
Sometimes you get ordered to do things that don't make sense to programmers, but make
some sense in the real world.
(There appears to be quite a lack of suitable Filter:: modules. Obfuscators are often only commercially available, as mentioned previously in this thread.)
Obfuscating/filtering/compiling perl is an oft breached topic. Lots of programmers get offended by the suggestion, but here I am having to implement it
somehow for work.
The source needs to be "de-filtered" at some stage (unless we're using obfuscation), so using a source filter written in Perl doesn't seem to be the answer because it would need to be delivered with our product - meaning that the filter
itself could easily be viewed by "potential bad-guys", and in turn reverse engineered. Maybe I need a filter written in C - but is even rarer to find (and harder to code myself.) So should I write a black box encoder/decoder in C? ... Should I perlcc the filter? ... Why wouldn't I just perlcc the original script instead?! ... So many lame, half-baked solutions!
The only thing that makes management's idea kind of make sense is this: if someone would really go to the trouble of (unobfuscating|reading from memory dumps|insert technique here) my code... then they are most likely talented enough to have written my code in the first place! (Seeing as this project is not
that hard)
I guess I have two points for anyone interested in this thread:
- Apparently in the real world, a certain degree of obfuscation (especially chained with other techniques) makes it a bit harder for people to crack AND MOST IMPORTANTLY keeps your pay cheques coming through.
- You won't find good filters/obfuscators for free very easily.
Thanks for your help on such a brain-dead exercise. Now I'm off to prepare a mish-mash of solutions for review.