I guess you need to cut it. Start MSDM string, length 85 bytes as always....I bet it's one with that dummy key.
If thats the way, then here it is: Code: MSDMU.....GBT GBTUACPI1.0BGBTU.....................................................DSDT&J...DGBT GBTUACPI....MSFT.....O.\_PR_[ƒ.\
You've dumped a part of the DSDT as well. Nevermind, that MSDMTable at the ACPI.BIN module is 'empty'. I wonder if OA3.0 still requires a SLIC and a certificate as well...
Yes you are right, since each machine has to be licensed with a unique key, you never will find a complete MSDMTable at a special place somewhere at the BIOS(update), but at ACPITable memory. I wonder if the way how to apply the key is also a fixed part of the OA3.0 specifications. If yes then there might be some additional checks....(from where do the key data actually come)....
Hi, just out of curiosity. What is the state of the activation attempts (if any)? Or how does the process goes compared to W7? I'm a noob when it comes to biosmods, I know a little bit about bootloaders but that doesn't cut it.
No attempts so far. It's not advisable to try before RTM as always. The major changes are: There will be no more offline activation method, no more generic OEM keys but there will be unique hardware hashing / serials at OA3.0. There will be a additional MSDM ACPITable which holds the serial.... I guess it will happen the same when w8 is RTM'ed: Frankenbuild attempts (mixed files from RC). IMHO it is not worth to find an activation method. It will end in a cat and mouse game since w8 files need to be modified.... I'd just would apply unlimited rearm, if I use it, but I won't... Anyway I want to know how OA3.0 works...
It sounds like you are up for the challenge Nononsence. I guess anything that can be done , can be undone or emulated ! We will see soon enough I guess
I have been looking at how the OA3 module in newer ASUS firmware works, the MSDM table is boring pulls the product key out of storage and constructs the MSDM acpi table, same with the SLIC table BORING. the two interesting things it does, it uses an undocumented extension to the SMBIOS protocol to do ??? (add or retrieve something) and also adds ??? to the legacy memory region this also could turn out to be boring like add the OemId to the SMBIOS table and SLP 1.0 string to the legacy memory region. It still maybe possible to inject some data from a donor machine into memory (or other hacker tricks) and get past the new product key restriction, but wouldn't Microsoft notice if the same machine was activated a million times from places all over the world? anyone that figures out an exploit will likely keep it to themselves.
Interesting case Does it mean that WCP can be activated via a KMS host?? Then there must be a GVLK key for WCP. Or its a simple typo by MS.
@nononsence As I had written #512 the MSDM table won't be a problem "To create a valid MSDM table from a known key and to inject it into a EFI is not the problem, I guess." The problem might be the hardware hash / signature which belongs to the machine and is stored as computer build report CBR (will work as new certifiate)......also if the key comes from NVRAM could be verified.... There are some inconsistencies. Either OA3.0 is only OA2.1 plus the MSDMTable or it is with hardware hashing additionally, created as CBR.(XML file) I guess the latter is true. At a fresh install the CBR might be verified...it also might be the preinstalled licenses are already activated. So the CBR might be the 'new' certificate, also unique then.
I guess our only chance is to take a genuine but not yet activated machine, let it activate and capture all network packages from and to MS and then see what happens. Check what's read from and written to where and when. Network traffic might be encrypted but then still that key must be somewhere on the machine to decrypt it. Then another question: if MS plans to disable activation, do they replace core files with new versions or is there an off switch for OA3?
There is a lot of unused space in the MSDM table I thought it may contain more data, that may have not been installed on the machines we were seeing in the wild yet, but so far that is not the case. the last bit of the OA3 module seems to be looking at the OEM strings record in the SMBIOS table and then if found add it to legacy memory, my guess this is the SLP string.