2

My company has an analytic product written in matlab. We want to compile it to executable file and sell to the third party. One thing we concern is the possibility of the codes been reverse-engineered.

Would it be hard to reverse engineer a compiled matlab code? How hard would it be to do that compared with do it on a compiled c++ code? So that we would come up with a decision if we need to convert everything to c++, which would cost a lot labor time obviously.

Kevin Brown-Silva
  • 40,873
  • 40
  • 203
  • 237
Jack2019
  • 275
  • 2
  • 10
  • 3
    It is possible to reverse-engineer everything. Why do you think that your little library is an exception? – BЈовић Aug 17 '15 at 16:49
  • 4
    If someone really wants to reverse engineer your code then it doesn't really matter whether it's compiled from C++ or from matlab. So, no, don't bother to rewrite it in C++ unless you have other reasons for doing so. – Richard Forrest Aug 17 '15 at 16:53
  • Please read [Protecting my code from reverse engineering](http://stackoverflow.com/questions/584828/protecting-my-code-from-reverse-engineering?rq=1). Then write in the license agreement that reverse engineering is not allowed. :-) – Bo Persson Aug 17 '15 at 17:05
  • 1
    Also read that : [Protect Your Source Code](http://mathworks.com/help/matlab/matlab_prog/protect-your-source-code.html) and stop over-worrying. Nothing is completely reverse-engineering proof. As long as you make it not trivial to rev your code, it discourages the majority who thought they could easily get the program for free. The other class of attacker (who absolutely want to rev it to _copy_ it) will have to invest time and effort to rebuild the functionalities... meanwhile you work on an evolution of your stuff so you're still ahead (you release v2.0 when they just get v1 to run). – Hoki Aug 17 '15 at 17:36

1 Answers1

5

MATLAB Compiler (and other deployment products, such as the Builder products) do not compile your code in the same way that a C or C++ compiler does.

MATLAB Compiler encrypts and archives your code, and packages it within a thin executable wrapper. You supply this to your end user along with MATLAB Compiler Runtime (which is freely redistributable and, if you want, can also be packaged within the executable as well).

When the end user runs the application, the executable simply dearchives and decrypts the MATLAB code, and executes it against the MCR rather than MATLAB itself.

At no point is your code visible to the end user in a decrypted form (however, non-code files that are included within the application will be, if the user pokes around in temporary directories).

"Reverse-engineering" the code would involve breaking the encryption on the code files - I believe the encryption used is AES256, a strong standard. I'm no expert, but my understanding is that this would be a harder process than the decompilation of a C/C++ application.

I'd also agree with many commenters' suggestion that the best idea is to simply put a licensing restriction in place and rely on that. If it eases your mind, there are plenty of commercial applications successfully being deployed and distributed using MATLAB Compiler.

Edit: R2015a replaced the Builder products with a new product, MATLAB Compiler SDK. The above answer remains the same for this product.

Sam Roberts
  • 23,951
  • 1
  • 40
  • 64