".vbox" is from VirtualBox ? I'm using "VMware". The corresponding file ".vmx" of "VMware" has these parameters: uuid.location = "xx xx xx xx xx xx xx xx-xx xx xx xx xx xx xx xx" uuid.bios = "xx xx xx xx xx xx xx xx-xx xx xx xx xx xx xx xx" But the value and pattern don't match with "Machine uuid" from registry "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}" ...
Isn't the unique online "validation" generated when connected to the internet placed as a hidden file "data.dat" in the "store" file folder ? This may be the corner stone for future WGA or not
I don't know. I think it has something to do with the UUID since the vm's that were using KMS keys for the early win8 activations all used similar UUID settings. So Yen is likely thinking about how they create the unique UUID. I'd guess that they have to verify each unique UUID when assigning pkeys for OEMs, but for the online activation of retail copies, it must have something to do with the disc as well or you'd end up with a few people with the same UUID.
Yes understood .. The distinction I think is the difference between "activation" vs. "validation" which with no WGA yet and the push for everything to be done through the Store who knows where this ends up .. M$
It would be the same, afaik. When it comes to the UUID the VM reads the vbox file and then assigns the info to whatevers been changed (you could look at the VirtualBox source for detailed info). But I believe the actual UUID is generated from the BIOS information, so it can't be emulated or injected anywhere. It would require you to modify system files to return a static string, which obviously isn't desired as you'll run into problems with Windows updates. I believe OA3.0 is a dead end and a waste of time because even if it were possible all it'll result in is people getting their keys blocked and/or stolen. In fact you'd probably have better luck having one activated officially and one activated over the phone. The issue, however, is that they'll both be reporting the same key to MS so I wouldn't be surprised if one or both of the systems loses activation at some point. For offline and worry free activation it's much easier to just use KMS. It's probably a whole lot more "permanent" too.
Yes, sure. My motivation is not to have a free windows 8, it is to understand OA3.0. I could get a legit copy of my company where I work.... they will not install it for sure on our clients, but I don't like w8. I think others are also interested in OA3.0 just to know how it works..... Concerning UUID, I guess it can be simply changed at registry also on a physical instalation. Only thing is to take care of MachineGuID.txt. ....it should be the same ID......oh well I never have got a RTM image of w8...no interest..but to find my answers I probably need to get it......
With regards to Hardware UUID: This is a value that is stored permanently in the BIOS (I believe in the DMI information). It is put in there by the motherboard manufacturer. It is optional, so not every motherboard has one, but it has been pretty much standard for a long time now. How the motherboard manufacturer generates this UUID is entirely up to them. On some motherboard models, the same UUID is contained in every motherboard of the same model. You can check the Hardware UUID with the following command: Code: wmic csproduct get uuid Windows activation mechanisms have been using the Hardware UUID as one of the pieces of information they use to detect hardware changes. It has the same the same role as, for example, the hard disk serial number or the NIC MAC address. I don't know which Windows version started using the Hardware UUID, but it's known that in Windows XP, the Hardware UUID was not part of the process yet that generated the unique hardware hash used for activation. The Hardware UUID has no relation whatsoever to the value in the registry at HKLM\Software\Microsoft\Cryptography\MachineGUID. I don't know how the MachineGUID is generated. I believe the MachineGUID is not important for activation. You can compare yourself the output of "wmic csproduct get uuid" with the MachineGUID on a physical computer. In connection with Virtual Machines, most virtualization products allow you to specify the Hardware UUID so that you can replicate a physical system exactly, just like you can usually specify the hard disk serial number or the MAC address. In VirtualBox specifically, you have to be a bit careful because as Yen posted earlier, there is some swapping around going on with the byte order. In a VirtualBox VM, the output of "wmic csproduct get uuid" is not in exactly the same byte order as the order in the .vbox file. From all the experimenting in Virtual Machines that happened back when the first of the KMS host keys were leaked, it is clear that the Hardware UUID carries a pretty big weight for the purposes of activation. If it's changed, then Windows almost certainly believes that it's now running on different hardware and triggers reactivation. There have only been a few exceptions to this.
You can change the registry key, but it won't make any difference as Windows doesn't get the information from the registry key for anything important. I can understand why you may want to understand OA3.0, but after playing around with it myself before I've found that it only wasted my time. Like sure, it's nice to know how it works, but theres no clean activation hack that can come of it. That's part of the reason why I didn't bother talking much about OA3.0 as I don't want to give people false hope. That plus I've decided that I won't release a loader for Windows 8 even if it was possible to share the keys, simply because it risks keys getting blocked.
Thanks for your post. I think I need to have a closer look at the SMBIOS; it is supposed to be the successor of the DMI. And you are right, the ID obtained by your command does not match the registry value stored at MachineGuid on my 'real' w7 installation.
I have done a quick research. Yes the ID is found at SMBIOS, formerly known as DMI, exactly at System information Type 1. The area is write protected. The ID is not stored at the BIOS ROM itself. It can be changed using the right DMI tools, or probably when modifying the module 06. This applies to 'physical' AMI BIOS. It's not worth to play with it. On a VM it would look different....rw-everything could read its SMBIOS and one could find the relation to the setup of the vm in order to change the right ID...
I may be misunderstanding what you are saying here, but for a VM it's trivial to change the Hardware UUID. It is usually stored in the VM's configuration file, and for most products there is a command for modifying it. For example, in VirtualBox: Code: vboxmanage modifyvm <vmname> --hardwareuuid <uuid> This will force the VM's BIOS (or DMI or SMBIOS) to contain the appropriate UUID, and that's what will be seen by Windows. You can of course verify the UUID inside the VM with "wmic csproduct get uuid".
Btw: OA never had been cr*cked, just mimicked! According to my experiences the AMIBIOS string of the 1b module gets mapped to FF400h physical memory. (It is used by the SSV3 approach at AMI when SLICing the BIOS). The ID here for instance is found at F074Dh physical memory. It is a offset difference of ECB3h. When I go forward at the 1b module relative to the AMIBIOS string which is located at offset 11D21h then I 'land' at offset 306Eh. There is a zero byte area one could place the ID of a OA3.0 machine. With some luck it maps the new ID to the same address if it has priority. Then the SMBIOS would have the same UUID as a OA3.0 machine. Then one just has to apply the serial from a MSDM table.....also AMIDEDOS could be able to write a new UUID. Anyway I do not go for it. All one needs is rw everything. To read physical memory and the MSDM table and the SMBIOS. And a way to spoof the UUID physically. @kelorgo. Ah OK, I just posted a method to make it sure since it'd query the SMBIOS of the vm directly to verify that it really has got the right ID. I guessed windows reads out the SMBIOS not the setupfile of the vm. Anyway thanks for your info. I assumed it would be easy but didn't know that it is clearly possible that way.
The registry UUID was from a script I'd created months ago during my testing and I shared it with Yen a few days ago. I couldn't remember which UUID was correct (if any). Code: strComputer = "." Set WshShell = CreateObject("WScript.Shell") Key = "HKLM\Software\Microsoft\Cryptography\" rUUID = WshShell.RegRead(key & "MachineGuid") Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_ComputerSystemProduct") For Each objItem in colItems Wscript.Echo "v1: " & objItem.UUID & vbNewline & "v2: " & rUUID Next When the KMS host key leaked I'd told people how to apply the files and UUID to a VM. I think it was this script I used at the time to confirm that things were working.
Your "blue" suggestion was just tested. Implemented UUID from original OEM activated PC into VMware Installing Windows 8 with OEM key (without Internet connection) in VMware Checked UUID with wmic csproduct get uuid and product key - same as original OEM activated PC Restart with established Internet connection Result: Not activated. Phone activation works. Remark 1: UUID can also find here in registry: [HKLM\SYSTEM\HardwareConfig] "LastConfig"={UUID} If value of "LastConfig" is changed - next boot it has the old value. Remark 2: You also can see with "RWeverything" that original OEM PC and VMware with implemented UUID has the UUID in "SMBIOS": [System Information] (Type 1) Hex version: Byte 9-24 And text version at the end of this part. Change the UUID in the config files of VMware. After booting the VM "Windows 8" shows "Hello … we have to do some things …" and the "wipe" video. When checked the changes of UUID with wmic csproduct get uuid, in registry HKLM\SYSTEM\HardwareConfig\LastConfig and with "RWeverything" / "SMBIOS" they all have the changed UUID. And Windows 8 (phone activated) is still activated ...
Thanks a lot for posting your result. I have just re-checked my info about OA3.0 which I had got for more than 1 year already. Requirement for OA3.0 is an UUID in SMBIOS that is non-zero and at least one valid MAC address (NIC). The info differs during development of OA3.0. also concerning phone activation. But it seems that they allow now to phone activate a different mobo if the original should become broken. And it seems phone activation is very 'tolerant'... Your test shows that at least one more info is transmitted. I guess it is the MAC address of the NIC. Don't know if it can be changed on a vm for another test. I remember to have spoofed the MAC address one time of a windows NT client (registry) in order to get internet access on it many years ago. But that's all I know concerning MAC address atm...need to research a bit...