Processor ID / other unique values??

[bloukewer]

Hi, can anyone please tell me how to obtain a processor's unique ID (if such a thing exist, which I believe does)? Or maybe some other unique number such as the Harddrive's serialnumber or something. I need it to copy-protect a program which is nearly ready for distribution. Any references to tutorials of related subjects would also be much appreciated.

 

[TPM]

HD's serial can be pulled like this :
dim hds as new system.managment.managementobject("win32_logicaldisk='c:'")
hds.get()
dim s as string = hds.properties("volumeserialnumber").value

I'm sure there's a way of doing the same for the CPU, but I don't know it off the top of my head.

Hope it helps

TPM

 

[Administrator]

I would be interested in the "typical three" for licensing:

-Primary MAC address
-Boot Drive Serial Number
-Machine Name (already know this one - Environment.MachineName)

 

[TPM]

I would be interested in the "typical three" for licensing:

-Primary MAC address
-Boot Drive Serial Number
-Machine Name (already know this one - Environment.MachineName)

Well both Mac address and and machine name are changeable, so I wouldn't recomend using those. Another alternative however would be a GUID, but that could be copied..

 

[JuggaloBrotha]

Well both Mac address and and machine name are changeable, so I wouldn't recomend using those. Another alternative however would be a GUID, but that could be copied..

but if neal uses all three, then it's 3x harder to spoof the software he's written.

no matter how spoof-proof you make your program there will always be a way around it all, but the more spoof-proofing you include the less likely someone is going to bother with the trouble.

 

[Administrator]

I actually want more elements not to make licensing harder to crack, but quite the opposite, to keep support calls to a minimum from changing one element. For example, when I was reviewing Xheo, I had my C drive take a turn for the worse and became a rock in the lake! I replaced the drive and guess what, Xheo would not reactivate! That's terrible licensing practice in my opinion, which is why I use Desaware now! If I can collect three pieces of info and 1 or 2 match, then I'm fine, reactivate, but if all are different, we have a problem!

Licensing/Activation is a huge dilemma! The balance is earning your pay vice keeping your customer base! I did a poll and the poll takers said they'd move to another product just to avoid activation. So I don't know what to do....thinking hard for my next round of rewrites/new apps!

 

[TPM]

but if neal uses all three, then it's 3x harder to spoof the software he's written.

no matter how spoof-proof you make your program there will always be a way around it all, but the more spoof-proofing you include the less likely someone is going to bother with the trouble.

Yes, but 3 times easier to break...

 

[TPM]

If I can collect three pieces of info and 1 or 2 match, then I'm fine, reactivate, but if all are different, we have a problem!

Licensing/Activation is a huge dilemma!

Well I'd say just make it easy for the user to activate. Through an activation prog. or web page. If you keep a log of how often a user ativates the program you can cut down on software sharing.

 

[bloukewer]

Yin and yang

Well, this proves to be quite the dilemma. It differs from one situation to another, but a customer database from which you can keep track of your customers becomes more and more necessary, so that they can contact you and you can give them a password in case they format their drive/s and need to reinstall your app. (The database is to know whether the person querying is really a customer etc). Of course, you must decide if it is financially more viable to set up a customer-support infrastructure than to lose sales to software-pirating and reverse-engineering etc.

Such a customer-support infrastructure may be a web-based - or a callcentre based solution, or a combination of both, depending on your targetmarket.

Unfortunately, in my case, only a few individuals within my targetmarket have internet access, so the relatively cheaper web-based solution is not a viable option.

Generally, it is better to copy-protect your software as best you can (not to metion protecting against other bad-elements such as cracking and reverse-engineering), and to set up some sort of customer-support.

Like I said, it differs from one situation to another, but it seems to me that the better your product, the better you need to protect it, and the bigger the need for some sort of customer-support service.

 

[bloukewer]

Processor ID

Just to elaborate... A machine with multiprocessing would complicate things.

A combination of Processor and HD-ID would be better (Either HD-ID matches or processor-ID matches).

I think that that would be the best combination of unique numbers to protect your software with.

Just remember that when you do this they can take the HD, put it in another box and voila! They now have two comps on which they can run your program.

But because HD's are more likely to crash and burn than processors (in my limited experience), it would be best if you can check if the processor's ID (or one of the processors's ID's) match with the password/unlocking code.

In conclusion, the only way to protect your software entirely without setting up a customer-support infrastructure is to write such a crappy program that no-one woul want to use or abuse it. Bummer.