if you look at the source for the COM version I posted, I had to resort to temporarily copying the product key to the default product key registry key. judging by the disassembly of sppcomapi.dll the function Code: CProductKeyUtilsT<CEmptyType>::BinaryDecode(uchar const *,ulong,ushort * *,int *) could be part of a COM interface, but does not appear as a member of any of the public interfaces I think it could be accessed just not in a generic COM way.
@ nononsence Not a bad workaround. Now I'm not sure which method I prefer as they both have pros and cons
The SLIC is valid. The SHA-256 hash of the message E5EEF1B9437A788F653485DACD6237B4997AF9161C4C00C7D3ABEFE936429226 matches the Digital Signature data, the Public Key Exponent data and the Public Key Modulus data. So I assume the key might be valid, too. And yes bytes at offset 14h-16h represent the entire module length. 18h-1Ah represents module body length. (Offset 18h till end) Bytes at offset 10h and 11h must be sums. Set both sum bytes to 00 at offset 10h and 11h to calculate them. Offset 0-16h 8 bit sum range and operate 'NOT' +1 and you get sum at offset 10h. (must be set that 0-16h without sum at offset 11h sums to zero) Offset 18h till end 8 bit sum range, operate 'NOT' +1 and you get sum at offset 11h (must be set that module body sums to zero) Hmm it reminds me of a module of Phoenix BIOS new structure. Have to check that later.....lol I have figured what's about Phoenix new structure headers but I can't remember it right now, lol I guess I am getting old. The entire module 8 bit sums to F8, that's why it reminds me at Phoenix modules, lol.
Whatever you will emulate it will be pointless for hardware-specific on-line activation (which OA3.0 supposedly is).
This comment reminds me of how many times long term members here dicsussed Loaders versus BIOS modification / SLIC insertion. The amount of times it has been mentioned theat all M$ would have to do is make activation hardware specific. Now look what they've gone and done...... Someone came here from M$ and learned how to secure their OS.
It's hard to believe in MDL's fault here, as far as even SLIC's patent states that signed info in SLIC ACPI table should include hardware hash. MS preferred to ignore this aspect of SLIC's specification, probably to make things easier for OEM's at that time, thus made the entire OA2.0 a bit senseless and got expanding piracy as the result. Why they didn't fix it after Vista in Win7 is a mystery, probably also some marketing reasons. What exactly is going to be implemented in OA3.0 is still a puzzle, there should be a patent for MSDM ACPI table already out there though.
Well the major 'issue' isn't the hardware hash and it's still not clear if hardware hashing is a part of OA3.0. It's the fact that they are using unique keys now. So mimicking could be still a way, but it all depends on how often and at which circumstances M$ will allow reactivation of the own legit licenses. Also when blacklisting such a unique serial, they have to keep in mind that they always disable the legit machine as well. So I guess there is something else we all don't know about. It could be remote access to the UEFI related modules when validating, to write in a own signature. This all would make sense if the MSDM table hadn't been found at BIOS also. Phone activation could become an interesting part.....
Curois for your bitlocker picture. I have BitLocker installed on my laptop and I forgot to disable it before updating my backup and I had to enter the key also. But on my laptop, the screen was a Dos-style white on black text and didn't allowed me to use the number keys. Only F1 to f10 was allowed. Are-you using UEFI?
Found some info regarding Microsoft Software Licensing Tables (SLIC and MSDM). Below is an extract from the post. Unable to post the link cause I'm new. Just google and you will find the link. Maybe this explains something about OA3.0? This specification defines the format of the software licensing (SLIC) table and the Microsoft Data Management (MSDM) table, used in platform firmware to enable Windows software licensing. The next version of Windows, code-named Windows 8
Microsoft Software Licensing Tables (SLIC and MSDM) In this white paper there is info regarding MSDM table as follow, The ACPI MSDM table defines the information necessary to enable individualized OEM activation. OEMs must be licensed for Microsoft OEM Activation licensing program and receive the approved licensing information prior to any ACPI work. The payload of the table starting at offset 36 is expected to be provided by a Microsoft-developed tool, and OEMs are advised to collaborate with their motherboard and/or BIOS vendors to construct the entire table and inject it into ACPI. hxxp://msdn.microsoft.com/en-us/library/windows/hardware/hh673514.aspx