We Keep Coding

Create a robust hardware serial / hardware ID in C#

I created a little hardware lock in my licensing process. A (hopefully) unique hardware ID is generated before installation and encoded as part of my license file. Whenever my application starts, the hardware key is regenerated and compared to the registered one.
Actually, the hardware key refers to the first CPU, BIOS and mainboard infos based on the solution by Alex Sutu.
So far so good - now, the system runs in a virtual environment where new CPUs are linked in dynamically - and so the order of CPUs changes. with the invalidated key, the software is not running anymore - as wanted and expected by me, not by my client. Therefore I have to change the process a bit.
As far as I remember, Windows 7 (or even previous versions) had some kind of robustness within their activation / registration IDs - smaller hardware changes did not invalidate the activation / license - an that is what I want to mimic in my licensing context.
I found a little explaination here - which lets me think of the following process in general:
For registration:
Generate X different hardware IDs using different settings (CPU, mainboard, bios, whatever)
Register these IDs within the license file
When starting the application:
Generate X different hardware IDs using different settings (CPU, mainboard, bios, whatever) (is WMI access fast enough? Alternatives?)
If more than X percent (95?) of the the newly generated ones are equal to the registered ones from the license file, everything is fine and the application starts
Actually, generating a hardware ID using WMI queries takes pretty long (somewhat between 4 to 8 seconds).
static string identifier(string wmiClass, string wmProperty)
{
string result = "";
var mc = new ManagementClass(wmiClass);
var moc = mc.GetInstances();
foreach (var mo in moc)
{
if (result == "")
{
try
{
result = mo[wmProperty].ToString();
//Only get the first one
break;
}
catch
{
}
}
}
return result;
}
Example call:
string retVal = identifier("Win32_Processor", "UniqueId");
So I am quit a bit uncertain, whether taking more IDs into account is the right choice.
Therefore the final question:
Is this a practicable way of creating a robust hardware licensing or am I missing a point?
Secondly, if this is "state of the art", is my WMI approach the right one or are there better ways?
Thanks a lot in advance!

Your approach is generally correct. Collect different identifiers, store them securely and issue the license. Whenever only a few of the identifiers have changed, you update your storage to the new values, but still run the application.
As of the time to collect HW info, you may start loading the application in "locked mode". Once HW identifiers become available, you check the license and asynchronously unlock the application. This way you are not so limited by the communication delay - I used this approach with license validation against a remote server.

UDID for windows 8

Is there any unique device ID (UDID) or any similar ID I can read out on Windows 8 that doesn't change with hardware changes, app-reinstallation etc.?
If No - what is the best way to generate it yourself?

No. Yes.
No, there is not such ID because (in theory) you can change ANY hardware component so you may get a completely different ID (that's why Microsoft suggest to calculate a score based on ASHWID).
Yes, there is such ID (but it may not be applicable in your case).
If you can't rely on hardware because it's easy to add memory, change disks, add another network card (for example turning on/off bluetooth or wi-fi) then you have to rely on a "software" ID.
In the registry there is an unique ID generated during Windows installation and it won't change until you reinstall Windows. You can find such ID in HKLM/Software/Microsoft/Cryptography, it's a string named MachineGuid.
If you can identify a component you're pretty sure that won't change (motherboard for example) you may use a simple WMI query to get its serial number but you should always provide a fallback because many many MBs returns a fake S/N (and virtual machines may returns always the same one). What's the proper solution...well it depends on what you have to do with that ID. Identify the user? Check for license? Encrypt data? Each of these has a different "best practice" for ID.
Get an unique ID for the device
If you have to identify a particular device (regardless to the user) you have many options, what I'd prefer to do is to generate an ID using only stable data (S/N from motherboard and BIOS, for example). This won't help you if he/she completely renew its hardware but it should be stable enough (but you have to define what is enough in your case). You may even use the S/N of the primary disk (with portable devices it's pretty stable and you may even use it in combination with other serial numbers to build your own ID). You can get this informations through WMI or (if you're targeting WinRT) through specific bytes of the ASHWID structure.
Encrypt data
In this case you have to think when data may be unrecoverable. If with a small hardware change your users won't be able to read their previous files well, they'll be unhappy. In this case I would suggest to use the MachineGuid, unless they reinstall the OS they wouldn't have to worry (but do them a favor and provide a way to read back that GUID somewhere). If you're sure you're targeting a portable device like a phone or a tablet then disk serial number (or CPU ID, if available, or MB or BIOS) may be appropriate too (because it's pretty uncommon they'll change).
Licensing
I would use a combination of many (stable) IDs. As for an unique identifier for the device you can't be sure nothing will change. In the past MAC address was vastly used for this but mobile devices changed these rules (because it's easy to turn off a NIC). You can still use them but you have to put extra care (and code) to manage that situation. Again a combination of multiple IDs (chosen carefully) can help you to minimize customers effort when they change their hw/sw setup. In this case a good compromise could be the OS serial number (not the MachineGuid). If they install a new OS then they have to update your license too (but I would use it combined with something else to be sure they won't use the same OS copy on multiple computers or virtual machines).
Note about virtual machines
If you have to target VMs too then things become more complicated. In theory an user can create multiple copies of the same VM with exactly the same hardare and software configuration. If this is an issue and if you can't address this properly (for example using a network check) I would suggest you don't support them at all (just quit if you detect a VM).

here is a code example in JavaScript that filters form ASHWID the hardware modules that are unlikely to be changed (CPU id, size of memory, serial number of the disk device and bios) and convert it to string. the code is based on a code from this thread
// get the hardware Profile id and convert it to byte Array
var hardwareToken = Windows.System.Profile.HardwareIdentification.getPackageSpecificToken(null);
var byteArray = Windows.Security.Cryptography.CryptographicBuffer.copyToByteArray(hardwareToken.id);
var deviceSerial = '',
offset = 0;
// we filter the hardware modules that are unlikely to be changed, and aggregate them to a string.
while (offset < hardwareToken.id.length)
{
// CPU ID of the processor || Size of the memory || Serial number of the disk device || BIOS
if ((byteArray[offset] == 1 || byteArray[offset] == 2 || byteArray[offset] == 3 || byteArray[offset] == 9) && byteArray[offset+1] == 0)
{
for (var i=0; i<4; i++)
{
deviceSerial += byteArray[offset+i].toString();
}
}
offset += 4;
}

Can I use the first OR last 16 characters of a Guid and it still be unique?

Objective
Generate a unique 16-character key, to use as a batch name, that doesn't require any type of storage (e.g. a unique counter).
Background
I have a Windows service that runs every 30 seconds. I picks up messages off of an MQ and processes them in a batch. One of the service calls I'm making is requiring a 16-character batch name now. They don't care what the batch name is, it just needs to be unique across all batches.
Question
If I generate a Guid, can I use the first or last 16 characters of that string and it still be unique for my needs?

No.
Raymond Chen explains why in great detail in GUIDs are globally unique, but substrings of GUIDs aren't.
However, if you are running this on a single machine, then you don't need your ID to be globally unique - merely locally unique. Therefore, you can drop the MAC address requirement from the GUID algorithm he describes. Also, if you know that only one will be generated every 30 seconds, you can drop the collision part of the algorithm. This pretty much leaves you using the date-time as qujck suggests.

No is the simple answer. Why not use the date/time?
For example, here's some Oracle generated GUIDs
D71CDF38BB3B6026E0430A9A9A286026
D71CDF38BB3C6026E0430A9A9A286026
D71CDF38BB3D6026E0430A9A9A286026
D71CDF38BB3E6026E0430A9A9A286026
D71CDF38BB3F6026E0430A9A9A286026
D71CDF38BB406026E0430A9A9A286026

Help with Hardware ID

I'm using C# and .NET 2.0. My app needs some way to check the different users so I'll use hardware id, but I saw that I can use only:
mac address - easily changeable and not everybody have it // NO
processor id - using WMI it returns a value for the cpu model, it's not unique // NO
motherboard serial - not every motherboard have it // NO
the Windows's volume serial - I'm not sure if it will be changed on Windows reinstall and format of the volume
So is there something I didn't mention for hwid? I want something that everybody have and it won't be erased on windows reinstall. Else I'd have to use the windows's volume serial number.
EDIT: From the commments I think it's best to use HDD id. How to get it?
EDIT2: I just read that the SCSI drives don't have serial. Is that true?
FINAL EDIT: I'm already using the root drive serial on my app. It work's pretty well. Thanks all.

HDD Serial number: unique, unchangeable, and everyone has it.
not a perfect option but...

Well i'd go for more than one id. If you combine enough IDs they will get you enough uniqueness.
EDIT: you might also go for the place on the harddisk your program was installed too (Platter, Cylinder etc.)

Why do you want to use hardware Id? I'd go with some kind of forms-based (or AD based) security, myself.
Given that, however: The thing about HWID is that it identifies that particular computer configuration: it is designed to change if there are system changes. You mention that Windows Volume Serial could change on reinstall and reformat, but won't your software also have to be reinstalled at that point? HDD Serial could also change if, say, the user swaps HDDs for some reason.
If you have to use HWID, you'll probably need to select one (or more) of the available options to provide uniqueness and either code around, or inform users about, hardware changes requiring a re-install and/or reconfigure of your software.

The MAC address is not very reliable.
You should use something that cannot be changed such a CPU ID or HDD IDE ID.
Here is want I mean:
http://www.soft.tahionic.com/download-hdd_id/index.html
http://www.soft.tahionic.com/download-hdd_id/hardware%20ID%20programmer%27s%20DLL.html
And to answer your question, Yes, SCSI does not have a hardware ID.

Do you have to think about security or only reliability, i.e. does the user want to tamper your ID check?
If you need (high) security, buy one of the "software protection" products, this is far cheaper than to do it yourself.
No high security required? =>
Another possibility is to use the User or Machine SID. You have to take into account that your application is executed elvated => User is Administrator then.
Last but not least: Write a random value of some bytes into the registry (possibly at various places) under HKEY_CURRENT_USER and use these as an ID.

APIs in C# for grabbing CPU IDs and drive/volume serial

I'm aware that I can grab the CPU identifier and the volume serial number for a physical drive by querying WMI, but WMI usually takes its sweet time. What other speedier options, if any, are available to retrieve this information? Are there Win32 APIs that would accomplish this?
Edit: Allow me to clarify. By CPU identifier, I'm referring to the same value one gets by querying the following WMI instance properties:
Win32_Processor::ProcessorId
Win32_LogicalDisk::VolumeSerialNumber

Just keep in mind that ID of the CPU is not always available.
By the way, what are you trying to accomplish? If you want to generate a unique key for a computer instance, check the Generating Unique Key (Finger Print) for a Computer for Licensing Purposes post by Sowkot Osman at Codeproject; it can give you some hints (also read comments).

You can query the windows registry for the drive information, not sure about the CPU though. It seems that your question is addressed in this SO q/a (demonstrates a number of methods to get this info, but for speed, maybe getting it from registry is your best bet):
How to list physical disks?

WMI actually takes a good portion of its data from the registry. The system stores plenty of information in there about the system, and it's obviously very quick to respond.
If you're looking to lock to the motherboard, CPU and/or HDD for licensing reasons, check out the following values:
HKLM\HARDWARE\DESCRIPTION\System\BIOS\BaseBoardManufacturer
HKLM\HARDWARE\DESCRIPTION\System\BIOS\BaseBoardProduct
HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0\Identifier
HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0\ProcessorNameString
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BuildLabEx
HKLM\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\0\DiskController\0\DiskPeripheral\0 (may be specific to boards with RAID in use)
If you want to get the disk serial without WMI, issue a DeviceIoControl call to the physical drive device. Sample code in VB.NET: http://www.dreamincode.net/code/snippet429.htm

I like GetSystemInfo but that doesn't cover physical drives..