I need to write a function that generates an id that is unique for a given machine running a Windows OS.
Currently, I'm using WMI to query various hardware parameters and concatenate them together and hash them to derive the unique id. My question is, what are the suggested parameters I should use?
Currently, I'm using a combination of bios\cpu\disk data to generate the unique id. And am using the first result if multiple results are there for each metric.
However, I ran into an issue where a machine that dual boots into 2 different Windows OS generates different site codes on each OS, which should ideally not happen.
For reference, these are the metrics I'm currently using:
Win32_Processor:UniqueID,ProcessorID,Name,Manufacturer,MaxClockSpeed
Win32_BIOS:Manufacturer
Win32_BIOS:SMBIOSBIOSVersion,IdentificationCode,SerialNumber,ReleaseDate,Version
Win32_DiskDrive:Model, Manufacturer, Signature, TotalHeads
Win32_BaseBoard:Model, Manufacturer, Name, SerialNumber
Win32_VideoController:DriverVersion, Name
I had the same problem and after a little research I decided the best would be to read MachineGuid in registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography, as #Agnus suggested. It is generated during OS installation and won't change unless you make another fresh OS install. Depending on the OS version it may contain the network adapter MAC address embedded (plus some other numbers, including random), or a pseudorandom number, the later for newer OS versions (after XP SP2, I believe, but not sure). If it's a pseudorandom theoretically it can be forged - if two machines have the same initial state, including real time clock. In practice, this will be rare, but be aware if you expect it to be a base for security that can be attacked by hardcore hackers.
Of course a registry entry can also be easily changed by anyone to forge a machine GUID, but what I found is that this would disrupt normal operation of so many components of Windows that in most cases no regular user would do it (again, watch out for hardcore hackers).
With our licensing tool we consider the following components
MAC Address
CPU (Not the serial number, but the actual CPU profile like stepping and model)
System Drive Serial Number (Not Volume Label)
Memory
CD-ROM model & vendor
Video Card model & vendor
IDE Controller
SCSI Controller
However, rather than just hashing the components and creating a pass/fail system, we create a comparable fingerprint that can be used to determine how different two machine profiles are. If the difference rating is above a specified tolerance then ask the user to activate again.
We've found over the last 8 years in use with hundreds of thousands of end-user installs that this combination works well to provide a reliably unique machine id - even for virtual machines and cloned OS installs.
Parse the SMBIOS yourself and hash it to an arbitrary length. See the PDF specification for all SMBIOS structures available.
To query the SMBIOS info from Windows you could use EnumSystemFirmwareEntries, EnumSystemFirmwareTables and GetSystemFirmwareTable.
IIRC, the "unique id" from the CPUID instruction is deprecated from P3 and newer.
What about just using the UniqueID of the processor?
I hate to be the guy who says, "you're just doing it wrong" (I always hate that guy ;) but...
Does it have to be repeatably generated for the unique machine? Could you just assign the identifier or do a public/private key? Maybe if you could generate and store the value, you could access it from both OS installs on the same disk?
You've probably explored these options and they doesn't work for you, but if not, it's something to consider.
If it's not a matter of user trust, you could just use MAC addresses.
You should look into using the MAC address on the network card (if it exists). Those are usually unique but can be fabricated. I've used software that generates its license file based on your network adapter MAC address, so it's considered a fairly reliable way to distinguish between computers.
For one of my applications, I either use the computer name if it is non-domain computer, or the domain machine account SID for domain computers. Mark Russinovich talks about it in this blog post, Machine SID:
The final case where SID duplication would be an issue is if a distributed application used machine SIDs to uniquely identify computers. No Microsoft software does so and using the machine SID in that way doesn’t work just for the fact that all DC’s have the same machine SID. Software that relies on unique computer identities either uses computer names or computer Domain SIDs (the SID of the computer accounts in the Domain).
You can access the domain machine account SID via LDAP or System.DirectoryServices.
In my program I first check for Terminal Server and use the WTSClientHardwareId. Else the MAC address of the local PC should be adequate.
If you really want to use the list of properties you provided leave out things like Name and DriverVersion, Clockspeed, etc. since it's possibly OS dependent. Try outputting the same info on both operating systems and leave out that which differs between.
There is a library available for getting hardware specific informations: Hardware serial number extractor (CPU, RAM, HDD, BIOS)
Maybe cheating a little, but the MAC Address of a machines Ethernet adapter rarely changes without the motherboard changing these days.
Can you pull some kind of manufacturer serial number or service tag?
Our shop is a Dell shop, so we use the service tag which is unique to each machine to identify them. I know it can be queried from the BIOS, at least in Linux, but I don't know offhand how to do it in Windows.
I had an additional constraint, I was using .net express so I couldn't use the standard hardware query mechanism. So I decided to use power shell to do the query. The full code looks like this:
Private Function GetUUID() As String
Dim GetDiskUUID As String = "get-wmiobject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID"
Dim X As String = ""
Dim oProcess As New Process()
Dim oStartInfo As New ProcessStartInfo("powershell.exe", GetDiskUUID)
oStartInfo.UseShellExecute = False
oStartInfo.RedirectStandardInput = True
oStartInfo.RedirectStandardOutput = True
oStartInfo.CreateNoWindow = True
oProcess.StartInfo = oStartInfo
oProcess.Start()
oProcess.WaitForExit()
X = oProcess.StandardOutput.ReadToEnd
Return X.Trim()
End Function
Look up CPUID for one option. There might be some issues with multi-CPU systems.
Try this one, it gives a unique hard disk ID: Port of DiskId32 for Delphi 7-2010.
Related
We are using Turbo.net for Publishing applications. One of this application (designed by our own Company) uses a Broadcast to find devices in the Network and then get a reply by a dynamic UDP Port (30000 - 50000). Opening all These ports on the Windows Firewall is not an Option.
I have therefore tried to specify the exe file in the Windows Firewall. That works but the Problem is, I Need to do this for 200 users. So I want to do this by GPO. Unfortunately the path to the exe is something like this:
%userprofile%\AppData\Local\Spoon\Servers\apps.elpro.com\Users\Firstname.Lastname.Domain\Sandboxes\ECOLOGPROModuleConfigurator__1-4-8-420__en-us__Default__AnyCpu\local\stubexe\0x4D80DB43F65B57C8\ PROModuleConfigurator.exe
The problem is "\Firstname.Lastname.Domain\". I was not able to find a way to use a wildcard for this in the Windows Firewall.
It seems that Windows-Firewall does not allow Wildcards.
Is there an easy fix for this or do I Need to script something and if how?
Thank you!
The fact that it can handle %userprofile% tells you that it's okay with Windows variables, so the thing to do would be to set up more such variables, to pass this path as %userprofile%\AppData\Local\Spoon\Servers\apps.elpro.com\Users\%Firstname%.%Lastname%.Domain\...
Sorry there's not a copy-paste solution for you. It would take some scripting on your end to pull this name data out of Active Directory (or some Linux/Unix LDAP server – whatever your organization is using) and fill these variables on a per-user basis. On the up-side, the variables could have other uses once you get them set up, like naming backup directories on a NAS in %Lastname%, %Firstname% format, and so on.
Exactly how to do this will vary by coding language, by OS version, and by directory service type. The information about this is scattered far and wide, so you'll have to search around a bit. E.g., for how to get an AD user's real names with C# under dotNet 3.0+, see this StackOverflow thread. And there are lots of SO threads with info on using Get-ADUser in Powershell to find and filter by user's IDs and names. This thread on SpiceWorks might also be of interest.
You'll almost certainly need Remote Server Administration Tools (RSAT) for Windows (see that page for installation details, which are totally different depending on OS version, even within Windows 10!). Tools that deal with ActiveDirectory need the AD stuff in RSAT to do their work, including both Powershell and C#.Net. RSAT requires Windows Pro or Enterprise (on the machine you're going to use to do the AD work; user workstations can be any version). But AD itself requires Windows Server.
This is only going to be doable with an Active Directory or other LDAP server, in which this user firstname/lastname information, as such, is even stored. Local accounts do not have this information at all except when they inherit it in munged "full name" form, e.g. from Microsoft.com account credentials. In Powershell, you can run 'Get-LocalUser | Select *', or follow the more "deep dive" local-ADSI method demonstrated here, and you'll find no first and last name data. It's just not part of an account, absent some systemic means (AD, or Microsoft online account connection, or Microsoft Family Group management, etc.) of injecting it. There are multiple ways of manually adding "full name", but even doing this across a bunch of users probably would not help you, since human names are not easily software-parseable into first name and last name (Many people have two last names, and many have two or more given names; so what is "Pat Morgan Otero"? And of course given-name versus family-name order varies culturally.) There appears to be no way to add separate first and last name fields to local accounts; tools like Set-LocalUser cannot do it.
[aside]There's no connection between Windows user data and Windows Subsystem for Linux user data (even the usernames can be different), so that's no help. If you have a network-wide unified user ID system via LDAP or whatever, and it has an end result of everyone's user IDs and their real names being in account information under any Linux/Unix system on your network (print server, NAS, anything you can get privileged shell access to), then you might have an easier go of it, given the text-processing tools available to bash in Linux/Unix (including macOS), like grep and sed and awk. All you'd need is a command-line tool for accessing LDAP (or whatever) to run directory queries, then parse the results for name information. Or that name info might even already exist in that Linux box's passwd file. This was how I did something similar for one client, but it was a Linux-heavy shop. If you have any (or most) users isolated from Linux in a Windows-only sphere of users, then this approach would not work.[/aside]
It looks like accessing AD data (or LDAP, whatever) in Windows with Windows-based scripting/programming is the only certain way to do what you want to do. Even then, it will only work if the data is present and correct. You'd need group policy that doesn't permit people to change their names (e.g. by removing their surname) once their account is configured, and human procedural rules that admins must enter this data when setting up accounts, and that it be correct and complete (not missing surname, and not be placeholder or role data that might be substituted out later or might even occur on multiple machines).
PS: Ultimately, I think you should write to the creators of that software and ask them to stop using first and last names in paths, as it breaks the administrability of their product.
I am using snmpwalk for retrieve my system(localhost) or remote system's mac address and I am using this command:
snmpwalk -v2c -c public localhost .1.3.6.1.2.1.2.2.1.6
and get an error like noSuchObject.
How can I solve this error? Is there another way to get system mac address using snmp?
There is no such thing as "system MAC address". Systems do not have MAC addresses; network interfaces do, and a system may have zero, one, two or more network interfaces.
That's why you use snmpwalk: because .1.3.6.1.2.1.2.2.1.6 (i.e. ifPhysAddress) is a column in a table of interfaces and you don't know in advance how many conceptual rows you'll get back (and what unique numerical index each row will use as its key).
So, you're using the command properly. But next we have to consider that times have changed since the SNMP and SMI RFCs were written, well before the dot-com boom and back when the internet was a relatively pleasant and happy place. Nowadays, implementations tend to be far more conservative in the information they disclose, because every piece of information you disclose is potentially another way to attack your system. Why does anyone need access to know your system's MAC address? They probably don't. I created an SNMP Agent recently and its support for "standard" objects doesn't go anywhere near listing network interfaces. And many of the RFC1213 packet/status counters in snmp were deliberately made obsolete when a "safe" subset was adopted into RFC1907.
What does this mean for you? Well, the remote system must have a network interface otherwise you wouldn't be able to talk to it. So, the SNMP Agent you're polling/querying (you didn't say which) is either hardcoded or configured not to provide this information. You can't get around that, except by talking to the person who created the software and asking whether it is configurable; prepare for the answer to be "no".
I would like to develop an application that can connect to server and uniquely identify clients then give them permissions to run a specific query on server's database.
How can I identify clients in a unique way. Is MAC address reliable enough? or should I use something like CPU id or something else?
clarification : I do not what to create a registration code for my app. As it's suppose to be a free application. I would want to detect each client by an id and decide which one could have the permissions to run a specific method on server or not.
The usual approach is to give each client a login (name + password). That way, it's easy to replace clients when they need upgrade or when they fail.
MAC address should be unique but there is no central registry which enforces this rule. There are also tools to change it, so it's only somewhat reliable.
CPU and HD IDs are harder to change but people will come complaining when their hard disk died or when they upgrade their system.
Many PCs have TPM modules which have their own IDs but they can be disabled and the IDs can be wiped. Also, there are privacy issues (people don't like it when software automatically tracks them).
Another problem with an automated ID approach is how to identify them on the server. When several clients connect for the first time in quick succession, you will have trouble to tell them apart.
This question appears to have already been asked and answered in detail (although, you may not like the answers, since they appear to add up to: it's problematic.) I agree with Xefan's comment that more details would help define your question. Here's a link to earlier discussion on this:
What is a good unique PC identifier?
Question: I have to come up with unique ID for each networked client, such that:
it (ID) should persist once client software is installed on target computer, and should continue to persist if software is re-installed on same computer and same OS installment,
it should not change if hardware configuration is modified in most ways (except changing the motherboard)
When hard drive with client software installed is cloned to another computer with identical hardware configuration (or, as similar as possible), client software should be aware of that change.
A little bit of explanation and some back-story:
This question is basically age old question that also touches the topic of software copy-protection, as some of the mechanisms used in that area are mentioned here. I should be clear at this point that I'm not looking for a copy-protection scheme. Please, read on. :)
I'm working on a client-server software that is supposed to work in a local network. One of the problems I have to solve is to identify each unique client in the network (not so much of a problem), so that I can apply certain attributes to every specific client, retain and enforce those attributes during the deployment lifetime of a specific client.
While I was looking for a solution, I was aware of the following:
Windows activation system uses some kind of heavy fingerprinting mechanism that is extremely sensitive to hardware modifications,
Disk imaging software copies along all Volume IDs (tied to each partition when formatted), and custom, uniquely generated IDs during installation process, during first run, or in any other way, that is strictly software in its nature, and stored in registry or on hard drive, so it's very easy to confuse two.
The obvious choice for this kind of problem would be to find out BIOS identifiers (not 100% sure if this is unique through identical motherboard models, though), as that's the only thing I can rely on that isn't duplicated, transferred by cloning, and that can't be changed (at least not by using some user-space program). Everything else fails as either being not reliable (MAC cloning, anyone?), or too demanding (in terms that it's too sensitive to configuration changes).
Sub-question that I'd like to ask is, am I doing it correctly, architecture-wise? Perhaps there is a better tool for the task that I have to accomplish...
Another approach I had in mind is something similar to a handshake mechanism, where a server maintains an internal lookup table of connected client IDs (which can be even completely software-based and non-unique at any given moment), and tells the client to come up with a different ID during handshake, if a duplicate ID is provided upon connection. That approach, unfortunately, doesn't play nicely with one of the requirements to tie attributes to specific client during lifetime.
It seems to me that you should construct the unique ID corresponding to your requirements. This ID can be constructed as a hash (like MD5, SHA1 or SHA512) from the information which is important for you (some information about software and hardware component).
You can make your solution more secure if you sign such hash with your private key and your software verify during the starting, that the key (signed hash value) is signed (only public key must be installed together with your software). One can expand such kind of solution with different online services, but corporate clients could find online services not so nice.
What you're looking for is the Windows WMI. You can get the motherboard ID (which is unique across the same type of motherboard) or many many other types of unique identifiers and come up with some clever seeded function to generate a UHID. Whoa did I just make up an acronym?
And if you're looking specifically for getting the Motherboard (BIOS) ID:
WMI class: Win32_BIOS
Namespace: \Root\Cimv2
Documentation: http://msdn.microsoft.com/en-us/library/aa394077(VS.85).aspx
Sample code: http://msdn.microsoft.com/en-us/library/aa390423%28VS.85%29.aspx
Edit: You didn't specify a language (and I assumed C++), but this can be done in Java (with a COM driver), and any .NET language, as well.
Many programs use the hostId in order to build a license code (like those based on FlexLM). Have a look at what Matlab does depending on the operative system:
http://www.mathworks.com/support/solutions/en/data/1-171PI/index.html
Also have a look at this question:
Getting a unique id from a unix-like system
Once I also saw some programs basing their licenses on the serial number of the hard drive, an maybe that is the less likely thing to change. Some would suggest to use the MAC of your ethernet card, but that can be reprogrammed.
MAC
DON'T RELY ON MAC! EVER. It is not permanent. The user can easily change it (under 30 seconds).
Volume ID
DON'T RELY ON Volume ID! EVER. It is not permanent. The user can easily change it. It also changes by simply formatting the drive.
WMI
WMI is a service. Can be easily disabled. Actually, I tried that and I find out that on many computers is disabled or broken (yes, quite often broken).
License server
Connection to a validation server may cause you also lots of troubles because:
* your customers may not always be connected to the Internet.
* your customers may connect with special settings (router/NAT/proxy/gateway) that they need to input into your program in order to let it connect to the validation server.
* they may be behind a firewall that will block all programs except a few (my case). In some cases the firewall may not be under their control (valid for MOST corporate users)!
* it is super easy to redirect your program to a local fake webserver that emulates your licensing server.
Hardware data
If you need strong protection you need to rely on hardware. Something that cannot be edited by the user. Something like CPU ID instruction available in the Intel/AMD CPUs and the serial number written into the drive's IDE interface.
The CPU ID and HDD ID are permanent. They will never change, not even after you format the computer and reinstall Windows.
It is doable. For example this library reads the hardware ID of a computer. There is a compiled demo and also sourcecode/DLL. Disclaimer: the link leads to a commercial product (19€/no royalties).
I'm developing some desktop software for a client to resell. The client wants to restrict the software so that the registration code will be specific to one and only one computer.
Besides using the MAC from the network card, does anyone have any other techniques (that work on both Windows and Mac OS X) for uniquely identifying a computer?
Another solution is to use a licensing technology with a dongle. This is a small device that plugs into USB or another I/O port on the host, and serves as a unique, physical key to activate the software.
A third solution is to provide a license manager. That is, when the software starts up, it queries a server on the network (either on the customer's LAN or else accessed at your company via the internet) that validates that the customer's usage of the software is legitimate. This is a good solution for "concurrent licenses" so customers can install your software on many hosts, but you license it for simultaneous use on a limited number of hosts. FLEXnet Publisher is an example of a license management solution.
The MAC address of the network card is the solution I used last time I worked for a company that licensed software to run on a specific host.
However, I want to offer a caution: if you do this type of licensing, you have to anticipate that it'll become an ongoing administrative chore to track your customers' licenses. Once you have a few hundred customers, you'll be amazed at how frequently you get phone calls with requests to change keys
"We upgraded our server to a gigabit
network adapter, and now the license
won't work because the new adapter has
a different MAC address."
Or else the customers may replace their whole machine, and need an updated license to run your software on the new machine. We got these calls practically every day at the company I worked for.
You also need to trust the customer to stop using your software on the old computer (or network adapter) if you give them a new key. If you couldn't trust them to obey the license in the first place, how can you trust that they'll throw away the old key?
If you don't plan how you're going to support this administrative activity, don't license your product in this way. You'll only inconvenience your good customers, who would have cooperated anyway.
best way is taking the UUID using C# in Windows
The Best Way To Uniquely Identify A Windows Machine
public string GetUUID()
{
var procStartInfo = new ProcessStartInfo("cmd", "/c " + "wmic csproduct get UUID")
{
RedirectStandardOutput = true,
UseShellExecute = false,
CreateNoWindow = true
};
var proc = new Process() { StartInfo = procStartInfo };
proc.Start();
return proc.StandardOutput.ReadToEnd().Replace("UUID", string.Empty).Trim().ToUpper();
}
The idea I am toying with is using a few serial numbers or unique id's related to the hardware and hashing them together.
Things that get upgraded:
-Memory
-MACs (can be spoofed, usb adapters get plugged in, etc.)
Things that don't get upgraded often:
-CPU
-BIOS
-Motherboard
Using WMIC can be a great way to grab some info, I would start by grabbing things that don't change often as the first and preferred choice, I would like to be able to fingerprint at least 2 serial numbers or devices to use for generating a registration key.
wmic cpu get DeviceId /format:value
That will grab the CPU ID, you could run that command for:
1 - CPU (cpu:DeviceID)
2 - Motherboard (baseboard:serialnumber)
3 - BIOS (bios:serialnumber)
if you don't get at least 2 populated values, then grab
4 - Network Adapter - (nic:MACAddress)
5 - RAM - (memphysical:SerialNumber)
Depending on your business logic you can use the first two serial numbers available to create your registration number, and if you always follow the same order then on re-installs the registration number will still work, however if a device changes or a user tries to install on a secondary computer the id's change invalidating the registration number. To reduce the amount of tech support calls the least amount of hardware you fingerprint will give the least amount of headaches and if you try to fingerprint the least likely items to be upgraded that further reduces headaches. My preference is the order above.
You could use a Diffie-Hellman key exchange scheme to have the user generate a private/pulic key pair with their hardware id's as a payload, then pass this information up to a registration server where the registration server would use a public/private key to decrypt the payload and compute the registration key to return back to the end user. I like to use JWT to pass things back and forth witht he public keys included in the payload of the JWT. Hope that helps.
UUID was mentioned above and is a great idea you can get that by using the below command from your windows cmd.exe:
wmic csproduct get UUID /format:value
Disclaimer these command only work for Windows I think 2000 and above but you would need to verify, they maybe available for systems below 2000 but at that point I really try not to support those devices. Good luck. *Looks like WMI is being deprecated in favor of powershell so to keep this post current here are the power shell commands.
Get-CimInstance -ClassName Win32_Processor | Select SerialNumber
Get-CimInstance -ClassName Win32_BaseBoard | Select SerialNumber
Get-CimInstance -ClassName Win32_Bios | Select SerialNumber
Get-NetAdapter -Physical | Where-Object Status -like Up | Select-Object MacAddress
Get CimInstance -ClassName Win32_PhysicalMemory | Select SerialNumber
The network adapter cmdlet will only check for physical adapters so a virtual adapter couldn't be used and manipulated and I like to use the first adapter that is Up or being used so that a spare NIC can't be swapped around for install reasons.
On Mac:
system_profiler | grep "Serial Number (system)"
On Linux (debian):
sudo dmidecode -t system | grep "Serial Number"
dmidecode and system_profiler has other components it can grab serial numbers from similar to wmic in windows. I don't work on macs so I can't confirm a list of exact specs but creating a list of LCD (least common denominator) the serial numbers for the parts that all three commands can access is put together and groomed to the least likely parts to be upgraded or changed. Then a combination of the top 2-3 numbers hashed can make for a unique machine id that's a bit more robust and allows a cross platform app to be activated even on a device with it's operating system updated.
There is no sure way to uniquely identify a computer, if you assume a computer is built with many parts that can be replaced eventually.
Some hardware parts - MAC address, HDD disk serial number, even motherboard serial, etc - are a few good sources of "uniqueness" but as you may know if a client decides to upgrade the part the license depends on... be prepared for some customer support.
Also to keep in mind is that some parts can be spoofed (the MAC being one of them).
An online license check is another good way to go - you can manage everything on the server side and even define your own rules for it (how many licenses per client/install, concurrency, etc) but the big thing to note is what happens when connection can't be established?
I would just use the MAC address to generate a request key, then require users to register with your client. Your client will have a special application that takes that request key and produces an activation key which the user can then use for activating the software. Once activated, the software works, just works - no occasionally phoning home for verification and such.
That's if it were a real requirement. My first task would be to try and convince the client that this was a bad idea.
The reason is that these schemes practically never prevent your code from being cracked. They do however make the lives of your genuine customers harder. I find it hard to think of any other industry that goes out of its way to annoy its genuine customers with schemes that never achieve their goals (other than government service, of course :-).
If you must do this, I'd just do a token effort to meet the contractual obligation (don't tell your client this however). Taking the MAC address (or a random number if, $DEITY forbid, the computer didn't have a network card) as the request key and using a program to just XOR it with an ASCII string to get the activation key, seems like a workable approach. I would also store both keys since you don't want the software to de-activate if they just change their network card (or even motherboard) - they still see that as the same computer and will not be happy if the software stops working.
Your code's going to be cracked regardless (unless the program is rubbish which I'm sure is not the case) - this method will give your genuine customers an avenue for moving their software to another machine if your client's company becomes unresponsive somehow (drops support, goes out of business, and so on).
The main trouble with all schemes that rely on the uniqueness of a bit of hardware is that the customer may choose to change that bit of hardware:
ghosting their disk contents to a larger hard disk makes HD serial numbers change.
using CPU serial numbers means upgrading to the latest Intel bigmutha CPU kill your software.
using the MAC address means they can't change their NIC.
These can all be fixed by using those values to create a key at install time and only check against that key, not the changed value six months down the track. It means you have to store the request and activation values but upgrades will not require your users to go through the process of re-activating their software. Believe me, they will despise you for having to do that.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography
"MachineGuid” key is generated uniquely during the installation of Windows and it won’t change regardless of any hardware swap (apart from replacing the boot-able hard drive where the OS are installed on). I am not sure about this.
MY SUGGESTION
You can Use that MachineGuid, Hard Disk Serial Number, Mother Board Serial Number and UUID. Together HASH it using SHA 256 or any other HASH function.
UUID - wmic csproduct get UUID
MachineGuid - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography
Hard Disk Serial Number - wmic diskdrive get serialnumber
BIOS Serial Number - wmic bios get serialnumber
Mother Board Serial Number - wmic baseboard get serialnumber
How about using MotherBoard unique serial number?
One can create a serial key that the user has to enter once.
It should include the user's eMail address (something like someuser#mailprovider.com-9828372-398232). This will stop many people from trying to tamper with it or give it to other people.
During activation, the software should check against an online db if the serial key exists.
Open up Registry and navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography
Find the key called “MachineGuid” this key is generated uniquely during the installation of Windows and it won’t change regardless of any hardware swap (apart from replacing the boot-able hard drive where the OS are installed on). That means if you want to keep tracking installation per OS this is another alternative. It won’t change unless you do a fresh reinstall of Windows.
There used to be a serial number imprinted into the CPU's, as far as I have seen though; this information (PSN, Pentium Serial Number) has been deprecated. The information may possibly still exist, but at least in the P3 world it was gone. Also, I think the obvious choice of MAC address on the NIC for the main interface used for the host should be considered as a real possibility. Unless your client is not expecting ethernet interfaces to be present on the hosts that they sell to.
You might consider a third-party licensing utility which will more likely get this "right" and also provide you (or your client) with additional options should requirements change (and don't they always?). I'd mention some specific ones by name, but I'm really not intimately familiar them.
I have some experience on this. In my solution we issue service key when we sell the product to the client.
At the time client install the application it generate a key by reading the motherboard serial of the client machine. Client is supposed to email the service key and the key generated at the installation to our organization to activate the product.
We maintain an admin application at the organization at issue activation keys. We offer only one activation key for key for a particular service key.
We sold number of copies and it runs without an issue. But then we found out some computers that does not provide a motherboard serial number. Those machines return null value as the motherboard serial number. still we trying to fix this issue.
Or you could simply have no activiation code and ensure you have audit rights written into the EULA and exercise your right to audit from time to time.
Works wonders for Oracle.
how about hashing anything that has a burned-in SN, harddrive, proc, ram, etc... this hash will remain with the computer until it has it's parts replaced.