Runtime Use Limitation

[mhudd]

Is it possible to distribute a FM runtime with a use limitation? Something like after the runtime is opened 20 times then it's disabled...?

[SteveB]

Sure. Define a global number field that gets incremented by a startup script.

[mhudd]

Perhaps I should rephrase my question.

I want to limit the use of my runtime and at the end of the time limit either the user buyes the runtime or it won't open.

Is it possible to provide unique passwords or registration numbers that "unlock" the limited version?

[SteveB]

Again, yes. Have the user give you the hard drive serial #, which you can get thru the use of the crypto toolbox. After he pays you, give him an encrypted string that your solution will decrypt back into the serial number.

You can also check www.databasepro.com for other techniques.

[mhudd]

Steve,

I would like to pay you for the script that does what you indicate in your post. Please let me know how to proceed.

Michael

[Steven H. Blackwell]

Such validation schemes are usually easily bypasssed. Proceed with caution.

Old Advance Man

[SteveB]

OAM: I'm really curious as to how locking the solution to a given hard drive can be easily bypassed. I have a Kiosk that I'm using this on. I think what I've done is pretty bullet-proof. I capture the disk ID when the solution opens for the first time and save it in a global. If someone can find it and change it, how?

[Steven H. Blackwell]

quote:

---

Originally posted by Steveinvegas:

OAM: I'm really curious as to how locking the solution to a given hard drive can be easily bypassed. I have a Kiosk that I'm using this on. I think what I've done is pretty bullet-proof. I capture the disk ID when the solution opens for the first time and save it in a global. If someone can find it and change it, how?

---

Well first, suppose that someone opens the file in a way that does not check the value in the global? Would it be reasonable to assume that this check is part of a start-up script?

Second, the value in the global can be found via relations, via AppleScripts, via other external API's, and so forth.

Some of this is covered in the Security CD available from MAcAcademy-Windows Academy.

HTH

Old Advance Man

[danjacoby]

What I've done (and there may be a more elegant way to do this) is create, in the "demo" version, a script that runs on opening. It checks the date in a global date field and, if it is empty, returns the current date. Then it tests the date in the global field with the current date. If enough time has passed, it enters some data (anything at all will do) into a global text field.

It actually checks the global text field first. If there's anything in that field, the script does a "show all", then shows a message saying that the time is up for the demo, but if they want to pay for a full version, yadda yadda yadda.

Upon paying for the full version, they get one that doesn't have all this stuff, but does have an import script attached to a button that they can run upon opening the full version. That way, they won't lose any data.

[djgogi]

I'm agree with Dan:

The only wayis to create an real demo version of your products. Otherwise you should execute the controll script every time is triggered some of your scripts and not only at atart-up. Also bevare of possibility ro read any data accessable with current password wether present or not on any of your layouts.

So you should do your calculations inside a script, like this:

code:

---

if(ValidationFormula(userName)=regNum)

unlock

end if

and not

if(calcField=regNum)

unlock

end if

where calcField=ValidationFormula(userName)

because , (almost) anybody coul read data in calcField

HTH

Dj