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

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.

Edhy Rijo

Hi,

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.

we dont have a mechanic in the licencing to detect wether a computer was moved. however, we dont really care where the computer is located. if the customer moves a computer to another office, he would have to put a new computer on the old office and require a new licence for it there.

Hi Keith,

I'll be watching out for that.  Thanks

Edhy Rijo

Hi Philipp,

And in a case of component being updated, how do you know it is the same computer/same customer requesting the new license since it could be the same customer at another branch/office?

Edhy Rijo

we are using a mixture of different information from the wmi for our licencing. this includes mac-adresses, hd-serials, mb-serial, processor-id etc..

if a component is updated, the client needs to request a new licence.

I have the desktop portion done, just the web service left, when I have it done I'll post it if anyone is interested to hold over until SF gets their activation module out.

I did it using HD serial, going to retrofit to use MAC and see if it is a pain. Trent you say I dont have to allow them to pick MAC necessarily?

Would you just pick any one at random and use that, theory being that MAC devices will change less often than hard drive?

Do you guys use WMI to get MAC address or is there a better way?

Keith Chisarik

Hi Keith,

I am also looking for activation/protection alternatives look at this post http://forum.strataframe.net/FindPost21518.aspx

In my VFP applications I use a commercial library which allow me to activate the licenses online, but it is not easy to implement and maintain, also now with .NET having the need to be installed in each workstation I am having problem trying to implement this solution.

I guess the guys at MicroFour should get the activation module project a top priority

Edhy Rijo

The SN on a hard drive is something that we used in the past, but it was a headache and depending on drivers, drive types, etc. this wasn't always consistent.  But even once we worked past that, hard drives were always "crashing" and we would have to issue new keys which most of these were people not telling the truth in the end.  So the MAC address is where we turned and it has worked well and if they replace a hard drive or even rebuild the entire machine, as long as they have that NIC ini the machine, they can re-activate and we know it is the same machine.

You don't have to let them pick the NIC and you can pick it from the installed NICs on the machine.  But it is really the most simple approach that we have ever taken and to date, the most simple to keep up to date and prevent overall theft.