MATLAB: Can I build a time limited demo version of a stand-alone application using MATLAB Compiler

30compilerdaydemoexpirationexpire.MATLAB Compilerstandalonetime-limitedtrial

I have developed a stand-alone program using the MATLAB Compiler that has some commercial value. I would like to be able to distribute a time-limited demo version of my application, as this is a common practice to let the potential user/buyer test the application before buying.

Best Answer

The ability to build a time limited demo version of a stand-alone application is not available in MATLAB Compiler.
Note that when working with a trial of MATLAB Compiler, the stand-alone applications created are time limited, but there is no feature in the MATLAB Compiler product that leads to a stand-alone application that is time limited.
To work around this issue, there are several possible solutions:
(1) Just put a date-time check in the MATLAB code. Hard-code the time limit and check current date from the computer or from an online date site (more secure). Naturally, the limitation of this is that you cannot have a separate license file and if the time limit is changed, the component has to be recompiled again.
This is pretty secure, not flexible, and very easy to implement.
(2) If users of application are not sophisticated hackers or customers are not worried about that type of attack (and they do not want to deal with encryption), they can do a simpler license file effect by having a text file with lots of garbage characters, and embed the date characters at different locations in the text file. The date characters can be further obfuscated by getting converted to numbers or binary or whatever else is appropriate and doesn't stand out from the garbage. In this case, only the developer knows how to create the license file such that the program can read it correctly. Whenever a new license file is created, all the garbage characters can be regenerated so that the whole file changes.
This is an easy way to implement a license file, but sophisticated hackers might be able to determine the read pattern (for example, by changing each character in the license file one by one while observing the date string stored in the program memory).
This is decently secure, kind of flexible, easy to implement.
(3) Create a symmetric encryption key, and use that to encrypt the license file. Then the program, which also has the key, can decrypt it and read the license file for the date. The program knows the file was not edited because if it was, the decryption process will fail to result in a coherent date.
Really determined hackers can possibly find the encryption key in the deployed application memory and use that to generate the license files, so there is that weakness, but it is still not easy.
This is pretty secure, flexible, and decently difficult to implement.
(4) Create an asymmetric private-public key pair. Create a license text file with the date in plain text, then hash that into a small string, then encrypt the hash with your private key to get an encrypted hash, and put this encrypted hash next to the date. This is the signature of the date. If the date changes, then the signature won't match and becomes invalid. You put the public key with the deployed application. The deployed application then later reads a license file, decrypts the hash signature using the public key, rehashes the date string and compares the hash with the unencrypted hash to make sure the date was not changed.
The advantage of this method is that the private key is not in the deployed application so hackers cannot find it there and create a fake license file. Also, the date can be plain string and visible, but still is protected against tampering.
This is the most secure (in modern security standards) and most flexible, but pretty difficult to implement if you do not have security infrastructure knowledge already.
(5) Another option is to embed the date into a binary file, like a shared library or other file, which can be changed after deployment. Then the MATLAB code loads this binary and reads the date. It's moderately secure depending on the implementation, but can be very unsecure if implemented badly (e.g., if you just hard code the date string, any old binary analyzer can find it).
This could be moderately secure, kind of flexible, and could be easy to somewhat difficult to implement.
Related Question