The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How 2 read the CPU or HDD serial# whhen running in a virtual PC?

I need to implement a copy protection mechanism in my application and I came accros this issue.

The application runs on a web server and that can be run on a Vmware or some other kind of virtual machine.

I was planning to have a registration key based on the hardware elements of the machine so the application can't be installed /copied several times but this seems to be quite impossible anymore with so many people running applications on virtaul machines these days.

I don't need a strong anticracking protection, just a minimal way of protection the application being installed on several machines without authorization.

I was curious to see how are other people dealing with this issue?
Are there any ways to uniquely identify an OS running in a virtual machine ?
John Staffini Send private email
Monday, October 23, 2006
 
 
The popular VM technolgies (VMware, Virtual PC) dont virtualize the CPU, so it should be possible to interrogate the CPU.

Other than that, you're prob. out of luck.  From experience, I've seen that e.g., Windows XP is quite happy to run on many physical machines once it's been activated in the VM.
BillT Send private email
Monday, October 23, 2006
 
 
This discussion thread started out talking about licensing Vista within a virtual machine:

http://discuss.joelonsoftware.com/default.asp?joel.3.403176.30

But in the process, the conversation diverged into a discussion of how to detect a virtual machine. I thought the provided links near the bottom were quite fascinating.

A little more to the point, since it's now possible to transfer virtual machine "images" from "player" to "player", I think it's no longer feasible to tie a product directly to hardware. Sure, Microsoft is doing it, but they have far more resources and hardware samples to play with. You'll have to find another way to enforce the "one per server" concept.
TheDavid
Tuesday, October 24, 2006
 
 
Err...  I ended my last post too early.

One option to consider is that if your application relies upon a database, structure the database and application such that the database can only service one instance of the application.

A second option is to embrace the virtual machine philosophy and allow users to swap servers, but limit licenses to an IP address range. For example, my company Foo.com can work on any web server in the Foo domain, but will fail if I copy the files to the Bah domain.

If I think of more, I'll post 'em.
TheDavid
Tuesday, October 24, 2006
 
 
I start to realize that the "one per cpu" approach will probably not work anymore in the generalized vm era.

Now that I'm thinking better, I will not try to tie athe app to the cpu but to the user.

Since I'm developing enterprise software which is literally of no interest to the home users, my only concern is actually lost revenue from illegal sales made by pirates to users buying in good faith.

So I will not try to inforce the application to be bound to the server but to the organization who purchased it via a splash screen.
At each launch on the splash sreen it will be displayed something like "This software is licensed for use to ACME Corp, Dept of Engineering".

By providing encrypted activation keys with the user information stored inside I feel that I will have enough protection as people will question the legit status right away  if they see a software running on their premises but with someone else's name on it.

And that should discourage the pirates right away also.

I don't see any flaws with this approach ...
John Staffini Send private email
Wednesday, October 25, 2006
 
 
Sounds like a good approach. The bottom line is that businesses don't want to put themselves at risk so they will stamp out the piracy themselves in most cases.

As a side note, we use something similar but we also tie the registration to a piece of data that must vary by user in order to be usable. For example, we write Point of Sale software. So we put the store number into the registration scheme so that pirated stores end up sharing the same store number. This causes havoc on corporate reporting systems so it basically makes the software unusable. A retailer could technically call all of their stores 'Store #1' but that would be much more costly in workarounds on the back end than just paying a licensing fee. Look for something in your application that may be similar.
Turtle Rustler
Thursday, October 26, 2006
 
 
I have to admit I really like both the splash screen and the "hard coded data" suggestions. I may have to steal them one of these days.
TheDavid
Thursday, October 26, 2006
 
 
Someone posted on BoS about doing this, and found people would print out the reports, mask out the original companies logo and photocopy them!

It's amazing the lengths that companies will goto to avoid paying for software, especially when the same compnaies would go crazy if they were shoplifted from or had their offices burgled.
Martin Send private email
Friday, October 27, 2006
 
 
I agree that binding a registration to a user is a good thing. Showing his name, email address, etc. might prevent him from sharing is serial number.

See a recent thread for more suggestions about serial numbers:
http://discuss.joelonsoftware.com/default.asp?joel.3.408301.7#containerDiscussTopic408675
Yoriz Send private email
Friday, October 27, 2006
 
 
If your code is in Windows, you may be able to use WMI to get this and other useful information. Grok WMI, IWbemLocator and IWbemServices at Microsoft.
Jeff Phillips Send private email
Saturday, October 28, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz