PCode obfuscation cracked - alternatives?

Hello, I'm asking this question since a quick google search revealed software able to de-obfuscate p files to m files almost perfectly.

is there any way safer (wrt reverse engineering) than pcode to protect matlab code to be used by matlab (i.e. no stand alone executable)? In particular, the code to be protected calls and is called by functions/m files that cannot be obfuscated/protected (they are part of another library that cannot be modified).

we are currently using R2012b on production systems,

Thank you,

------------EDIT--------------

Just to be clear... I'm not talking about information leaking from running code, debugging or anything requiring programming skills.

I'm talking about decompilation of a p file to a human readable and (very likely) executable m file, by a simple command line statement. A search in google brought up software that seems able to do just that.

Assuming that works (and it sure looks that way), is there a second line of defense to prevent proprietary algorithms being disassembled by a simple one-click operation, while mantaining compatibility/executability in the matlaab environment?

e.g.:Once upon a time, i recall m files could be compiled to mex, but it seems this is not the case anymore (or at least it seems requiring multiple steps and lots of headaches).

[Walter Roberson]

If you happen to be referring to

http://sourceforge.net/projects/decodepcode/files/

then note that their "pcode" does not refer to MATLAB. "pcode" is a term that has been used with software for decades.

[gius]

No i'm not referring to that. I do know what pcode files are in the context of Matlab, thank you.

I'm not certain of the legal implications of posting public links to the software I'm referring to, but it's on google.

[Walter Roberson]

Philip works for Mathworks. You could email him the information.

(Note: I do not work for Mathworks. However, if Mathworks would like me to investigate or give opinions on matters, I am good at keeping to NDAs.)

[Jan]

@Walter: NDAs are funny, when you find the code freely downloadable in the net. Obviously others did not care about surely existing NDAs already. If the encryption is such weak, an NDA is not the limiting factor for telling my opinions, but the fact, that rudeness is not accepted in this forum.

@guis: Thanks for mentioning this interesting detail. Understanding Matlab's parsing methods is useful for some legal applications.

Answer 1

[Philip Borghesani]

What leads you to the conclusion that pcoded files can easily be de-obfuscated? I am aware of the numerous ways that information can leak from a pcoded file and there are some defenses that have been posted in other answers and downloads on this site. I believe that it is simple to defend p-code from the only credible software I found to inspect pcoded files. I believe this software is capitalizing on an already posted weakness of pcoded files.

I expect this software can be defeated by any function that checks the datatypes of inputs and errors on unexpected types.

[Walter Roberson]

The only thing I find so-far is some mention in tomcat, but I am not convinced at the moment that it does anything different than running the pcode on symbolic variables and then optimizing the relevant expression.

[Philip Borghesani]

Yes that is what I found and I drew the same conclusions.

[gius]

As i wrote in the question, I'm affirming pfiles can be deobfuscated because i found software that seems to do just that.

I edited the question to make it clear.

the software was found by a simple google search: I saw pfiles being recommended as a relatively safe ip protection strategy, and checked on google just to be sure.

Answer 2

[Jan]

P-coding removes all comments and the help section securely. When the names of the internally used variables are obfustcated also, e.g. 'a', 'b', 'Omega13', understanding the code might be more expensive than paying you sufficiently for the source code. I've seen such obfuscated M-file in the FileExchange. Inspite of an excellent demonstration of advanced obfuscation techniques, the comments and rating have not been positive.

You can apply AES encryption to strings, which are EVAL'ed. Unfortunately the US laws forbid to post the 2 lines of Java code or the corresponding M-code for a strong AES encryption. I'm convinced that this law is counter-productive, so it is up to the US citizens to influence the politics to remove it.

But even then the standard problem remains: How can an encryption key stored securely? You could start a C-mex thread, which pokes into the memory of a Matlab variable with a specified timing. Then the debugger is not able to determine the key reliably. But I remember, that there has not been any 100% secure method in the history of modern computing. If you invent one, M- and P-files will not be your profession anymore.

[gius]

Thanks, we'll see if eval'ing scrambled versions of critical portions of the code could be a stopgap while looking for more long term solutions.

I'm looking to the possibility of wrapping m functions to dll's (with compiler), and then writing mex interfaces to these. Do you have any pointer or helpful hint in that direction (in particular whether there are tools to generate the boilerplate)?

Thanks again

[Bjorn Gustavsson]

Quote from the Importance of being Ernest: "A man should always have an occupation." (Slightly out of scope comment on that profession thing, but in the case I invented something like that, I'd still like to keep me occupied with what I do now)

[Jan]

A new quote: "If a man has earned enough money, it is time to sit down and take a nap."

Matlab code and and a secure obfuscation are a contradiction by design. It is the purpose of M-code to be compatible with different Matlab versions and environments and therefore dynamic overloading is a fundamental brick of the design. This is a great benefit for interpreted languages.

Hiding details in compiled stand-alone applications is not secure, or if it is, it is not flexible anymore.

I'm going to make some experiments in the evening.

[Peng Xu]

Pretty sure name that used internally is not obfuscated, because there is something called workspace in MATLAB, and the p-code generator has nothing to predict what is going to be in your workspace in runtime.

Answer 3

[Peng Xu]

It is never secure to ship the code or even resulting binary to end-user and hope some kind of key is able to protect it. My suggestion is to put a crucial part of code away from end-user, e.g. on a company server. And in MATLAB, communicate to this server to do that crucial part. This may be the only way you can achieve a level of security that you can control.

[Jan]

And this has the disadvantage that the customers will hate it, when the software they have payed for does not work, when the internet connection is down temporarily. We all know the annoying troubles with online activations and such stuff.

And as we know from e.g. the heart bleed problem, even data on a company server are not under a perfect control.

Answer 4

[David Leffingwell]

Use:

pcode -R2022a

See also Security Considerations to Protect Your Source Code