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.

 

[Rephistorch]

Personally I think it's a bad idea to do any type of machine hardware checking. 1) people change things. 2) people buy new computers 3) just limit the how many times they can activate in a year and monitor all activations.

Here's how I would do it. Check all hardware and send it to a database online. then if they activate again have a program notify you and show you both configurations. If they're the same or a few things have changed then cancel their activation key. Also, to ensure that they don't pull around the activation key to another computer with a different harddrive have the software A) send the online database a notification on hardware changes B) hide the activation key in some obscure registry file/folder on the hard drive.

For programs that touch base at home with a database, be sure to include that in the all important End-User License agreement that no-one reads. And for further coolness... send the key without the user's knowledge.

 

[TPM]

You really should check the date before posting, this is from 2004!
I'd also point out the reason for using some sort of machine ID is to prevent a simple copy, there's programs that can monitor things like the registry for changes so even if you hide the key it'd be easy to find. I'd also suggest you check the legality of sending the key without the user's knowledge.

 

[Rephistorch]

lol. Yeah i just realised that tihs was from 04. . Anyways, it would be completely legal if you put it in the end user license agreement

 

[TPM]

Yeah it would, but you'd be surprised how many people actually do read those things.. It could end up giving you a bad reputation.