How to set a 30 days demo version

[Henry]

Hi,

Just want to ask about the script to set a program valid for 30 days only, like today is the date for first time using the program, after 30 days, the program will not allow user to run or use it.

Henry

[djgogi]

If you think that the program you have made really deserve the decent protection than make an true Demo version with limited set of options like disallowing Print, Export ect (from password privileges) and/or creating demo versions of your main scripts that only explain what would happen in full version of your program.

The important is that there is no option for registering and hence gaining access to full version inside your DEMO files, iow you should have two separated versions.

Any way if you want to give a way your work the script should be something like this:

Start-up script

Allow Usere Abort [off]

Set Error Capture [on]

Freeze Window

If[gDemo] //first hacker's entry point

If[gFirstRun] //second hacker's entry point

Set Field [gStartDate, Status(CurrentDate)]//third hacker's entry point

else

If [status(CurrentDate)-(gStartDate+30)>0]//another hacker's entry point

Show Message [This Demo has been expired, blah blah blah]

//Closing Script

end if

end if

end if

Continue if everything is OK

Dj

[digitalchaos]

Personally this is the script that i use for my Demos and i have been getting paid so far but if someone beleves that this is hackable please let me know how you think it can be done and what to do to fix it.

Validate Me

# ?This whole script validates if a certain calender date has passed and if it has requires a validation code to be entered to continue opening the file or else it quits the

program?

Allow User Abort [ Off ]

Allow User Abort [ Off ]

Set Zoom Level

[ 100%, Lock ]

Toggle Status Area

[ Hide, Lock ]

If [ Validation = "Activation Code Goes In Here" ]

Set Field [ Validation Mark, "" ]

Go to Layout [ Layout Name Goes Here ]

Exit Script

Else

If [ Status(CurrentDate) ! Date(0,00,0000) or Validation Mark = "X" ]

Set Field [ Validation Mark, "X" ]

Beep

Go to Layout [ Activation ]

Go to Field [ Validation ]

[ Select/perform ]

Show Message [ Buttons: ?OK?, ??, ??; Data: ?It has been 30 days since you started usingThis program To continue use of this product , you must obtain a validation code If you wish to purchase a validation code Please see purchasing instructions that came with this Template? ]

Pause/Resume Script [ Indefinitely ]

If [ Validation = "Activation Code Goes In Here" ]

Set Field [ Validation Mark, "" ]

Go to Layout [ Layout Name Goes Here ]

Exit Script

Else

Beep

Show Message [ Buttons: ?OK?, ??, ??; Data: ?Warning this program will continue to quit Until we are paid, Please see Validation Code purchasing

instructions that came with this Template? ]

Quit Application

End If

End If

End If

[djgogi]

1) This script may not be evere called.

Solution: None

2) If [ Validation = "Activation Code Goes In Here" ] is plain text (in any hex editor)

Solution: At least use some text functions to mask the code

3) Set Field [ Validation Mark, "" ] Validation Mark could be set from external (to your solution) file

Solution:Change "Validation Mark" from (global) field to calculation

4)Go to Layout [ Layout Name Goes Here ] used with Toggle Status Area [ Hide, Lock ] is not an valid protection, since Status Area would be unlocked when opening file by reference.

Even hiding all layouts form Layout menu, would not increase the security of the system; all layout that could be accessed (according to privileges assigned to the current password) will be accessed (if neccessary)

Solution:Use launcher file with this script and step Open[yourSolutionFile] instead of Go To Layout

5)If [ Status(CurrentDate) ! Date(0,00,0000) or Validation Mark = "X" ] first parameter in or suffer the same problem as in 2), also Validation Mark could be set from external (to your solution) file

Solution:Change "Validation Mark" from (global) field to calculation

6)Pause/Resume Script [ Indefinitely ] could be easily Halted

Solution : None

Global valutation:

Basic Protection , Easy to by pass

Requested skills for cracker :

Intermediate knowledge of FM and/or basic usage of hex editor

How to improve the system:

Create an external "launcher" file

Allow User Abort [ Off ]

Set Zoom Level

[ 100%, Lock ]

Toggle Status Area

[ Hide, Lock ]

Freeze Window

If [ Validation Mark ]

Open[your files]

Close[]

Else

Beep

Go to Layout [ Activation ]

Show Message [ Buttons: ?OK?, ??, ??; Data: ?It has been 30 days since you started usingThis program To continue use of this product , you must obtain a validation code If you wish to purchase a validation code Please see purchasing instructions that came with this Template? ]

Go to Field [ Validation ]

[ Select/perform ]

Pause/Resume Script [ Indefinitely ]

If [ Validation Mark]

Open[your files]

Close[]

Else

Beep

Show Message [ Buttons: ?OK?, ??, ??; Data: ?Warning this program will continue to quit Until we are paid, Please see Validation Code purchasing

instructions that came with this Template? ]

Quit Application

End If

End If

Where Validation Mark is calculation field defined as some function of Validation and Demo date fields

Dj

[Cousin Jack]

Thanks, Djukic. I was searching in the hope of finding this info, but think I will take your advice and put out a separate Demo rather than use a 30 day expiry.

Many thanks

CJ

[CobaltSky]

Hi Cousin Jack,

Your response on this thread is topical, because coincidentally I've just recently posted product announcements for a couple of new shareware products that relate directly to the issues discussed above (see Product Announcements thread).

In broad terms I agree with much of what Djukic said on this thread - and it must be said that no solution (FileMaker or otherwise) can be made absolutely unassailable. However there are a couple of points that are worth noting, especially in relation to the first and sixth issues, for which Dj indicated that there was no solution. Just as you can never hope to cover every eventuality to protect a solution, so too there is no hacking method that can't be countered in some way.

That said, I thought it might be worth making mention on this thread of a core security technique that is frequently used in advanced solutions and that can go quite a long way (if implemented with care, thought and a little ingenuity) to providing a solution to the issues 1 and 6 identified above.

The solution is one that is most commonly termed 'script signalling', and the basic idea is simple enough. Script signalling involves using one script to pass a 'security clearance' to others - and in its simplest (and least secure) form it sometimes involves having one script place an obscure alphanumeric string into a designated field, and having other scripts check that the correct 'clearance' is present before proceeding (and immediately deleting it if it is present).

In more sophisticated implementations, the script signal will not be fixed but will be dynamic, being dependent on some combination of time, date, file size and a range of other variables which can be combined in ways that make the system extraordinarily difficult to 'spoof'. Secure implementations often also involve multiple signals and one or more calculation fields which compare the signals to see if they match before returning a corresponding (also dynamic) signal of their own (which is what is picked up by the subsequent script/s). Dynamic signalling of this type can be implemented in ways which are considerably more robust than the static method (ie so that a hacker cannot simply contrive to find out what all the signals are and write them to the relevant fields at the correct instant from an external source).

How this relates to the issue of disabling start-up scripts or halting the start-up or other scripts before they have run their course is that the whole solution can be structured so that every other script or calculation is dependent on receiving valid signals from the start-up script and other security scripts. What that means is that though hackers may manage to bypass the start-up script, nothing else will work, calculation results will not show and every script and button in the file can be set to invoke the start-up script if the signals (that indicate it has already run) are not present. Or to abort and exit - or whatever else you determine.

The chief value of this technique is not so much in its 'impregnability' as in the fact that each developer can devise startlingly individual variations on it, which makes the hacker's job of reverse engineering more awkward to say the least.

That said, I am not about to give specific details about some of the dynamic signalling implementations (of my own or others) that I have seen - certainly not on a public forum. But I can say that there is quite a lot that can be done to counter a range of vulnerabilities - including each of those that Dj has referred to above.

I stop a long way short of suggesting that any solution can ever be totally secure - there are no absolutes. But with a little attention to detail you can certainly ensure that the level of effort required to circumvent security is going to be greater than the 'pain of payment' for the overwhelming majority of users. The use of dynamic script signalling, along with the judicious application of encryption techniques can make the level of expertise and effort required of the hacker exponentially greater.

[Cousin Jack]

Thanks Ray, greatly appreciated

[Leb i Sol]

I stop a long way short of suggesting that any solution can ever be totally secure - there are no absolutes

http://www.softpile.com/Utilities/Password_Recovery/Review_18489_index.html

[-Queue-]

"Limitations

Databases protected with FileMaker Developer Tool are not supported"

This is the one good reason I've seen to get FM Developer so far.

[CobaltSky]

Hello Leb i Sol,

Your reference to FileMaker Key, apart from further aiding their cause, serves to point to the fact that unless steps are taken to intelligently safeguard a solution, it will be easy prey to street-wise hackers.

You quoted one line out of my previous message, but overlooked another: "Just as you can never hope to cover every eventuality to protect a solution, so too there is no hacking method that can't be countered in some way...".

I failed to mention third party hacker tools because it was not (previously) the subject of this thread, but just as there are tools to aid the hacker, so too are there tools - and very effective ones at that - to counter those threats.

As Queue has already mentioned, the FMD Developer Tool itself provides protection against that particular threat, but there are other tools also, such as Password Administrator from New Millennium Communications. It is interesting that you seem to be aware of the one - and happy to publicise it, but are seemingly not aware of the various solutions that are widely used to protect against it.

I might add that it doesn't stop there - there are still other methods and tools available to hackers which place solutions at risk. And in each case there are methods by which those tools can be countered and those risks reduced or eliminated. In the case of the product you have drawn attention to, the threat can be eliminated entirely by the use of readily available tools, all of which have been in common use since well before the hacker tool itself became available.

The point of my earlier email was in part to point out that while hackers may develop and acquire tools and techniques, others need not passively wait to be their victims. There are many options available which will increase a solution's ability to resist attack, including - but not limited to - those that I mentioned above.

And equally importantly, just as there are third parties who, in their wisdom, choose to publish or publicise tools to aid hacking, so also there are third parties who choose to publish tools and/or techniques designed to frustrate hackers. I count myself among the latter.

[djgogi]

Ray,

there is absolutely no way to protect your solutions.

This includes use of :

Developer's tool "stripping" info on file structure

Use of plug-ins of any kind

Custom encrypting

Manual editing of fm file

Any other method you could think of.

the level of effort required to circumvent security is going to be greater than the 'pain of payment' for the overwhelming majority of users.

It is the question of minutes if not seconds and, trust me, I'm not exaggerating

Dj

[djgogi]

CobaltSky said:

the FMD Developer Tool itself provides protection against that particular threat, but there are other tools also, such as Password Administrator from New Millennium Communications.

Too bad it's not the true.

NMC Password Admin is good for internal (developer) use but by stripping the master pw from file you will not in any way increase the security of it (I know that many of you will find this sentence absurd )

On the other side, do you think that developer tool will really strip the info on file structure?

Only thing that you can really protect is the data inside the file:

use of one-way-hash as in Bob Weaver's example or your's 30 page calcs in DataVaultMaker.

Dj

[CobaltSky]

Hi Dj,

Nice to hear from you.

When I said "the FMD Developer Tool itself provides protection against that particular threat" I was referring to the specific threat posed by the tool called 'FileMaker Key' which Leb i Sol drew attention to. I believe that if you investigate further, you will find that Queue is quite correct and that particular tool provides no 'support' for FMD-stripped databases, nor for NMC-PA 'treatment'.

Moreover when I said "greater than the 'pain of payment' for the overwhelming majority of users" I meant just that. You are not one of the majority, Dj. The fact that you may be able to get into any database on the planet in a matter of seconds does not mean that the other 99.9% of the population can. Unless you (or assorted others I won't name) are advertising your services at a rate which is cheaper than the buy-price of a given end-user solution, most people will find it easier and/or cheaper to simply buy the product - provided reasonable steps have been taken to protect it, as outlined by both of us above.

I stand by my earlier statement that there is no hacking technique that cannot be countered in some way - and I believe I am familiar with most, if not all, the techniques you're referring to, including packet sniffers and disk and resource editors. Surely you are not saying that you are a better hacker than developer - that you cannot develop in ways that you yourself could not hack apart in seconds? If that's true, then I respectfully suggest that you've been resting on your laurels.

I challenge you to find and propose constructive solutions to add to those that both of us have described on this thread, rather than standing on the side-lines repeating that 'it can't be done'.

[djgogi]

Hi Ray,

it is always pleasure to discuss with you;

First, let me clear one thing:

I'm not the hacker...

... and that's exactly the problem.

If I can enter in any FM file in matter of minutes than I don't see why it could not be done by someone else.

I have to disappoint you, I cannot develop in ways myself (or someone else with same or major knowledge on issue)

could not hack apart in seconds.

Anyway,the same is valid for you too, and the problems is not the technique used to protect the files.

The problem is burden deeply in FM document structure and I don't see how it could be addressed and solved in near (FM 7) future.

Stated simply, any FM file (including those "special" files) has intrinsically potential to "forget" restrictions imposed by any means.

Against that, I don't see what you, me or anybody else could do.

Now, regarding "constructive" solutions (it's quoted because they are in fact all destructive from document point of view) the only thing I can say here is:

I'm working on it.

Best regards,

Dj