How can I protect files other than .m file with Matlab compiler?
Show older comments
After I compiled the matlab files and other non-matlab files successfully, I found that when users run the executable files, the extraction of the executable will expand all files into temporary folders. All Matlab files are encrypted but all other files are just original files without any protection (not encrypted). Do you have any idea to protect the non-matlab files as well? Thanks.
1 Comment
Walter Roberson
on 4 Feb 2018
Mathworks does not provide any facility for this.
In some cases, you could use your own encryption function. However some routines such as imread() only read from unencrypted files, so you might have to do a notable amount of work to replace those functions, such as finding a combination of Java stream functions that can process them.
Answers (1)
Jan
on 5 Feb 2018
0 votes
If you want to deliver encrypted files, encrypt them before the compilation. Then you Matlab code must contain the required decryption methods.
Remember that the keys for the decryption must be included in your compiled code. Then the keys can be found more or less easily also. If the files should be read by standard methods like imread, load etc., this will not work directly. Decrypting the files at first will leave clear text data on the disk.
6 Comments
Zheng Yan
on 5 Feb 2018
Thanks for all inputs. These files are text files. Do you have any recommended encryption methods for text file in Matlab code?
Walter Roberson
on 5 Feb 2018
https://www.mathworks.com/matlabcentral/linkexchange/links/3025-aes-advanced-encryption-standard contains a link to AES encryption code that lives in Europe rather than the USA (location is important for some legal reasons.)
Note though that every time you build a key into your code to decrypt, that there is a risk that someone could reverse engineer your code to find the key. You have to consider whether the value of what you are protecting against the costs of making the software more robust.
Zheng Yan
on 5 Feb 2018
Thanks for the information. Yesterday, I also found this link after my post and it seems to be working for me except I need to google the source code for the some functions that only exist in communication toolbox. Could you please elaborate a little bit on the reverse engineer my code to get the key? Thank you very much!
Walter Roberson
on 5 Feb 2018
Not all functions in toolboxes can be compiled or have code generated. If you rely on one of those you might need to find or write replacement code.
Any sufficiently determined opponent could run the compiled executable under a debugger, and put in breakpoints where files are opened and then step through the machine level code to try to figure out which encryption key you are using and use that to decrypt the files. Or they could put a breakpoint in the decryption function and wait until the file had been decrypted in memory and examine memory.
It is not possible to implement 100% security in a program that has static decryption, except perhaps with using specialized hardware that prevents debugging and has a sealed CPU that is specially designed to resist x-ray and electromagnetic probing and specially designed to fracture if any attempt is made to open the package (because one technique used is to sand the cover off of a CPU to expose the traces and then put probes on the traces.)
You should assume that a sufficiently determined attacker will be able to decrypt the files. The only thing you can do about that is to make it more effort to decrypt than the value of the information itself. When you put a series of anti-decyption efforts in, that would cost too much to bother with, then attackers mostly stop bothering to decrypt and will instead switch to the much much easier target of infiltrating your office, or kidnapping your family to force you to hand over the files.
Zheng Yan
on 5 Feb 2018
Hi Walter, this is very useful information. Thanks for your detailed explanations.
Walter Roberson
on 5 Feb 2018
In my experience, the easiest way to ensure that no-one will defeat your encryption system, is to make your program bug-ridden and useless: if the "value" available to be extracted from your program is pretty much zero, then it is not worth anyone's time to analyze it.
Categories
Find more on High Dynamic Range Images in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!