Protecting a Runtime- Lobby Filemaker!

[MSPJ]

Hi -

I have been trying to figure out how to effectively copy protect a runtime database, and have determined that it is not possible to do it in any way that isn't very awkward - more below.

I have also determined what it would take to accomplish this effectively, and it isn't all that much - also explained below. If anyone else thinks this is important, I would encourage you to put in a feature request to Filemaker on their website - you can copy the relevant part of this post. This is most important if you distribute your solution to many users rather than a few large companies.

Here's how I see this:

A runtime consists of the runtime executable and your actual database (plus a bunch of other files). The database part is a standard FM database and can actually be opened in filemaker software independent of the runtime.

If you are developing an application that will be distributed to many users (ie too many for custom coding passwords), you need some other way to protect your database from piracy. This is true regardless of whether you need to protect the data in it or the structure of a database that is distributed empty to the user.

Here's what it would take to effectively protect a runtime solution:

1) Protect the .exe file so someone who obtained it illegally can't run the program: there are several effective third party solutions for this - so this part is not a problem (for instance, armadillo).

2) Since someone can bypass the protected executable by simply opening the database in Filemaker software, you need to prevent them from doing this. This can be easily done by having your open script check if it's running in a runtime, and exit if not. So no problem here either.

3) Here's the current weak link: Generating a new runtime does not require any password at all - that is, someone who has FMP 8.5 Adv can easily generate a new runtime from your database without opening it, and without entering a password. Now they have a new, unprotected executable that is bound to your database with a new bindkey. They can now distribute copies of the runtime solution with abandon. If your sales model makes it too difficult to have individually password protected the database, you have now lost your work.

So - what is the solution to the flaw in number 3 above? There are a few independent ones:

Solution 1 - make it possible to password protect the ability to generate a runtime from a database. This could be tied to a privilege set - perhaps by adding a new privilege specific to this function. Regardless of how it is implemented, the ability for a developer to require a password to generate a runtime would go a long way to protecting their work.

Solution 2 - create a Get(bindkey) function - since the developer knows their own bindkey, they can code a script that checks the bindkey used to generate a runtime - if it is not the developer's key, the script closes the database. Simple! If for some reason, accessing the bindkey is too difficult, a somewhat less ideal, but still workable solution would be a Get(BindingTimestamp). To use this, you would need to create your runtime, then open the database up again in FM software and hardcode a test to see if the runtime was bound at the time you did it. If it was not, someone has remade a runtime after you did. This is not as good since you have to edit your database after you make the runtime, which means you can't completely remove all modification privileges -but it's better than nothing.

Solution 3 - add some kind of registration key system directly inside your database - this is possible, and 1 commercial system exists that I've been able to find (Code-X), but for a variety of reasons it is not as preferable as the others. (For one, it requires you to manually distribute keys to your customers).

So - here is a concise list of features to request from Filemaker:

1) The ability to password protect the process of creating a runtime

2) Adding a Get(Bindkey) function

3) Adding a Get(BindTimeStamp) function

Having all 3 would be great!

Here is a link to Filemaker's suggestion page:

http://filemaker.com/company/feature_request.html

Michael

[Steven H. Blackwell]

2) Since someone can bypass the protected executable by simply opening the database in Filemaker software, you need to prevent them from doing this. This can be easily done by having your open script check if it's running in a runtime, and exit if not. So no problem here either.

Since opening scripts can easily be bypassed, this isn't a solution.

The issues you described are part of a larger set of problems. FMI is aware of these problems.

Steven

[Stuart Taylor]

If all your scripts test for a script parameter the bypass can stopped.

(although i'm sure Steven will tell me that someone can easily bypass that too)

ho hum

just a thought

[Steven H. Blackwell]

If all your scripts test for a script parameter the bypass can stopped.

How is that? The object of bypassing the opening script is to prevent its running. How does including a parameter do that?

Steven

[Stuart Taylor]

Hi Steven

We kind of discussed it once before.

Link

There is an example file in that post.

The post mentions preventing someone from bypassing the opening script by executing another script with an opener file.

By attaching a script parameter "key" to test before executing it would be possible to quit the file if an illegal "operation"/script was performed.

There may be other ways to open a file with another bypass method but this is just one way that i can think of to attempt someone using this method.

best

Stuart

[Steven H. Blackwell]

The two methods generally employed to bypass the opening script consist of running another, different script in the same file or using the script Debugger to halt execution of the opening script after its first step.

Steven