So... the contents of the msdm table is derived from the key (maybe from unique hardware hash too)? Will windows send the key and/or table to homebase? If not: let's take any key and create own msdm But not sending the key home renders the whole unique key thingy useless... But what about offline activation then?
Yen posted this image a while ago, I would speculate that the CRC value and the abbreviated authenticator value will end up in the MSDM table, if they are generated in a firmware module then it might be possible RE the process. the secret key will be the hard part. unfortunately I expect abbreviated authenticator value and serial number to be generated else where, and the CRC value to be generated by the firmware, possibly even using some information unique to that machine like S/N of the PCH.
Do I get this right? From a unique 5x5 key the OA3tool.exe creates a bin file. This bin file is used by the OEM to be written into the e.g. UEFI’s NCB (non critical block) by using e.g. the /A switch of AFU tool. Also the OAtool creates a XML file with a 128bit hardware hash. The serial+the HWH build the CBR (computer build report, a XML file). This report will be send to M$ by the OEMs for each device. At first boot of the preistalled device a EFI module gets the serial (reads it from a defined place, e.g. NCB.), builds the MSDM table (triggered by SMI call), builds the HWH and compares them (the OS might compare that) with the data of the CBR stored at the M$ server. If they match the system is activated. After each boot the HWH and the MSDM table are created newly. The HWH is stored on HDD (UEFI partition?), the MSDMtable found at acpi namespace. To create a valid MSDM table from a known key and to inject it into a EFI is not the problem, I guess. Unique serial plus unique HWH all stored at a M$ database = end of OEM mimicking and start of total control. It had been mentioned a database would end the game. Who needs w8 at all?
I found a module that generates an MSDM table in ASUS P8P68-Pro firmware version 3207 module GUID A1902AB9-5394-45F2-857A-12824213EEFB cant look at it now, off to work.
It's not the end... Let the MS database server be 127.0.0.1 and run something similar to the kms keygen at every boot. That "keygen" gives the HWH + key combination for your system, even if it doesn't exist at MS servers. It must be possible to change the server ip to localhost somehow, cause updates must be able to do it in case MS changes the server ip. And what about the rest? If the HWH is stored on hdd, it can be changed to the real hash for the "stolen" key you have installed and the server will validate it just fine? I guess that's where the MSDM table is for, but what does that table actuallu do? At least we can be sure that the server checks are done by the OS, cause if the only internet connection is a protected wireless network, UEFI won't be able to access it.
Thinking as Microsoft do now, i will say, if you do not have Internet, you cannot activate windows 8, and then use it....
They can let it activate in the store where they bought it. Btw, if it is activated, will it stay activated forever or does it need to be redone every x days like kms?
I am not so sure about that. Why, I will tell you. I have read in the documentation that is available about UEFI that it can use signed drivers and can connect to a activation server. So this scenario isn't far fetched at all, but highly possible. If it will happen, only time will tell. Scenario: During the setup of Windows 8, the user could be asked to configure their network settings. If they do so, then this is stored on the system partition. An UEFI module could read that information and use it to contact the Microsoft Activation Server(s). The UEFI must hold all drivers for the wireless and/or network cards that are available (or the most common).
At school we have to enter a username + pw on a special webpage before we have full internet access. Before logging on you can only access that page. How are they going to solve that?
I had some time to look at module A1902AB9-5394-45F2-857A-12824213EEFB (MSOA), data for the SLIC refrenced as SYEK and PL2S (I dont know which is the marker and which is the key yet) and data for the MSDM refrenced as PL3S and LTPS are retrieved by a protocol interface installed by module 98584C0B-49D6-4BAF-B542-ECEE2582409C (ASUS Backup). it would be really neat if the tools to create this data would leak