With a phone activated VMware Installation ... You can change UUID (in VMware config file): Activation remains You can additional change MAC address of NIC (in VMware config file): Activation remains You can additional change HD ID (in VMware config file): Activation remains Remark: I have seen a table for Vista (but don't find it again) where every hardware has some points. And when the sum of the points exceeds a limit a new activation is triggered.
I am sure. VM was generated UUID was changed in VMware config file Only then Windows 8 was installed. This could be helpful. An AiO ISO was used. At installation start no key was requested. Shortly before the end of the installation a key was requested - but skipped. So generic key was used. Then UUID was checked. Only now the Key was installed with slmgr -ipk command.
Thank you - very good and comprehensible tutorial. Result: A new, fresh VMmare machine Implemented key into VMware bios Configured VMware to boot modified VMware bios Implemented UUID in VMware config file The modified VMware bios boots from original retail Windows 8 DVD and installs "Core" version without requesting any key. So the installation routine takes the key from MSDM table of the modified VMware bios. After installation: Without Internet connection Windows 8 is not activated. With Internet connection Windows 8 activates itself via Internet. But the key was in previous test in VMware "phone activated". So it should be tested with a not in VMware used OEM key. Or an OEM key which is activated with a real OEM PC. One confusing thing: In the test the checksum byte has to be "7D". But "RWeverything" shows the checksum byte as "74" - makes a difference of "09". A check of the basic MSDM bios of you post shows the same behaviour: In the basic MSDM bios the checksum byte is "7A" (red), but "RWeverything" shows the checksum byte as "71" - makes also a difference of "09". Only this one byte is wrong - all other are correct (Brand name "DELL" and key). I don't know where this error comes from. Is it "display" error of "RWeverything" ? Is it Windows 8 which extracts the checksum byte from the modified VMware bios ? Or is it "VMware" which gives the checksum byte to Windows 8 ? But this doesn't influence the automatically reading the key from the MSDM table whilst installation procedure (no key request).
You are awesome Yen. I have been wondering about this for a while. Now to test if AIO pulls the keys correctly.
Thanks for your tests. I am glad that my mod works. The inconsistency.... Either the sum of the table is now wrong (means rw-everything error) OR at least one more byte of the table (of the 85 bytes) has changed as well (sum is still zero = valid)...anyway it is a minor issue since the table appeared to be functional. I strongly assume that the table as it is in the ACPI namespace sums (still) to zero. But if only one byte should have changed it cannot be. The ACPI namespace holds the complete ACPI table structure and is provided by the ACPI-BIOS. (Vmware virtual BIOS). During boot the OS looks after the RSDP (root system description pointer) at specified memory addresses. (Low memory usually write protected). The RSDP holds the addresses of the two major ACPITables RSDT and XSDT. These two tables hold further addresses of further ACPITables. When the ACPI BIOS initialises, it maps the ACPITables into virtual memory. At dynamic allocation it usually corrects / calculates the checksum, but tables can become invalid if the ACPITable of the BIOSmodule itself contains a wrong sum. The result would be that the table gets not mapped into ACPI namespace (is missing). My guess: Additional bytes have changed at the MSDMTable. You might check all the 85 bytes... When I modified the BIOS I placed a new ACPI module into it and called it from the SLIC module. After that I jumped back. I didn't check if there is another code which changes IDs of the ACPITables. It of course shouldn't change the OEMID (Dell) and the OEMTable ID PE_SC3 and the data itself = serial. If you want you can upload the MSDM.bin saved by rw-everything (save as binary of course when used the dummy key...) I would like to know why the byte has changed. Thanks.
Whilst booting and installing in EFI mode (vmx file: firmware = "efi") with MSDM bios the installation procedure requests a key (to make decision between "Pro" and "Core"). Seems that in EFI mode the MSDM table is not accessible ? Or in EFI mode VMware is not using the modified "bios440.rom" ? After entering the Core OEM key the installation starts, formatting the disk in GPT and creates EFI system partition. But "RWeverything" don’t show the MSDM tab. After installation: Without Internet connection Windows 8 is not activated. With Internet connection Windows 8 activates itself via Internet. But the key was in previous test in VMware "phone activated".
Different parameters need to be used in the .vmx file: Code: efi32.filename = "efi32.rom" efi64.filename = "efi64.rom" Note that you can't just use BIOS rom files here, as the EFI rom files are different altogether. You have to extract the EFI rom from the VMWare executable and mod it.
It might be also a difference of: OA3.0 activation and (re)identification of a particular machine. OA3.0 re-activation trigger when activated online OA3.0 re-activation trigger when activated by phone. The UUID seems to be important here, but it is not @ OA1.0 and OA2.x.
I think that a pretty consistent picture is starting to emerge about OA 3.0. It seems to behave just like Retail, or CoA based activation in past Windows versions. The only difference is that the product key, instead of being on a sticker in a box, is stored in the firmware of the machine. The factors that are the same: * Each machine has a unique product key (like Retail, and not like OA 1/2) * Activation online or over the phone is required * Unique hardware info is recorded and transmitted to Microsoft * There is 1-to-1 connection between product key and hardware info Essentially, after Microsoft decided that many-to-1 activation of machines doesn't work (i.e. using one product key on multiple machines), they just fell back on the well-established 1-to-1 solution.
And there is still potential for more tests. It is interesting to know if there is a way to activate a VM with a 'non phone activated' MSDM serial. And it would be interesting to backup / restore / use the activation files at C:\Windows\System32\spp\store of a original machine BEFORE it ever had been online. And it would be interesting if activation simply can be restored without re-activation.... Unfortunately I don't have access to a w8 OEM PC.
This is the MSDM table shown by "RWeverything" from the basic "bios440.rom": Code: 4D 53 44 4D 55 00 00 00 03 71 44 45 4C 4C 20 20 MSDMU....qDELL 50 45 5F 53 43 33 20 20 00 00 04 06 41 53 4C 20 PE_SC3 ....ASL 00 00 04 00 01 00 00 00 00 00 00 00 01 00 00 00 ................ 00 00 00 00 1D 00 00 00 42 48 33 52 4E 2D 42 37 ........BH3RN-B7 46 44 4D 2D 43 37 57 47 54 2D 34 43 52 34 58 2D FDM-C7WGT-4CR4X- 36 43 4B 48 4D 6CKHM Here the same in hex editor layout: Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0005FFA0 4D 53 44 4D 55 00 00 00 03 71 44 MSDMU....qD 0005FFB0 45 4C 4C 20 20 50 45 5F 53 43 33 20 20 00 00 04 ELL PE_SC3 ... 0005FFC0 06 41 53 4C 20 00 00 04 00 01 00 00 00 00 00 00 .ASL ........... 0005FFD0 00 01 00 00 00 00 00 00 00 1D 00 00 00 42 48 33 .............BH3 0005FFE0 52 4E 2D 42 37 46 44 4D 2D 43 37 57 47 54 2D 34 RN-B7FDM-C7WGT-4 0005FFF0 43 52 34 58 2D 36 43 4B 48 4D CR4X-6CKHM And here hex editor layout from the basic "bios440.rom": Code: Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F 0005FFA0 4D 53 44 4D 55 00 00 00 03 7A 44 MSDMU....zD 0005FFB0 45 4C 4C 20 20 50 45 5F 53 43 33 20 20 01 00 00 ELL PE_SC3 ... 0005FFC0 00 41 53 4C 20 00 00 04 00 01 00 00 00 00 00 00 .ASL ........... 0005FFD0 00 01 00 00 00 00 00 00 00 1D 00 00 00 42 48 33 .............BH3 0005FFE0 52 4E 2D 42 37 46 44 4D 2D 43 37 57 47 54 2D 34 RN-B7FDM-C7WGT-4 0005FFF0 43 52 34 58 2D 36 43 4B 48 4D CR4X-6CKHM Just have seen: When only used basic "bios440.rom" in VMware (and UUID and MAC address of NIC is randomly generated by VMware): Whilst booting and installing in BIOS mode with basic "bios440.rom" the installation procedure requests a key to make decision between "Pro" and "Core" because the MSDM key is not valid. After entering the Core OEM key the installation starts. When installation is finished "RWeverything" shows the invalid key in MSDM tab. After installation: Without Internet connection Windows 8 is not activated. With Internet connection Windows 8 activates itself via Internet. But the OEM key was in previous test in VMware "phone activated". So I think key in MSDM (invalid) and UUID (randomly created) and MAC address of NIC (randomly created) have no influence. Or in other words: Phone activation is very "tolerant". Yes. Should be tested. Have seen the following test: User has an activated Windows 8 OEM PC with 1 TB HDD (EFI, GPT, secure boot) User shrinks the Windows 8 partition to 50 GB User cloned that partition on same HDD (with Linux/GParted). Cloned installation is still activated. User upgraded cloned Windows 8 installation to Windows 8 Pro and activated online User cloned that Windows 8 Pro partition on same HDD. Cloned installation is still activated. User upgraded cloned Windows 8 Pro installation to Windows 8 Pro WMC and activated online User cloned all three partitions (Windows 8 / Pro / WMC) on same HDD. Cloned installations are still activated. The last three cloned partitions are all updated to Windows 8.1 / 8.1 Pro / 8.1 WMC Preview. All six installations are activated. Perhaps user can create a 7th partition and install Windows 8 from the scratch and test if online activation on totally different hardware is possible with a key previously used in VMware for phone activation ...
Thanks again for your efforts. Bytes at offset 24-27 (decimal) hold the OEM revision bytes of an ACPITable. Some BIOSes have 'global' code which affects defined ACPITables at the moment when they are mapped. For instance to have fixed and the same IDs at those tables. This is important when SLIC'ing the BIOS. Such code can ruin (overwrite) activation relevant IDs. (OEM and OEMTableID), so we needed to patch the code then..... But the OEM revision bytes are not OA relevant. We know now the reason why rw-everything shows another checksumbyte, it is no error of the program. The ACPI module I have placed into the BIOS is called from the SLIC containing ACPI module and its data (the MSDM table) dynamically allocated to ACPI namespace. At this moment other code changes the OEM revision bytes to 00 00 04 06 and another code corrects the checksum byte again. All done by the BIOS. Everything's fine.