I am going now to develop AntiWPA (Anti Windows Product Activation) for all new Windows versions, for this I will reverse engineer the existing techniques and push them out from the underground to the open public. It has been now over 2 years that last I give thoughts about that topic ( With this article I want to cover how AntiWPA works and how I am doing the implementation in my Stoned Bootkit. I'll make it freely public available, however won't cover it at Black Hat USA 2009 until that is a security, not hacking conference. But I'll show it to you at Hacking at Random 2009 in Vierhouten.

Peter Kleissner, Software Guru & Anti-Windows Researcher

AntiWPA Community

A cure against the M$ Windows Product Activation - Main site - Forums - Blog

I personally like the idea of free and of open source software. It's like the human knowledge belongs to the world, and free information exchange (freedom of information, freedom of spech) is more worth than ones companies interest. So I show a bit solidarity with people they are like me and push out a new AntiWPA generation here.

OEM BIOS Emulation

This is the trick that I like the most - OEM BIOS emulation to use corporate keys. Microsoft decided to not push out any typical corporate keys for Windows Vista as there were for Windows XP. Let's give an introduction about the BIOS emulation (taken from the forum):

Both load an emulated SLIC table into memory and Vista will activate without reference to the Microsoft activation servers if there is an appropriate digital certificate matching the SLIC table installed into Vista's software licensing manager service and the OEM key matches the Vista version installed.

Effectively Vista believes it is installed on a Microsoft licensed OEM partner's machine such as a Dell Acer Asus HP Lenovo etc notebook or desktop.

As Vista boots it checks for the SLIC table in the BIOS and these both cause it to think it is there as it is loaded into memory. They both install the Certificate and key. Most install an Asus table and certificate and key as the default.

A lot of the stuff is also discussed at, mostly discussing how it works for which versions. Microsoft uses SLP 2.0 (System Locked Preinstallation) for activating OEM versions of vista. For that, the BIOS must contain ACPI-SLIC tables (Software Licensing Description Table) with a SLP public key (from betalog):

Microsoft is using SLP 2.0 (System Locked Preinstallation) technology for activation process of OEM (Original Equipment Manufacturer) edition of Windows Vista on branded PC. One of the requirement to activate Windows Vista with OEM product key is the existance of SLP public key and SLP marker which stored in SLIC table in ACPI. If you have older motherboard with no updated BIOS with SLIC table, the BIOS has to be patched or hacked to add in SLIC table plus OEMID and OEMTableID. The original instruction to add in SLIC information involves method to replace an existing ACPI description table, which may affect some functionalities of computer. Now there is improved way to actually add in SLIC table into BIOS ACPI module, without replacing any existing tables. 

Another interesting entry from the forum:


There is a secret arrangement of Microsoft and computer OEM companies that they put a SLP key into the BIOS, technically including it as a seperate ACPI table. When activating Windows with an OEM license it checks whether this table is present and uses it together with a digital certificate (given from CERTs). There is no public description available of this SLIC table, not even confirmation in any ACPI document. However there exists an source code file (actbl1.h) from intel (part of this arrangement) that reveals that table:

 * Name: actbl1.h - Additional ACPI table definitions

 * Copyright (C) 2000 - 2008, Intel Corp.
 * All rights reserved.

#define ACPI_SIG_SLIC           "SLIC"  /* Software Licensing Description Table */

According to the Advanced Configuration and Power Interface Specification (chapter ACPI Software Programming Model) there is the Root System Description Pointer (RSDP) structure that is set up by the firmware (= your BIOS) and contains the address of the Extended System Description Table (XSDT), which references other description tables. It is supposed that the XSDT contains a pointer also to the SLIC table, so this is the point where we have to look (or inject) at. There are following tables publicly discussed and open available:

#define RSDP_NAME               "RSDP"
#define RSDP_SIG                "RSD PTR "  /* RSDT Pointer signature */
#define APIC_SIG                "APIC"      /* Multiple APIC Description Table */
#define DSDT_SIG                "DSDT"      /* Differentiated System Description Table */
#define FADT_SIG                "FACP"      /* Fixed ACPI Description Table */
#define FACS_SIG                "FACS"      /* Firmware ACPI Control Structure */
#define PSDT_SIG                "PSDT"      /* Persistent System Description Table */
#define RSDT_SIG                "RSDT"      /* Root System Description Table */
#define XSDT_SIG                "XSDT"      /* Extended  System Description Table */
#define SSDT_SIG                "SSDT"      /* Secondary System Description Table */
#define SBST_SIG                "SBST"      /* Smart Battery Specification Table */
#define SPIC_SIG                "SPIC"      /* IOSAPIC table */
#define SRAT_SIG                "SRAT"      /* SRAT table */
#define SLIT_SIG                "SLIT"      /* SLIT table */
#define BOOT_SIG                "BOOT"      /* Boot table */

The XSDT contains an array to each this table, and each such a "system description table" has a header DESCRIPTION_HEADER and of course its data. Its easy to find the RSDP and so on the XSDT, the RSDP is given at 40Eh in memory:

The first 1 KB of the Extended BIOS Data Area (EBDA). For EISA or MCA systems, the EBDA can be found in the two-byte location 40:0Eh on the BIOS data area.
The BIOS read-only memory space between 0E0000h and 0FFFFFh.

I don't want to spam around here with structures and everything, but to let you know RSDP + 24 points to the XSDT, and XSDT +36 contains an array with pointers to the description tables. Easy, eh?

Of course there are tools currently available that list the ACPI tables, take a look (what there is shown is the DESCRIPTION_HEADER of the SLIC table):

ACPI Signature SLIC
Table Description Software Licensing Description Table
Memory Address 7FEE8F30h
Table Length 374 bytes
OEM Table ID Notebook
OEM Revision 11000624h
Creator ID MSFT
Creator Revision 00000097h

Putting the information together this means that Windows checks if the ACPI SLIC table is present, and if, checks together with installed certificates (via the Windows Key Management Services). If the SLIC table and the certificate are matching, then it will accept the OEM key and no internet activation is necessary.

So what do we have to do?

Add this additional SLIC table (its just 374 bytes of size) to the ACPI system description table list or replacing an existing ACPI system description table. I chose first, because I don't want people to lose functionality, overwriting an existing one would result for example in the loss of functionality of the shutdown button, or you couldn't hibernate anymore or such side effects. I have seen in the wild people replace their "RSDT" table (Root System Description Table), which has the side effect that old operating systems, that are only compatible with ACPI 1.0, will not be able to power-manage your computer. This includes all operating system before the year 2000 (because ACPI 2.0 was specified in 2000).