Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

obfuscating source code

by snacktime (Sexton)
on Dec 25, 2004 at 06:42 UTC ( #417390=perlquestion: print w/ replies, xml ) Need Help??
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
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.

      …but only the first one who feels so inclined.

      Makeshifts last the longest.

      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 :-|

        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.
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
      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

        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
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

      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.
        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

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.
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.
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.
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.

Re: obfuscating source code
by eyepopslikeamosquito (Canon) on Dec 26, 2004 at 03:26 UTC
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

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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://417390]
Approved by Old_Gray_Bear
Front-paged by bgreenlee
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (7)
As of 2014-09-19 01:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (129 votes), past polls