Develope license management

[alex.]

Want to develope a license management software module for my LV application.

Just somehow like LV license activation.

1. User generate a code and email to me.

2. I generate a code and send back.

3. User uses the new code to activate the software.

The concern is

1. What should be inside the user's code? CPU id or others, better can use for embedded system also.

2. After activation, where should I save the OK info.

I am totally new for this.

Any suggestion, thanks. 

[CoastalMaineBird]

Here's what I do; it's not bulletproof; maybe it helps, maybe not.

My app is for Windows only.

I have a LICENSE manager; a VI to handle all this.

I have three STATEs: UNLICENSED, PENDING, and LICENSED.

I have a LICENSE FILE: a cluster of USER NAME, COMPANY NAME, SERIAL NUMBER and KEY (U64)

At STARTUP, I get the VOLUME SERIAL NUMBER of the disk we're running from (use "GetVolumeInformationA" in KERNEL32.DLL) to get this - it's the number you see when you DIR in a DOS window).

At startup, read the LICENSE file.  Decode the KEY from the license file  into a VSN, PRODUCT ID, and SERIAL number.  Use your own scheme of XOR, bit shifting, whatever to do the encoding/decoding.

If the VSN from the file key matches the VSN from the disk you're running, AND the PRODUCT ID from the file key matches your PRODUCT ID, AND the SERIAL from the file key matches the SERIAL from the file, then set your own state to LICENSED, and enable all features.

Otherwise, if the SERIAL from the file is 0, then you're UNLICENSED: disable PRINTING, saving, whatever, and run in DEMO mode.  If the SERIAL in the file is not zero, you are PENDING.

When the user enters a USER NAME and COMPANY NAME and clicks REGISTER, the program sends that info, along with the VSN, in a request to the host server, requesting registration.   The program there (A PHP script in my case) issues a SERIAL NUMBER in a reply, and a message to a human at the host site.

The SERIAL NUMBER (being not zero), changes the program into the PENDING state (so it won't ask again).

The host site processes credit cards, checks, whatever (outside this program), and approves the user.

The PHP script generates a KEY  (using the same scheme as the user's program) and the next time the user checks (by pressing a CHECK for REGISTRATION button), the key is available.  The key is stored into the license file, and the program is then licensed, with all features available.

You have to invent a scheme that turns a VSN, PRODUCT ID, and SERIAL NUMBER into a U64, and back again.

There's a lot of error handling you have to pay attention to. Only you can decide if it's worth it (my client decided that question for me).

[alex.]

May I know how to call KERNEL32.DLL in LV, thanks.

[F._Schubert]

You also can get some information on the PC from the registry (Windows).

Instead of using xor, it is much safer to use blowfish. There is a LV implementation somewhere on ni.com 

Felix 

[CoastalMaineBird]

May I know how to call KERNEL32.DLL in LV, thanks. 

Check out post #2 in  this thread.

That's a DLL call that you have to configure - I recommend using is from the vi, rather than starting from scratch.

That might be where I snarfed this from - here's my version:

[alex.]

As I understand, may I do like this.

Every software comes with a Serial Number.  

1. When do activation at the client side, it will get hardisk volumn number and Serial Number, then encrypt with

 key1(string1) by AES256, and send to server.

2. When server receive it, decode with key1(string1) by AES256, and check if the serial number is in the list, but not activated before, if so, it will encrypt volumn number with key1(string2) by AES and send back to client.

3. When client receive it, it will save it in a file. Every time runup, it will decode the file by key2(String2) and compare with the one get by kernell.dll, if they are the same, then go on.

Is there any weak points in the procedure, thanks. 

[CoastalMaineBird]

Close but not quite.  Not to say your scheme won't work, but if you're trying to understand mine, here's what I do:

Every software comes with a Serial Number.  

 --- No, every copy is the same when starting out.  There is no serial number yet. 

1. When do activation at the client side, it will get hardisk volume number and Serial Number, then encrypt with

 key1(string1) by AES256, and send to server.

--- I get the HardDisk VSN and USERNAME / COMPANY NAME along with a PRODUCT ID and encrypt those.  PRODUCT ID is in case you have two separate programs, PROGRAM A = Product ID 101, PROGRAM B = Product ID 102. 

2. When server receive it, decode with key1(string1) by AES256, and check if the serial number is in the list, but not activated before, if so, it will encrypt volumn number with key1(string2) by AES and send back to client.

--- When the server receives the request, THEN it assigns a serial number and sends that to the requester.  The server enters the HardDisk VSN and USERNAME / COMPANY NAME, PRODUCT ID, and serial number into a database.

When the software has a serial number, but not a key, it's in the PENDING state, and won't ask for registration again. 

The serial number is saved into a license file, along with the VSN. There is only one key for the software.

--- The server at this point does whatever is necessary to verify credit cards, purchase orders, whatever.  When the server side is satisfied that the bill is paid, it uses the VSN, SERIAL NUMBER and PRODUCT ID to compute a key, and puts that into the database.

--- The client checks periodically with the server to see if a key is available yet.  If no key is available, the client stays in the PENDING state (demo mode). 

3. When client receive it, it will save it in a file. Every time runup, it will decode the file by key2(String2) and compare with the one get by kernell.dll, if they are the same, then go on.

--- Exactly.  It decodes the key in the license file.  The decoded VSN has to match the actual VSN from the hard disk to enable everything; otherwise, stay in demo mode. 

Is there any weak points in the procedure, thanks.

Yes.

1... If a user replaces or reformats their hard disk, the registration is lost.  The new VSN will not be the same as the old.  They have to go thru the whole process again.  They will have to call the central office and explain things - if the people there believe the story, they get a new key.

2... If a user replaces their computer, same thing.

3... The VSN is theoretically unique. But some companies use tools to duplicate disk images onto all computers in the company.  That means the VSN is duplicated, and a license for one of those computers will work on all of them.

4... There are hacker's tools that will allow you to diddle with the VSN.  If they figure out that it's VSN based, those tools will crack it.

It's not bulletproof, as I said.  It will deter casual piracy. It will not stop a determined hacker (nothing will).