Windows OEM Key aus BIOS/UEFI bzw. ACPI per Powershell auslesen oder wo kommt der Windowskey für die Aktivierung her?

Letzthin war ich doch etwas geschockt, als es darum ging, einem neuen Rechner Windows 8.1 Update 1 beizubringen. Nicht dass jetzt die Installation unmöglich gewesen wäre aber ein paar Details haben mich etwas stutzig gemacht.

Zunächst muss ich sagen, es handelt sich um einen fertigen ASUS-Tower. Dieser wird mit Windows 7 vorinstalliert ausgeliefert. Da aber Windows 8 drauf sollte und dabei gleich die neueste Fassung mit 8.1 Update 1, wollte ich über die übliche Methode diese Version installieren: https://newyear2006.wordpress.com/2013/09/13/windows-8-1-mit-product-key-von-windows-8-installieren/ indem ich die Installation über einen Microsoft-Demokey vornehmen wollte. Bei der Vorbereitung machte ich mich dann auf die Suche nach dem Windows 8 Key. Aber was soll ich sagen? Es gab keinen! Weder auf dem Tower aufgeklebt noch auf den DVDs oder sonstwo.

OK, es gibt ja die Möglichkeit den Key auf die DVD zu verpacken. Also DVD untersucht und die WIM-Dateien mittels 7zip angeschaut aber nix. Keine Datei mit einem Key. Was geht hier ab?

Ich gebs zu, ich hab dann doch von der Original-DVD Windows 8 installiert. Aber nur um zu sehen, ob später ein Key eingetragen ist. Siehe da, die Installation flutscht durch, ohne nach dem Key zu fragen und führt bei Internetverbindung gleich noch die Aktivierung durch. Das nenn ich ja mal Service! Aber genau diesen Service möchte ich am allerwenigsten.

Die Herausforderung
Jetzt wird es aber interessant. Also auf der DVD ist kein Key zu finden. Aber Windows ist nach der Installation aktiviert. Wie geht das? Wo kommt der Key für die Aktivierung her? Hat es Microsoft etwa eingesehen, dass dieses ganze Zwangsaktivierungsgedöns langfristig deren Untergang ist und aktiviert einfach so? Oder ist die Sache irgendwie an das ASUS-Bios bzw. ASUS UEFI Umgebung gebunden?

Mit der letzten Vermutung kommen wir der Sache näher aber zu meiner Überraschung ganz anders, als ich ursprünglich gedacht hatte. Es hat tatsächlich etwas mit UEFI zu tun aber es wird nicht einfach ein Hersteller ermittelt und dieser freigeschaltet, sondern jeder Rechner bringt seinen eigenen Key im ACPI mit! Dies ist auch keine Besonderheit von ASUS sondern alle Hersteller LENOVO, ACER, DELL usw. alle scheinen diese Variante mittlerweile zu praktizieren!

Die verfügbaren Tools
Hier der erste Artikel bei dem ich über die Sache gestolpert bin: http://www.zdnet.com/will-bios-embedded-windows-8-product-keys-cause-reinstall-troubles-7000008226/. Dieser bestätigte also schon mal, dass es tatsächlich so ist, dass der OEM-Key im BIOS hinterlegt ist. Dann ging es weiter: Wenn der da hinterlegt wird, dann kann man den ja irgendwie auslesen: http://www.nextofwindows.com/how-to-retrieve-windows-8-oem-product-key-from-bios/. Hier kommt neben den üblichen Verdächtigen wie Nirsoft auch RWEverything (http://rweverything.com/download/) zur Sprache, welches ich bisher noch nicht kannte. Der Link bei nextofwindows hat auch ein Python-Script parat. In diesem Script kommen interessante Win32-Funktionen zum Einsatz um den OEM-Key auszulesen! Hier das Script auf Github: https://github.com/christian-korneck/get_win8key#files. Python ist gut aber Powershell wäre besser! http://www.eightforums.com/installation-setup/35444-laptop-encrypted-key-uefi-bios-how-obtain-iso-2.html hat einen Powershellfetzen und spricht mittels WMI den SoftwareLicensingService an, welcher mittels OA3xOriginalProductKey den Key anscheinend auslesen kann. Nur leider klappte dies bei mir nie!

Die Hintergründe
Microsoft hat scheinbar schon lange die Möglichkeit vorgesehen, Daten aus dem BIOS bzw. aus dem Firmwarebereich auszulesen. So gibt es z. B. die Win32-Funktion EnumSystemFirmwareTables bereits seit Windows XP mit 64-Bit und generell seit Windows Vista. Macht auch Sinn, da ja ab Windows Vista durch die Umstellungen der Systemsicherheit vieles abgeschottet und umgebaut wurde. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724259(v=vs.85).aspx. Mittels EnumSystemFirmwareTables und GetSystemFirmwareTable kann man nun die nötigen Daten aus der Firmware auslesen. http://msdn.microsoft.com/en-us/library/windows/desktop/ms724379(v=vs.85).aspx. Diese Funktionen nutzt auch das Pythonskript um den Key auszulesen.

Dazu gibt es auch eine offizielle Beschreibung der Speicherstruktur: http://msdn.microsoft.com/en-us/library/windows/hardware/dn653305(v=vs.85).aspx. Microsoft nennt es Microsoft Software Licensing Tables, welche im ACPI-Bereich unter den Systembeschreibungstabellen zu finden ist. Das Dokument spezifiziert davon zwei, einmal SLIC-Table und einmal MSDM-Table. Obwohl das Tabellenformat identisch ist, ist der Unterschied, dass SLIC für VolumeLicenseKeys und MSDM für individuelle Keys gedacht ist.

Bei Tests hat sich herausgestellt, dass Lenovo wie Asus und wahrscheinlich die meisten Hardwarehersteller MSDM benutzen. Dies zeigen auch die vielen Scripte, die es zum Auslesen gibt, welche sich ausschließlich immer auf MSDM beziehen. Interessant dabei ist natürlich, dass bei der Herstellung der Rechner jeder einzelne mit seinem individuellen Key versehen wird! Okay, früher waren es die individualisierten Keyaufkleber aber durch diese Methode können ja im Prinzip viel mehr Dinge auf dem Rechner aktiviert oder individualisiert werden. Denken wir jetzt an nichts Böses, sondern einfach mal an die bei der Bestellung hochgeladene, individuelle Startgrafik.

Powershell Fassung
Auf der weiteren Suche nach einer Fassung in Powershell, bin ich über diese Variante gestolpert: http://winaero.com/blog/how-to-get-the-windows-product-key-without-using-third-party-software/. Auf den ersten Blick genau was ich wollte aber leider wird nur wieder der Key aus der Registrierung ausgelesen, wie man es früher gemacht hat.

Diese Variante war auch ganz hilfreich und enthält noch mehr Infos zu verschiedenen Gegebenheiten und verschiedene Sourcecodes und Scripte: http://forums.mydigitallife.info/threads/43788-C-C-VB-NET-Read-MSDM-license-information-from-BIOS-ACPI-tables/page3.

Aber am Ende war keine Powershellfassung dabei. Also selber machen! Warum eigentlich Powershell? Ja warum? Weil Powershell wird solange da sein, wie sich Microsoft über Wasser halten kann und es ist bei jedem neuen Rechner von Haus aus mit an Bord! Sogar Windows RT bringt es mit. In der reinen Lehre gibt es also nichts anderes.

Also hier der Code:

$SFTCode = @"

 

[DllImport("kernel32")] public static extern uint EnumSystemFirmwareTables (uint FirmwareTableProviderSignature, IntPtr pFirmwareTableBuffer, uint BufferSize);

[DllImport("kernel32")] public static extern uint GetSystemFirmwareTable   (uint FirmwareTableProviderSignature, uint FimrwareTableID, IntPtr pFirmwareTableBuffer, uint BufferSize);

 

"@

 

$SFT = Add-Type -MemberDefinition $SFTCode -Name "SFTKlasse" -Language CSharp -UsingNamespace "System.Reflection", "System.Diagnostics", "System.Collections.Generic" -PassThru

 

# 0x41435049=ACPI ? https://github.com/michaelforney/coreboot/blob/master/src/include/cbmem.h

$firmwareTableProviderSignature = 0x41435049

$StructSize = $SFT::EnumSystemFirmwareTables($firmwareTableProviderSignature, [IntPtr]::Zero, 0)

try

{

    $StructPtr = [Runtime.InteropServices.Marshal]::AllocHGlobal($StructSize)

}

catch [OutOfMemoryException]

{

    throw Error[0]

}

 

$buffer = New-Object Byte[]($StructSize)

$SFT::EnumSystemFirmwareTables($firmwareTableProviderSignature, $StructPtr, $StructSize)

[Runtime.InteropServices.Marshal]::Copy($StructPtr, $buffer, 0, $StructSize)

[Runtime.InteropServices.Marshal]::FreeHGlobal($StructPtr)

 

if (([System.Text.Encoding]::ASCII).GetString($buffer).Contains("MSDM"))

{

    $firmwareTableMSDMID = 0x4d44534d

 

    $StructSize = $SFT::GetSystemFirmwareTable($firmwareTableProviderSignature, $firmwareTableMSDMID, [IntPtr]::Zero, 0)

    try

    {

        $StructPtr = [Runtime.InteropServices.Marshal]::AllocHGlobal($StructSize)

    }

    catch [OutOfMemoryException]

    {

        throw Error[0]

    }

 

    $buffer = New-Object Byte[]($StructSize)

    $SFT::GetSystemFirmwareTable($firmwareTableProviderSignature, $firmwareTableMSDMID, $StructPtr, $StructSize)

    [Runtime.InteropServices.Marshal]::Copy($StructPtr, $buffer, 0, $StructSize)

    [Runtime.InteropServices.Marshal]::FreeHGlobal($StructPtr)

 

    $encoding = [System.Text.Encoding]::GetEncoding(0x4e4)

 

    $key = $encoding.GetString($buffer, 56, 29)

}

$key

Wie immer gilt, von der Formatierung nicht abschrecken lassen, sondern einfach Copy&Paste und loslegen. Übrigens es werden keine Admin-Rechte benötigt! Da einiges durcheinander geht, hier noch der Gist-Verweis: https://gist.github.com/newyear2006/5578386bf4793a334f85#file-getacpi-oemkey-ps1

Würde mich freuen, wenn der eine oder andere seine Erfahrungen im Kommentarbereich verewigen könnte, um ein Gefühl dafür zu bekommen, welche Hersteller die Variante unterstützen.

Zusätzlich interessiert mich besonders:

PS > ([System.Text.Encoding]::ASCII).GetString($buffer)

Dies gibt einen String aus, mit den auf dem Rechner verfügbaren Firmwaretabellen.

Noch ein Hinweis:
Falls es nach dem Copy&Paste zu einem Fehler wie diesem hier kommt:

0×41435049 : Die Benennung "0×41435049" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen

Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.

In Zeile:12 Zeichen:35

+ $firmwareTableProviderSignature = 0×41435049

+ ~~~~~~~~~~

+ CategoryInfo : ObjectNotFound: (0×41435049:String) [], CommandNotFoundException

+ FullyQualifiedErrorId : CommandNotFoundException

dann bitte das x bei 0x41434049 löschen und nochmal eingeben. Scheint eine nette Anomalie von WordPress zu sein.