So Windows 10 now has the ability for any application to get system-unique tracking identifiers that persist across reinstalls by storing them in the TPM or UEFI firmware variables...
To add insult to injury, the APIs lead into clipc!GetOfflineDeviceUniqueID, which calls into a licensing-related service which would be obfuscated by Warbird...
"The identifier returned by this method is specific to a user on the current device and allows for correlation of usage across different applications running on the same device for a particular user."
To others who follow me and who think my hatred of UEFI is unjustified, . . .
To reiterate, I personally refuse to run UEFI on my Kestrel computers, and I refuse to trust ANY computer with UEFI baked into firmware, now and forever more.
Any computer equipped with UEFI is to be considered no more than a mere appliance, a convenient means to an end at best. This includes all Linux and BSD machines as well. They are not to be trusted otherwise.
UEFI tries to not only serve as a glorified boot loader, but indeed, also a small OS unto itself, and then there's the whole TPM racket. And, IIRC, UEFI also has components that run in negative rings, which means even with OSes that take over the hardware, it's always running.
@slipstream @samis Both ARM and x86 are lost causes as far as I'm concerned (certainly AArch64, if not 32-bit ISAs as well). This is in large part why I chose RISC-V for the Kestrel project, as it's one of the few open standards that gives me complete and total autonomy in building the hardware and system software for it. With the whole stack being MPLv2, I hope it'll attract folks who are trust-conscious with their platforms.
@vertigo @slipstream The problems with BIOS is that at this point it's a pile of backwards compatible hacks, and while UEFI is too complex for it's own good (I agree that it's basically an OS itself), it has the advantage of being able to make a clean break.
My ideal world is one where both are dead, replaced by a different architecture more inspired by coreboot and OpenFirmware.
Here's a quick proof-of-concept of clipc!GetOfflineDeviceUniqueID.
uses a zero-length salt,
uses salt "salt"
uses salt "\x12\x34".
@newt yes, but the *real* api used here is clipc!GetOfflineDeviceUniqueID, so just hook that? see: https://gist.github.com/Wack0/663dc0a91056cf4431365f77036f3bf3
So apparently the "intended audience" for these "system-unique tracking identifiers that persist across reinstalls" APIs is mobile device management.
If so, then why add it to OneCore and include a seperate codepath for Xbox One?! (Also, just allowing the "real" API to be called by anyone...)
@MightyPork it also sounds like a fine identifier for things like "network investigative techniques" to use
also, i should go try calling it in a low-integrity Chrome/Edge process. if that works then one can theorise that adtech scum might use browser code exec sploits just to get their hands on such identifiers...
It turns out that clipsvc.dll is NOT obfuscated by Warbird, and public symbols are on MS's symbols server?!
The "offlinedeviceuniqueID" is SHA256(salt.identifier) where "identifier" is one of the following:
* TPM public endorsement key.
* OfflineUniqueIDEKPub UEFI variable, from namespace eaec226f-c9a3-477a-a826-ddc716cdc0e3
* OfflineUniqueIDRandomSeed UEFI variable (from the same namespace)
* in RS2+: Registry entry HKLM\System\CurrentControlSet\Services\TPM\ODUID\RandomSeed
If the calling process is IL=Low or in an AppContainer (not sure which), you cannot pass a zero-length salt; but this is checked by the usermode clipc.dll and not the remote service clipsvc.dll (which runs as SYSTEM). So to work around this I guess the best way would be to call into clipsvc yourself.
As for those four identifiers, the worst one would be the TPM public endorsement key, that can't ever be changed...