Possibility of decompiling .exe to m files?

Hello !!!

I lost the data of my computer but I have an executable, is it possible to recover the .m files from and executable version ?? using MATLAB?? please it is urgent.

Answer 1

[Rik]

Have you tried insert favorite search engine? My first hit was this page. I don't think this will have changed in the mean time, so the answer is no.

PS why your question is not urgent or an emergency

[Corentin OGER]

I hope the info in the 2012 post still holds, since I rely on this method to protect years of work on my code.

I feel sorry for the orignal poster who lost her work, we all know how unnerving that can be.

[Walter Roberson]

I have seen someone claim that they have recovered the encryption key and can decode the executables. This is plausible.

[Jan]

@Corentin OGER: Do not overestimate the encryption level of P-coding and compiled applications. Matlab is an interpreted language and even compiled applications call a Matlab execution engine. A reverse engineering is illegal, but this does not mean that it is hard to monitor, what is going on inside.

[Kris Janssen]

@jan: Compiled code is not encrypted. At best it is obfuscated, which is entirely different. https://danielmiessler.com/study/encoding-encryption-hashing-obfuscation/

Moreover, the act of decompiling is not illegal. All depends on your intent. https://security.stackexchange.com/questions/30359/is-decompiling-software-considered-unethical-or-illegal

Thirdly, monitoring compiled native code is not at all trivial and likely requires specialized tools like Ghidra or IDA.

[Jan]

@Kris Janssen:

• "Compiled code is not encrypted"

I've written: "Do not overestimate the encryption level of P-coding and compiled applications." Your reaction does not hit the point, because you forgot to consider the point "P-coded". Of course P-coding is an enryption.

• "Moreover, the act of decompiling is not illegal. All depends on your intent."

No. Take the time to read the license agreement of your Matlab installation:

"Licensee shall not, and shall not cause or permit any other individual or entity to, directly or indirectly:

3.3. disassemble, decompile, or reverse engineer a Program, or attempt to gain access to its method of operation or source code;"

This condition does not depend on your intent. Concerning the topic of P-coding, a reverse enginnering of the encryption method would collide with this agreement.

• Thirdly, monitoring compiled native code is not at all trivial and likely requires specialized tools like Ghidra or IDA."

The topic was P-coding and compiled Matlab code. This does not create "native code", but still Matlab commands, which are easy to follow after the decrypted, e.g. with Matlab's debugger and not with external tools like IDA.

[Kris Janssen]

@jan :

1) p- code is not encrypted, it is obfuscated bytecode, something else entirely. You can easily look up the difference, it was referenced here already.

2) the user was asking about retrieving m files from what is presumably their own compiled executable from such m code. I fail to see how the Matlab EULA applies to that. Even disregarding the EULA:

2009/24/EC

Article 5 (Exceptions to the restricted acts) paragraph 3 states:

The person having a right to use a copy of a computer program shall be entitled, without the authorisation of the rightholder, to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.

Article 6 (Decompilation) has two central parts:

1. The authorisation of the rightholder shall not be required where reproduction of the code and translation of its form within the meaning of points (a) and (b) of Article 4(1) are indispensable to obtain the information necessary to achieve the interoperability of an independently created computer program with other programs, provided that the following conditions are met:

(a) those acts are performed by the licensee or by another person having a right to use a copy of a program, or on their behalf by a person authorised to do so;

(b) the information necessary to achieve interoperability has not previously been readily available to the persons referred to in point (a); and

(c) those acts are confined to the parts of the original program which are necessary in order to achieve interoperability.

2. The provisions of paragraph 1 shall not permit the information obtained through its application:

(a) to be used for goals other than to achieve the interoperability of the independently created computer program;

(b) to be given to others, except when necessary for the interoperability of the independently created computer program; or

(c) to be used for the development, production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright.

What the user is asking for is likely non-trivial but not necessarily illegal unless what they are trying to do is reversing an app that was not written by them.

[Jan]

"2) the user was asking about retrieving m files from what is presumably their own compiled executable from such m code. I fail to see how the Matlab EULA applies to that."

To do this, the method for hiding the original code (which is a kind of "encryption") must be revealed and reverted. This would be a conflict with the license agreement.

[Kris Janssen]

@jan

Come on: encryption is the reversible act of hiding data using a key pair.

Creating bytecode from m code is nothing of the sort.

This from Matlab btw:

https://nl.mathworks.com/help/matlab/matlab_prog/protect-your-source-code.html

With obfuscation, all you are doing is mangling variable and function names and perhaps tangling up code flow constructs but it is essentially still the same code.

There is nothing illegal about any of this.

Read the EC directive and get your facts straight about encryption vs obfuscation.

[Jan]

@Kris Janssen: P-coding was developed as method to encrypt M-files to protect the intellectual property. See e.g. the documentation from R2009a: doc pcode

"pcode fun obfuscates (i.e., shrouds) M-file fun.m for the purpose of protecting its proprietary source code. The encrypted M-code is written to P-file fun.p in the current directory."

After some discussions, in which e.g. I participated also, MathWorks has changed the corresponding text and reduced the estimation of the protection level. The fact, that repeated P-coding of the same file produces different output shows, that this is not just a simple byte-coding.

I do see, that you have a different opinion and the discussion does not help to solve a Matlab problem.

Personal attacks are not accepted in this forum (see: help, guidelines).

[Kris Janssen]

This is not a personal attack.

Computers and topics related to computing are exact in nature.

Obfuscation and encryption are not the same. If you obfuscate and mangle code multiple times you will also get different outputs but this is still not encryption.

Read again https://nl.mathworks.com/help/matlab/matlab_prog/protect-your-source-code.html

You also seem to have trouble with the notion of Mathworks intellectual property regarding its tooling and the IP of code developed by a developer using Matlab and distributed as either m, p or natively compiled executables.

Once again, OP inquired whether he or she could somehow recreate what is presumably their m code from a binary to mitigate consequences of loss of the m code. By no means is this illegal.

By telling people that things are ‘illegal’ based on a fundamental misunderstanding of technical subject matter, you are distributing misinformation.

This is not personal, nor is it attack or even a personal opinion of mine. You just got some facts wrong. Let it go.

[Jan]

"This is not a personal attack."

I'm glad to hear this. Nevertheless, it does not help to solve a Matlab problem.

[Walter Roberson]

Kris Janssen:

"encryption is the reversible act of hiding data using a key pair."

That is incorrect. Encryption is any process that is intended to make data unreadable to unauthorized people. Encryption with a key is only one kind of encryption. ROT13 is encryption even though it does not use a key: it is a Caesar Cypher with offset 13. Encryption that uses a key is typically better encryption, but it is not the only kind of encryption.

The page you linked to talks about limits to obfuscation, that the result must still be readable to the programming language, but the result of pcode is not valid matlab source code: matlab has to have a separate reading routine for pcode.

"2009/24/EC"

I am not in the EU. In my country, the lobbying from entertainment industries have considerable influence on law, and breaking deliberate hiding of information (whether with a key system or not) is specifically illegal, with the exception that people with disabilities are permitted to make adaptations to get the program to work with their equipment (such as breaking protection on an ebook in order to use a screen reader) -- but it is illegal for anyone else to help them do this or to sell devices for the use by people with disabilities. It is a theoretical right with a very high bar. It is an open question in law as to whether security researchers in my country have the legal right to investigate security... unlike the United States which has a specific exemption for security researchers.

Answer 2

[Jan]

No, this does not work. The executable contain some parts of the M-files, e.g. the comments, under certain conditions. But the actual code is encrypted. To decrypt it, you would have to crack the encryption method, but this is very expensive (perhaps hundreds of years of computing time), and illegal (reverse engineering of the encryption method).

Unfortunately the golden rule is true:

 All data without a backup are not important.

[Michael McEvoy]

Hi Jan, can you comment further on "The executable contain some parts of the M-files, e.g. the comments, under certain conditions." I would like my executable to not include such comments. I assume any mat files or other assets compiled with the binary are also encrypted?

[Jan]

To be sure, you can check this by your own: Create an executable. Then open it e.g. in 7zip to check, what you can find directly. Afterwards install it on another computer and open the created files. I'm not sure where they are found, I'd search in the %APPDATA% folder.

The best way to remove comments, is to remove the comments. Copy the relevant M-files to a specific folder, and strip the comments. You find several tools for this in the FileExchange: https://www.mathworks.com/matlabcentral/fileexchange/?utf8=%E2%9C%93&term=remove+comment . Then compile the cleaned files.

[Corentin OGER]

Thanks for the information, I didn't realize you could open an .exe file with 7z and watch what's inside. I just did that with an exe from R2016b app compiler and it worked.

More information about my code is visible than I thought was possible, including unencrypted .mat files and code structure. All .m files appear, but they are garbled, I could not see readable comments, which is good because I sometimes use unprofessional language in the comments when I'm upset.

I know that if "Do not display the Windows Shell (console) for execution" compiler option is unticked, errors will show in plain text in a DOS-like console (like it would in Matlab Command Window). While experimenting with a crude limited-time license system to distribute my software to partner companies, I realized that by supplying an incorrect key, I could trigger an error that would reveal the line of code with my hard-coded "secret" key in plain text in the console. Users could in theory use this to produce their own unlimited key.

[Rik]

So you have a line like this in your code?

if ~strcmp(provided_key,'UnlimitedKey'),error('license incorrect'),end

Shouldn't you move that key to a variable so you can change it more easily? That would have the benefit of using a variable instead in that line, which would prevent this leak. You could also further obsfucate your code, see this thread.

I also suppose you are aware of RunAsDate, which completely defeats many limited time licensing systems by modifying the system time. The only solution around this would be to run your own time server and query the time at startup. Your users will strongly dislike you for requiring an internet connection.

[Jan]

@Corentin OGER: Remember, that MATLAB is an interpreted language. A line like

if ~strcmp(provided_key,'UnlimitedKey'),error('license incorrect'),end

calls strcmp. The first thing an attacker tries to do is replacing the original strcmp function by something, which replies true, when one of its inputs is 'reply_true_in_every_case' and type this in as secret password. Using builtin('strcmp', ...) is safer, if you can proove, that builtin() was not highjacked also.

Never store passwords in clear text in the code, but use hashing methods. Otherwise they are too easy to find.

Do not rely on the system time, because this is very easy to modify. Look for the newest date of files in the TEMP folder to estimate the real date. Check the times of all processed files also.

If the code exists immediately after a license check, it is very easy to locate the check. So do not insert an error() near to the check, but set a flag, which is caught far away in the code and let the code exit regularily to avoid shadowing of the error() function.

These methods concern other programming languages as well. Especially in MATLAB the creation of a secure protection is a hard piece of work.

I gave up trying to protect my code completely but ship my codes as M-files. Then only one central function is protected as P-code and calls a C-Mex function, which calls a DLL, which decrypts a text block, which contains Matlab code to unlock the function. This is eval'ed and overwritten immediately. The decryption does not happen, if the debugger is active, the time from starting the function is longer than 1 second or any of the used functions is shadowed.

The much safer part of the copy protection is the code size: The customers can modify some lines of the M-files to adjust them to their needs, but they cannot keep the overview over 350'000 lines of Matlab and C code. So I give them the code for free and get money for the maintenance. I have a set of tools to manage the code automatically, e.g. to check the compatibility with a new Matlab or OS version. Then stealing the code is not useful for their scientific work.