Demo Version Protection Scheme Project

[digitalchaos]

This is a general question to the board

Before i start i do understand the principle of having demo files one with only a certain amount of records that can be saved i.e. 250 record limit and disabling exporting, printing, deleting, etc and then haveing them pay to get a fully working copy

My reasons are limited bandwith for them to redownload a paid version and i can not afford the prices for the developer plugins that would provide these features and functions for me.

But this is what i would like to do please let me know if i am on the right track.

(1) If the user sets the clock back from the date that the file was launched. then quit the program with a message telling them to fix the date

(2) set a limit on days file will work based on the launch date i.e. 30 days after that the file quits the program

(3) Upon reaching that time limit an activation code must be purchased this activation code is produced using a random serial number generator using all the characters on the keyboard

(4) Also an serial number calculated based upon their name, email address, or mailing address or some other string i provide must be entered also

(5) The default password only allows them to create, not print, delete, export, any records they get a password that allows all these minus any developer privileges when they pay

(6) Remove any comments from scripts because when viewed in a hex editor it seems that any literal text can be read even in a calculation i.e. password="abcd"

(7) make the activation string large enough that when viewed in a hex editor that it just blends in

with what is seen

(8) make no reference to fields by literal name i.e. password serial number, etc use something that makes no sense except to you like i.e. kala2nsd9

any way thanks for reading this and any creative critisim is welcome

[SteveB]

You've raised a lot of issues. First, I would get a free copy of David McKee's encryption plugin (check the FM plugins web site www.fmplugins.com ?).

(1) If the user sets the clock back from the date that the file was launched. then quit the program with a message telling them to fix the date

I would kill the demo if they mess with the clock.

3) Upon reaching that time limit an activation code must be purchased this activation code is produced using a random serial number generator using all the characters on the keyboard

Use the encryption plugin for these issues.

You should get FM Developer and create a runtime or a kiosk, as this will make it much harder to take your solution apart.

Steve

[digitalchaos]

Unfortunately i cannot afford the developer release yet but hopefully i will be abel to purchase it some time in the future. I should have clarified that i am developing on a Mac using OS X as the crypto plugin says it is for Mac OS 9

When you say kill the demo do you mean so even if they fix the date it still wont run i.e. launches and then quits. Filemaker Pro

[SteveB]

David hasn't updated his web site for a while. The plugin probably still will work on OS 10...it's worth trying.

I mean kill the demo permanently. If a user is trying to bypass my copy protection, as far as I'm concerned the demo has permanently ended. The more chances you give them, the likehood of success will increase.

There is nothing that we develop that can't be overcome with enough trial and error, so why make it easier for them.

Steve

[kenneth2k1]

Your DVDatabase looks good, BTW

[digitalchaos]

Thanks for the nice comment kenneth2k1 i used to only dabble back when filemaker was ver 3.0 now i just want to do a few small and inexpensive solutions for people that can afford to pay the small fee i am asking and to Steveinvegas you are absolutely right if the have the nerve to try to circumvent the protection scheme then the program should no longer work

[cjaeger]

(1) If the user sets the clock back..

you dont travel between timezones, do you? And never had the OS X date bug, setting the date back to 1970 .... It's OK to refuse launching while the date is set back, but destroying the file is not.

(2) set a limit on days file will work

fair enough. but I would count the days of actual use (if launchdate > lastlaunchdate, count+1). make sure you give a warning before it expires.

(3) Upon reaching.. using a random serial #

cant be that random. How will you validate a random #?

(4) Also an serial number calculated based upon their name, email address, or mailing address or some other string i provide must be entered also

email is a bad idea. those tend to change. Name is OK (most people don't forget their maiden name ...)

(5) The default password only allows them to create, not print, delete, export, ....

that's simply not fair. the program is yours, the data not. And not being able to delete is just stupid. try a record limit instead & allow only to print/export part of the data.

How do you expect people to be able to test your solution?

(6) Remove any comments from scripts....

don't use them in the first place. Comment your scripts on paper/ in developer report

(7) make the activation string large enough

... you can split it between different, randomly named fields with some kind of calc ...

(8) make no reference to fields by literal name ...

that makes it very hard for you to develop. Just imagine scripted imports or field labels.

just keep this trick for password, activation and other internal fields, not for visible (customer) data fields.

General comment:

working with activation codes is never 100% safe. Codes, however sophisticated, can be shared. Limiting your demo user too much discourages from buying your solution. With the help of http XML ex-/import, you can actually keep track of the use of your demo, notify about updates and upgrade information. You may even exchange 1 or to files to turn the demo into a full version, so you can save a lot of time working on encryption algorythms. Once the software is purchased, you should query for validation only if the software is moved to another computer (or the file path/computer name/ethernet address/Volume serial # is changed). Automatic version checking via internet should be optional for the user.

[BobWeaver]

A very simple solution is to let the demo run only 20 times, and don't allow any import/export. After 20 times, you give the user a message saying that the demo has expired. The user can always reload a clean copy of the demo, but it would not have any of his records in it. So, he would have to manually re-enter them. This should be enough to discourage anyone from using it without paying.

[cjaeger]

Hi Bob, it may discourage from buying as well. The user should have some return from using that demo. I'd prefer feature-limited demos over time-limited ones. But then, I studied Marketing, not Programming.

[cjaeger]

David hasn't updated his web site for a while. The plugin probably still will work on OS 10...it's worth trying.

None of them work on OS X. They are simply not compiled for it.

Does anybody use CodeWarrior here?

Please do us a favour and compile them for OS X. The sources (exept the FileMaker APIs) are at www.fmplugins.org . The FileMaker APIs are part of FileMaker developer.

Anybody want to try?

[BobWeaver]

I'd prefer feature-limited demos over time-limited ones

From the users' point of view, I'm just the opposite. If I'm given a full featured demo, it doesn't take me very long to know whether I want to buy it or not. When I get one that has half of the features disabled, then I'll probably never know whether it will do what I want. I usually won't bother wasting my time playing with crippled demos.

[SteveB]

I agree with Bob...I distribute a fully functional demo that has a 30 day time limit from the install date. A user can purchase a registration # which will convert the demo into a complete version. If they can't decide within 30 days whether they want to purchase, they probably don't.

Steve

[cjaeger]

feature limited like

- a (generous) limit on the number of records

- a DEMO watermark on each printout

- missing customizing options

- annoying warnings/advertising screens every now and then.

- and yes, maybe a time limit of 20 actual days working with it, not 30 calendar days.

You may also consider to split the solution in modules, so you can unlock different options even after registering by upgrading your key. Keeps contact to the customer and the initial price lower.

[BobWeaver]

The "Demo" watermark is a good idea. It doesn't limit the user's ability to explore the program, but it would discourage him from distributing the output to others. Useful in a situation where the user only needs the program for a short oneshot project and hopes to do the whole thing with the demo.

I would allow user customization etc., because one or more of these features could be deciding factors for purchase.

Annoying warnings wouldn't limit the user's ability to explore the program, but I'm not sure that the benefit would be worth the development time.

I prefer to limit the number of times the database is opened rather than put an actual time (date) limit on it. It's much harder to reset an internal run counter than the system clock.

[digitalchaos]

No sorry i do not travel outside the US and i haven't had the OS X date bug problem i kind of agree on the not destroying the data but it is a sticky situation not knowing if the set the date back intentionally or not

As for the random number i generate that ahead of time and it is already in the file i just have to check for it when i email it back to them right now the string is 253 characters long and as generated by a random number generator if i need to i can generate a string over a thousands characters long

The reason i chose the email address as a first choice is because it is so readily available i.e. they have to email me to get the serial anyway so why not use it as a first choice

The literal name for fields thing was only for fields that apply to anything that has to do with activation nothing else

I also like the idea of printing demo watermarks across printed pages of unregistered printouts

BobWeaver can you elaborate a bit more on setting up a database to track the amount of times it has been opened thanks i cant seem to find anything about that when i search the forums database

I would like to thank everyone for their input so far please keep the ideas coming

[Anatoli]

RE: can you elaborate a bit more on setting up a database to track the amount of times it has been opened thanks i cant seem to find anything about that when i search the forums database

In start script increase value in field by 1. Set HowMany to HowMany + 1

HTH

[digitalchaos]

Gee that was so simple i dont know why i was thinking it was some part of a status function anyway thanks for setting me straight on that Anatoli

[Anatoli]

Great!

I know only simple things

[Tony59]

For my Demos I do a combination of the techniques mentioned in this thread ie

- Put a Logo on a layout (hidden) password protected and have this appaer and print on all layouts

- Put in a time limitation with three components done via fields and calculations to a) measure how long the demo has been open, : when the first date opened was, c) when the expiry date should be. This will cover the messing with clock issues. The changing time zone may trigger the time limitation a little early or late as the case may be (a small issue). The time open script/calc is triggered as a frequently used button is pressed.

- I also put a record size limit in as well again via script at shutdown.

Once the time limit is triggered there are a couple of options. The nasty one to people I "don't know" is to kill the database - many solutions to break the relationships so it doesn't work any more. Or with others take them to a layout that is one big button that quits out of filemaker after a notice of your choice.

The reality is that any of this could be worked around by experts such as the guys here (although FM Developer makes it harder). I take the philosophical view that if naughty people are good enough to figure out ways around the above they are much better filemaker programmers than me so they could also make a better solution as well. So good look to them.

Hope this helps, I don't contribute often (mostly because I only know the basics) but I think the combination of the above is the a realistic approach.

TTFN

Tony