6
$\begingroup$

I have a package which I need to deploy in a client's environment. It has proprietary code and solutions that I need to protect from prying eyes and inquisitive minds. The forum has discussed much of this sort of thing in the past. See:

How safe is Encode?

How to distribute proprietary Mathematica code

Seeking strategies to deploy a function securely without a front end

I will utilize Encode, DumpSave, and attributes: Locked and ReadProtected. They help but I wonder if I can impose other barriers to access.

The package in question will only need to get called from NET/Link. This leaves me with three related questions:

  • Does any means exist to prevent the package from ever opening in a front end notebook?

  • Does any means exist to prevent the package from ever being called from a front end notebook?

  • Does any means exist to delete or erase the package's code if someone did open it in a notebook?

$\endgroup$
8
  • $\begingroup$ I don't see why it would be problematic to open an encoded package or mx file in the frontend, you can never prevent anyone to open such a file in a text editor which will show exactly the same information. Can you explain? Or do I miss your point? $\endgroup$ Commented Apr 24, 2014 at 13:49
  • $\begingroup$ @AlbertRetey -- I just want to make it harder. I want to limit (as much as possible) their access to my code to NET/Link. The code in the package already restricts use to a specific authorized machine. If not run on the authorized machine the code shuts down the kernel. I'd also like to restrict them further, perhaps shutting down the kernel if the kernel gets accessed from a notebook. $\endgroup$
    – Jagra
    Commented Apr 24, 2014 at 14:12
  • $\begingroup$ what about compiling the compressed code string into the NET assembly and send it to to the kernel for uncompress/evaluation? Then it would not even live as a file in the filesystem on the executing machine... $\endgroup$ Commented Apr 24, 2014 at 14:31
  • $\begingroup$ @AlbertRetey - That would work for many situations. The problem with this one is that the client owns and develops the .NET code. Whatever I supply them has to encapsulate its own protection. $\endgroup$
    – Jagra
    Commented Apr 24, 2014 at 18:32
  • $\begingroup$ Honestly, I don't know .NET very well, but there are for sure binary libraries/assemblies/object-files that another .NET program can load? If you provide such a binary for them to load from their .NET code that wouldn't make much difference to calling an encoded package file via NETLink for them, would it? You could even sell that as a feature as they wouldn't have to bother with NETLink in their code :-) $\endgroup$ Commented Apr 25, 2014 at 20:13

1 Answer 1

8
$\begingroup$

I have been thinking about this for quite some time but didn't had enough spare time to develop it into something finished. Nevertheless, I want to give my two cents.

As you have already understood, there are two different problems here. First, you want to secure your package from looking directly into the .m file. Second, you need to secure your package when/after it is loaded into the kernel from all kinds of spelunking techniques.

For your first problem, there is maybe an easy and fast solution which should give you some security. But before you read on: I have not tested this carefully. I only assume that it gives a moderate protection! So be warned and prove me wrong.

The trick I'm using is the following: When you have written your package, you have to load it somehow in the clients kernel. What I suggest is that your client never gets any kind of source-code. You simply take your whole package and compile it into a library.

The good thing is that this can be done completely from within Mathematica. First, let's create the encode version of our example package in the same as I did in this answer:

file = FileNames["Collatz.m", {$InstallationDirectory}, Infinity];
encoded = ToFileName[$TemporaryDirectory, "encoded"];
Encode[First[file], encoded];
encCode = Compress[Import[encoded, "Text"]]

The variable encCode contains the encoded package code for which Wolfram claims that there is no way to decode it. Furthermore, I have used Compress because the result

...generated by Compress contains only printable ASCII characters.

Next step is to load the CCompilerDriver` package and create a minimal WolframLibrary code which will create a library. This library will contain the encoded, compressed and compiled version of your Mathematica package:

Needs["CCompilerDriver`"]
libsrc = "#include \"mathlink.h\"
   #include \"WolframLibrary.h\"       
   DLLEXPORT mint WolframLibrary_getVersion(){
     return WolframLibraryVersion;
   }       
   DLLEXPORT int WolframLibrary_initialize( WolframLibraryData libData) {
    return 0;
   }       
   DLLEXPORT void WolframLibrary_uninitialize( WolframLibraryData libData) {
    return;
   }

   DLLEXPORT int setup(WolframLibraryData libData, mint Argc, 
     MArgument *Args, MArgument Res){
       int pkt;
       MLINK link = libData->getMathLink(libData);
       MLPutFunction ( link, \"EvaluatePacket\", 1);
   MLPutFunction ( link, \"ImportString\", 2);
   MLPutFunction ( link, \"Uncompress\", 1);
   MLPutString ( link, \"" <> encCode <> "\");
   MLPutString ( link, \"Package\");
   libData -> processMathLink ( link);
   pkt = MLNextPacket ( link);
       if ( pkt == RETURNPKT) {
           MLNewPacket(link);
       }
       return LIBRARY_NO_ERROR;
   }";

The important part here is hidden in the setup function where the package code is directly injected into a MLPutString call.

To create the library you need to distribute to your client, you now use

lib = CreateLibrary[libsrc, "collatzPackage"]

The final package your client will see is only a stub which will contain the library in the aproapriate library folder (see under Applications) and the code which, instead of loading a package, sets up the package through a library-call. This last part is as easy as loading the setup from the library and calling it:

LibraryFunctionLoad[lib, "setup", {}, "Void"][]

And now you have your package ready

Mathematica graphics

$\endgroup$
7
  • $\begingroup$ Your solution looks like a great advance in securing Mma code for distribution. Lots of us have wrestled with this question for a long time. Many thanks. If I follow this correctly my C# .NET/Link code from Run encoded package code through NET/Link could then simply "compute" LibraryFunctionLoad[lib, "setup", {}, "Void"][]. Yes? $\endgroup$
    – Jagra
    Commented May 10, 2014 at 12:13
  • $\begingroup$ Everything seems to work on a Mac OS X. My version of your code creates the library as: "/Users/jagra/Library/Mathematica/SystemFiles/LibraryResources/MacOSX-\ x86-64/myLibrary.dylib". Note the "dyLib" extension rather than "ell". Hmmm? Will such a library file port to a Windows OS? $\endgroup$
    – Jagra
    Commented May 11, 2014 at 20:48
  • $\begingroup$ Sorry, I ment "dll". $\endgroup$
    – Jagra
    Commented May 11, 2014 at 21:27
  • $\begingroup$ @Jagra No, you will have to create an OS specific version of your package. I'm discussing currently some issues of this approach. That's why I'm commenting so late. Would it be possible that you send me an email? Ping me in Mathematica Chat if you don't find my address through google. $\endgroup$
    – halirutan
    Commented May 12, 2014 at 11:09
  • 1
    $\begingroup$ @IntroductionToProbability I'd go with the simple mx approach and protecting, readprotecting, and locking all your symbols. It's not worth the trouble. $\endgroup$
    – halirutan
    Commented May 24, 2020 at 21:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.