Activation Code

[SteveB]

Hi Genx:

While I can understand you wanting to move to a Mac, look at WinBatch in the meantime. It will give you a whole new bag of tricks...stuff that would be difficult or impossible to automate with Filemaker or VBScript. Link

Steve

[CobaltSky]

[color:blue]Moderator's Comment:

Comment, you're just plain irritating.

[color:blue]Steve,

Whether or not the above words were posted in jest, I'm afraid they are *really* not appropriate for the Forums.

Please stay on topic. This site is all about FileMaker and not at all about individuals. Personal remarks and observations - particularly those that could be interpreted negatively - have no place here.

[color:#ffffff].

[Genx]

I'll have a look at it Steve.

Cheers

[Andy Reimer]

Depending on the nature of the application, you can simply hard code certain client information into the database, making it effectively useable only for that client. I'll be selling a runtime online within the next few months and I intend on having paying clients provide me with a name that will appear on the invoices that are generated from the database. I'll hard code it into the build and zip it up for the client to download.

The downside: a bit of work on my part for every sale / client may have to wait a few hours

The upside: the client can give the system to someone else to look at, but they won't really USE it

[Genx]

The downside, should you ever offer upgrades and or / bug fixes, you are going to have generate a new file for every single one of your clients.

Either way, i honestly suggest you reconsider that at this point - you may be getting yourself into trouble - to much customization per client is to much unpaid effort on your part.

Also, if your extremely desperate to do something this way, you could just give them a program, but also send them a text file that is simply encoded - really simply encoded using char numbers or something - just not human readable.

Then simply get the run time to parse this info in if it's never been parsed before. That way you don't have to compile seperate zip files for every single one of your clients.

Edited July 19, 2006 by Guest

[Inky Phil]

I just spent the last few days working on this problem for distribution of my own runtime. Maybe my solution will be of help to others - and then maybe someone will come up with a fault in my logic but here goes.

Issue a fully functional demo file with no hard coded data so anyone can use it as a demo or indeed pass it on to others to use also.

Once installed on their machine, on first use store the date, the time and machine name and set the 'days left to run' field to 30 (or whatever).

On each subsequent use count the appropriate number of days down thereby allowing them the 'dem' period and also check that they have not altered the machine clock/date. If so lock them out..

Before the end of the dem period they have to hand over their money in order to get an activation code off you so that they can continue using your masterpiece .

When they hand over the money they also give you what they think is the 'in-built' demonstration activation code (there really isn't one - in the absence of a 'real' activation code it is just going to run for the dem period then just stop).

What they are giving you is in fact a code that your software has generated on their machine and which encodes the first used date & time to personalise this code to their installation. You then re-encode it some other way and give it back to them.

That way the code you supply them with will only apply to an installation that was first run at a given time and on a given date. It isn't perhaps unique but the chances of someone passing on a code to someone who happens to have run the thing for the first time at exactly the same moment must be low enough not to count.

I also include other details in the code that they give back to me such as version no. of the software and revision no and scramble it all up so it looks all official-like.

So there you have the bare bones of it. I can issue demo discs that anyone can use yet they end up with a personalised code that not anyone can use. I have my money. I also have feedback as to who is using which version and where (if you hard coded each demo disc with a few alts to the code you could even trace them as they moved around)

The only drawback is that if they copied the installed file and gave it to someone then they could use the same code. That is where the machine name comes in.

In the event that someone tries to use the solution on a different machine it issues a warning then reverts to demo mode thereby allowing legitimate users the opportunity to come on to you and get another code and allowing none legitimate users the opportunity to hand over some money.

I realise that this is far from a perfect solution and would not be satisfactory for everybody but it does mean that at least you can put up a fight against piracy without resorting to any third parties.

I would appreciate anyones comments on this because I am well aware that there may be a fatal flaw in all of this and I just haven't seen it yet

Regards

Phil

Edited July 19, 2006 by Guest

[Andy Reimer]

to much customization per client is to much unpaid effort on your part.

I've got applescripts that do the majority of the work for me, but you are right, sell enough copies and any extra work required per sale becomes onerous.

I still think though, that having a set company name (in a solution that prints such things) is a viable way to prevent unwanted duplication of the solution. It's quite possible to allow them to enter the company name when they set up their preferences for the first time and THEN lock it down.

Edited July 19, 2006 by Guest

[Stuart Taylor]

I would have to agree that this seems to work for me. Heres some of the things that are in my solutions and make theft a problem for other companies, (i know not everyone deals with companies)... and i know most of this is not useful for a clean downloaded file ... but may be useful if your install code tests against some of the unchangeable data.

The solution has user logins and on purchasing the buyer/licensee sets themselves with an admin account and password which only allows them to edit the main preferences. I suggest the director do this as it will give them the control over employees access (keep it simple to administrate as they often hate computers too, and they may end up giving the job and code away to other employees)... i find most directors/CEOs are pretty paranoid about there data so this usually works.

The company name is set and unchangable. The software is licenced to there company for its administration so if they start a new company they should buy a new package in my opinion.

Labels include a return address with the company name (which can't be removed), this means that labels to mailing addresses where people have moved get returned. Which is great for them to keep there mailing list up to date and also causes problems for anyone stealing a mailing list as they can't change the company name on the labels.

This works well but does not stop people exporting the data and mail merging it and this has to be possible as quite a few people need to export to send to mailing houses ... you can always add an admin export script password known only to the administrator as they will probably wish to protect from exporting anyway, but its not perfect as directors don't often like to do this kind of job.

Invoices contain the company name and Tax/Vat registration number this can also be set only once and is unlikely to change (in my experience once people have one reg number and it stays the same).

Invoice numbers increment and are not editable and invoice records can also not be deleted only cancelled which is a problem for any potential thief and is also a deterant for anyone thinking about giving a solution to another as this is often sensitive info and will deter the licensee from this kind of action.

Delete all records is not an option in any part of the database making getting the database empty after its been used a problem.

To be quite honest though most people i work with always want some kind of data imported when they buy a solution and it usually comes from a messy excel spreadsheet or crappy solution which is why they want something new, so i find it hard to not have a 1 on 1. (would be great if i could automate everything...am getting closer every day, week, year)

If you are in that kind of situation you may aswell hardcode some stuff like a waking great company logo at startup ... thats pretty imbarrasing for any corporate thief!

I also find people want to take copies around on laptops so hard coding the system into the thing to make it unmovable is asking for trouble, (although i suppose you could set an expiry date on these kind of moved files).

If a system fails most companies will want their solution up and running again on another machine within a couple of hours, therefore they have to move the backups to another location. Hardcoding the system is not a solution and makes a mockery of any backups.

Would be great if you could set part of the install code from filemaker server as if you moved systems presumably most would reinstall the same filemaker server too (of course filemaker server would have to log a list of codes as any upgrade codes would screw this, oh and if your client opted for upgrades a couple of years down the line with a fresh set of filemaker full versions (not upgrades) you'd be screwed again)... sorry streaming thoughts. ... infact forget this last idea as your thief probably stole filemaker too!!!

Some of these things may be of help some people ...

Stuart

Edited September 1, 2006 by Guest

[Fei]

I am using a little software to distribute my Windows Runtime solution. Check this out.

www.exeshield.com

I have been using this software for the past 3 years. During the runtime compilation, strip off the admin access permanently so that people can't copy your software design code. Hope this help dev that need to distribute their software.

[pjdodd]

Stuart T

Some good ideas.

I also favour clever techniques that limit and/or lock out the solution rather than over-hard-coding ideas that assume that your client (a) wont move address ( upgrade their computers © employ only sensible employees with perfect computer skills and (d) has malicious intentions.

In my solution I also have a single "Admin" access account that's set once on registration. Of course it's not full-access (that's wiped on creation of the runtime) but it's nevertheless as much as I dare grant.

I have also created an access level system using the limiting capability of the Accounts. For example, in Demo mode a specific field is set to Zero, in Registered mode it is set to 1, Enhanced mode it is set to 2 and so on. This way layouts, scripts, and the ability to create, modify or delete record can be limited using the formula

not <> >0.

i.e. user must be registered

not <> >1.

i.e. user must be registered to Enhanced level or whatever you wish to call it.

Registration could be complex and hard coded that it will decrypt the username and company from it. As suggested a nonsense text file would work well. And also mean that unlocking a file means having someone else name plastered over the solution, a further deterent.

I also include several "integrity checks" in the startup and shutdown scripts that include :

Checking that the solution is being opened in a runtime, else quitting.

Checking the solution is running on Mac, else quitting.

Checking the status of Registration and if in doubt i.e. possible tampered, reset to Demo mode.

Presence of Demo mode triggers additonal limits on necessary fields (than those enabled via the Accounts options mentioned above) and annoying messages Solution wide.

I also recommended setting the menu options to editing only or none. That way record creation and deletion can be controlled and monitored via scripts that in turn can have limits set on them when in Demo mode for example...

[Tony D.]

Here is a database that I have used in the past to create a unique registration number. The attached database creates a 24 digit registration code based upon the client's name and modification date.

Here is how it works....

You create a registration layout (similar to the one in the attached database) with a company name and six registration entry fields. These six entry fields will be where the customer enters their registration code. You will have to create a script that will check what they enter with the registration code that the attached database creates.

When your program is copied to the hard drive and executed for the first time, a script (that you need to write) creates a single record in the registration database. The customer then types in their company name and makes a note of the modification date that you display on the layout. The customer sends you the company name and the modification date.

You then type in their information to generate their code and you send the code to them. And since this code is created by the same calculation that is in their copy of the database/product, the code that you send will match the code that was generated on their end. After you send them the code, they will then type it into six fields. Once the six fields match the hidden six fields that contain the registration numbers, a calculation field is set to "Registered".

Then, the next time they start the program, a script checks to see if this calculation field is set to "Registered". You would then also need to set an expiration date for the script to check. If the product hasn't been registered within 14 days of the registration modification date, then the program will quit. You should set this expiration date to be a global variable - and use a script to set the value versus a calculation - otherwise they could just create a new registration page which would push the expiration date out further.

The attached database is "your copy" that you use to create a unique registration code, using the company name and modification date that the customer provided.

The calculation field takes the modification date and company name and substitutes various strings for each letter/number in both. It then produces a string of 4-digit codes that you can use for your registration code.

The code is dependent upon the user typing in their company name, as that is how the code is generated. If you are worried about someone copying your database and giving it to a friend, the formula uses the modification date on the registration layout in the formula, and that produces a different first four characters for the code. You could also incorporate the modification time, or serial number based upon a date or day of the year, etc. in case you are worried that someone will copy it on the same day.

In this example, Apple Computer has registered three different times, with three different dates. Each of the registration codes are now different, as the first four characters are driven from the registration date.

And, you can change this formula around to create different codes - just be sure to copy the same formula to your product/database before shipping it to your client.

Tony D.

registration_code.fp7.zip

[Genx]

I don't get how it works?

[pjdodd]

What you have uploaded is a good version of what I have seen elsewhere and even commercially. More importantly, it is not a painful plug-in and is easily to impliment.

I both like and dislike the idea of coding the de-coding parts in to the solution. I like it because it is a one-off effort, i.e. many, many codes work for just one set of scripts but then the flaw could be if someone actually figures out HOW the code is being translated and/or validated. Obviously the more complicated the code is and the more steps that are required the better. But still there is the inherent danger that a good hacker will get your file and be able to find the decryption routine.

There is also the "problem" of using the computers serial number, or MAC address, or even IP address. It allows for the hacker to easily begin to track the activation code sequence.

I strongly like the idea of client and developer interaction, in a similar way that responding to one or two emails can be required for activation of a forum account. I think this aspect warrants further development, perhaps involving the transmission of a small "activation" file from client to developer that the developer returns that enables something in the main solution.

I still have not got my head around joining the two problems of activation and how to solve them in one secure step;

1) How do you turn a demo solution in to a full one securely?

2) How do you transmit the ability to activate the solution to the client, but render that activation inoperable to anyone else?

My head hurts.

[Stuart Taylor]

I still have not got my head around joining the two problems of activation and how to solve them in one secure step;

1) How do you turn a demo solution in to a full one securely?

2) How do you transmit the ability to activate the solution to the client, but render that activation inoperable to anyone else?

And there the problem lies

I think the security forum should be split up... or at least when discussing security each of these should have an equal footing and be discussed seperately or addressed as seperate and equally valid issue.

1. Securing the data extraction and invalid script triggering of a solutions by an unauthorised person (hacker)

2. Securing the data from access by users any level of access from gaining access to data above their level.

3. Securing the solution from illegal distribution and modification both in terms of licences and intellectual property.

1 = attack

2 = user

3 = developer

(of course a user may be an attacker)

just my thoughts.

[comment]

I agree - although a two-way split should be quite sufficient, I think:

1. Protecting the users' data;

2. Protecting the developer's intellectual property.

[Stuart Taylor]

Hey Comment,

Your right.

Think i should pose this to Steven? Like he doesn't have enough to do... or poll it on Forum Feedback.

what do you think ... should i put in the request for the Intellectual Property sub category of Security Concepts?

Security Concepts > Intellectual Property

or

Security Concepts > Intellectual Property Protection

or

Security Concepts > Intellectual Property Concepts

or

Security Concepts > Intellectual Property Techniques

or

Security Concepts > Intellectual Property Methodology

best

Stuart

[Stuart Taylor]

Actually i think this is really important so i am gonna go ahead and put in the request

[Genx]

This one sounds good:

Security Concepts > Intellectual Property Protection

Ignore that last bit.

Edited December 10, 2006 by Guest

[Stuart Taylor]

You can vote or disagree here ... YAY A POLL

http://fmforums.com/forum/showtopic.php?tid/182890/

[pjdodd]

My point was to highlight that the best approach for an Activation Code would be to combine to dual aims of securing intellectual property and building different "levels" of access into your solution. In terms of access there is enough in-built security with priviledge sets (and fine tuning them) to keep data secure and prevent one user from attempting to access records/layotus etc from a higher level. The issue I wanted to highlight was how do you securely promote a user from one access level to another via secure scripting? And surely this must be done best by combining it with a method that allows software activation, isn't it?

I am nervous about approaching these two aims from two different perspectives because I believe they are the same, sort of! Therefore I do not think the security forum requires splitting at this time.

There is gap in Filemaker (or is that flaw?) that simplisitically assumes that all users only ever need one priviledge set and never change it, at least not without incurring some kind of security hole. Yes there is ability to change a users priviledge set using scripts but there isn't a built-in security check, nor is there any kind of built-in validation. At the moment the checks are coded by hand, as is the "validation" and therefore it's open to human error on the developer side and hacking on the user side.

Filemaker hasn't been designed to do much beyond handle data, which is does exceedingly well. Despite the changes and improvements regarding security to FM7 I still do not think it has caught up in terms of providing the flexibilty that developers demand once their solution gets released. This applies to parts of security as well as other neglected areas. Custom login screens, proper "user promotion", built-in timed demo, fully customized menus, decent GUI options...I guess the wish list for later versions of FIlemaker will get some new additions. Again. Do they ever read them?

[Genx]

Data security is not synonymous with Intellectual property security, in one you are protecting your clients investment, in the other you are protecting yours as a developer -- namely to dealing with piracy, theft and distribution issues.

Edited December 12, 2006 by Guest

[pjdodd]

Thats my point - in order to protect your intellectual property you must presently employ methods that rely upon protecting data (i.e. the data held by your solution that validates a registered user, or not). The two are currently co-dependent and in my opinion should remain so.

[Genx]

I really don't see how they are co-dependent... Here's the issue, the user gives the file to someone else with their login and password... Sure the data is secure, but how does it help you?

[Genx]

New idea, why not just have a 30 times open thing.. or wipe all data each time it closes, or something like that, until they "activate" it. At least that way you get rid of the chance of them changing the date on you.