I'm writing an application that will be installed in multiple locations on any given computer by my client. I want to charge him for every installation which means I can't allow him to copy the application into another folder without asking for another key. I was initially going to generate a unique application key based off the physical location of the executable and the computer's MAC address (which is secure enough for my purposes) which I would use to create the license key. Unfortunately, the client is planning on having multiple people use the application from a shared drive. This mean the MAC address wont be the same every time the application is run, but the working directory will change due to various ways of accessing the shared drive.

My next idea was to use the date created timestamp on the file itself instead of path/MAC, but that means I wont be able to update the application after it's run the first time without recreating new license keys.

I know in unix systems all files have an inode number that is unique to that file. Is there any way to uniquely identify a file on a windows computer like the inode in unix?
Posted on 2011-01-20 08:38:23 by Sparafusile
Yes, NTFS is quite similar in that sense, all files have a unique ID.
You can get it via the GetFileInformationByHandle() API function, for example ( DWORD nFileIndexHigh and DWORD nFileIndexLow form a 64-bit unique identifier).
Posted on 2011-01-20 09:35:02 by Scali
Under which usecase does it make sense licensing based on executable file path, and charging for multiple copies on one machine?

Seems like it has potential to penalize regular use, and in the case of running from a shared network drive, while allowing multiple concurrent users to run the app?
Posted on 2011-01-20 09:58:35 by f0dder
If the application makes use of shared data you can base your key on a fixed number of users and implement a lock region on the shared file big enough to account for each licensed users.  As each application starts up, it looks into the lock region for a free slot and if found locks that region.  When the app is finished it unlocks it's region.  So the size of the region can be determined by the key.

If the preceeding doesn't apply to you, see if your customer can map to the network resource consistently so that use of your key requires the app to be located on the M: drive for example.

If that doesn't work, you could attempt to implement a network broadcast scheme to determine number of active users to prevent further execution.  This, of course, assumes that your customer always runs your application on a network.

If none of these work for your situation, well.. I tried  :)
Posted on 2011-01-20 10:46:37 by p1ranha
Thank you Scali, that's what I was looking for.


Under which usecase does it make sense licensing based on executable file path, and charging for multiple copies on one machine?

Seems like it has potential to penalize regular use, and in the case of running from a shared network drive, while allowing multiple concurrent users to run the app?


Agreed, it's not a very fun requirement. I might even come back and say it can't be done (my client is the reseller), but in order to do that I have to say I tried everything. Gotta pass the "red face" test when they ask me why it can't be done.
Posted on 2011-01-20 11:26:30 by Sparafusile

This mean the MAC address wont be the same every time the application is run, but the working directory will change due to various ways of accessing the shared drive.


Well, the MAC address will be the same (as long as the NIC doesn't change) every time the application is run from a particular machine, as you will be checking the local machine despite loading the exe from a shared drive.

If you are going for per-installation, i.e. per-computer, and assuming Windows clients then you can simply store the key in the registry under HKLM. Make it so that the key is the hash of a local MAC address (or network/computer name, system id, etc...) and a GUID/key relative to the application installation. This way the application can verify in a standard and file-location-independent manner.

This should afford your clients a level of flexibility, granted that you trust them to a certain degree, without compromising your terms or implementing a centralized license management system.

All of the answers, including mine, however, depend entirely on how you intend to generate, distribute and enforce said license keys.
Posted on 2011-01-20 13:07:05 by SpooK
The MAC address can be modified in memory at runtime, I would not recommend using this as the (only) means of uniquely identifying a particular machine.
Fingerprinting a machine by hardware can be a good idea, however there are some catches.
You should allow for hardware modifications to not render the 'login' as invalid - you might award 'points' for the number of hardware ID's which match, and allow sufficiently similar configurations to authenticate, while recording the difference for the purposes of detecting 'shared keys' as well as updating the authentication configuration should it become clear that this user has certainly changed their hardware config.
You do NOT want customers calling you because 'they changed their soundcard and now the login is broken'.

Posted on 2011-01-21 01:32:54 by Homer
I'd also like to point out that you should not be taking 'the MAC address' too literally.
Many computers these days have at least two network interfaces on board (ethernet and WiFi). The more high-end motherboards also have two ethernet adapters these days.
And when people install software such as VirtualPC or VirtualBox, additional pseudo-network interfaces might be added to the system in order to allow the virtual PC to communicate with the physical one.

So you should be able to handle situations with multiple MACs. Don't just pick the first one and assume it's the only one. I suppose a good way to go about it is to store all MACs you can find, and accept if you find at least one MAC that matches.

I'm still pissed off about the fact that my Windows XP had to be re-activated after I installed a new motherboard. The new board had two NICs... but when I first booted into Windows XP, there were no drivers... and I had no network, so Windows Update could not retrieve them. When I manually installed the drivers later, it counted that as two hardware changes, and apparently that went over my quota. Pretty ridiculous, since technically I had not changed any hardware at all. I only changed the motherboard, which Windows accepted... the NICs are part of the motherboard, they shouldn't count as hardware changes. Especially not when they were already on the board, just not enabled with a driver.
Posted on 2011-01-21 01:51:59 by Scali

The MAC address can be modified in memory at runtime, I would not recommend using this as the (only) means of uniquely identifying a particular machine.


Yes... and then you have issues with VPN users, needing a new key in case the computer dies and is replaced... and so on and so forth.

This is why I was more interested in the level of trust and enforcement... figure out how serious you are about enforcing your licenses and work your way backwards.
Posted on 2011-01-21 10:28:37 by SpooK
I've decided to forgo the use of the MAC address for various (stated) reasons. I'm going to use the volume serial number alone to identify individual installations. This will be good enough for my needs. Thanks for the help everyone.
Posted on 2011-01-21 12:42:16 by Sparafusile
I've decided to forgo the use of the MAC address for various (stated) reasons. I'm going to use the volume serial number alone to identify individual installations. This will be good enough for my needs. Thanks for the help everyone.
Ah, so limiting to machine and not "installed path" - that at least makes sense.

You could also have used the Windows product key hash thingamajig, I'd personally prefer that over a volume serial.
Posted on 2011-02-07 17:38:03 by f0dder