protecting MatLab code from being pirated?
in [Matlab]
|
From: Andy on 30 Jul 2010 11:41 Walter is suggesting that you have your code check a server to make sure it is allowed to run. This is probably the only robust solution, but it's somewhat more work on your part than the time bomb. us, I suppose there's no solution I can give to which you can't reply "overload X". So I have a few thoughts: 1) How does the user, with the p-coded function, determine which function they need to overload? In other threads discussing p-code security, it seems the user can see the value of any variable in the workspace at any time. But that's pretty far away from identifying the line "if builtin('clock') ..." explicitly. 2) If the user of a p-coded function can see the code at this level and determine which function they need to overload, I think the safest thing is to not use the builtin command. Instead, call 'clock' directly. The option for the user to modify their system clock or overload the clock function is somewhat more harmful to their own system then overloading builtin. In that sense, this is perhaps more "secure". 3) Building off of 2, accepting the end user's ability to overload whatever functions we use to wrap our call to clock, what is the most harmful function we can use as a wrapper? Can we make it so the user would have to overload a function that is critical to other operations in the code? Can we make it so the user has to overload a basic MATLAB operation that would likely ruin this or other code?
From: Giovanni Ughi on 30 Jul 2010 12:45 thank you all for your reply. I agree with you that probably the best solution for time-bombing remain to call "clock" directly (and not other bultin functions). The fact that if the user simply modify the "windows date" clock will return the modified date remains... ok, he can not read directly to the pcode to see if we are using "clock" function, but I can imagine that is it not so difficult to think to try to modified the system date and time....
From: Sean on 30 Jul 2010 12:59 "Andy " <myfakeemailaddress(a)gmail.com> wrote in message <i2urqf$sms$1(a)fred.mathworks.com>... > Walter is suggesting that you have your code check a server to make sure it is allowed to run. This is probably the only robust solution, but it's somewhat more work on your part than the time bomb. > > us, I suppose there's no solution I can give to which you can't reply "overload X". So I have a few thoughts: > > 1) How does the user, with the p-coded function, determine which function they need to overload? In other threads discussing p-code security, it seems the user can see the value of any variable in the workspace at any time. But that's pretty far away from identifying the line "if builtin('clock') ..." explicitly. > > 2) If the user of a p-coded function can see the code at this level and determine which function they need to overload, I think the safest thing is to not use the builtin command. Instead, call 'clock' directly. The option for the user to modify their system clock or overload the clock function is somewhat more harmful to their own system then overloading builtin. In that sense, this is perhaps more "secure". > > 3) Building off of 2, accepting the end user's ability to overload whatever functions we use to wrap our call to clock, what is the most harmful function we can use as a wrapper? Can we make it so the user would have to overload a function that is critical to other operations in the code? Can we make it so the user has to overload a basic MATLAB operation that would likely ruin this or other code? Would it be useful to have the program pcode a file of dates every time it's run? That way it can also check against logged dates to see if the output from clock is before any of them? This would mean if they didn't know it was going to expire and ran it on Thursday; then when it expired Friday they'd have to continually keep it in that 24hr stretch. Actually, it could also log the time the first time it fails the clock function. Then regardless of overloading the various means of getting the time it still knows it's past the date. This pcode file could be required to run and have some random password string at the top so it can't be overloaded on its own. Then as Walter said, it passes back an encrypted string to be interpreted by the main pcode file. This could be irreversibly dangerous if they accidentally set their clock forward. Though a new license, i.e. pcode file with actual date log, could be issued.
From: Giovanni Ughi on 30 Jul 2010 13:36 function output = myFunction(varargin) % this code stops working after May 5, 2011 lic = 0; c = clock; if c(1) > 2011 % yy lic = 1; end if c(1) == 2011 % yy if c(2) > 05 % mm lic = 1; end end if c(1) == 2011 if c(2) == 05 if c(3) > 5 % dd lic = 1; end end end if lic == 1; disp('license expired') delete myFunction.p %% once the check fails once, p file will disappear return end % rest of function what do you think of this guys? once the check fails once, p file will be deleted
From: Sean on 30 Jul 2010 13:58
"Giovanni Ughi" <giovanni.ughi(a)gmail.com> wrote in message <i2v2i4$avn$1(a)fred.mathworks.com>... > function output = myFunction(varargin) > > % this code stops working after May 5, 2011 > > lic = 0; > > c = clock; > > if c(1) > 2011 % yy > lic = 1; > end > > if c(1) == 2011 % yy > if c(2) > 05 % mm > lic = 1; > end > end > > if c(1) == 2011 > if c(2) == 05 > if c(3) > 5 % dd > lic = 1; > end > end > end > > if lic == 1; > disp('license expired') > delete myFunction.p %% once the check fails once, p file will disappear > return > end > > % rest of function > > > what do you think of this guys? > once the check fails once, p file will be deleted It won't actually be deleted just moved to the recycle bin, pretty useless. It'd be better to overwrite it with another pfile that displays it as expired. Also, that was way more checks than you need for the whole thing. It could all be done with this condition: %%% if all([c(1)>=2011 c(2) >= 5 && c(3) > 5]) disp('license expired'); delete myfun.p end %%% |