# Prevent package from being opened in a notebook interface

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?

-
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? –  Albert Retey Apr 24 '14 at 13:49
@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. –  Jagra Apr 24 '14 at 14:12
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... –  Albert Retey Apr 24 '14 at 14:31
@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. –  Jagra Apr 24 '14 at 18:32
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 :-) –  Albert Retey Apr 25 '14 at 20:13

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"]
#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;
MLPutString ( link, \"" <> encCode <> "\");
if ( pkt == RETURNPKT) {
}
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: