It is very hard to disable the debugger reliably. I claim it is even not possible.
You can include at least some obfuscation to impede the debugging:
function dbstep(varargin)
function dbcont
function dbup
function dbdown
function [Q,I]=dbstack(varargin)
function [varargout]=inmem(varargin),varargout=cell(1,nargout);
function S = who(varargin), S = {};
function S = whos(varargin), S = builtin('whos', 'fraud_');
And in addition shadow even these functions by local variables:
dbstep = [];
dbcont = [];
etc.
Of course you should clear all breakpoints in the code by "dbclear funcname", but they can be set again, when any of the called toolbox functions can be stopped by a breakpoint.
I've tried a lot of more tricks:
- Putting all code in one line help a lot, because the debugger steps through the code line by line. But still you can set breakpoints in all subfunctions.
- dbclear of all functions of Matlab's toolboxes to avoid that the user can break the process. But an attacker can shadow "dbclear", "builtin", etc.
- AES encrypted strings, which are EVAL'ed - bad idea: the key must be stored in the function and can be obtained.
- One single wrapper function called "Q" and an encrypted message, which determines the action to perform. Finally the M-code was such ugly, that a P-coding was not needed anymore...
- Opening a second Matlab instance and evaluate the function there
- Check the timing using the high accuracy timer of Windows in a Mex to detect, if the code processing is slowed down by a curious user. Of course a detected fraud is should not lead to an immediate action, because this would reveal the location of the test.
- I've learned more dirty tricks from the cheaters at Cody.
There are more techniques like obtaining the memory address of the loaded debugger functions and inject code for an early return. But without doubt this would be a reverse engineering of Matlab and therefore a conflict with the license conditions. It is a bad idea to protect your code by cracking another one.
If you find a way to block Matlab's debugger, an assiduous user can still use a disassembler to debug Matlab itself while it runs your P-code.
My conclusion: P-coded files are not readable and observing, what's going on inside, is possible. The debugger can not be disabled. Obfuscation increases the time is to analyze a function, but in consequence the code looses its maintainability. Therefore the main advantage of P-coded function is, that a user cannot claim to have copied a part of the code unintentionally. Analyzing a P-file is obviously a reverse engineering. Therefore I think, that a solid non-disclosure agreement is much better than any crude obfuscation tricks. Here "solid" means a physical sheet of paper and the requirement of a hand-written sign - the check-box NDAs used by all standard software are ignored by 100% of the users.
Best Answer