Software Venture Consulting

FileMaker Pro downloads & Resources
FileMaker Custom Functions
FileMaker Web Viewer Examples
FileMaker Pro & Lasso Consulting
FileMaker Books
FileMaker Articles

Free Web Tools
Free FileMaker Tools

Personal Pages

Shopping Cart
Shopping Cart


Free Newsletter


Privacy Policy

FileMaker is a registered trademark of FileMaker, Inc. in the U.S. and other countries.

Browse Mode
March 2004

Enforce Seats in FileMaker 7/8/9 Commercial Solutions
by Brian Dunning

digg this article | this article

Developers of commercial solutions have a lot of reasons to be excited about FileMaker 7/8/9, but I wanted to draw special attention to a neat little gadget that will simplify and strengthen the enforcement of purchased seats. Often, when you sell a commercial software application that is a FileMaker Developer runtime, you may have a three, four, or even five figure price point. You certainly don't want a customer pirating your application to a second user, or to their friend across the street.

One solution is to sell a hardware dongle. This is a little thingie that plugs into a USB or serial port, and there are FileMaker plug-ins available that can check for the presence of the dongle and disable the software if it's not there.

I am not a big believer in dongles, primarily because people hate them. They're inconvenient, they can be lost, and they require a port that may not always be available. My philosophy is that selling software is hard enough, so I avoid any possible opportunity to irritate my customers further. So I don't use dongles, but they are one perfectly valid solution.

Another answer, which we're going to examine in detail today, is to sell a unique serial number or license key. It's easy to generate unique license keys, but it's not always so easy to enforce that a particular key run on a single machine, and only that particular machine. The best way to do this is for the license key to incorporate elements of the computer's NIC address.

A NIC (Network Interface Controller) address (also variously known by other names) is a unique six-byte code embedded by the manufacturers of network devices, such as your computer's Ethernet interface. There are 281 trillion possible NIC addresses, so you can be reasonably certain that your customer won't happen to have two that match. FileMaker Pro can read this address, and if the decrypted license key matches that code, then the software can proceed. Such a license key will not work on any other computer.

(We won't talk about the encryption here -- but if you want a detailed, all-in-FileMaker example of generating encrypted license keys, see Easy Encryption at A free demo download is available, which is a great companion to this article.)

Before we get into the technology of how to accomplish this, remember that there is a limit to what technology alone can do. Business rules will have to make up an equal part of a complete security scheme. So, to understand what some of those limitations are, let's examine some Gotchas about using the NIC address as part of your license key:

  1. Gotcha: Many computers these days, particularly laptops with wireless cards, have multiple NIC addresses. My PowerBook has one NIC address for the Ethernet interface, and one for the AirPort Wi-Fi interface. Be aware of this when you design your logic. Similarly, there are computers with no NIC address at all (old ones with no Ethernet card). I have one in my closet.
  2. Gotcha: It is possible for customers to share a Wi-Fi card, and use it exactly as they would a dongle, if the license key is bound to that card's NIC address. If you're concerned about this, make the license key dependent upon all found NIC addresses, since machines with wireless cards usually have Ethernet interfaces also. If you do this, keep in mind that someone might choose to remove their Wi-Fi card for some reason. You can't reliably tell from reading the NIC address what type of interface it's for.
  3. Gotcha: Customers often change computers, buy new ones, etc. If your policy is to grant them new license keys to run on their new hardware, be aware that can also lie and claim to have bought a new computer, when they really only want a second license key for their coworker. This Gotcha is the primary reason that companies like Adobe and Microsoft are susceptible to pirated serial numbers: when you have as many customers as they do, it's not feasible to manage license keys that are machine-specific. For this reason, you may wish to adopt a pricing policy where the first seat is full price, and subsequent seats are heavily discounted. Make it clear up front that new computers will require the purchase of a new seat. You might choose to make exceptions for cases where they present a bill of sale showing that the computer was sold, or a police report showing that it was stolen.

Those are the Gotchas. It's up to you to develop business rules to deal with all of the above, but once you've done this and are satisfied that the model will work for your product and your customers, you're ready to look at how to read these codes using FileMaker Pro.

It's especially easy in FileMaker 7/8/9, with the Get(SystemNICAddress) function. This function evaluates to the NIC address, expressed like this:


If there are multiple network devices present, they'll be listed as above separated by carriage returns.

It takes a few extra steps in FileMaker 5/6. On Macs, you'll need to use AppleScript to retrieve it. Here is an AppleScript that places the current NIC address onto the clipboard:

set nic_address to do shell script "ifconfig en0 | grep ether | cut -b \"8-24\""
set the clipboard to nic_address as string

Your FileMaker script can then proceed to paste the NIC address into the desired field. The above script retrieves the first NIC address; to get the second (when available), replace "en0" with "en1," and so on.

To get this into FileMaker in Windows, use the Send Message script step and specify the following:

ipconfig /all -> nic.txt

This creates a text file called nic.txt that looks like this:

Windows IP Configuration
Host Name . . . . . . . . . . . . : TEST
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : CNet PRO200WL PCI Fast Ethernet
Physical Address. . . . . . . . . : 00-08-A1-2A-DB-26
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . :
DNS Servers . . . . . . . . . . . :
Lease Obtained. . . . . . . . . . : Sunday, October 27, 2002 8:35:42 PM
Lease Expires . . . . . . . . . . : Sunday, October 27, 2002 9:35:42 PM

Your script can proceed to import this text file, and parse out the Physical Address line contents. Note that I've seen this text file get generated in different places on different machines, so you might have to do a search to find where the file gets generated. It's usually in the current user's home directory.

Once you know how to retrieve the NIC address using your software, here is an overview of one way that you can manage this process from beginning to end:

  1. Deliver your runtime application with the NIC address field blank. Whenever the software launches on the customer's computer, run a script to retrieve the NIC address and store it in a global field. Always overwrite the contents of that field.
  2. You may choose to use customer numbers or some other data as well. Use some technique (a good example is the one described in Easy Encryption) to use the NIC address and any other data to generate a unique "challenge code." It's wise for this challenge code to be in clear, readable text, and to avoid any ambiguous characters like 0, O, I, 1, or l, as demonstrated in Easy Encryption.
  3. The customer can telephone you with the challenge code, or you can have the software connect to a web site over the phone and submit the challenge code along with a credit card payment. When you receive the challenge code, generate a unique license key that is bound to that specific challenge code, and also incorporates any other privileges or data that you want. Make sure that these license keys are well obfuscated, as in Easy Encryption.
  4. The customer enters their new license key. Your solution's logic should always check for the presence of a valid license that matches the machine's NIC address. As you can see, if the customer passes the installer around, different machines will generate different challenge codes, so the purchased license key will not work for them. And, if the customer passes around the installed program folder of your application, launching the application will fail because each machine's individual NIC address will fail to match the license key.
  5. Naturally, it's important to design your software in such a way that the script that checks the validity of the license key is accessed not just upon launch of one particular file, but at many crucial access points throughout its usage. Certify that no "back door" exists, or any other way for the check routine to be skipped or avoided.

Follow the above steps, and you can rest assured that your software cannot be pirated, subject to the Gotchas which, in my experience, are well mitigated by the reality of what a pain it would be for customers to cheat by swapping network cards back and forth.

Brian Dunning

Browse Mode
Jan 10 Solving Performance Emergencies with FileMaker Server
Aug 06 Top Ten Sessions Cut from the 2006 FileMaker Developer Conference
Jul 06 Who's Driving This Thing, Anyway? Or, How Marketing and Engineering Buried the Hatchet (Warning: Contains a Curse Word)
Nov 05 Shingle Grandiloquence
Oct 05 In Celebration of Geek Magnetism
Aug 05 A Rogues' Gallery of Devcon Attendees
Mar 05 Lies, Damned Lies, and Project Specifications
Feb 05 Pick the Right Tool for the Job
Oct 04 Home Media Server Requirements
Jul 04 Leveraging Your FileMaker Lingo
Apr 04 Technical Support Redux
Mar 04 Enforce Seats in FileMaker 7/8/9 Commercial Solutions
Feb 04 Reinventing the Wheel
Oct 03 WAP: The Technology That Wasn't
Aug 03 Brian Dunning's California Governor Election Platform
Jul 03 Sex and the Single Software Developer
May 03 XSLT: Creeping Out of the Closet?
Feb 03 A Consultant's Guide to Traveling
Nov 02 Adventures of Bat Magnum, FileMaker Consultant
Sep 02 FileMaker at Area 51
Aug 02 FileMaker Terminology
Feb 02 Computer Shunts
Dec 01 Aquabase Alpha & the Consultant's Challenge
Aug 01 It IS the Size That Counts
Jun 01 On the Trail of Sasquatch
May 01 Spring Cleaning
Feb 01 FileMaker Mobile Survivor Challenge
Jan 01 Letter from Nürburg
Dec 00 Performance Anxiety
Nov 00 Objection, Your Honor
Oct 00 Leveraging Convergence: Jargon for the 21st Century
Sep 00 Top Ten Things to Do at Devcon
Aug 00 Aesop's FileMaker Fables
Jul 00 Ten Commandments of FileMaker Pro
Jun 00 Explats Cross Examined
May 00 iMac, Therefore iServe
Mar 00 Valley of the Dollars
Jan 00 Are You Up for a Review?
Nov 99 Tales from the Script
Sep 99 Tech Support Revisited
Jul 99 Moderns vs. Classicals
Mar 99 Nashoba, We Hardly Knew Ye