obfuscating source code

snacktime has asked for the wisdom of the Perl Monks concerning the following question:

I've been working on putting together an open source project for credit card payment systems. I've worked as a lead developer in this area for about 9 years now. One of the main challenges faced in this project is that some processors require strict NDA's. Also, by processors I don't mean the likes of Authorizenet, Verisign, etc.. I mean the real processing networks such as Vital, FirstData, etc..

Most of the code could be open source without any problems, but the pieces that implement the API's of the processing networks will be restricted in varying degrees. For some, I might be able to distribute the source, but for others I can't. I need a way to hide the source for particular modules. This isn't a case of security versus non security, it's a case of working withing the rules as they are, whether they make sense or not doesn't really matter at this point. They just are what they are.

The main reason these companies don't want anyone not bound to their contracts getting ahold of the source is that changes require re certification, and amateurs changing the code without knowing what they are doing can have some rather bad side effects.

Now all of that said, the code that implements the processing API's would only be about 20% of the overall project. There would be a lot more features and layers on top of the processing code itself.

I really do not want to go to Java or Python, but for this project to work some modules must be delivered without the raw source. Does anyone have any ideas on this? It seems the perl compiler has been put on the back burner, and I've taken a look at the encryption modules but am not sure if those would work for something like this?

Comment on obfuscating source code

Replies are listed 'Best First'.
Re: obfuscating source code by diotalevi (Canon) on Dec 25, 2004 at 07:18 UTC
You can't encrypt the source because you'd also have to dstribute the decryption key so the program will run. You can obfuscate your source but that won't prevent people from deobfuscating it. You could compile your source but that won't prevent people from decompiling it. You'll need to decide what an acceptable levels of veils are required. Nothing is going to protect you from someone who wants to modify their source but you can at least force them to work a few minutes on it.	[reply]
Re^2: obfuscating source code by cog (Parson) on Dec 25, 2004 at 13:00 UTC
In fact, obfuscating code will prevent you, in the future, from being able to change that code. Sure, you could obfuscate, give them the obfuscated version (which could always be deobfuscated) and make changes in your original version but once you'd do those changes you would have to obfuscate everything again to deliver it... that's not a good option :-\|	[reply]
Re^3: obfuscating source code by diotalevi (Canon) on Dec 25, 2004 at 19:46 UTC
I don't generally believe that because anyone going to obfuscate their source is more likely to use an automated method than doing it manually. Heck, you could even use my B::Deobfuscate module to do this. I meant to write a complementary obfuscating module but its quite a bit more of a pain since B::Deparse includes a lot of explanatory white space that's difficult to remove. The B::Deobfuscate module trivially renames things by subclassing B::Deparse and overriding some of the functions related to naming things.	[reply]
Re^2: obfuscating source code by Aristotle (Chancellor) on Dec 25, 2004 at 07:49 UTC
…but only the first one who feels so inclined. Makeshifts last the longest.	[reply]
Re: obfuscating source code by zentara (Archbishop) on Dec 25, 2004 at 11:20 UTC
This method is very simple, will fool a casual observer, and is easy. Generic script compiler It might get you past the NDA, but has been shown to be easily breakable by a competant Perl programmer. I'm not really a human, but I play one on earth. flash japh	[reply]
Re^2: obfuscating source code by CountZero (Bishop) on Dec 25, 2004 at 12:33 UTC
Interesting, but --as I assume-- a lot of the functionality will be placed in modules, they will still have to be provided as regular .pm files and are thus open to inspection and breaking the NDA? Or is this script compiler bright enough to also encrypt all dependent modules? Sorry, I didn't try the script compiler myself (for lack of a C-compiler on my Winbox) CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law	[reply]
Re^3: obfuscating source code by zentara (Archbishop) on Dec 25, 2004 at 14:14 UTC
No, all the script compiler does is encrypt the script with RC4, and pack it into it's own data. When it runs, it unpacks the encrypted code, and exec's it. So if you want to include modules in the encryption, you probably should gut the module innards, and include them as a package in the main script. Then the whole thing gets encrypted. You also need the Perl installation, as this is not like Par, it only encrypts the script itself. I'm not really a human, but I play one on earth. flash japh	[reply]
Re: obfuscating source code by eyepopslikeamosquito (Archbishop) on Dec 26, 2004 at 03:26 UTC
I really do not want to go to Java or Python, but for this project to work some modules must be delivered without the raw source. Why would Java or Python be more secure? Don't they face the same fundamental problems? (Googling for Java Decompiler is instructive). This sort of question has been asked here many times: Concealing Perl Code simple encryption for perl files Protect source code Perl Obsfucate Or Encrypter Closing Perl Source Here is a commercial obfuscator perl2exe - no more secrets Protecting perl source code Why is it bad to hide the source?	[reply]
Re: obfuscating source code by BUU (Prior) on Dec 25, 2004 at 19:47 UTC
If you think Java, Python or C is some how more secure, you could easily distribute the modules in whatever language you wish that is not perl and then use perl's excellent linking facilities to link to these libraries. Compiling a C dll and using it from perl would be fairly trivial, for example. Or a java .class thingy.	[reply]
Re: obfuscating source code by Thilosophy (Curate) on Dec 26, 2004 at 03:19 UTC
Would it make sense for you to ship only the 80% of your project that has no license issues and have the users get the tainted modules by themselves from the processing networks? Is it possible to structure your code so that it contains stubs that can easily be made to work by dropping in some binary libraries or code obtainable from the processors? That way, you can get all your higher-layer features "out of the door" and get some response from potential users. If your project gets popular, and some of the processors allow shipping (thus making it easier for the clients to work with), the others might change their licensing agreements, too.	[reply]
Re: obfuscating source code by thor (Priest) on Dec 25, 2004 at 15:30 UTC
The main reason these companies don't want anyone not bound to their contracts getting ahold of the source is that changes require re certification, and amateurs changing the code without knowing what they are doing can have some rather bad side effects. I can see how obfuscating the source would help with that, but what says that they have to change anything in the first place? If they find a version of your code that they like, there's no reason that they have to accept the next version in order to stay with the version that has been certified.. There's a reason that mainframes still exists; it's called legacy software. thor `Feel the white light, the light within Be your own disciple, fan the sparks of will For all of us waiting, your kingdom will come`	[reply]
Re^2: obfuscating source code by snacktime (Sexton) on Dec 25, 2004 at 18:20 UTC
An end user could almost always use an older version and still be fine. Processors rarely make changes that cause older api's to not work. More frequently the transactions processed using an older api do not qualify for the best rates. When an upgrade is required, the merchant's bank will usually tell the merchant they have to be using the most recent version, or they can't process transactions.	[reply]
Re^3: obfuscating source code by thor (Priest) on Dec 26, 2004 at 03:42 UTC
And so the question that the bean counters have to answer is "which would cost us more: the upgrade or the lost revenue due to having the old version?". Sometimes, it just doesn't pay to upgrade. thor `Feel the white light, the light within Be your own disciple, fan the sparks of will For all of us waiting, your kingdom will come`	[reply]
Re: obfuscating source code by ccn (Vicar) on Dec 25, 2004 at 15:39 UTC
As diotalevi said you can not protect the code logic of your script. But you may find useful the approach implemented by Macurious in Macurious Analyzie script.	[reply]
Re: obfuscating source code by redhotpenguin (Deacon) on Dec 25, 2004 at 18:21 UTC
The pp utility which is bundled with PAR looks like it could do what you need.	[reply]
Re: obfuscating source code by demerphq (Chancellor) on Dec 26, 2004 at 15:15 UTC
I would say that you should code the required logic in XS and only provide binaries for those modules that are under NDA. It means some of your code will be restricted to the platforms you support but I think its really the only way you are going to keep the code secret. (Well, they can decompile the libraries but...) Incidentally doing "perl" in XS/Inline::C isn't that difficult, and can offer some nice speed improvements. --- demerphq	[reply]
Re: obfuscating source code by Anonymous Monk on Dec 27, 2004 at 11:50 UTC
The short answer, and the only answer that's acceptable by the legal department of your company is: it can't be done. Sure, you might want to try to convince your legal department that any binary can be decompiled - but it's probably a lot easier to write your program in both Python, Java, C and COBOL, than it is to win an argument with your legal department.	[reply]


XP is just a number
	PerlMonks