>My client wants his software protected from theft (perhaps by an employee selling a copy to a competitor) by blocking it from running unless it is being run from the User’s computer that it is currently running on. I have the logic all worked out, but when tying it by referencing the CPU ID, some of my client’s machines returned the same ID as first stored (encrypted) in a dbf, and on a following run, returned a different ID … so the valid user computer (in some cases) failed to allow the program to run. I’ve since read that CPU ID can do this, and so to avoid it.
>
>I’m now looking at tying to the Serial Number of the motherboard, and found some nice code samples for motherboard S/N, CPU ID, and Hard Disk S/N at http://www.foxite.com/archives/cpuid-and-motherboardid-0000396340.htm by Pete “the IceMan”, but others say it’s better to call the Windows API (working across all Windows versions) rather than the WinMgmts that he uses (but I don’t have any sample API approach code for motherboard S/N to work with anyway). Still others say that BIOS settings can block the motherboard S/N from even being available to me.
>
>I’m almost there, but still just a little short on picking my route. I’m hoping to have a solution that works across all current platforms, including Windows 10, and in both 32 and 64 bit environments. Any thoughts.

I can think of 3 general approaches:

1. Microsoft considers a "hardware hash" good enough for Windows activation: https://technet.microsoft.com/en-us/library/Bb457054.aspx . I don't know how they calculate the individual components. This has some flexibility to accommodate legitimate hardware changes or upgrades.

As you point out, the trend in hardware is to lock down so user processes may not be able to access functions they formerly could. Some hardware attributes such as network card MAC address can be changed programmatically, so may not be reliable for antipiracy purposes.

All hardware hashes will run into problems with virtual machines. Virtual hardware is malleable (for better or for worse depending on your requirements).

2. Hardware key (aka "dongle"). This is the problem these devices are meant to solve. None are 100% foolproof but most are hard to crack. These cost money but if your client is really serious about protection you should look into something like this.

3. Software hash. One thing I've sometimes recommended to deter casual copying is to use the computer's NetBIOS name, which is available as part of SYS( 0 ). You can combine this with other things such as the date/time of the $Recycle.Bin on drive C:, various Registry values such as ProductId and InstallDate in HKLM/Software/Microsoft/Windows NT/CurrentVersion, etc. You can combine all of these values, run them through a hash function and store the digest somewhere. Some of these values can be changed by a pirate but doing so can cause other problems and so are generally a PITA to change even if the pirate knows which values to change. If you're storing a digest, from that the pirate can't determine the values needed even if s/he knows which items need to be hacked and manages to decompile your app.

I think for many purposes a well-thought-out software hash should be as good as a hardware hash and doesn't have the hardware hash's drawbacks.