How to protect an EXE file created using deploytool

How can we optimally protect our EXE file generated using deploytool? What is the best practice? I am aware that it almost impossible to have a fully-protected EXE file created using Matlab deploytool. Am I right?

[BeeTiaw]

No one answering my question? :)

[BeeTiaw]

still, have not got any response.

Answer 1

[Jan]

As soon as we explain the "best practice" to protect an executable, the methods are known in public, which makes it easier to find a workaround. In consequence, the formerly "best" practice is flawed.

As long as executables cannot be protected perfectly, all trials to do so involve some obfuscation. How this can be done, depends on what you try to protect the software from: Copying? Using outside a specified range of time? Reverse engineering? Creating different results on different hardware?

Start with defining, what you want to protect and how much time and money it is worth to spend for this protection.

[BeeTiaw]

Hi Jan, thanks for your response. I really appreciate this and I truly agree with what you have said in the first paragraph.

I am after a method or workaround that, at least, make anyone (of course not those who are really really good on this) feel difficult to crack my executable apps built using deploytool.

At the very least, I am looking for a way to protect the original m-file lines embedded in the executable file.

The way I created them is to first convert the m-file into p-file and then only I created the executable file. Is it enough to, a so-called, protect my code? Again, I am not looking for a fully protected workaround but to make them spending hours of time to crack is good enough for me.

does that workaround enough?

And I am interested to know more about protecting the code outside a specified range of time? How do we do this?

Btw, I am willing to share my executable file with you and get your feedback on how "easy" is to crack them.

I have read a post that said only by using a standard zipping software that the executable file can be "cracked". I do not know if this is still possible in 2018?

https://uk.mathworks.com/matlabcentral/answers/311718-exe-from-deploytool-can-be-cracked-by-unzipping-it

[Jan]

So "cracking" means to get access to the source code in your case? Please explain exactly what you want protect the code from.

The m-files contained in the exe-file have a readable help section, but the code is encrypted. So there is no need for p-coding. You can strip off the comments instead. If the exe files contains the p-files directly (I did not check this, but you can do it), then the protection level might be lower. Do not overestimate the encryption level of p-files.

Trying to crack your exe file would mean a reverse engineering of the method the data are encrypted by compiling. I've confirmed the license conditions of Matlab, which forbid a reverse engineering. In consequence cracking is illegal, even if you ask me to examine a program you have written. Sharing how this would work with you or in public would not be legal also. Therefore I suggest to discuss this with the technical support of MathWorks.

I assume, that I'm not even allowed to crack my own executables and p-files. Therefore I'm using an old-school protection method for my code: a non-disclosure-agreement printed on paper and signed by hand. Each of the M-files I deliver contains the name of the customer and a HMAC hash. This works nicely and trustworthy with a limited number of customers.

Professional software relies on 2 mechanisms to limit the use to a specific range of time: The check the current date as relied by the operating system or by an internet service. The latter has the disadvantage, that it works online only. The first suffers from the very easy method to reset the date during the test. Therefore it is essential not to reveal, when the test of the date is performed. Do not let a program stop immediately after a failing test to avoid giving the cracker valuable hints. In addition to checking the current date, you can compare the date of the newest files in TEMP or the last date of e.g. Windows Updates in addition. This reduces the chance to be successful with just resetting the date temporarily.

You can provide obfuscated M-code in clear text easily: Remove the comments, rename the important variables to "c1, c2, ...", remove the line breaks (you need them only before the "function" keyword. Then a reverse engineering of 20'000 lines is most likely more expensive than re-writing the code from scratch.

Remember that even the highly skilled professionals in this forum fail frequently to understand the purpose of the code posted in this forum, when it exceeds 20 lines, does not contain comments and contains some eval commands. ;-)

Answer 2

[Walter Roberson]

It is not possible to have a fully protected program written in any programming language including assembler, at least not without hardware support such as sealed circuits in radiation hardened devices and deliberate hardware routings to prevent analysis of timing to figure out what instruction is executing.

[BeeTiaw]

I understand this and I am not looking a workaround to fully protect the code but rather to make anyone who is trying to crack them would feel exhausted :)