Windows Activation History/Documentation¶
Ok, sorry to wade in here with my cluebat on my first post, but there’s a lot of misinformation and almost-not-quite in this thread, and I feel compelled to educate. My apologies.
OEM activation down through the ages, oldest to newest, with a particular focus on how it can be used and abused, with customer/user OSes as the default:
Windows 2000 and prior: OEM protection is pretty much a joke, just changing the product ID to the right numbers removed all serial prompts. Activation not invented yet.
Windows XP: Online activation and OEM SLP bios locks: Commonly defeated by pirates by simply using VLKs. VLKs were not checked online in any way in XP/2003, so this was ideal. Later many/most VLKs got blacklisted, but just generate more! Royalty OEM activation at this point used generic XP keys which simply provoked OEM validation. OEM validation consisted on checking the oembios files. oembios.bin was a somewhat obfuscated and MS-signed file describing memory locations and copyrighted/trademarked data to look for at those locations. If the OEM check scanned the appropriate memory addresses and found one or more matching strings, activation was done, OS was activated. This wasn’t widely abused by pirates because VLKs were easier, but towards the later days of XP, it grew in popularity because it was easy to abuse, and hard for MS to check and invalidate.
Windows Vista: First generation ACPI table locks (SLIC): With the lessons learned from XP activation and the abuses thereof, Microsoft decided that a more active approach was needed in later OSes. Starting with Vista, VLKs as they had been were over. There are no longer any “magic keys” which allow an unlimited number of offline activations. Volume customers (businesses) were steered towards KMS and MAKs, which are useful but not for Royalty OEMs and/or pirates. Since the old VLK path was now fully locked off, pirates now looked into Royalty OEM methods. Microsoft had observed some limited abuse of the old oembios system in the latter days of XP, and they wanted a new, more tamper-resistant method. Enter SLIC. SLIC was a custom ACPI table that contained a public key encrypted OEM certificate. When Windows installed, it could be given certificate files with appropriate OEM information and public keys. The certificates themselves were signed by a Microsoft private key to resist tampering. The Royalty OEM process was triggered by use of a generic OEM serial number, common to all computers sold by a particular OEM. Once an OEM serial had been given, the system firmware would be checked for a SLIC table, and the contents compared to any and all OEM certificates that had been loaded by Windows. If the SLIC table was present, and matched a signed certificate, Windows would activate, completely offline. Many BIOS modifications were used to exploit this method, from initial ISA module loaders to rather complex ACPI edits.
Windows 7: Exactly the same as Vista, just the certificate version was increased from SLIC 2.0 to SLIC 2.1. The system had not been successfully exploited by many pirates, partially because bios modification was more difficult than prior methods, but also because Vista was widely disliked. With Windows 7 being massively more popular, BIOS modifications to exploit SLIC became more and more popular. As the tools advanced, the process became simpler and easier to apply. Microsoft did not overlook this, and prepared a third generation of OEM activation.
Windows 8, 8.1, 8.1u1: SLIC 3.0. This system is a further development and refinement of the previous SLIC 2.0 and 2.1 systems. Windows 2012, in fact, uses SLIC 2.2 with no other changes from the Windows 7 methods, precisely because server OEMs did not want to take on SLIC 3.0 for small volume markets. Windows 8 uses a new generation system, looking for an OEM ACPI table called MSDM. The MSDM table contains a hardware hash that matches the machine it is installed on, along with a full OEM Windows key, which is specific to the machine it is installed on. There are no longer generic OEM keys that will trigger OEM activation, each OEM machine has a unique key. No system is perfect, and MSDM could probably be overcome by pirates if there were no other methods, but since there are alternatives, attention has focused there. Specifically, local KMS server emulators are very popular for the purposes of Windows 8+ and Office 2010+ piracy.
To further refine my post and get a little closer to OP’s point, some additional information on Windows 7 and Windows 8 OEM licensing:
With Windows 7, OEMs generally had one key for each major product version (Home, Pro, etc), and you could change versions by simply using a different OEM key. The BIOS certificate (SLIC) was specific only to the OEM, one SLIC was used for any and all Windows versions. With Windows 8 and SLIC 3.0, there were not generic OEM keys in this way. Since each machine had a unique serial embedded into the firmware, it was possible to determine Windows edition as well as type/OEM from the firmware alone. If your new laptop has a Windows 8 Standard preinstalled, and you’ve purchased an OEM System Builder (OEMSB) copy of Windows 8 Pro, you will encounter the problem OP had. Installing from Windows 8 Pro OEMSB media, the installer detects the valid Windows 8 non-Pro MSDM table, inserts that key, and installs non-Pro. You are not given any opportunity to override this. You are also generally not allowed to change edition easily post-install with the OEMSB keys.
In order to keep your install media from using your MSDM key, the methods mentioned here generally work. By creating an ei.cfg file and adding it to your install media, you tell the installer that it is not OEM media, it is retail. Since retail does not have MSDM, it never checks for it and will instead ask for the serial to use. In the sources folder, create ei.cfg with the following:
[EditionID] [Channel] Retail [VL] 0
Likewise, forcing a PID via pid.txt will insert your OEMSB or retail key before the installer does the edition (retail/OEM/VL) check, so that works as well. Create a file called PID.txt in the “sources” folder, an just stick your legitimate product key as follows:
Sphynx - You had most everything correct. Congrats on figuring this all out by yourself! It’s not an exploit, though, it’s MS’s backdoor designs, so don’t worry that this will ever go away.
Ardax - As you can see in my posts, it’s a little more complex now. With SLIC 3.0, it can force a particular edition of Windows, so this info can be handy if you’re installing 8 Pro onto a machine that came from the OEM with Win 8 non-Pro, for example.
Sterling_Aug - Sorry, but you’re just plain wrong. With SLIC 3.0 and MSDM, there certainly is a complete and human-readable product key in the ACPI table. You’ve mixed up info from OEM SLP, SLIC 2.0-2.1, and SLIC 3.0. Also, Windows edition hasn’t been determined by the volume name, not ever. There are other places and switches on the media to set that, ei.cfg is the common one for Vista+.
HellDiver - ei.cfg changed the way it was used after Windows 7. Windows Vista and 7 both had an ei.cfg by default, and removing it caused the install to ask what edition to install. With Windows 8, it’s reversed. If there is no ei.cfg file, Windows 8 will look for SLIC 3.0 information, and if it isn’t found, it’ll ask for a key. If you create and add an ei.cfg file, you can change the install media from OEM to retail or even Volume Licensed. That’s what is done here, by creating an ei.cfg and tagging the release as Retail, it skips the step where Windows Setup looks for SLIC 3.0/MSDM info, and goes straight to the next retail step, where it asks what edition to install and then prompts for a key.