The problem with this approach is that the file can be copied to another computer and the same unlock key can be used there as well.
And re-installation on the same machine (after a factory reset) would seem like a new computer, even though it’s the same, etc.
reFX and adam are totally right, its not really a machine ID.
Just a workaround thats quick, dirty and really not that great.
I only used it for analytics stuff.
We use a combination of CPU, BIOS, and memory metrics to generate a fingerprint that does not change even between OS installs.
On Intel CPUs, you must be very careful what flags to mask out, as some of them differ between performance and efficiency cores (Alderlake onward). It’s hard to get right and requires lots of trial and error. We purchased multiple weird/outdated systems for testing, which was still a nightmare.
Thank you all for your votes. We have a new machine ID implemented here:
We have also deprecated a few functions that no longer provide reliable, device-specific, identifiers.
Omg happy day thank you JUCE team!!!
Great! There’s multiple
// Please tell someone at JUCE if this occurs
in the code. This makes me feel somewhat uneasy about how much testing went into the new unique ID. Obviously this is a very sensitive area - if something goes wrong, customers are going to be extremely unhappy.
Which is why you should tell someone at JUCE you hit the jassert
You can blame me for that one. I tested as much as I could with the hardware we had available.
The IDs are unique. That assertion lets us know if the methods used for said IDs are unavailable on a particular platform.
This stuff is really hard to test – but if these are stable through windows upgrades and never dependent on network cards – it will be a huge improvement!
That’s not the only goal. They also need to stay stable as much as possible after hardware swaps and all kind of updates.
On Linux the fallback if no board serial can be found the fallback is to use the bios date and version. That probably means the hash changes if the BIOS is updated in that case - and multiple identical machines without board serial running the same BIOS version will produce the same hash.
On windows a table of the bios is read and up to 1024 bytes are hashed. I assume this contains a hardware UUID not overwritten by bios updates, but is there any guarantee the hash of the table won’t change on (larger) bios updates?
I apologize for being such a nitpicker, but customers are also very picky if unlocks fail.
Some changes to the underlying system are going to invalidate the ID. Linux will resolve to BoardSerial + CPU or Boardinfo + CPU.
Windows reads the RSDT table, which is unique to aspects of that machine; it will persist across Windows installs but will be invalidated if you change the motherboard/CPU.
Ideally I would have used the same method on Linux but it requires extra packages installed to query that information.
Updating the BIOS is potentially going to invalidate the ID but changing HDD, GPU, and RAM is not. (In my testing, anyway). This is somewhat unavoidable as it’s one of the very few stable data sets available that persists across different operating systems and hardware changes.
the changelog says:
data = call ("cat /sys/class/dmi/id/bios_date") + call ("cat /sys/class/dmi/id/bios_release") + call ("cat /sys/class/dmi/id/bios_vendor") + call ("cat /sys/class/dmi/id/bios_version");
That’s not Boardinfo, but Biosinfo.
On Windows, there is a small section of the bios that does not get overwritten on bios updates, containing the board serial. Ideally the hash would be based just on that. Unfortunately I don’t know exactly how to locate that part and documentation is bad for these kinds of things. That would make things work more like OSX and Linux (if board_serial doesn’t fail) and imho would be the right way to go.
The windows approach with hashing an entire bios table feels like too blunt a weapon.
Bios updates unfortunately are a common thing on windows, with the new kind of exploits showing up that need bios fixes, and many machines shipping with bananaware bioses.
Sorry yes, Typo.
There’s no guarantee a BIOS update wouldn’t clobber parts of the table we rely on even if we parsed it, and some manufacturers don’t fill out all the board info. It’s not uncommon to see all zero serial number fields etc.
While this method is quite a ‘blunt’ approach, it does give us a unique snapshot of data that we can use to generate a hardware unique ID.
Tentatively in a couple of weeks, but we have some other, more disruptive, changes landing that might push that back a bit.
Ah, I didn’t find this thread, linking my request here:
The new Unique Machine ID implementation looks great.
I’m just wondering about the Mac version, if there’s a particular reason you extract the uuid via ioreg in a child process, instead of calling the gethostuuid() function (available in <gethostuuid.h>)? For me they give the same results, but there might be an issue with using that function that I’m not aware of?
Thank you so much, guys, this is going to save a lot of customer support!
Documentation for ‘gethostuuid’ appears to be a bit thin, it could also potentially be deprecated (it’s also possible I’ve just missed the docs for it).