Installation code

[danjacoby]

So I've created this amazing solution and bound it for both Mac and Windows, and I'm ready to distribute it on CD-ROM.

I'd like to do what major software companies do -- have a unique installation code for each copy. It won't prevent illegal copying, of course, but it cuts down on it.

Can this be done using FMP Dev., or thru an installer program, or is it really expensive?

[CobaltSky]

It certainly can be done.

Installer programs aside, there are a couple of approaches you can take which work from within your runtime, requiring that the user input valid and unique activation code in order to use the solution. Two that I've used a couple of variations of are:

Generic encrypted activation codes:

This involves developing an encryption system which will be coded into a script and several calculations which will receive an alpha-numeric string such as AB1C-D23E-F4GH-56JK and determine whether it meets certain narrow criteria you've defined. Since each block of four alpha-numeric characters can deliver over 1.5 million combinations, (and the total number possible is 7.9587e+24) so long s the number of combinations which can meet your criteria are less than a million or so, the chances of anyone randomly stumbling on one are very remote. You can further lock this down by limiting the number of false attempts (to say 1,000).

This system requires a bit of work to set up. It will be considerably more secure (but clearly there are still limits) if you permanently remove access to Define Fields, ScriptMaker etc at the point of binding. Its chief advantage is that you can mass-duplicate the CDs or distribute the solution via the net. It's chief weakness is that there is little to stop a licensed user from passing their activation code to others (but in this, it is little different from the methods relied upon by many major software vendors).

User-Targetted activation codes

This method is one in which the activation code is tied to a User Name and therefore more secure because you can require that both be entered (and that they match) in order to activate the solution, and you can then display the user name on the splash, the screens and the reports etc.

If you are going to mass-distribute the solution, you will have to put more work into the encryption in order to ensure that the user name and registration code are sufficiently linked, but that the encryption is nevertheless sufficiently secure. An alternative approach is to write a program which will generate multiple copies of the runtime each pre-personalised to a particular customer. Though more secure, this approach is also potentially more labour intensive, since CDs must be burned individually rather than en-masse. It may be made relatively automatic for distribution via internet download. (eg user provides payment and a user name, your database triggers a scripts to install the user name and a corresponding registration key, compress the files and place them in a directory from which the user can download etc).

The above methods give reasonable security. As I see it, you want to make it sufficiently hard to crack that most users will have to spend more time unravelling the mystery than it would be worth to them. There will always be a few users who will stop at nothing (they are the ones who will labour for 100 hours to cheat you out of $50).

In either case, if you're working with Developer v5.5 (or above, when it arrives shortly...) you could consider building in a call to the Status(CurrentFilePath) function to detect if the application has been moved to a new location (eg 'pirated') and require that the installation code be re-entered if it has. Again this is not watertight, but can be made more so by the use of external functions (such as, for instance Protolight's freeware Crypto Toolbox, which allows you to retrieve the hard disk volume serial number).

If you need to store data as part of the encryption process and don't want to spend the time required to develop your own encryption methodology, you could also consider using one of the various encryption plug-ins (eg Troi, Protolight) to secure internal activation key-related data. Note that althout freeware and 'x-plat', the Protolight offering has the limitation that it will not accurately decode an encryption which was encoded on a different platform (eg Mac vs Win), whereas the Troi product has no such limitation.

Hope these ramblings have given you a few ideas to pick over...

[SteveB]

I can't talk about MACs, but most Windows intsallers can generate install codes. I use Setup Factory, altho I wrote my own copy protection using Crypto Toolbox. I wanted multiple users to be able to install a trial version from the same CD . They have 30 days to purchase, otherwise it dies. Since the data it deals with is time-sensitive, playing with the clock defeats its use for the user. It is a kiosk, so its easier to prevent them from playing games. I encrypt the disk serial # and the user's initials in a string that I store in a global, and check it each time the system starts.

[danjacoby]

You mention "an encryption system which will be coded into a script and several calculations which will receive an alpha-numeric string...", which sounds like what I want (especially since I do disable Define Fields, Scriptmaker etc.).

The question is about the details -- how do I do it? Or where can I get details?

Yeah, I know no system is perfect (witness all the folks sharing program CDs -- I, of course, don't know anyone who does this ), but having such a system not only cuts down on piracy, but also enhances the "professional" image.

[stefangs]

this problem of non-unique password problems can be tricky. if you are worried about people distributing passwords (to their friends, via cracksites etc.), here's a plug for you.

<plug alert>

i've developed a set of files you can add to your solution, which automatically creates unique passwords for each copy. if you don't mind the extra work that administering such a setup brings, you may want to write to me off-list for more info at [email protected].

</plug alert>

[CobaltSky]

Hi Dan,

I admit I wasn't all that forthcoming about the encryption system bit of my previous message.

I guess if you publish too much detail about how to do it, there is a risk of at least partially defeating the purpose. I won't tell you exactly what I do (in fact it varies each time, but I don't mind telling you in broad terms how I go about it.

The approach I use is not a boiler-plate, but a random amalgam of different methods, from a 'kit-bag' of simple tricks. The way I figure it, if you use one method to obscure content, anyone worth their salt will have it undone in ten minutes. If you mix up and overlay two methods randomly, it may take them more like an hour - three methods most of a day, and so on.

If you want something that will take most folks a week or more to reverse engineer, you need four to six methods all mixed up together. What I suggest is that you get together a list of about ten simple cryptographic methods and then randomly select from them each time you want to devise a custom encryption. The standard grab bag might include:

1. Scrambling the order of characters

2. Hiding the characters inside another string

3. Translating the alphanumbet (eg adding a fixed value to each asci charnum)

4. Transposing the alphanumbet (eg factorising or multiplying each asci charnum)

5. storing certain values as hex etc

6. apply diagraphic character transfers

The list of possibilities is limited only by your imagination, but suffice to say that each should be simple and reliably reversible. None of them need be all that difficult to crack on their own. The security comes from the fact that only you know which ones have been used and in what order, for a particular encryption.

The second part of the process is establishing 'rules' that valid codes must meet. These can be as simple as: The fifth alpha character must equal three times the modulus of the sum of the second and ninth (speaking in relation to the ascii numbers associated with the characters) for example. Another would be that: the first F, S, Z or Q will always be in a position corresponding to the first numeral after position 11 in the string. The more inventive you are, the better.

You then need to create some code which will generate a bunch of codes which will reliably encrypt and decrypt, and - when decry[ted will meed all your 'rules'. To do this, I suggest you the random function along with some other text and number functions to generate codes that meet your rules, then use a script which cycles through randomly generated codes and, when it finds one that is unique and meets all your rules, stores the value and starts again.

So long as you don't let anyone get hold of your rules or the mini application you're using for generating valid codes (and don't publish your methodology in one of the forums!! ) you'll be as safe as the next guy

[djgogi]

To bad Ray that you don't have to spend 100 hours for breaking any FM based (with or without plugin) protection other than built in password scheme.

It doesn't matter how clever is the algorithm for encryption/decryption you are using, it will take only few MINUTES for by-passing it to someone with, let's say average knowledge of FileMaker.

Dj

[CobaltSky]

I agree that nothing will be totally secure.

However Dan is talking about a bound runtime. Given that the option to "Permanently prevent modification of database structure" (which removes access to Define Fields, Define Relationships, Access Privileges, Layout Mode and ScriptMaker) is selected at the time of binding, I'd say that your estimate of "[color:"brown"]only few MINUTES" is a shade too pessimistic, Dj.

...or perhaps that should that be optimistic - depending on your point of view

[djgogi]

You can always create an relationship with any of solution's files binded or not.

You can not create relationship from protected files.

Dj

BTW compliments for your artworks

[CobaltSky]

BTW compliments for your artworks

Thanks Dj - for the compliment and the 'smirk'

[danjacoby]

I think we're getting off what I intended to be the subject, so...

The problem (as I see it) is in assigning a different code to each copy of the same bound solution without having to re-bind each copy, and then be able to distribute the unique code along with each CD.

Generating some long alphanumeric string I could do in my sleep, but using it as an installation code is a different matter.

Which is probably why I woke up this morning.

[CobaltSky]

Back on the thread, Dan, there are two methods I use (as obliquely referred to in earlier posts).

The first is to create an extra 'admin file (which is not distributed to the user) and which generates the codes, encryptes them and writes them into the bound solution files (the files can be opened in FMP to do this without disturbing their bound status). I generally have the admin utility also write the user name into the files.

The second approach is the one where there are lots of 'rules' for what is a valid string and what isn't and the rules are pre-coded in (but, as discussed earlier, this has the drawback that the codes are not specific to the user and can be shared by users with "generous natures").

[Fitch]

Generating some long alphanumeric string I could do in my sleep, but using it as an installation code is a different matter.

I think the idea is that these codes aren't individually "bound" to each copy. You just generate the codes, print them on stickers, and slap a sticker on each CD you sell. Any of the codes will work on any copy, but the users' don't know each others' codes, only you know who has what, so there's a chance you could know where a pirate copy originated.

[harryk]

How safe is/are the FILEMAKER protection option(s)? More specific, do you or others have knowledge of succesful cracks of the passwords? What's happening outthere in the real world apart from philosophical and theoretical views on the possibily of cracking?

Have filemaker solutions really been around on Warez sites?

Harryk

[djgogi]

Hi, Harryk

Since Vers. 5.x the FileMaker's password scheme is pretty safe. (I've heard some rumors on existing password cracker for FM 5 but don't know if it's true)

Have filemaker solutions really been around on Warez sites

Well, I don't know , but consider the fact that FM solutions are usually tailored for specific user(s) and their needs.

What I'm telling is that any "calculated" protection could be by-passed without need be a cracker.

Some reasons for that are:

1)start up script will not execute if the file is opened by reference, for example by selecting perform script external, from some other file ( as colateral effect the satus bar will be unlocked so if you have left the layout list the navigation could be operated without your scripts, on the other side it is always possible to navigate in protected file using for ex. AppleScript)

2)DF of FM file is readeable, hence it's very easy to individuate the "protection"

3)It is always possible to create relationship toward protected files and hence gain access on any field (inluding "demo" flags)

The explanation for this is following:

FM use file name for referencing target file in relationship.

FM use field id for referencing right field in relationship, so...

given right file name and right field id...

Until those "bugs" are present there won't be an "safe" FM solution, where safe mean that cost for breaking it superate benifits of not paying for it

Dj

[harryk]

Thank you for your clear explanation. I will try and simulate this related access to a protected file, and see what happens.

You mention, DF (defined field) is in some circumstances readable. Do you mean that only the list of fields is readable or also the (calculation)contents? We may hope not..

From all that you say, and some other things I read, I do not have to have parapsychological gifts to guess that you discourage limited demo versions that in itself have the powers to be complete..

Harryk

[harryk]

3)It is always possible to create relationship toward protected files and hence gain access on any field

(inluding "demo" flags)

The explanation for this is following:

FM use file name for referencing target file in relationship.

FM use field id for referencing right field in relationship, so...

given right file name and right field id...

My experience is not so. The moment you try choosing that file in 'define relationships' you get the message: The password of the file does not allow you to do this.

Even if you fiddle around by replacing/renaming the protected file by a name of a file that can normally be accessed, you get this obstacle as soon as you try to edit the relationship: You have to edit anyhow to create a key that makes it possible to read fields of the protected file in a portal, but this is blocked.

You can always create an relationship with any of solution's files binded or not.

You can not create relationship from protected files.

or are solution (runtime) files an exception to this? would be strange..

Nevertheless, I can imagine there are ways (making an unprotected dummy file, using existing fields from the protected file to make a key, renaming files) to go around this, but I wouldn't say it is easy.

By the way, it might not be too wise to be to explicit on these subjects..

Harryk

[Anatoli]

RE: By the way, it might not be too wise to be to explicit on these subjects..

Harryk

Why not? We have long topic going on about security loophole on web and as result people are more aware about possible security breaches.

And we have also something more from that -- Chazboi wrote nice investigating program for Macs, we did our great FileMaker Security Filter for protecting our databases on Web and Keith is shifting data from Web shared database to database without web access.

Everyone, who is serious about FileMaker, will welcome any founding about shortcomings.

Also maybe FMI will get the right feeling about their not-so-much-secure product and will be making some improvements.

[djgogi]

DF stands for Data Fork

sorry for confusion

Dj

[harryk]

RE: By the way, it might not be too wise to be to explicit on these subjects..

Harryk

Why not? We have long topic going on about security loophole on web and as result people are more aware

about possible security breaches.

I was thinking aloud. The poll you set up about this question is a good idea.

Still, I'm kept up with some questions about your saying: a protected file is always accessible as a related file, as my experience is that FM has blocked that out with the password protection... I am persistent..

(I did not try out with binded (runtime) files)

Harryk