Im Sommer 2001 haben wir den Prozess der Produktaktivierung von Windows XP genauer unter die Lupe genommen und insbesondere die Installations-ID, die der Benutzer Microsoft bei der telefonischen Aktivierung mitteilen muss, bis ins letzte Bit analysiert. Offen blieb jedoch eine Diskrepanz bei der Aktivierung per Internet: Hier wird ein Vielfaches mehr an Daten übertragen, als es für die Installations-ID eigentlich notwendig wäre.
Dieser Artikel schließt jetzt die Lücke und dokumentiert das für die Internet-Aktivierung verwendete Protokoll. Dabei beschränken wir uns auf die Aktivierung und lassen die ohnehin optionale Registrierung außen vor.
Die grafische Benutzeroberfläche für die Aktivierung von XP besteht aus einer HTML-basierten Applikation, also einer Reihe von HTML-Seiten, Javascripts und COM-Komponenten, die sich alle im Ordner "oobe" ("out of box experience") unterhalb des System-Verzeichnisses befinden. Durch Starten von msoobe.exe /A in diesem Ordner wird der Aktivierungsprozess angestoßen.
Der Artikel ist für alle Leser auch als PDF-Download für 2,90 Euro zugänglich. Klicken Sie einfach unten auf "Artikel Druck/Download". Wir haben der ZIP-Datei außerdem die in diesem Artikel besprochene Software als kostenlose Zugabe beigefügt. Leser von tecCHANNEL-Premium können die Software hier direkt kostenlos downloaden.
Das Programm nutzt undokumentierte Funktionen der Windows-Aktivierung. Ein Service Pack oder ein Hotfix kann das ändern. Als Folge würde die Software nicht mehr funktionieren. Wir können daher keinen Support und keine Funktionsgarantie für die Software WPAtracer.exe übernehmen.
Die COM-Komponente
Die hauptsächliche Arbeit fällt der COM-Komponente "COMLicenseAgent" zu, die in der DLL "licdll.dll" im Systemverzeichnis implementiert ist. Die dazugehörige Type Library ("licdll 1.0 Type Library") lässt sich mit dem OLE-COM-Objektbetrachter aus dem Platform SDK überprüfen. Uns interessieren besonders die folgenden Methoden der "IComLicenseAgent"-Schnittstelle, da sie für die Produktaktivierung per Internet essenziell sind:
HRESULT Initialize([in] unsigned long dwBPC, [in] unsigned long dwMode, [in] BSTR bstrLicSource, [out, retval] unsigned long* pdwRetCode);
HRESULT AsyncProcessHandshakeRequest([in] long bReviseCustInfo);
HRESULT AsyncProcessNewLicenseRequest();
HRESULT GetAsyncProcessReturnCode([out, retval] unsigned long* pdwRetCode);
Außerdem enthält die Schnittstelle eine Reihe von "Set*()"-Methoden, wie zum Beispiel "SetFirstName", die für die Registrierungsdaten genutzt werden. Alle "Set*()"-Methoden erhalten einen BSTR als einzigen Parameter:
HRESULT SetFirstName([in] BSTR bstrNewVal);
HTML ruft COM
Während der Aktivierung werden die Methoden der COM-Komponente wie folgt durch die HTML-Applikation aufgerufen:
1. Das COM-Objekt wird instanziiert und dann mittels "Initialize()" initialisiert. Der Parameter "dwBPC" ist dabei immer auf 50293 gesetzt. Das entspricht dem bis zur Beta 2 von Windows XP benutzten Produkt-Code. Obwohl die finale englische Version den Produkt-Code 55274 trägt, findet diese Änderung keine Entsprechung im Aufruf von "Initialize()". Den Produkt-Code Ihrer XP-Installation finden Sie heraus, indem Sie die ersten fünf Ziffern der Produkt-ID nehmen, die Sie im Eigenschaften-Fenster von "Arbeitsplatz" erfahren.
Der Parameter "dwMode" wird immer mit 1 belegt, und "bstrLicSource" ist immer ein leerer BSTR. Die Bedeutung dieser beiden Parameter ist noch unklar. Wenn der Methoden-Aufruf erfolgreich ist, liefert er in "pdwRetCode" 0 zurück. Ein anderer Wert zeigt an, dass ein Fehler aufgetreten ist.
2. Die Registrierungsinformationen werden durch den Aufruf der diversen "Set*()"-Methoden an das Objekt übertragen. Da wir allerdings nicht registrieren, sondern nur aktivieren wollen, erhalten alle Methoden einen leeren BSTR für das Argument "bstrNewVal".
3. Mittels "AsyncProcessHandshakeRequest()" wird die Verbindung zum Aktivierungs-Server hergestellt. Der Boolsche Parameter "bReviseCustInfo" erhält den Wert "false", weil wir nicht registrieren wollen. Da es sich um eine asynchrone Kommunikation handelt, kehrt die Methode sofort zum Hauptprogramm zurück, ohne auf das Ende der Kommunikation zu warten.
4. "GetAsyncProcessReturnCode()" wird wiederholt aufgerufen, um den Status der Kommunikation mit dem Server abzufragen. Solange der Handshake noch nicht abgeschlossen ist, liefert die Methode den Wert 0x255 in "pdwRetCode" zurück. Ein erfolgreicher Abschluss wird mittels 0 signalisiert. Jedes andere Resultat zeigt einen Fehler an.
5. Die Methode "AsyncProcessNewLicenseRequest()" übernimmt den Hauptteil der Internet-Aktivierung. Sie überträgt - neben einer Reihe von anderen Daten - den Produkt-Key der XP-Installation und den Hardware-Hash für die Identifikation des Computers. Diese Informationen werden wir in den nächsten Abschnitten des Artikels genauer durchleuchten.
6. "GetAsyncProcessReturnCode()" wird nun wiederum wiederholt aufgerufen, bis die Kommunikation mit dem Aktivierungs-Server abgeschlossen ist (siehe Schritt 4).
Aktivierungs-Datenbank
Der erfolgreiche Abschluss der Aktivierung führt dazu, dass zusätzliche Informationen in der verschlüsselten Datenbank "WPA.DBL" im Systemverzeichnis abgelegt werden. Diese Datenbank wird von XP überprüft, um festzustellen, ob die Aktivierung bereits erfolgt ist. Bei einem nicht aktivierten Windows enthält die Datenbank lediglich Informationen wie das Installationsdatum, damit die 60-Tage-Frist überprüft werden kann.
Nach einer erfolgreichen Aktivierung per Telefon werden die Installations-ID und der dazugehörige Aktivierungs-Code in der Datenbank abgelegt. Im Falle der Aktivierung per Internet ist das Verfahren etwas komplizierter. Die Internet-Aktivierung basiert auf Zertifikaten und digitalen Signaturen. Die COM-Komponente fordert vom Aktivierungs-Server ein Zertifikat an, das die gegebene XP-Installation mit der aktuellen Hardware-Konfiguration bestätigt. Die Hardware-Konfiguration wird durch einen 64-Bit-Hash repräsentiert, wie er in diesem Artikel beschrieben ist.
Die Verbindung zwischen der Hardware und dem Zertifikat wird durch eine Zertifikat-Erweiterung realisiert, die den Hash-Wert spezifiziert. Bei erfolgreicher Aktivierung per Internet liefert der Server ein Zertifikat mit einer solchen Erweiterung und zusätzlich einer Zertifizierungskette, die für die Validierung des Zertifikats gegen ein Root-Zertifikat notwendig ist.
Nähere Informationen über die Konzepte und Grundlagen von Zertifikaten, Zertifikatsketten und Root-Zertifikaten finden Sie beispielsweise im Abschnitt "Cryptography" des Platform SDK oder in diesem tecCHANNEL-Beitrag über PKI.
Das Protokoll
Die Kommunikation zwischen der COM-Komponente und dem Aktivierungs-Server läuft über ein einfaches HTTP-Protokoll, das via SSL verschlüsselt wird. Um die Server-seitigen Aktionen anzustoßen, benutzt die Komponente ein einfaches HTTP-POST, das den auszuführenden Befehl und die dazu notwendigen Parameter enthält. Die Antwort des Servers kommt ebenfalls per HTTP.
Die Nachrichten an den Server bestehen aus binären Daten, wie in der folgenden Tabelle beschrieben ist. Integers werden - wie bei der Intel-Architektur üblich - in Little-Endian-Reihenfolge dargestellt.
Offset | Länge | Bedeutung |
|---|---|---|
| ||
0 | 4 | 32-Bit-Integer, immer 0 |
4 | 4 | 32-Bit-Integer, der die Anzahl der noch folgenden Bytes in dieser Nachricht enthält, also die Gesamtlänge der Nachricht minus 9 |
8 | 4 | 32-Bit-Integer, immer 2 |
12 | 4 | Anzahl der enthaltenen Parameter |
16 | variabel | Parameter |
Jeder Parameter hat das folgende Format:
Offset | Länge | Bedeutung |
|---|---|---|
| ||
0 | 4 | 32-Bit-Integer, der den Typ des Parameters spezifiziert |
4 | 4 | 32-Bit-Integer, der die Größe des Datenfeldes spezifiziert |
8 | variabel | Der Wert des Parameters |
Eine Beispielnachricht
Zur Verdeutlichung betrachten wir einmal die folgende hexadezimale Repräsentation einer solchen Nachricht:
Offset Daten
0000 00 00 00 00 20 00 00 00-02 00 00 00 01 00 00 00
0010 07 00 00 00 10 00 00 00-31 00 2E 00 30 00 2E 00
0020 30 00 2E 00 38 00 00 00
Die ersten vier Bytes stellen den 32-Bit-Integer-Wert 0x0 dar, die nächsten vier Bytes enthalten die Gesamtlänge der Nachricht minus 8, also 0x28 - 0x8 = 0x20. Danach folgt der Wert 0x2 als 32-Bit-Integer und dann ein 32-Bit-Integer mit der Anzahl der Parameter - in diesem Fall 0x1 für einen Parameter.
Der Parameter hat den Typ 0x7, wie im nächsten 32-Bit-Integer angegeben, und eine Länge von 0x10 Bytes. Diese nun folgenden 16 Bytes enthalten den Wert des Parameters, bei dem es sich um den Null-terminierten Unicode-String "1.0.0.8" handelt.
Kurz gefasst sendet diese Nachricht den String "1.0.0.8" als Parameter des Typs 7 an den Aktivierungs-Server.
Server-Antwort
Die Antworten des Aktivierungs-Servers bestehen ebenfalls aus binären Daten in einem ähnlichen Format wie die Nachrichten an den Server.
Offset | Länge | Bedeutung |
|---|---|---|
| ||
0 | 4 | 32-Bit-Integer, immer 0 |
4 | 4 | 32-Bit-Integer, immer 0 |
8 | 4 | 32-Bit-Integer, der die Anzahl noch verbleibender Bytes in dieser Nachricht enthält, also die Gesamtlänge minus 12 |
12 | variabel | Antwort-Parameter im selben Format (Typ, Größe, Daten) wie die Parameter an den Server |
Offset | Länge | Bedeutung |
|---|---|---|
| ||
0 | 4 | 32-Bit-Integer, der den Typ des Parameters spezifiziert |
4 | 4 | 32-Bit-Integer, der die Größe des Datenfeldes spezifiziert |
8 | variabel | Der Wert des Parameters |
Die wichtigsten Rückgabewerte sind der Status-Code und die ID-Werte. Der Status-Code ist ein 32-Bit-Integer, der 0 enthält, wenn die angeforderte Aktion erfolgreich durchgeführt wurde. Ist dieser Wert ungleich 0, so ist ein Fehler aufgetreten. Der ID-Wert dient dazu, einen Kontext zwischen nachfolgenden POST-Anfragen herzustellen. Einmal angenommen, dass die Antwort auf die erste POST-Anfrage die ID 3142 enthält, kann die COM-Komponente in den folgenden POST-Anfragen dem Server durch Mitliefern dieser ID mitteilen, dass die Anfragen zum selben Aktivierungsprozess gehören.
Der Datentransfer
Um zu erfahren, ob es bei der Internet-Aktivierung zu irgendwelchen Verletzungen der Privatsphäre kommt, ist es lediglich interessant, welche Daten von der COM-Komponente an den Aktivierungs-Server gesendet werden.
Die Aktivierung besteht aus drei POST-Anfragen an den Server und den entsprechenden Antworten des Servers:
1.) Aufbau der Kommunikation mit dem Aktivierungs-Server
2.) Anforderung einer Lizenz für das Aktivierungs-Zertifikat
3.) Bestätigung, dass das Zertifikat erhalten und in der WPA.DBL gespeichert wurde
Um zu ermitteln, welche Informationen an Microsoft übertragen werden, müssen wir zunächst herausfinden, wofür die verschiedenen Parametertypen in den Anfragen genutzt werden. Diese Aufgabe übernimmt unser Tool "WPATracer".
Da die COM-Komponente auf die WinINet-API zurückgreift, kann "WPATracer" sich einfach in den Aufruf von "HttpSendRequest()" einklinken und die POST-Anfragen abfangen, bevor sie verschlüsselt werden. Dann kann es die Daten analysieren und darstellen. Ein Klick auf die Schaltfläche Trace startet im Hintergrund "msoobe.exe /A". Wenn Sie dann die Internet-Aktivierung normal ohne Registrierung durchführen, speichert WPATrace die gesendeten Daten und stellt sie im Fenster dar. Das funktioniert natürlich nur auf einem noch nicht aktivierten Windows XP, da msoobe ansonsten meldet, dass Windows bereits aktiviert wurde.
Die erste Anfrage
Auslöser für die erste POST-Anfrage ist die Methode "AsyncProcessHandshakeRequest()".
Typ | Beschreibung |
|---|---|
| |
0x0007 | Bei einem Windows XP ohne installiertes Servicepack enthält dieser Parameter den Unicode-String "1.0.0.7", mit Servicepack 1 ist es "1.0.0.8". Möglicherweise eine Versionsnummer |
0x0008 | Dieser Parameter wurde erst mit SP1 eingeführt. Er enthält den Produkt-Key als Unicode-String. |
0x000b | Dieser Parameter enthält ein 32-Bit-Integer mit der Spracheinstellung des Systems, wie sie von der API-Funktion "GetSystemDefaultLCID()" zurückgeliefert wird. |
0x000c | In diesem 32-Bit-Integer ist der Produkt-Code dieser XP-Installation enthalten - also die ersten fünf Ziffern der Produkt-ID. |
0x000d | Der 64-Bit-Hardware-Hash, der diesen Computer repräsentiert. |
0x000e | In diesem 32-Bit-Integer ist der Wert des Parameters "bReviseCustInfo" für die Methode "AsyncProcessHandshakeRequest()" enthalten, also die Information, ob registriert werden soll oder nicht. |
0x0014 | Eine SYSTEMTIME-Struktur, die die aktuelle Zeit enthält, wie sie beispielsweise von der API-Funktion "GetSystemTime()" zurückgeliefert wird. |
0x0019 | Dieser Parameter enthält einen einzelnen Unicode-Buchstaben: "N", wenn es sich um eine erstmalige Aktivierung handelt, "T" wenn dieses XP zuvor schon per Telefon aktiviert wurde und "I" wenn es bereits per Internet aktiviert wurde. Die letzten beiden zeigen also an, dass eine erneute Aktivierung auf Grund von Hardware-Änderungen erforderlich wurde. |
0x001a | Optionaler Parameter, der bei einer erstmaligen Aktivierung entfällt. Anderenfalls enthält er die Informationen aus der bereits bestehenden WPA.DBL. Also bei einer Telefonaktivierung die Installations-ID und den Aktivierungs-Code und bei einer vorherigen Internet-Aktivierung das Zertifikat und die Zertifikatskette. |
0x002a | Enthält den Produkt-Key als Unicode-String. |
0x5001 | Bei einem XP ohne Servicepack enthält dieser Parameter den Unicode-String "WPAV20", bei SP1 "WPAV30". Sieht wie eine Versionsidentifikation für die Produktaktivierung aus. |
0x5002 | Enthält immer den Unicode-String "LICAGENT". |
0x5003 | Enthält den Unicode-String "HANDSHAKE". |
0x5004 | Enthält das Unicode-Zeichen "I". |
Die zweite Anfrage
Die zweite Anfrage wird durch Aufruf der Methode "AsyncProcessNewLicenseRequest()" angestoßen.
Typ | Beschreibung |
|---|---|
| |
0x0002 | Ein Block von 2134 Null-Bytes, der aus der Datei WPA.DBL gelesen wird. Da es nicht viel Sinn macht, nur einen großen Block Null-Bytes dort zu speichern, vermuten wir, dass dieser Block entweder früher für irgendetwas benutzt wurde oder für spätere Erweiterungen vorgesehen ist. |
0x0003 | Dieser Parameter enthält die ASN.1-kodierte Anforderung des Zertifikats. Da die Dekodierung von ASN.1 nicht trivial ist, gibt WPATracer nur den Hexdump aus. |
0x0008 | Wie bei der ersten Anfrage |
0x000b | Wie bei der ersten Anfrage |
0x000c | Wie bei der ersten Anfrage |
0x000d | Wie bei der ersten Anfrage |
0x0015 | Enthält einen 32-Bit-Integer aus der Antwort auf die erste Anfrage. Diese ID dient zur Identifikation zusammengehörender Anfragen. |
0x0016 | 32-Bit-Integer, immer 0 |
0x5001 | Wie bei der ersten Anfrage |
0x5002 | Wie bei der ersten Anfrage |
0x5003 | Enthält den Unicode-String "NEWLIC", also die auszuführende Aktion: "Neue Lizenz" |
0x5004 | Wie bei der ersten Anfrage |
Die dritte Anfrage
Die dritte Anfrage wird ebenfalls durch die Methode "AsyncProcessNewLicenseRequest()" angestoßen.
Typ | Beschreibung |
|---|---|
| |
0x0009 | Enthält einen 32-Bit-Integer aus der Antwort auf die zweite Anfrage. Diese ID dient zur Identifikation zusammengehörender Anfragen. |
0x0023 | Enthält ebenfalls einen 32-Bit-Integer aus der Antwort auf die zweite Anfrage. Diese ID dient zur Identifikation zusammengehörender Anfragen. |
0x0024 | 32-Bit-Integer, immer 0 |
0x5001 | Wie bei der ersten Anfrage |
0x5002 | Wie bei der ersten Anfrage |
0x5003 | Enthält den Unicode-String "LICACK", also die auszuführende Aktion: "Lizenz bestätigt" |
0x5004 | Wie bei der ersten Anfrage |
Aktivierung per Internet und Datenschutz
Die an Microsoft übermittelten sensitiven Informationen, also Daten, die nicht für alle Windows-Installationen identisch sind, lassen sich wie folgt zusammenfassen:
1. Produkt-ID: Diese wird aus dem bei der Installation eingegebenen Produkt-Key erstellt. Da (im Falle von Windows XP mit SP1) der Key ebenfalls übertragen wird, handelt es sich nicht um persönliche Daten. Dennoch könnte es sich als sinnvoll erweisen, erst zu aktivieren und dann das Servicepack zu installieren.
2. Spracheinstellung: Dies teilt Microsoft lediglich mit, in welchem Sprachumfeld dieses XP genutzt wird. Bei einer telefonischen Aktivierung erhält Microsoft diese Information indirekt über die Sprache des Anrufers und das Land, aus dem er anruft.
3. Produkt-Code: Enthält die ersten fünf Ziffern der Produkt-ID, also nichts Neues.
4. Hardware-Hash: Dieser Wert repräsentiert die Hardware, auf der XP läuft. Er wird in einer Art und Weise berechnet, die Microsoft keine Rückschlüsse auf die tatsächlich verwendete Hardware ermöglicht.
5. Informationen aus der "WPA.DBL" einer vorherigen Aktivierung: Das sind ohnehin Daten, die XP vom Aktivierungs-Server erhalten hat und die auch keine persönlichen Daten enthalten. Der Server weiß dadurch lediglich, ob es sich um eine neue Aktivierung handelt oder nicht.
6. Produkt-Key: Wurde ohnehin von Microsoft erstellt und auf die CD geklebt. Siehe Produkt-ID.
Lediglich bei der Spracheinstellung und den Informationen aus der "WPA.DBL" handelt es sich um Daten, die Microsoft bei einer telefonischen Aktivierung nicht erhält. Obwohl bei der Aktivierung per Internet mehr Daten übertragen werden, gibt sie dennoch nur unwesentlich mehr Informationen preis als die telefonische Aktivierung.
Offene Fragen
Einige Kleinigkeiten - wie beispielsweise der 2134 Bytes große Datenblock aus der WPA.DBL - lassen jedoch vermuten, dass sich mit späteren Servicepacks an der Aktivierung noch das eine oder andere Detail ändern könnte, wie es schon beim SP1 passiert ist. Dann werden wir sicherlich noch einmal nachschauen.
Weitere "Experimente" mit der Internet-basierten Produktaktivierung drängen sich jedoch auf:
1. Man könnte den letzten Request ("LICACK") unterbinden und eine normale HTTP-Antwort an die COM-Komponente schicken. Diese würde dann annehmen, dass die Aktivierung erfolgreich abgeschlossen wurde, obwohl der Aktivierungs-Server niemals die "LICACK"-Meldung erhalten hat. Es wäre sicherlich interessant herauszufinden, wie der Aktivierungs-Server auf eine solche Situation reagiert.
Es ist durchaus denkbar, dass er dann annimmt, dass die Aktivierung nicht vollständig abgeschlossen wurde und demzufolge ungültig ist. Das würde die Zählung der Aktivierungsprozesse unterbinden und verhindern, dass man irgendwann gezwungen ist, XP telefonisch zu aktivieren, weil man zu oft Hardware ausgetauscht hat.
2. Die COM-Komponente unterstützt auch andere Anfragen. Insbesondere handelt es sich dabei um die "DROPLIC"-Anforderung. Diese könnte beispielsweise dazu dienen, eine XP-Installation zu deaktivieren, um denselben Produkt-Key auf einem anderen Rechner wieder verwenden zu dürfen.
3. Produkt-Keys werden mittels einer digitalen Signatur gegen Key-Generatoren geschützt. Produkt-IDs dagegen sind in keiner Weise geschützt und lassen sich damit sehr einfach fälschen. Interessanterweise wurde bis Servicepack 1 der Produkt-Key nicht bei der Aktivierung per Internet übertragen. Es wäre also möglich, "NEWLIC"-Anfragen mit beliebigen Produkt-IDs zum Aktivierungs-Server zu schicken. Damit könnte man einen Benutzer ausschließen, der sein Windows XP mit einer dieser Produkt-IDs aktivieren will. Das wäre eine Bedrohung für alle legitimen XP-Besitzer. Die Tatsache, dass seit SP1 der Key mit übertragen wird, weist darauf hin, dass diese Bedrohung tatsächlich besteht. (mha)