I know I could use MAC address, but then I have to go to the trouble to enumerate all the MAC addresses and allow the user to decide which to use and store that. Is there another ID one can pull off a given PC that is accurate 99%+ of the time? If 1% of the time they have to call, that is OK. I am going to write a web service that handles the activation and key to PC management.

In our VFP applications we get a value based on the serial number of the hard drive and it has worked for 10 years in some applications, they just have to call when they get a new drive or PC.

Any thoughts on a "better" way in .NET short of MAC?

Keith Chisarik

just noticed you propably meant how we detect if a users claim of hardware change may be
detected by our licencing shema instead of what i answered to.

first off, our new licencing is not yet out on the field. its partly implemented currently and
will propably ship with the next generation of our products. not the current.

The key is, that if the customer claims "hey my harddisk died, had to buy a new one", or
"i needed a new graphics card", we have the means to controll weather really only the harddisk
or graphics card changed. for that reason our system doesnt produce 1-way hashes out of the
collected information, but rather encrypts the information (currently using Rijandel-Algo) and a
key that our licencing class calculates based on the customer information and the licenced product
and some additional logic, that is decryptable to us.

When the application is run at the customer, it will create an xml file containing some basic information
and the encrypted hardware information collection. We then issue the licence file based on that file and store
it (the hardware-info file) within our crm software.

Now when the customer would request a new licence because of an hardware upgrade, we could copy his latest
hardware-information file and compare it to the file we have stored in our crm. We then compare the two
files and get a list of what hardware information was in the old file, and what is in the new file.
The only difference should be the hardware the customer exchanged. if there are more differences, we may
suspect fraud

The reason i didnt want to go with Network-Adapter MAC Adress(es) only is, that there are easily accessible
programs on the internet to spoof a different MAC Address (even tho i admitly never tried them) that could possibly spoil the licencing.

With our solution, instead of just d/l a spoofing tool, the customer would need to figure out how the encryption process of the data work, e.g.
how we create the encryption key in detail. thats off course entirely possible to do for someone with some
reverse-engineering knowledge (specially with .net projects, which are kind of easy to reverse engineer) and
enough time and motivation to dive into it.

However we dont see either the programming knowledge, nor the motivation
towards reverse-engineering within our current customer base and therefore i think this method is sufficient enough.

You can go to great length in writing very very clever licencing code and thats very interested and fun todo,
but i dont think we have the time or money to invest development there beyond what we got/got planned for now.

Yes, that is what I meant.  In my case, I have some smart customers with branch offices in which they should also pay a license for the use of the software at each branch office. 

What I am trying to avoid is allowing the customer to have multiple workstations working under the same license and have a smart customer trying to use one of those workstation from another branch office and skip paying for that branch office license.

Obviously in your case, you don't really care, if they move one licensed workstation to another office and work from there, but as you explained, your method of comparing the hardware key information files will do the trick to find out if the computer has been replaced.

Thanks for the information.

yes. the trick to that is that the hw-id file is rewritten each time the application is started just before the licence validation is performed.

as said, the weak-point is the possible reverse enginering of our dll that carriers the key calculation for the encryption. we could minimize that by buying some obfuscation software tho. i had a look at a few, and the cheap ones tended to also have cheap results, while we won't afford the more expensive ones

also i noticed that some developers of obfuscation products for .net also offer .net dissambling software, which made me wonder weather that whole topic is just a big ripp-off