Jump to content

Protecting a Runtime- Lobby Filemaker!


This topic is 6174 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This topic is 6174 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.