Security for Commercial Runtime

[Blaze]

I have several commercially released runtimes.

Up to now I have been using Exeshield to protect them for PC (more on Mac in a minute).

Not only is that very hackable it is a pain in the patooty for my customers and one more layer of support for me. Time to move on.

I've researched plenty of 3rd party sources but have yet to find anything that rings my bell.

I do like the license key idea and have scripted something in the Mac version that equates to some thin protection involving the instal date, mildly encrypted data involving the users name and date. This is submitted to us and a "key" is sent which is then imported (via script) that is essentially a checksum to make sure that name, date and "encryption" match. THere is also a 14 day countdown involved which causes the runtime to shut down after the 14 days (until the key is entered)

I would love to hear some ideas from the group regarding security measures.

Here is my wish list.

1.Dual Platform

2.Online submission by user

3.User authenticated against valid purchase database

4.Key generated and sent via email.

5.Automated-hand off fulfillment would be great.

6.Runtime script/button applies key.

I have FM 10 advanced but have mainly been doing everything in 9v3.

I'm not opposed to 3rd party solutions, but am very interested in as close to a purely Filmaker avenue could yield.

Any collective wisdom to be had on the subject?

Thanks for donating your brain power!

[Blaze]

I put up a detailed post the other day but received no replies.

So Now I'll try a broad approach.

I've got a runtime that I'm selling commercially and want to take measures to protect it without using 3rd party products.

Does any one have any coding or scripting ideas along these lines?

[LaRetta]

Blaze, your post was only from yesterday - that doesn't give people much time to respond. I'd suggest usually waiting another day or so. Either way, please respond back on that post (including different/more information as you've done in this post) or just typing BUMP to get everyone's attention again. Please do not start a new post.

I will merge these two.

Edited March 25, 2009 by Guest

[JerrySalem]

When I was making shrink wrapped software I did something very similar to what you are doing.

User submits some info (either online or on the phone).

From that we generate a slightly encrypted activation key and have it emailed back to the user.

The key was validated by an internal calc in the database.

If someone tried to 'share' our product with a friend, the new user would not be able to open the database after they customized if for themselves.

It was cross platform and simple.

[Blaze]

The activation key approach is what we are doing now, validated by an internal calc after the key is imported.

Our product is more of a static program than an interactive database where the user would be more likely to try to share our activated program since it contains very little personalized info.

The two obstacles I'm trying to over come are these

1. Hinder the user's ability to share the activated program.

2. Disable the useres ability to defeat/reset the 14 day countdown via re-installing, therby eliminating the need to ever receive the key.

[JerrySalem]

Here is an idea for each problem

1. use get(SystemNICAddress) to grab the users MAC address, then use this in the activation key.

2. How about writing a small txt file to the users Preferences directory. Using get get(PreferencesPath) function. this would be a Tab file, on startup import this file and check the date. If the file doesn't exist or, if the date is no good exit program. This isn't foolproof, but makes it slightly harder for the casual thief to use your program without paying.

Of course as with any distributed run time, you will need to deal with all the exceptions you can come up with. I bought a new computer, I got a new ( or second) NIC card, etc.

Jerry

[Blaze]

Hi Jrry,

Thanks for your comments.

I am in fact already incorporating the MAC address into the key. Like you say there are always circumstances that require new keys to be issued but by and large these smaller measures add layers of security.

I have also given thought to the placing of an external file. I was going about it in a slightly different fashion. I like your idea better. I wasn't placing the file in a more permanent location like the preferences location. I'll have a look at that and see how that works.

I'm already way over the projected release date for this product.

Would you happen to have any coding/scripting already done that you wouldn't mind sharing?

Thanks again for your input.

Edited April 1, 2009 by Guest

[clz]

I used Easy Encryption from Brian Dunning and modified it to fit my needs. It is working really well with my runtime.

Cindy Zelinske

[Blaze]

Hi Cindy,

I've had a look at the demo version of that before, and could see some uses for it, but it seems to fall short of some of my criteria.

What modifications did you perform on it and how are you using it?

[clz]

It's been awhile since I had to work with that code but basically what it does is generate a registration id which is a combination of the computer name, installation date and time. The user then emails or calls me with the info and I send them the key to unlock the program.

They also get to use the program for 10 days before entering the serial number so we have some time to play with. My runtime is a racing program and my typical customers are using their computers in a race shop or at a race track with no internet access so my process right now is very manual. But it works!

Hope this helps!

Cindy

[ron G]

I just completed setting up my app as follows:

On startup:

Flag is checked to see if it is = 1. (0 = demo mode. 1= Activated)

a random "ID" of digits and letters is generated in a 'not browsable' field. The user is given 10 days in Demo mode to enter the 'activation code'.

The Activation Code is calculated from the ID. If the proper activation Code is entered, then a flag is changed from 0 (for demo mode) to 1.

One of the nice things about this system is that each copy, on startup, generates a unique ID. So, it is not possible to 'pass around' a copy without passing around your data as well.

Hope this gives you some ideas.

[Steven H. Blackwell]

Can you prevent the external manipulation of the 0 and 1 values?

Steven

[ron G]

Yes, g.flag (global flag variable) is initally set to 0. If a successful verification code is entered, g.flag =1.

Since part of my 'startup' script has an

IF [g.flag=0]....

... once the program gets a successful Verification Code, that part of the code is no longer evaluated.

Note: Since the Unit ID is calculated from a custom function, to prevent it from changing each time startup runs, there is another variable called 'g.firstrun' which is set to 0 if it is the 1st time startup runs and the 1st time the Unit ID is calculated. After it is calculated, g.firstrun is set to 1. This prevents Unit ID from changing.

Hope this helps.

[Raybaudi]

Hi Ron

are you sure that it's impossible to change that 0 to 1 ( g.flag ) ?

[Steven H. Blackwell]

Aside from possible issues with global fields in hosted environments retaining set values after the session ends, nothing you describe would appear to prevent the external manipulation of the flag field.

If someone creates a file outside your system, points a file reference to your file, and accesses the global field, it would appear that the value could be changed from 0 to 1.

Steven

[RodM]

true.. how would anyone know what the global var name be, that it was the flip/flop trigger other than the programmer anyways.. just wondering/?

[Raybaudi]

Which thing does prevent him to go on by multiple attempts ?

[Steven H. Blackwell]

Field or variable?

And what prevents bypassing that altogether by just running some other script in the file?

Steven

[maverik_uk]

One of the best ways of securing FileMaker is to to remove the Admin username and password.

 

This is done with FM Pro Advanced in Tools:Developer Utilities. I did some work with FileMaker a few years ago and we found that data and code was accessible if you had the FileMaker file. It is still possible to get at data from a runtime data file with the admin privileges removed, but requires a significant effort - days rather than minutes.

 

The main disadvantage of this method is that the file you distribute cannot be edited furtehr so you will need to build an upgrade process into the file. i.e moves the data into a new file.

[Blaze]

After starting this post years ago, I still find myself in more or less with the same need for help as I did then.

Here is an idea for each problem

 

1. use get(SystemNICAddress) to grab the users MAC address, then use this in the activation key.

 

2. How about writing a small txt file to the users Preferences directory. Using get get(PreferencesPath) function. this would be a Tab file, on startup import this file and check the date. If the file doesn't exist or, if the date is no good exit program. This isn't foolproof, but makes it slightly harder for the casual thief to use your program without paying.

I have been using a startup script which among other things places an external "date stamp" file on the customer's hard drive that indicates when the date of installation was. On subsequent openings the script checks to see if the file is present and if so then it imports the date into a global field. This governs the 14 day countdown timer that allows access to the solution without registration. After that time expires the user can no longer access the solution without registering. Even if they re-install, as long as the "date stamp" file remains on the hard drive, then re-installing will only search for and find the original  date stamp file, thereby preventing use without registration. (I quote Jerry's earlier post because that is exactly what I've been doing. The problem is that certain NIC hardware turns on and off, thereby changing the unique signature along the way. Also It seems that in Windows 10 there seems to be an issue with placing that file in the preferences folder?)

For registration, a unique code that contains the user's name, email address, computer name, an alphanumeric code derived from those previous entries and the computer's networking addresses. A key or code is generated from that for import or entry and checked for a match.

This is an awkward and clunky method that I would certainly like to get rid of, but I'm too tunnel visioned about it to be able to come up with a more simple yet effective coding to make this happen. Any help or coding examples would be greatly appreciated!

[Steven H. Blackwell]

I would not rely at all on any of these ersatz systems.  If the file is not properly secured by the processes FIleMaker provides, then these ersatz systems are rather easily defeated.

 

Steven

[Blaze]

Hey Steven,

I would love it if FIlemaker would provide extended protections for distributing solutions and incorporating end user registration features but I am certainly not going to hold my breath for that.

I failed to mention that this is not only a solution, but it is populated with data, so I am wanting to protect both. All write capabilities are turned off so it is simply a reference tool and not a user expandable database. A closed system.

A registration method is the only way that I can see that can offer some kind of protection, albeit paper thin. I would welcome any and all suggestions as to how to protect this solution and the data that it includes.

 

Edited September 24, 2015 by Blaze

[Blaze]

The main purpose of the registration method is to have users submit their purchase/installation validation within a specified time (14 days in my case).

Placing a date stamped file in the prefs folder and retrieving the info on every startup insures that even if they uninstall and reinstall, that there is some kind of preventative to installing every 14 days and never registering.

I would really welcome any suggestions on how to codethe easiest protection of both program and data against sharing/pirating.

[Claus Lavendt]

I think Steven is referring to using FileMakers tools for protecting your solution and data. Accounts, privileges, EAR, remove admin accounts.

It sounds like you want to lock your solution to a specific device when the user register your solution. That will ensure that the solution only will run on that specific device, given that you check for that device on startup. 

Regarding your file on users harddrive; you could create a masked code, which you can decode to the date. This way, you will make it harder for a user to try to manipulate that file in order to extend demo period. Another approach is to use a plugin that can get creation date of that file. This way, the file could be empty. However, that is not foolproof either as that could be manipulated. But it is much harder for the average user.

For registering the user, you could use a method where the solution sends you the users DeviceID.  Get ( PersistentID )
This ID should be unique and is created by the OS. (there have been some reports of errors on this function in windows 10 - I believe it was)

By using Get ( PersistentID ), you are not depending on network cards MAC addresses.

When the solution is registered, on startup you should check for the stored PersistentID in the solution in order to determine if the solution is allowed to run on that device. Thereby, it will not work if copied to another device.

These comments above is not exhausting recipes, but might give you some directions to investigate...