Thread Subject: protecting MatLab code from being pirated?

Hello All,

I'm supposed to write a portfolio optimization Monte Carlo simulation
for some foreign mutual fund company on an advisory basis. They have
MatLab and want me to ship my code to them so they can run it over
there. I'm wondering how I can code some kind of protection for my
MatLab programs so they don't just take it and cut me out of the
picture.

Is there a way to make the code unusable if they try to modify it? Or
some way I can put in some code so they can only run my progams until
a certain expiration date?

Any suggestions would be appreciated.

On Sep 16, 12:40 pm, stpatryck <stpatr...@gmail.com> wrote:
> Hello All,
>
> I'm supposed to write a portfolio optimization Monte Carlo simulation
> for some foreign mutual fund company on an advisory basis.  They have
> MatLab and want me to ship my code to them so they can run it over
> there.  I'm wondering how I can code some kind of protection for my
> MatLab programs so they don't just take it and cut me out of the
> picture.
>
> Is there a way to make the code unusable if they try to modify it?  Or
> some way I can put in some code so they can only run my progams until
> a certain expiration date?
>
> Any suggestions would be appreciated.

You can send them p code. That way, they can only use your code
without being able to see its contents.
doc pcode

Note: Create a backup of your file(s), because there is no going back
once you convert it to pcode.

This way, if they want to modify the code, they will have to contact
you and have you modify it for them.

Will this work for you?

-Nathan

A similar problem I had lead me to develop this file:

http://www.mathworks.com/matlabcentral/fileexchange/17288

Feel free to modify it to your specific needs, regarding the date.

stpatryck <stpatryck@gmail.com> wrote in message <0925d8cc-0669-4057-9ce0-04ccf1b627a4@d21g2000vbm.googlegroups.com>...
> Hello All,
>
> I'm supposed to write a portfolio optimization Monte Carlo simulation
> for some foreign mutual fund company on an advisory basis. They have
> MatLab and want me to ship my code to them so they can run it over
> there. I'm wondering how I can code some kind of protection for my
> MatLab programs so they don't just take it and cut me out of the
> picture.
>
> Is there a way to make the code unusable if they try to modify it? Or
> some way I can put in some code so they can only run my progams until
> a certain expiration date?
>
> Any suggestions would be appreciated.

This has been discussed, e.g search the thread "Licensing your deployed GUIs" in this newsgroup.

Supply it as p-code (pcode) might a possibility

/ per

Nathan, Per, and Matt,

Thanks for your input. I didn't know about p-code. I will research
it.

I appreciate all of your comments. Very good advice.


Regards,
Patrick


On Sep 16, 3:57 pm, "per isakson" <poi.nos...@bimDOTkthDOT.se> wrote:
> stpatryck<stpatr...@gmail.com> wrote in message <0925d8cc-0669-4057-9ce0-04ccf1b62...@d21g2000vbm.googlegroups.com>...
> > Hello All,
>
> > I'm supposed to write a portfolio optimization Monte Carlo simulation
> > for some foreign mutual fund company on an advisory basis.  They have
> > MatLab and want me to ship my code to them so they can run it over
> > there.  I'm wondering how I can code some kind of protection for my
> > MatLab programs so they don't just take it and cut me out of the
> > picture.
>
> > Is there a way to make the code unusable if they try to modify it?  Or
> > some way I can put in some code so they can only run my progams until
> > a certain expiration date?
>
> > Any suggestions would be appreciated.
>
> This has been discussed, e.g search the thread "Licensing your deployed GUIs" in this newsgroup.
>
> Supply it as p-code (pcode) might a possibility
>
> / per

SaintPatrick <patrickmyu@gmail.com> wrote in message <5131ea0f-cb7e-497b-9083-383dba9fbd01@d21g2000vbm.googlegroups.com>...
> Nathan, Per, and Matt,
>
> Thanks for your input. I didn't know about p-code. I will research
> it.
>
> I appreciate all of your comments. Very good advice.
>
>
> Regards,
> Patrick

... and of course you can allways "time bomb" your p-coded files to expire after a certain date. Yeas it is possible to wind back system clocks, but that tends to have undesireable side effects on many other programs these days.

and, how is it possible to "time bomb" p-file?

thanks in advance

"Giovanni Ughi" <giovanni.ughi@yahoo.it> wrote in message <i2s1mo$48o$1@fred.mathworks.com>...
> and, how is it possible to "time bomb" p-file?
>
> thanks in advance

Well, a simple solution:

function output = myFunction(varargin)

    if now > datenum('2011-01-01') % this code stops working Jan 1, 2011
        disp('Please renew your license');
        return
    end

    % rest of function
end

definitely easy!...

thanks a lot

easy... thanks a lot!

suggested solution seems to work well.

But, if I change the windows clock (system time) will this "crack" the time-bomb?

there is any solution robust to that?

thanks in advance

"Giovanni Ughi" <giovanni.ughi@yahoo.it> wrote in message <i2umlh$n2k$1@fred.mathworks.com>...
> suggested solution seems to work well.
>
> But, if I change the windows clock (system time) will this "crack" the time-bomb?
>
> there is any solution robust to that?
>
> thanks in advance

Winding the clock back is surprisingly harmful these days. Not to be recommended, specially if it's running other licensed software.

"Giovanni Ughi" <giovanni.ughi@yahoo.it> wrote in message <i2umlh$n2k$1@fred.mathworks.com>...
> suggested solution seems to work well.
>
> But, if I change the windows clock (system time) will this "crack" the time-bomb?
>
> there is any solution robust to that?
>
> thanks in advance

the solution is not working...
1) no need to play with the clock...
2) the user can simply overload the function NOW...

us

Giovanni Ughi wrote:
> suggested solution seems to work well.
>
> But, if I change the windows clock (system time) will this "crack" the
> time-bomb?
>
> there is any solution robust to that?

Network connection to a server that indicates whether it is authorized
or not. To prevent the user from interposing a different server, use
encryption on the transaction. Do not make the return value a simple
binary "yes/no" as the user could simply alter that return value.

"us " <us@neurol.unizh.ch> wrote in message <i2uofk$l42$1@fred.mathworks.com>...
> "Giovanni Ughi" <giovanni.ughi@yahoo.it> wrote in message <i2umlh$n2k$1@fred.mathworks.com>...
> > suggested solution seems to work well.
> >
> > But, if I change the windows clock (system time) will this "crack" the time-bomb?
> >
> > there is any solution robust to that?
> >
> > thanks in advance
>
> the solution is not working...
> 1) no need to play with the clock...
> 2) the user can simply overload the function NOW...
>
> us

Quick fix: use builtin('clock') to get the current date and time as a datevec, and compare that to your time bomb date.

"Andy " <myfakeemailaddress@gmail.com> wrote in message <i2up9s$elv$1@fred.mathworks.com>...
> "us " <us@neurol.unizh.ch> wrote in message <i2uofk$l42$1@fred.mathworks.com>...
> > "Giovanni Ughi" <giovanni.ughi@yahoo.it> wrote in message <i2umlh$n2k$1@fred.mathworks.com>...
> > > suggested solution seems to work well.
> > >
> > > But, if I change the windows clock (system time) will this "crack" the time-bomb?
> > >
> > > there is any solution robust to that?
> > >
> > > thanks in advance
> >
> > the solution is not working...
> > 1) no need to play with the clock...
> > 2) the user can simply overload the function NOW...
> >
> > us
>
> Quick fix: use builtin('clock') to get the current date and time as a datevec, and compare that to your time bomb date.

well... then the user overloads BUILTIN...

us

"Andy " <myfakeemailaddress@gmail.com> wrote in message <i2up9s$elv$1@fred.mathworks.com>...
> "us " <us@neurol.unizh.ch> wrote in message <i2uofk$l42$1@fred.mathworks.com>...
> > "Giovanni Ughi" <giovanni.ughi@yahoo.it> wrote in message <i2umlh$n2k$1@fred.mathworks.com>...
> > > suggested solution seems to work well.
> > >
> > > But, if I change the windows clock (system time) will this "crack" the time-bomb?
> > >
> > > there is any solution robust to that?
> > >
> > > thanks in advance
> >
> > the solution is not working...
> > 1) no need to play with the clock...
> > 2) the user can simply overload the function NOW...
> >
> > us
>
> Quick fix: use builtin('clock') to get the current date and time as a datevec, and compare that to your time bomb date.

Yes, indeed. Instead of using function "now" and "datenum" using function clock is robust. "Clock" is a build it function of matlab and can not be modified. (or it is possible?)

But, if someone change the system clock clock is in someway "cracked".
So, how to fix this? there is some other way to do so?

I am not understanding what Walter is suggesting...

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?

"Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i2uqqk$o56$1@fred.mathworks.com>...
> "Andy " <myfakeemailaddress@gmail.com> wrote in message <i2up9s$elv$1@fred.mathworks.com>...
> > "us " <us@neurol.unizh.ch> wrote in message <i2uofk$l42$1@fred.mathworks.com>...
> > > "Giovanni Ughi" <giovanni.ughi@yahoo.it> wrote in message <i2umlh$n2k$1@fred.mathworks.com>...
> > > > suggested solution seems to work well.
> > > >
> > > > But, if I change the windows clock (system time) will this "crack" the time-bomb?
> > > >
> > > > there is any solution robust to that?
> > > >
> > > > thanks in advance
> > >
> > > the solution is not working...
> > > 1) no need to play with the clock...
> > > 2) the user can simply overload the function NOW...
> > >
> > > us
> >
> > Quick fix: use builtin('clock') to get the current date and time as a datevec, and compare that to your time bomb date.
>
> Yes, indeed. Instead of using function "now" and "datenum" using function clock is robust. "Clock" is a build it function of matlab and can not be modified. (or it is possible?)
>
> But, if someone change the system clock clock is in someway "cracked".
> So, how to fix this? there is some other way to do so?
>
> I am not understanding what Walter is suggesting...

Walter is describing a network license manager, something very common in the software industry.

No licensing system is completely crack-proof. Ultimately they are based on a function call from the program to some other bit of code or device returning an agreed, expected (usually obfuscated) value. Making life hard for the person who wants to use your code without paying is about all you can hope for.

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....

"Andy " <myfakeemailaddress@gmail.com> wrote in message <i2urqf$sms$1@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.

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

"Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i2v2i4$avn$1@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
%%%

why you said: "just moved to the recycle bin, pretty useless"

in my case (winXP and Matlab 2009b) when the file is deleted from matlab is just deleted, I do not have anything in the recycle bin.

It may depend on the system settings? (in my case also on different pc it is the same)

Sean wrote:

> 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
> %%%

if now >= 734628


(By the way, the datenum for May 5, 2011 is prime, if someone is looking for a
  cryptographic obscuration of the above.)

"Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i2v52r$njt$1@fred.mathworks.com>...
> why you said: "just moved to the recycle bin, pretty useless"
>
> in my case (winXP and Matlab 2009b) when the file is deleted from matlab is just deleted, I do not have anything in the recycle bin.
>
> It may depend on the system settings? (in my case also on different pc it is the same)

Point taken; on my Macintosh with 2009b it just moves it to the trash. I'd still say overwriting it would be more secure.

Walter Roberson <roberson@hushmail.com> wrote in message <i2v5cd$82r$1@canopus.cc.umanitoba.ca>...
> Sean wrote:
>
> > 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
> > %%%
>
> if now >= 734628
>
>
> (By the way, the datenum for May 5, 2011 is prime, if someone is looking for a
> cryptographic obscuration of the above.)

What? 734628 is not prime.

Giovanni Ughi wrote:
> why you said: "just moved to the recycle bin, pretty useless"
>
> in my case (winXP and Matlab 2009b) when the file is deleted from matlab
> is just deleted, I do not have anything in the recycle bin.
>
> It may depend on the system settings? (in my case also on different pc
> it is the same)

Oh gee, somehow the write permissions on the directory disappeared!

Oh gee, and somehow the ownership of the directory got changed so that the
permissions couldn't be changed!

Oh gee, look here, someone overrode the delete function, too...


The world is littered with the bankrupt remains of software companies who
thought they had developed "unbreakable" license schemes.


I have only heard of _one_ unbreakable license scheme: it involves quantum
entanglement and quantum "action at a distance" to create a data stream that
is unforgeable and unsnoopable (seriously.)

Andy wrote:
> Walter Roberson <roberson@hushmail.com> wrote in message
> <i2v5cd$82r$1@canopus.cc.umanitoba.ca>...
>> Sean wrote:
>>
>> > 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
>> > %%%
>>
>> if now >= 734628
>>
>>
>> (By the way, the datenum for May 5, 2011 is prime, if someone is
>> looking for a cryptographic obscuration of the above.)
>
> What? 734628 is not prime.

Sorry, you are right, I was off by 1. That in turn means that the above code
should be

if now >= 734629

> >> (By the way, the datenum for May 5, 2011 is prime, if someone is
> >> looking for a cryptographic obscuration of the above.)
> >
> > What? 734628 is not prime.
>
> Sorry, you are right, I was off by 1. That in turn means that the above code
> should be
>
> if now >= 734629

But 734629 is not prime either:

>> factor(734629)
ans =
           7 104947

I think you were off by 1 in the other direction:

>> isprime(734627)
ans =
     1

Also, even though the datenum for May 5, 2011 is not prime, the concatenation of the date is:

>> isprime(552011)
ans =
     1

Andy wrote:
>> >> (By the way, the datenum for May 5, 2011 is prime, if someone is >>
>> looking for a cryptographic obscuration of the above.)
>> > > What? 734628 is not prime.
>>
>> Sorry, you are right, I was off by 1. That in turn means that the
>> above code should be
>>
>> if now >= 734629
>
> But 734629 is not prime either:
>
>>> factor(734629)
> ans =
> 7 104947
>
> I think you were off by 1 in the other direction:
>
>>> isprime(734627)
> ans =
> 1

The 734628 datenum was intended to be the datenum of the _next_ day, so that
now >= 734628 would be true as of the first invalidate time. And under that
(incorrect) supposition, the day May 5, 2011 itself would have been 734627,
which is the prime. The off-by-one was in the original number and thus called
for a correction of the number to 734629 for the purposes of the code.

Walter Roberson <roberson@hushmail.com> wrote in message <i2v5cd$82r$1@canopus.cc.umanitoba.ca>...
> Sean wrote:
>
> > 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
> > %%%
>
> if now >= 734628
>
>
> (By the way, the datenum for May 5, 2011 is prime, if someone is looking for a
> cryptographic obscuration of the above.)

now and datnum can be easily "modified". clock is safer

Walter Roberson <roberson@hushmail.com> wrote in message <i2v69h$9a7$1@canopus.cc.umanitoba.ca>...
> Giovanni Ughi wrote:
> > why you said: "just moved to the recycle bin, pretty useless"
> >
> > in my case (winXP and Matlab 2009b) when the file is deleted from matlab
> > is just deleted, I do not have anything in the recycle bin.
> >
> > It may depend on the system settings? (in my case also on different pc
> > it is the same)
>
> Oh gee, somehow the write permissions on the directory disappeared!
>
> Oh gee, and somehow the ownership of the directory got changed so that the
> permissions couldn't be changed!
>
> Oh gee, look here, someone overrode the delete function, too...
>
>
> The world is littered with the bankrupt remains of software companies who
> thought they had developed "unbreakable" license schemes.
>
>
> I have only heard of _one_ unbreakable license scheme: it involves quantum
> entanglement and quantum "action at a distance" to create a data stream that
> is unforgeable and unsnoopable (seriously.)

yes indeed,

cracks exists from a long time.

I was just looking for something reasonably safe.
"Clock" is safe enough, but the problem that a user can easily modify the system date and time is not yet fixed.

Someone can tell me more about that or about any other alternatives?

thanks

clock can also easily be overloaded. My point earlier that you should use clock without wrapping it in builtin is that overloading clock is somewhat more likely to have consequences in other MATLAB files. You could also use both clock and builtin('clock') (that is, check for one or the other) so that the user would have to overload both to get through your time bomb. The point isn't to make it more secure. The point is to make it more trouble than it's worth to get around it.

"Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v5lh$1ao$1@fred.mathworks.com>...
> "Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i2v52r$njt$1@fred.mathworks.com>...
> > why you said: "just moved to the recycle bin, pretty useless"
> >
> > in my case (winXP and Matlab 2009b) when the file is deleted from matlab is just deleted, I do not have anything in the recycle bin.
> >
> > It may depend on the system settings? (in my case also on different pc it is the same)
>
> Point taken; on my Macintosh with 2009b it just moves it to the trash. I'd still say overwriting it would be more secure.

And, how you can overwrite a p-file?

"Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i36bqh$l79$1@fred.mathworks.com>...
> "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v5lh$1ao$1@fred.mathworks.com>...
> > "Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i2v52r$njt$1@fred.mathworks.com>...
> > > why you said: "just moved to the recycle bin, pretty useless"
> > >
> > > in my case (winXP and Matlab 2009b) when the file is deleted from matlab is just deleted, I do not have anything in the recycle bin.
> > >
> > > It may depend on the system settings? (in my case also on different pc it is the same)
> >
> > Point taken; on my Macintosh with 2009b it just moves it to the trash. I'd still say overwriting it would be more secure.
>
> And, how you can overwrite a p-file?

Open it.
Write some garbage to it.
Close it.

"Steve Amphlett" <Firstname.Lastname@Where-I-Work.com> wrote in message <i36d01$59m$1@fred.mathworks.com>...
> "Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i36bqh$l79$1@fred.mathworks.com>...
> > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v5lh$1ao$1@fred.mathworks.com>...
> > > "Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i2v52r$njt$1@fred.mathworks.com>...
> > > > why you said: "just moved to the recycle bin, pretty useless"
> > > >
> > > > in my case (winXP and Matlab 2009b) when the file is deleted from matlab is just deleted, I do not have anything in the recycle bin.
> > > >
> > > > It may depend on the system settings? (in my case also on different pc it is the same)
> > >
> > > Point taken; on my Macintosh with 2009b it just moves it to the trash. I'd still say overwriting it would be more secure.
> >
> > And, how you can overwrite a p-file?
>
> Open it.
> Write some garbage to it.
> Close it.

I am talking about p-files (matlab pcode to encrypt a m-file).
As far as I know I cannot open and edit them anymore. Or am I wrong?

"Giovanni Ughi"
> I am talking about p-files (matlab pcode to encrypt a m-file).
> As far as I know I cannot open and edit them anymore. Or am I wrong?

in general: yes...
however, look at this recent thread...

http://www.mathworks.com/matlabcentral/newsreader/view_thread/271697#713066

us

"us " <us@neurol.unizh.ch> wrote in message <i36fmc$sdq$1@fred.mathworks.com>...
> "Giovanni Ughi"
> > I am talking about p-files (matlab pcode to encrypt a m-file).
> > As far as I know I cannot open and edit them anymore. Or am I wrong?
>
> in general: yes...
> however, look at this recent thread...
>
> http://www.mathworks.com/matlabcentral/newsreader/view_thread/271697#713066
>
> us

this means that you can get info about the variables which are used in the code and relative values (like password values of 12 in that examples)

not that you can edit and open them. So this means that you can not override a p-file as far as I know.

"Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i36e2c$e0p$1@fred.mathworks.com>...
> "Steve Amphlett" <Firstname.Lastname@Where-I-Work.com> wrote in message <i36d01$59m$1@fred.mathworks.com>...
> > "Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i36bqh$l79$1@fred.mathworks.com>...
> > > "Sean " <sean.dewolski@nospamplease.umit.maine.edu> wrote in message <i2v5lh$1ao$1@fred.mathworks.com>...
> > > > "Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i2v52r$njt$1@fred.mathworks.com>...
> > > > > why you said: "just moved to the recycle bin, pretty useless"
> > > > >
> > > > > in my case (winXP and Matlab 2009b) when the file is deleted from matlab is just deleted, I do not have anything in the recycle bin.
> > > > >
> > > > > It may depend on the system settings? (in my case also on different pc it is the same)
> > > >
> > > > Point taken; on my Macintosh with 2009b it just moves it to the trash. I'd still say overwriting it would be more secure.
> > >
> > > And, how you can overwrite a p-file?
> >
> > Open it.
> > Write some garbage to it.
> > Close it.
>
> I am talking about p-files (matlab pcode to encrypt a m-file).
> As far as I know I cannot open and edit them anymore. Or am I wrong?

You can open any file. It's unlikely (by design) that the contents of any p-file will be understandable. But that's not the point. The point is that overwriting the contents of a file is more secure than attempting to delete it. Just open it with fopen() and write some crap to it with fwrite() or fprintf(). Then close it.

"Giovanni Ughi" <giovanni.ughi@gmail.com> wrote in message <i36hbb$fve$1@fred.mathworks.com>...
> "us " <us@neurol.unizh.ch> wrote in message <i36fmc$sdq$1@fred.mathworks.com>...
> > "Giovanni Ughi"
> > > I am talking about p-files (matlab pcode to encrypt a m-file).
> > > As far as I know I cannot open and edit them anymore. Or am I wrong?
> >
> > in general: yes...
> > however, look at this recent thread...
> >
> > http://www.mathworks.com/matlabcentral/newsreader/view_thread/271697#713066
> >
> > us
>
> this means that you can get info about the variables which are used in the code and relative values (like password values of 12 in that examples)
>
> not that you can edit and open them. So this means that you can not override a p-file as far as I know.

well... you can replace/overload a P-file like any other (ML) file as long as you have permission to do so, which depends on the (admin) setup of the folder(s) etc...

us

Dear Giovanni,

> I was just looking for something reasonably safe.
> "Clock" is safe enough, but the problem that a user can easily modify the system date and time is not yet fixed.
>
> Someone can tell me more about that or about any other alternatives?

For Windows:
Get the modification date of the Windows directory.
Either:
  FileObj = java.io.File(getenv('WINDIR'));
  FileObj.lastModified
(of course you have to convert the numerical format)
Or use a Mex:
  http://www.mathworks.com/matlabcentral/fileexchange/24671

Of course this is not "secure": If you run your computer with the wrong date all the time, even the modification dates are wrong.

Another idea:
Let the user run a file, which checks the output of "!ver" (the version of the OS). Then compare the output in your P-file. Am I right: The version number changes with each patch, and nobody would disable the automatical updates???

If your program is really expensive, buy a cheap used laptop, install a trial version of Matlab, obfuscate the P-file as much as possible and check all hardware IDs you can access (User-SID, !powercfg /devicequery all_devices_verbose, dates of creation of the hard disks/WIN directory/Matlab installation, etc).

But finally be aware that some famous manufactures of software do not perfrom such tricks. So perhaps *trust* is the right way.

Kind regards, Jan

> But finally be aware that some famous manufactures of software do not perfrom such tricks. So perhaps *trust* is the right way.
>
> Kind regards, Jan

Trust, or a network license manager, which was suggested much earlier and, although more complicated than a time bomb, is probably as secure as you're going to get (or need).

"us " <us@neurol.unizh.ch> wrote in message > > > > But, if I change the windows
...
> >
> > Quick fix: use builtin('clock') to get the current date and time as a datevec, and compare that to your time bomb date.
>
> well... then the user overloads BUILTIN...
>
> us

d = evalc( 'system(''date /T'')' );

is that any safer?

/ per

"per isakson" <poi.nospam@bimDOTkthDOT.se> wrote in message <i42aaa$ovc$1@fred.mathworks.com>...
> "us " <us@neurol.unizh.ch> wrote in message > > > > But, if I change the windows
> ...
> > >
> > > Quick fix: use builtin('clock') to get the current date and time as a datevec, and compare that to your time bomb date.
> >
> > well... then the user overloads BUILTIN...
> >
> > us
>
> d = evalc( 'system(''date /T'')' );
>
> is that any safer?
>
> / per

... or
1. create a file
2. get the date modified with DIR
3. delete the file (use RECYCLE to avoid displaying the file in the recycle bin)

/ per

per isakson wrote:

> d = evalc( 'system(''date /T'')' );
> is that any safer?

Oh yes, sure, that's fine, we recommend that.



*giggle*. *snicker*. tee-hee. *snort*

Someone wrote about writing in pcode file.If I didnt get it wrong, the user will run the supplied pcode , say mycode.p . How can that file modify itself,while running?

Is it possible?

"Andy" wrote in message <i2v9l0$jk6$1@fred.mathworks.com>...
> clock can also easily be overloaded. My point earlier that you should use clock without wrapping it in builtin is that overloading clock is somewhat more likely to have consequences in other MATLAB files. You could also use both clock and builtin('clock') (that is, check for one or the other) so that the user would have to overload both to get through your time bomb. The point isn't to make it more secure. The point is to make it more trouble than it's worth to get around it.

As the builtin clock function has no executable matlab code in its contents, how about reading the clock function to see if there is any executable matlab code in it, like the word eval, or function?

That would validate whether the code was the original function or not.

This still doesn't stop the system time from being changed, but it prevents the clock function from being overloaded.

Why don't you get the date and time from the internet? If you have a web server you can write a php web page that returns the current date and time. Then you can use the urlread function in your program.

"JGL" wrote in message <ikl8o2$5pv$1@fred.mathworks.com>...
> Why don't you get the date and time from the internet? If you have a web server you can write a php web page that returns the current date and time. Then you can use the urlread function in your program.

Then you can also get statistics from your web server and know who is running your program.

Take into account that the user may be using a proxy, you should set the internet preferences correctly.

On 11-03-02 05:13 AM, JGL wrote:
> Why don't you get the date and time from the internet? If you have a web
> server you can write a php web page that returns the current date and time.
> Then you can use the urlread function in your program.

And somehow protect the interaction from "replay attacks", including somehow
detecting and protecting against urlread() being overridden, and including
somehow detecting and protecting against the entire validation module being
overridden...