Fog Creek Software
Discussion Board

Licensing Software to a Specific Machine

Hi guys,

As part of our licensing model, we are looking into ways limit our software to run on a specific machine (Windows). The registration process will involve producing a key that specifically works with that machine via a communication with a server.

The registration must be specific to the machine, and not the current user.

Would the machine's SID be the best info to use as a seed in the key generation process?

Does anyone have a different approach to protecting their software?

Off hand does anyone know the API to retrieve the machine's SID?

Tim H
Friday, January 2, 2004

MAC address from the NIC. It rarely changes.

I think the SID would change if they reinstalled Windows.

Friday, January 2, 2004

Ooo that's a good idea! Thanks!

Tim H
Friday, January 2, 2004

Hrm... Interesting post, if it hadn't already been discussed 1000 times earlier with 500 unique solutions already given.  Try using the search function.

Having said that, Limiting software to one machine is NOT a good way to license software.  It is not flexible enough and your customers will surely be upset by the trouble they have to go through if they move machines etc.  Unless you are writing software to control a nuclear reactor, you might as well go with a more flexible licensing system.  Imagine if Windows was bound to a machine?  Do you think it would have sold as many copies as it has?  I doubt it.  It would be a severe pain to use and hackers would have cracked it long ago as I'm sure they will your software.

It only takes a little bit of effort to keep the honest people honest.  Expending any more than that is a waste of time.

Friday, January 2, 2004

Thankyou for your reply anomous poster. I did search before posting, honest, sorry to have upset you.

The software that we are looking to protect is an Internet solution that our company would normally host ourselves.

As our business has grown, we are entering into new deals where our solution is hosted by the customer on their kit.

Our software will be installed by our installation team on a Customer's servers to form their solution.

We are looking for ways to prevent our software components being copied and reverse engineered on a developers test machine.

As the frontend is ASP and the backend SQL the majority of our solution is already transparent.

Tim H
Friday, January 2, 2004

Our company uses hardware locks, also known as dongles, so the software is not necessarily tied to one machine but instead to only whichever machine which has the lock attached. They can be expensive but hardware lock can be programmed with expiration dates etc.

There was another attempt by the following company to get the IDE hard disk serial number and use that.

DiskSerial.DLL Version 2.12
Copyright (C) 2000-2002 DSC Studio

But newer versions of Windows XP might prevent direct access to the harddisk ROM and I don't know if it would work for a SCSI disk.

Friday, January 2, 2004

>> MAC address from the NIC. It rarely changes. <<

Bzzzt!  The MAC address frequently changes in some scenarios -- for example, laptop users with a PCMCIA network card.  This is particularly insidious because often the network card is used to install software and then removed and not available when the laptop user is at home, or on a train, or 3000 miles away, or wherever. 

Of course, from Tim's description, it's not likely the software he's talking about will be installed on a laptop.  However, I'd really hate to be on the receiving end of the complaint when a customer who paid good money for this component replaces a network adapter after-hours and discovers that this component no longer works because of "licensing" issues.

Friday, January 2, 2004

Metrowerks Codewarrior uses the disk serial number for their license protection; so such a thing still works in Windows XP.

Seems like disk serial number would be the least likely thing to change; the MAC address is not as stable.

At this point, however, I will never purchase another Metrowerks product.  I've been waiting a month for a new license key file because I purchased a new computer (changes the serial number) and because I upgraded Codewarrior (invalidates the old license anyway).

Almost Anonymous
Friday, January 2, 2004

Dongles are horrible for desktops, but I can see the point of having them for servers. However if the company goes for rack mounted servers you're hosed.

Perhaps you could consider setting up partners, and providing the hardware as well :)

I'm not at all sure that your solution would prevent reverse engineering anyway. Copuldn't they just access the server log over a web browser?

Also think of the costs of providing 24/7 access so they can get back up and running in ten minutes if their server tanks and they need to go over to the backup.

Stephen Jones
Friday, January 2, 2004

I would hope your software is considerably more valuable than the machine it is on (by a very large order of magnitude), to even make this worthwhile.  And if the said machine dies in some way how fast can you get the legitimate user up and running? 

In any time zone, in any 24 hour period?

Simon Lucy
Friday, January 2, 2004

I have to agree with Simon and the other posters here when it comes to linking to hardware.  _All_ hardware fails.  No matter what you select as a hardware id, it will fail and someone, somewhere will be hosed. 

If it is mission critical app, you will get one or two of these before someone comes onto a board and says "never buy XYZ, we went down for 40 minutes due to a hardware failure and 15 hours because the license would not let us in."

If you feel you absolutely must use the hardware, all it to run for "X" days without a key.  This will allow someone who is reconstructing a box at 3 a.m. to get the key the next day. 

Friday, January 2, 2004

In regards to the different options, it all depends on the use model.  For servers this isn't that hard.

We sell server software with license keys binding to the IP address and MAC address of the NIC.  This is simple to implement (although the MAC address is hard to get in Java).  Neither is likely to change except at rare intervals.  If the customer wants to change the machine, they call and we send a new key within an hour or two.  Not a big deal.  We're a low-volume, high price business.  We operate on the assumption that the customer is basically honest. 

Essentially, the key protects against careless copying from machine to machine.  It's not unbreakable, but you have to go out of your way to violate the license.

Desktop/notebook software would be more of a challenge to protect, as would mass-market software (where there's more of an incentive to break the protection and distribute warez).

Friday, January 2, 2004

We've used the hard drive serial number for our software-based copy protection for a number of years, and it's worked out really well.  The only time the serial number seems to change is when it's reformatted.  (We ran into this when someone reformatted the hard drive because of an issue, then restored from backup. A quick phone call and a new activation code got them up and running quickly.)

We recently re-worked our licensing system and decided to go with the MAC address as the primary identifier, with the hard drive serial number as the backup.  As pointed out earlier, laptops may cause issues with this, since if they're not attached to a network, they may disable the ability to correctly read the MAC address, even if it's a built-in network adapter. To solve this, we use the hard drive serial number as a backup means of identifying the box.

When we added the hard drive serial number as the backup, it solved this issue. (We store both identifiers, and if the first cannot be found, it tries to match the second.)

Just my $0.02.


Friday, January 2, 2004

If you trust the customer why do you lock it to a MAC/IP combination?

For high value software, both intrinsically and in terms of its value to the customer organisation, I'd expect something like the right to audit, and for a server that is straightforward it can message auditing information back to your own server if needs be.

I wouldn't particularly favour licencing that relied upon some physical object, an external dongle is just about acceptable but only just.  Put it in the contract and make the violation of the licence a bloodcurdling result.

Simon Lucy
Friday, January 2, 2004

You aren't going to be able to prevent people from being able to reverse engineer the software, so you might as well give up.  They will mount the drive, examine the SQL and ASP code and whatever COM objects that you have and figure out how it fits together.  So it's a lost cause.

Most dongles can be disabled by a determined user.  Because they are obnoxious, even legitimate users will want to disable them.

You also need to consider the situation.  Most companies aren't going to screw around with some software they purchased unless it's so ludicrously simple that you are selling them snake-oil.  They generally want *you* to fix the bugs.

On the other hand, if you want to make sure that they are not messing with you too much as far as licensing goes, I'd suggest that the best way to do things is to have your software "phone home" with a status update.  If they install it on too many machines with astonishing regularity, have a salesperson contact them to remind them that it's $x per server.  If those signals dissapear, call them, ask them if they are having problems or are unsatisfied, remind them that in subparagraph 441k of the license, they need to make sure that the program can phone home.  This can be bundled with "useful" features that let you make sure that everything's all otherwise in the up and up to make it more palatable for them.

Flamebait Sr.
Friday, January 2, 2004

"Most dongles can be disabled by a determined user.  Because they are obnoxious, even legitimate users will want to disable them."

This is absolutely true. If I were faced with the choice of a dongle'd program and a non-dongle'd program, I'd likely choose the one without the dongle. If I had to buy the one with, then I'd be scouring the 'net for a crack, for sure.

Brad Wilson (
Friday, January 2, 2004

"This is absolutely true. If I were faced with the choice of a dongle'd program and a non-dongle'd program, I'd likely choose the one without the dongle. If I had to buy the one with, then I'd be scouring the 'net for a crack, for sure."

Would you really prefer the non-dongle'd program if it was locked to some other hardware component (disk serial, MAC address, etc.)?  What if this is mission critical software?  Given a choice between a dongle and a hardware locked license, I'll pick the dongle everytime.  Then, when a failure occurs, I can just swap the hardware and I'm back in business without having to waste time on the phone with the vendor to get a new unlock code.

Matt Latourette
Friday, January 2, 2004

"Most dongles can be disabled by a determined user.  Because they are obnoxious, even legitimate users will want to disable them."

How in the world are dongles "obnoxious"? From my experience I stick the dongle on (many of the USB are especially inconspicuous) and then basically forget about it -- I can use the software all I want with no problems, and if I upgrade machines the dongle pops onto the new machine. It's about as unobtrusive of a copy protection that could exist, and if I had the choice between activation/hardware keying or dongles/CD protection checks or a dongle, I'd take the dongle any day of the week.

Additionally, about 99% of users, especially business users, wouldn't spend a moment trying to reverse engineer or crack software -- applying the hacker standard to the general user community isn't really valid.

Dennis Forbes
Friday, January 2, 2004

See, the problem goes two ways.

If I *know* there's any sort of node locking to hardware or with a dongle, I'm going to be annoyed and try to find something else instead.

The fun part is that dongles are known at installation, whereas hardware locking isn't always known or disclosed at installation and thusly tends to cause fun surprises.

It seems like most of the node-locked software that I've used has sidestepped these sort of things by offering a 30 day freebie trial usage of the software so you can call tech support and beg for a new key.

Flamebait Sr.
Friday, January 2, 2004

Wow does the word "dongle" ever start to look odd after you've read it a few dozen times.

Dennis Forbes
Friday, January 2, 2004

Anything involving a telephone call, or a weird form of copy protection, not only will I not buy myself personally, but I will do all I can te prevent it from being bought at an institutional level. Why is that? Am I a fanatic? A cracker? No! I am someone who has years of data that can not be accessed because the software that reads it was made by a company no longer in business. I am someone who has years of data that can not be accessed because the hardware dongle failed and new ones are not available.

The USB dongles look sort of sturdy so I do have one piece of software that uses it. I wonder if I will be able to sue to get my data back if this dongle fails and the company whose software it protects is out of business. Maybe the dongle maker can be held liable for the billions in lost reveune when thousands of customers are locked out of data. Also I resent giving up a USB port just for such a thing. That is not what USB was made for. Registration numbers I am ok with as long as the registration number comes with the software and always works.

Companies can complain all they want but the fact is that honest users like me who pay for all their software are damn tired of getting burned and losing their data. And the crackers will do as they will. I think copy protection is like gun control - it doesn't affect the criminals one bit, but makes life more dangerous for honest citizens.

Tony Chang
Friday, January 2, 2004

To respond to Simon's question "If you trust the customer why do you lock it to a MAC/IP combination?"

I think customers are mostly honest, but some are not above bending the rules for convenience.  For a customer, tracking licenses is a pain.  In a crunch, it's easy for someone in the trenches to assume that a spare license is available and just install the software.  (this is more likely to occur in a small/midsize frim than a large company with established license tracking procedures).  By locking the license to a specific computer, we make the customer stop and think about the license.  It's takes intentional dishonesty to crack the code or to call us and try to scam another license, and as such is much less likely to happen.

As I said before, this is all about server software.  For desktop stuff the rules are different.

Friday, January 2, 2004

This still doesn't cover such things as network cards that fail at 3am, are swapped out by some diligent support engineer and lo your server software doesn't work anymore.

The hardware your software runs on does not belong to the software publisher.

The data created or served by some piece of software does not belong to the software publisher.

The only messages I can see being given by using these methods are that you don't trust the customer and that your product is more important than your customer's need for it.

So, do not be surprised when some competitor comes along with an alternative licence that is purely contractual that you start to lose sales.  Not because the customer wants to copy the software but because they don't want to be reliant on a single point of failure.

Simon Lucy
Saturday, January 3, 2004

Thanks guys,

I went to sleep and woke up to all these messages.
There's a lot of good stuff here.

I completely agree that dongles are a horrible thought. And that locking software to MAC/IP address could cause many problems.

The eternal license key that will work any where any epoch is definately the best solution. But some protection is required to stop the sharing of the same code (more so for desktop software).

I want to use a license key, but prevent the same key being copied. The best solution for this I can come up with (with my post-Friday-night lack of imagination) is a phone-home scenario where something unique (MAC-address/serial/SID) is involved to issue a unique key.

Should the software need redeploying after a disaster or stop working because someone has swipped the NIC, the process can be repeated and a new activation take place.

This must be a nightmare for Component vendors. We use a component (ChartFX) which now requires service-packs as the software has advanced. These are only available via a upgrade app that contacts their servers and no-doubt exchanges the keys and machine info so that they can see how many installations we have. Very clever.

Thanks for everyone's $0.02, I think I now have $0.34!!

Tim H
Saturday, January 3, 2004

"The best solution for this I can come up with is a phone-home scenario where something unique is involved to issue a unique key."

And what is your answer to: "What happens to my data when you go out of business, and stop answering the phone-home, and the program stops working?"

Brad Wilson (
Saturday, January 3, 2004

Good question. I'm not sure. What would you suggest?
How would/do you protect your IP?
(particularly in a component scenario)

Tim H
Saturday, January 3, 2004

Our solution is not to sell code, but rent it. They don't get the code, they get a URL. Of course, our application works in this business model, where many desktop-style applications don't.

It also eases the question of "what happens to my data if you go out of business?". If we were to go out of business, it would be a noteable event. We control the data, so we'd know exactly who needs to get their data distributed to them.

For a desktop app, copy protection is a waste of effort. I guarantee if your app is worth cracking, it will be cracked. Many cracking groups pride themselves on "0-day cracks", meaning they have it cracked the day it's released. *shrug* You accept that it's a part of doing business as a software house.

Brad Wilson (
Saturday, January 3, 2004

"For a desktop app, copy protection is a waste of effort."

I disagree. That's a little too defeatist for me!

Will said: "By locking the license to a specific computer, we make the customer stop and think about the license."

Which I think is a great point. Its the same as building a really high fence. You cannot accidentally be on the other side.

A mechanism that clearly demonstrates that the user has had to perform some kind of scam is enough to guilt a percentage of people who's conscience may then kick in.

Tim H
Saturday, January 3, 2004

So you think it's worth thousands of dollars (tens of thousands?) to implement and administer some active registration system, while pissing off legitimate customers, just to engage the conscience of the occasional cheater?

I could never justify that in pure budgetary terms. Apparently, you spend money based on different criteria than I do.

Brad Wilson (
Saturday, January 3, 2004

I wonder if there are two separate issues?

1. Knowing if the customer may be using more copies of the software than purchased

2. Taking action based on this knowledge

Perhaps there is a way to know that something may be amiss without prejudging incorrectly and therefore unjustifiably harming the customer?

Scot Doyle
Saturday, January 3, 2004

---"How would/do you protect your IP?"----

Your IP is worth squat unless you can convert it into cash.

And if your licensing scheme is so restictive that custmers won't buy it because it would mean giving you effective control over their data, then they won't buy it.

Stephen Jones
Saturday, January 3, 2004

"We control the data, so we'd know exactly who needs to get their data distributed to them."

Nice wishful thinking but that's not how most companies go out of business. When a copmany goes bankrupt, their assets typically are sold to other companies to satisfy their debts. This event of going out of business often comes about quite unexpectedly.

In 100% of situations I have observed, giving the clients their data back, or even honoring existing contracts, is simply not an option. The original corporation that had the liability in the form of the contract with the customer does not exist any more and the company who buys the customer data has no responsibilties or controls on what they dio with that data.

Hence, you see again and again companies that 'promised' to never sell customer data to anyone reorganizing and in the end the customer data is sold and exploited.

Even putting a master keycode in escrow in the event of bankruptcy does not always work, though this is something to consider having the protection of through a contract. In real life, by the time the courts decide to allow you access to your escrowed master key to unlock your data, your data has long since become relevant and you yourself may have gone out of business if you were relying upon it to stay in business.

Dennis Atkins
Saturday, January 3, 2004

"Apparently, you spend money based on different criteria than I do. "

No. I haven't implemented anything yet. I am just looking into ways it can be done and if its worth doing.

"I could never justify that in pure budgetary terms."

To allow the justification, licensing tracking could be added to a mechanism that delivers added benefit to the customer. The legitimate phone home scenarios discussed above: deploying service packs, checking for updates, bug reporting etc.

I like the distinction between knowing if more software is being used and taking action.

Tim H
Sunday, January 4, 2004

My point about phoning home is that you don't need to "activate" a key, you just know how many copies are installed at a given company.  If too many copies stay installed for too long, then you give them a call.

The other thing is that you are probably worying too much about "protecting your IP".  The reason why they are purchasing your software is because they don't want to write it themselves.  It makes little sense for them to buy something to make their lives easier and then follow up on that by making life hard for themselves again.

Flamebait Sr.
Monday, January 5, 2004

Both damn good points!

Tim H
Tuesday, January 6, 2004

Dave:  We've used the hard drive serial number for our software-based copy protection for a number of years, and it's worked out really well.  The only time the serial number seems to change is when it's reformatted.

That means you're using the volume ID, not the drive serial number.

The volume ID is easy to access, and easy to change, I like changing mine to DEAD F00D or equally silly hex strings and seeing where they show up.

Getting the real drive serial number is fiddly (I think), and not all drives have one.  Similar situation for the motherboard BIOS number, also popular for these schemes.

Wednesday, January 7, 2004

I thought that accessing drive and motherboard IDs was impossible in Java.  What is the point in having a copy protection scheme if it is not portable across platforms.  Unix based systems are more likely to be used in Server Environments than desktops.  Therefore a copy protection system aimed at the server must be able to cope with more than one environment.  Use of MAC and IP address is really just a workaround for the cross platform issue and systems that make use of this are in my opinion a waste of time.

Dongles seem a better bet especially for cross platform compatibility.  Like Satellite TV cards they have on board intelligence.  This must provide a higher level of protection.

Tim B
Monday, July 5, 2004

*  Recent Topics

*  Fog Creek Home