 |
|
|
In general, HD serial number is not as reliable as one would think. In FAT file systems (obsolete long time ago) serial number was stored as a 4-byte value somewhere in first bytes of the volume boot sector. NTFS should store the serial number in similar way. There was even a utility available to change the HD serial number into any value.
HD serial number protection would only work somewhat reliably if there are multiple applications on the same HD that require different HD serial numbers. Changing the serial number was easy, but each time the number was changed the machine had to be rebooted so that Windows would note the change, making it inconvenient enough to play with numbers every time you want to switch from one application to another. Virtual machines would solve that problem, just configure one VM for each app that requires a specific HD serial number.
|
|
|
|
|
|
|
What your referring to is the volume serial number which really is not a secure serial number by any means. The one referred to in article is located in the ROM of the actual HD which is put there by the manufacture and can not be changed without flashing the drives firmware. The bigger issue is all the new PC's with RAID controllers, you can no longer access the true ROM serial number as you can only see the RAID controller. I've been using the ROM serial number for a few years but with more and more PC's are using RAID it's becoming an issue once again.
|
|
|
|
|
|
|
A subject I'm interested in and this article presents some well thought through arguments and ideas
|
|
|
|
|
|
|
I have used diskid32 but it fails on many machines running Vista or Win7. Internally it tries a number of techniques to get the manufacturers HD serial number (as opposed to the Windows assigned drive serial number which can easily be changed) but too often these all fail.
My approach is to use a combination of several identifiers. These include (machine name, HD serial number(from Windows), OS install date, MAC address, etc.
These I encrypt and build into a single reversible ID. When checking a license I allow one of these identifiers to change without disabling the software. This allows for some change to the PC without disabling a license.
Unfortunately VM's are hard to protect against. My solution here is to only support network based licensing and restrict the installation of the license server to a physical machine. Users running in a VM need to point to the physical license server. And if a user needs a stand-alone software installation they install the license server (which is extremently light weight anyway) on their local PC. This is how some commercial systems work also (e.g. Flex).
|
|
|
|
|
|
|
A good discussion article. Started a lot of feedback (except for a few hapless / pointless '1's). Could a NEW (or unknown to me, at least) way of uniquely identifying PCs be devised that would answer this ?
How about these questions on the unique identification => In what scenario (and context) is the unique ID important and when is it important, how much spoof proof must it be ?
Are there any 'World Government' implications ?  ))
|
|
|
|
|
|
|
|
|
|
I am here to share knowledge with the Code Project community, and you are more than welcome to point to me of any problems you find with the concept of generating a unique hardware ID from the HD serial number, but why voting 1???
|
|
|
|
|
|
|
Well you have missed the point of the article haven't you. This is a discussion about trying to obtain a unique hardware ID. The author did not have to supply any code at all but did so to aid others in their investigation. If he was to remove the sample code the article would still be a good discussion document.
So the fact that you voted 1 really reflects upon you and not the author (who I do not know BTW).
|
|
|
|
|
|
|
Nice code examples, but...
If anyone of my team members suggested using the primary hard drive’s serial ID (or mac), is the day new positions become available.
By the way, hard drives are replaced much more often than NIC cards. Using a HD serial ID is just as unreliable as using a MAC.
For what it's worth...
|
|
|
|
|
|
|
NIC cards are replaced less often but MAC addresses can be forged, and the reading of the harddrive serial number is always accurate and can't be forged. But you know... this is a coding web site, if you can prepare a POC for a better way, just upload it and let all of us try it on our machines. After all, I'm here to learn from others...
|
|
|
|
|
|
|
True, mac's can be forged, i stand corrected.
Better then POC; a real-world example would be what Nico Cuppen suggested. I've been using this method for a few years now, and so far, 100% unique id's with no hiccups.
|
|
|
|
|
|
|
Greg Cadmes wrote: If anyone of my team members suggested using the primary hard drive’s serial ID (or mac), is the day new positions become available.
I think yours is an overreaction. Surely it depends upon the purpose of uniqueness. If this is as part of a one off check at install time then the hard drive serial number is appropriate because when the hard drive is replaced a reinstall is required.
|
|
|
|
|
|
|
We use code from diskid32 since 7 years to build a unique key for every PC.
Probably programmers change disk often to have more space, end users dont; they simply change PC every 3..4 years. With 500+ site we have less than a request of key activation for disk replacement a week
The problem we faced is related to RAID on servers since you cant get disk serial number on device attached to RAID controllers. In this case we use NIC, and we know that can be changed with many anonymizer
To avoid stolen key on network (95% of our customers) we use and ID ( 001..999 ) and a key ( MD5 - SHA of disk sn ) written both on registry and on a network file. You must have both valid to start program; if you have requested a key and you still have old PC on the network the registry return ok, but on record associated with ID on the network ther is the key of the new computer and that's all.
The real problems of this kind of protection schema are the ability to avoid code patching and virtual environments.
|
|
|
|
|
|
|
This is the best solution.
|
|
|
|
|
|
|
I’m a shareware author (www.nicocuppen.com). Years and years ago I was thinking about a way to bind the license for my software to a particular machine. After much thinking I decided to use as machine identifier the date and time Windows on that machine was installed. It is stored in the Windows registry as the number of seconds since January 1, 1970. During the lifetime of a Windows installation this value never changes (unless the user starts tinkering with it of course), and it’s obviously a unique (ok, sufficiently unique) value. And when the user decides to reinstall Windows on her machine, for whatever reason, well, then she will also reinstall my software. So in this respect it’s about the same situation as replacing a malfunctioning hard disk and getting a new hard disk serial number.
This is how to retrieve the Windows installation date and time:
OSVERSIONINFO OSVersionInfo;
HKEY hKey;
DWORD dwRC = 0;
DWORD dwType;
DWORD dwCount = sizeof(DWORD);
OSVersionInfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx(&OSVersionInfo);
if(OSVersionInfo.dwPlatformId == VER_PLATFORM_WIN32_NT) { if(RegOpenKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion", 1, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS) {
RegQueryValueEx(hKey, "InstallDate", NULL, &dwType, (LPBYTE)&dwRC, (LPDWORD)&dwCount);
RegCloseKey(hKey);
}
}
else { if(RegOpenKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\Microsoft\\Windows\\CurrentVersion", 1, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS) {
RegQueryValueEx(hKey, "FirstInstallDateTime", NULL, &dwType, (LPBYTE)&dwRC, (LPDWORD)&dwCount);
RegCloseKey(hKey);
}
}
dwRC will now contain the date and time Windows was installed on this machine as number of seconds since January 1, 1970.
For what it's worth.
Nico Cuppen
|
|
|
|
|
|
|
Great tip! Thanks! Of course you need to be sure it is next to impossible to forge that piece of information. Lets say I bought your software and I know you are using this method, so I buy a license to one PC, and want to use it on other 9 machines. All I need to do is to set the value of the Windows installation date to be identical to the one with the legitimate license.
|
|
|
|
|
|
|
Did you really expect me to disclose here the way I protect my intellectual property?
Like you said in one of your comments yourself: "Please note that even though some of you think against copy protection and licensing, my article is NOT about this issue".
|
|
|
|
|
|
|
You are right... I will send you a private email...
|
|
|
|
|
|
|
For software protection in days with VitrualBox this is not really useful anymore. (I know it was not the topic of the article).
To protect software properly, you can either send license codes that include the email address of the customer, his name or additional hardware that has an unique ID.
Such extra hardware known as "hardlocks" can be easily programmed with SDKs. CodeMeter e.g. provides very good software, but the devices are quite expensive. Nothing for "shareware" style apps.
What I used in a new project is the idea, that each of the modern mobile phones (iPhone, Android phones...) have an app-store and a unique ID built in! So, you can use the ID of the device, accessing it with a free-to-get, custom app running and communicating to your desktop app with TCP/IP e.g.
|
|
|
|
|
|
|
Yet, sometime you want the same software to run differently on different machines, based on a locally stored license.
|
|
|
|
|
|
|
I get the point.
Please also check, when you have a wifi MAC address, that it might not appear, when the adapter it powered off. The disk-serial is the easiest to do, but for virtual machines it might be cloned also.
Another idea is to write a registry key (random number) to HKLM.
|
|
|
|
|
|
|
Personally I run many (>50%) applications under/inside a virtual machines (i.e. on the same physical laptop I have several VM). How will my user scenario affect your discussion?
|
|
|
|
|
|
|
It is important to be able to detect VM, and there is some ways to do so.
|
|
|
|
|
|
|
The virtual PC's, assuming they are running on the same physical box, will all report the same ID as they all access the same harddisk. But in order for these virtual PC's to be able to access the network, they will have to have different PC names. So you could use a combination of the HD serial + the PC name, possibly hashed, as your unique ID.
/NIP
|
|
|
|
|
|
|
Just FYI.
Usually people use an approach that combines a number of generated hardware based IDs (e.g. hashed motherboard ID, hard drive, RAM size, MAC address, CPU ID, etc.). So the final value depends on a number of independent parts. And as a policy option they use a number of different parts which can be changed without hardware ID violation.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin