MATLAB Answers

Truly encrypt code to run *in* MATLAB, not standalone?

21 views (last 30 days)
Giles on 5 Mar 2016
Commented: Martijn on 16 Feb 2021
I am having a ridiculous amount of difficulty trying to do something that should be straightforward. I want to encrypt code for deployment. The application will run in MATLAB, i.e. end users will have MATLAB installed and will run the application in the MATLAB environment (that's the whole point). How can I do this?
p code is inappropriate since MathWorks go out of their way to state that p code is "obfuscated", not encrypted, and is "not appropriate for protecting your intellectual property". This raises the obvious question of what is the point of p code if it isn't secure. But aside from that, p code is clumsy when you want to retain function help text, which is a pretty basic thing--arbitrary rules about where the help text m file must be on the path relative to the p file, constant "your p file is older than your m file" warnings, etc.
Compiling would seem to be the way to go but this seems to produce only applications that must run outside MATLAB and require the user to install the MATLAB runtime, neither of which I want. Is there a way around this?
I could use Coder to turn m files into C code and then turn that in turn into mex which is called in MATLAB, but of course half of the MATLAB language isn't supported by Coder (making me wonder what the point of it is as well). For one thing, I use try catch blocks, nested functions, and other such basic constructs, ruling out Coder.
Walter Roberson
Walter Roberson on 7 Mar 2016
Why are you bothering to protect your intellectual property if you do not care whether it is stable or secure?

Sign in to comment.

Answers (2)

Jan on 5 Mar 2016
Edited: Jan on 5 Mar 2016
P-coded files are encrypted, but as all encrypted data, which should be used, there is a method for decryption. The encryption method is not made public as well as the key. Either all P-files have the same key, which is stored in the Matlab application, or the keys must be included in the P-file.
If you use any other method for encryption, you have to use an equivalent approach: You need an decryption function and a key on the users machine. During the usage, the code must be decrpyted. In consequence all methods for working with encrypted data on the user's computer is "obfuscation" only.
This is not a problem of Matlab, but the need to "encrypt code for deployment" leads to the same problem in any programmibng language.
If a code is large (1e5 lines of code) and does not contain comments or meaningful names for variables, it is extremely obfuscated also. You simply cannot use or understand parts of it without investing more time (==money), that it is cheaper to develop the code again.
I'm using this approach for projects: 99% of the code is provided as M-code. The main routines are P-coded and check the validity of the license, which is partially done in a Mex file. Inside the P-coded functions, some simple checks detect if the debugger is active.
Giles on 7 Mar 2016
Yes. MATLAB's official line is: "The pcode function obfuscates your code files, it does not encrypt them. While the content in a .p file is difficult to understand, it should not be considered secure. It is not recommended that you P-code files to protect your intellectual property."
This presents a glaring gap if you need to deploy proprietary code to run within MATLAB, and there turns out to be no way (other than pcode) to do that.

Sign in to comment.

Walter Roberson
Walter Roberson on 5 Mar 2016
You can use MATLAB Compiler to generate DLL that can be called from MATLAB.
For this to work, I would expect that the user would still need the MCR corresponding to the version of compilation. Consider the opposite possibility, that it was not necessary to use a runtime corresponding to the version of compiling. As the release the user was running might be different than the release compiled with, code would have to be brought in from the version running with -- but that code might act differently in the new release and there might be different underlying features available in the release the user is running. For stability, then, it would be necessary to bundle up all used MATLAB functions -- which is the same function as MCR. Also, clearly if the functions from the release the user was running were brought in, then the user could make changes to those functions and in so doing break the security of your functionalities or expose portions of that functionality that you did not want exposed. So for security again you want the functions of the release compiled against bundled up, which is the same function as MCR.
  1 Comment
Martijn on 16 Feb 2021
Note that the article you refer to is about MATLAB Compiler 3.x (as included with MATLAB R13 (from 2003) and older) which works in a completely different way than all MATLAB Compiler versions as included with MATLAB R14 and newer.
That old MATLAB Compiler version can better be compared to MATLAB Coder than to newer MATLAB Compiler (SDK) versions; it did use to actually convert MATLAB Code to C-code (with calls to various C-libraries we used to provide). You did not need a full MCR to run that code, just those few selected libraries.
Newer MATLAB Compiler SDK versions do not actually convert MATLAB Code to C-code, they generate native wrapper code around the (encrypted) MATLAB Code which allows it to be integrated in other environments. This code does require an MCR and that MCR needs to be initialized inside that other environment before you can use your component. And that is where a problem arises: to be able to use a MATLAB Compiler SDK Shared Library in MATLAB again, you would theoretically have to initialize an MCR inside MATLAB and that is actually not possible. Both MATLAB and the MCR have not been designed for this and they would conflict with each other.

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!