package matlab app without reveling source code

I have a MATLAB app that I would like to publish and share as a MATLAB app, but I don't want to reveal the source code. at least not all of it. I saw that most packaged MATLAB apps (Curve fitting, optimization etc) do not include the source code but when you package an app and install it all the files are available to the user. I know I can package the entire app as a stand alone desktop app but this is not what I am talking about at the moment. so my questions are:

1. is there a way to package and install a MATLAB app (not a standalone desktop app) in a way that the contents are not exposed?
2. is there a way to compile specific *.m files in a way that they can be called through MATLAB but cannot be read. I saw you can turn them into *.p files but this is not secure. or you can package them as executable files but then they cannot be called through MATLAB directly.

many thanks in advance

Nathan

Answer 1

[Walter Roberson]

If you are looking to create binary files that can be called from a normal MATLAB interactive session, then you can use MATLAB Coder to generate mex files; https://www.mathworks.com/help/coder/ug/how-to-generate-mex-functions-using-the-matlab-coder-project-interface.html You would then have to compile the mex source for each target operating system

[nathan blanc]

thank you for your answer Walter. what about my first question? is there a way to do this? do you know?

nathan

Answer 2

[Bruno Luong]

"Is there a way to package and install a MATLAB app in a way that the contents are not exposed?"

In R2021b the compiler (MCC) it is possible to package with obfuscating file structures and file names (-s option).

[nathan blanc]

thank you Bruno. This is regarding compilation into a standalone app, no?. I am referring to a MATLAB app, such as the optimization toolbox, curve fitting etc. The code to all these apps is inaccessible as far as I saw. How can I do the same for my matlab app?

nathan

[Walter Roberson]

The built-in portions of MATLAB, such as the code for eig() or the code for the details for the core routines of some of the optimization tools: those are written by Mathworks in languages such as C or C++ (or sometimes fortran), and are compiled into Shared Objects (Windows calls these "DLL"; Mac and Linux commonly refers to Shared Objects as a Shared Library). MATLAB ships with a number of these libraries in binary form; at the time of installation on a particular operating system, MATLAB loads in the operating-system specific versions of the libraries.

In order to create shared libraries from MATLAB code, you need to use MATLAB Coder to generate C or C++, and then compile it; in particular, there are flags for taking MATLAB code and generating mex files, which can then be compiled to .mex* files specific to the operating system.

If you use MATLAB Compiler to build an executable, then traditionally it has had the issue that although all of the source is encrypted using AES encrypted, that you can still see the file names and the directory hierarchy, and that might give more clues than is desired about the implementation. As of R2021b (I think it was), the MATLAB Compiler now supports the -s flag, which can put your code tree into an encrypted component (sort of like a zip file), and that the expansion that is done when the standalone application loads will not show the file names, just the name of the zip-like file, thus hiding the implementation details. This is not more "secure" at hiding the contents of the source code (which is protected by AES whether you use this new facility or not): it is just better at hiding names and directory relationships.

If you are building up an Application and not using MATLAB Compiler or MATLAB Coder to make it into a binary executable (operating-system specific), then about your only option is to use MATLAB Coder to generate .mex and compile the mex for the target operating systems, and bundle the .mex* files along with the MATLAB code that is driving the system.

Note: the File Exchange does not directly permit contributions with included binary executables; however, File Exchange accepts references to github hosted projects that might include binary executables.

[nathan blanc]

Thank you for you elaborate answer walter. The issue is now clearer to me