Extra: For an English version, please click here.
Zahlreiche Spekulationen ranken sich um die Frage, was bei der Aktivierung von Windows XP im Detail geschieht. Welche Informationen werden zu Microsoft übertragen, und wie wirken sich Änderungen der Hardware auf die Aktivierung aus? Die Fully Licensed GmbH hat die Produktaktivierung von Windows XP genau unter die Lupe genommen und in einem White Paper auf ihrer Website veröffentlicht. Zu dem White Paper gehört ein Tool, mit dessen Hilfe Sie die einzelnen Schritte bei der Aktivierung selbst nachvollziehen können.
Inzwischen existiert ein weiteres Tool, das Sie nach einer Aktivierung darüber informiert, welche Komponenten Sie noch ohne erneuter Aktivierung austauschen können. Details dazu finden Sie in unserem Beitrag Der Aktivierung auf der Spur. Zum tieferen Verständnis des folgenden Artikels empfehlen wir Ihnen auch unsere Grundlagenbeiträge zu digitalen Signaturen und Verschlüsselungstechnologien.
Hinweis: Der folgende Text ist eine Übersetzung des White Paper "Inside Windows Product Activation" der Fully Licensed GmbH, Rudower Chaussee 29, 12489 Berlin, Germany. Die dort enthaltenen Aussagen und Meinungen entsprechen nicht unbedingt denen der Redaktion. (mha)
Grundlegende Fragen
Obwohl wir fest davon überzeugt sind, dass jeder Software-Hersteller das Recht hat, seine Lizenzbestimmungen auch mit technischen Mitteln durchzusetzen, glauben wir, dass jeder Anwender das Recht hat, sich detailliert über mögliche Auswirkungen und Einschränkungen zu informieren, die sich dadurch für den Gebrauch der Software ergeben.
Wir wollen die zwei in unseren Augen wichtigsten Fragen im Zusammenhang mit der Windows-Produktaktivierung beantworten:
Welche Informationen werden zur Aktivierung übertragen?
Wie wirken sich Änderungen an der Hardware auf eine bereits aktivierte Windows-XP-Installation aus?
Unsere Aussagen beziehen sich auf Windows XP RC1, Build 2505. Spätere Build-Nummern und das fertige Produkt können davon etwas abweichen, zum Beispiel bei den verwendeten kryptographischen Schlüsseln. Abgesehen von solchen geringen Abweichungen glauben wir nicht, dass Microsoft Grundlegendes am Aktivierungsmechanismus ändert.
Daher sind wir überzeugt, dass unsere Antworten auch bei der endgültigen Version von Windows XP noch hilfreich sind. Falls erforderlich, werden wir aber auch zusätzliche Informationen auf unserer Website bereitstellen.
In diesem Artikel geht es um tief greifende technische Informationen über die internen Vorgänge der WPA. Trotzdem mussten wir an einigen Stellen vage bleiben, um es Crackern nicht zu leicht zu machen, die Lizenzbedingungen zu umgehen.
XPDec, ein Kommandozeilen-Utility, mit dem sich unsere Informationen überprüfen lassen, steht hier zur Verfügung. Es verwendet den Algorithmus, den wir hier vorstellen. Sie sollten auf jeden Fall den Quellcode lesen, den Sie ebenfalls unter der oben genannten Web-Adresse finden.
Wir haben einen wichtigen Kryptoschlüssel aus dem XPDec-Quellcode entfernt. Ein Rekompilieren des Quellcodes erzeugt daher kein brauchbares Programm. Das gilt jedoch nicht für die XPDec-Exe auf unserer Website, die den Schlüssel enthält und voll funktionsfähig ist.
Werfen Sie also einen Blick in den Quellcode, um mehr über die inneren Vorgänge der WPA zu erfahren, aber benutzen Sie die Exe-Datei, um mit Ihrer XP-Installation zu experimentieren.
Wir setzen voraus, dass der Leser mit dem allgemeinen Vorgang der Windows-Produktaktivierung vertraut ist.
Die Installations-ID
Für unsere Analysen haben wir auf die Produktaktivierung über Telefon zurückgegriffen. Wir glauben, dass sich dieses Vorgehen am besten zur Analyse eignet.
Um während des Aktivierungsvorgangs, eingeleitet durch msoobe.exe, keine Internet-Verbindung zuzulassen, zogen wir das Netzwerkkabel heraus. Um völlig sicher zu gehen, steckten wir auch das Modem aus, da eine automatisch aufgebaute Wählverbindung die wahrscheinlichste Alternative bei fehlender Internet-Verbindung ist. Msoobe.exe bot uns dann schließlich auch die manuelle Aktivierungsmöglichkeit per Telefon an.
Bei der telefonischen Aktivierung nennt man dem Call-Center-Mitarbeiter zunächst die Installations-ID, die msoobe.exe anzeigt. Diese ID besteht aus 50 Dezimalziffern, die in Sechsergruppen unterteilt sind:
002666-077894-484890-114573-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX
In dieser tatsächlich vergebenen Installations-ID haben wir einige Stellen durch X ersetzt. Bei jedem Aufruf von msoobe.exe wird übrigens eine neue Installations-ID erzeugt.
Der Call-Center-Mitarbeiter nennt dann eine Bestätigungs-ID, die zu der Installations-ID passt. Die Eingabe der Bestätigungs-ID beschließt den Aktivierungsprozess.
Da die Installations-ID die einzige Information während der Aktivierung ist, könnte man die Frage nach den beim Aktivierungsprozess übertragenen Daten auch anders stellen: Wie wird die Installations-ID erzeugt?
Um die Frage zu beantworten, verfolgen wir jede einzelne Ziffer zurück zu ihrem Ursprung.
Prüfziffern
Die letzte Stelle in jeder Zifferngruppe ist eine Prüfziffer, um etwaige Tippfehler auszuschließen. Der Wert der Prüfziffer wird durch Addition der übrigen fünf Stellen der Gruppe gebildet. Dann addiert der Algorithmus die Ziffern an geraden Positionen hinzu und teilt die Summe durch sieben. Der Divisionsrest ergibt den Wert der Prüfziffer. In unserem obigen Beispiel kommt die Prüfziffer (6) der ersten Zahlengruppe folgendermaßen zu Stande:
Position | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| |||||
Ziffern | 0 | 0 | 2 | 6 | 6 |
Schritt 1 (Addition aller Ziffern)
0 + 0 + 2 + 6 + 6 = 14
Schritt 2 (Addition aller Ziffern an geraden Positionen)
0 + 6 + 14 = 20
Schritt 3 (Division)
20 : 7 = 2, Rest 6
Die Prüfziffer ist somit 6
Die zusätzliche Addition der Ziffern an geraden Positionen wird wahrscheinlich verwendet, um Fehler durch Zahlendreher zu verhindern. 00626 statt 00266 führt dadurch zu unterschiedlichen Prüfziffern.
Dekodierung
Entfernt man die Prüfziffern, ergibt sich eine 41-stellige Dezimalzahl. Eine Dezimalzahl dieser Länge stimmt ungefähr mit einem 136-bittigen Multi-Precision-Integer-Wert überein. Und tatsächlich ist die 41-stellige Zahl nur die dezimale Darstellung eines solchen Integer-Werts, der in einer Little-Endian-Byte-Folge als Byte-Array gespeichert ist. Unsere Installations-ID lässt sich also darstellen als Abfolge von 17 Bytes in hexadezimaler Darstellung (die X stehen für die ausgeblendeten Zeichen):
0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0xXX 0x94 0xAA 0x46 0xD6 0x0F 0xBD 0x2C 0xC8 0x00
Beim Entschlüsseln beliebiger Installations-IDs kann man feststellen, dass das höherwertige Byte entweder 0x00 oder 0x01 ist, während die übrigen Bytes anscheinend zufällig zu Stande kommen. Der Grund liegt darin, dass die niedrigen 16 Bytes der Installations-ID verschlüsselt sind, das höchstwertige Byte hingegen nicht.
Der verwendete kryptographische Algorithmus ist eine proprietäre Feistel-Chiffre mit vier Runden. Da der Block der an eine Feistel-Chiffre übergebenen Eingabe-Bytes in zwei gleich große Blöcke unterteilt wird, wird diese Chiffre-Klasse typischerweise für Eingabeblöcke verwendet, die aus einer geraden Anzahl von Bytes bestehen. In diesem Fall sind das die unteren 16 der 17 Eingabe-Bytes.
Rundenfunktion der Chiffre
Die Rundenfunktion der Chiffre ergibt sich aus dem Algorithmus SHA-1 Message-Digest, verknüpft mit einer Sequenz aus vier Bytes.
Im Folgenden steht + für die Verkettung von zwei Byte-Sequenzen, ^ für die XOR-Verknüpfung, L und R für die linke bzw. rechte Eingabehälfte für eine Runde, L' und R' für die Ausgabehälften dieser Runde und First-8() für eine Funktion, die die ersten acht Bytes eines SHA-1 Message-Digest zurückliefert. Eine Entschlüsselungsrunde sieht dann so aus:
L' = R ^ First-8(SHA-1(L + Key))
R' = L
Als Ergebnis erhält man 16 Bytes im Klartext. Diese werden - zusammen mit dem 17. unverschlüsselten Byte - von nun an interpretiert als vier Double Words in Little-Endian-Byte-Reihenfolge, mit einem einzelnen Byte am Schluss:
Name | Größe | Offset |
|---|---|---|
| ||
H1 | Double Word | 0 |
H2 | Double Word | 4 |
P1 | Double Word | 8 |
P2 | Double Word | 12 |
P3 | Byte | 16 |
H1 und H2 spezifizieren die Hardware-Konfiguration, auf die die Installations-ID verweist. P1, P2 und P3 enthalten die Produkt-ID, die mit der Installations-ID verknüpft ist.
Produkt-ID
Die Produkt-ID besteht aus Gruppen dezimaler Ziffern, wie in diesem Beispiel:
AAAAA-BBB-CCCCCCC-DDEEE
Sucht man in der Registry nach einem Wert "ProductID", findet man die zur jeweiligen Installation passende ID. Im Hilfe/Info-Fenster in Microsofts Internet Explorer findet man die Produkt-ID ebenfalls. Auch die Eigenschaften des Fensters "Arbeitsplatz" zeigen die Produkt-ID an.
Dekodierung
Die Zuordnung zwischen Produkt-ID in dezimaler Schreibweise und der Binärverschlüsselung in die Double-Word-Werte P1, P2 sowie P3 haben wir in der folgenden Tabelle zusammengefasst:
Ziffern | Länge | Verschlüsselung |
|---|---|---|
| ||
AAAAA | 17 Bits | Bit 0 bis Bit 16 von P1 |
BBB | 10 Bits | Bit 17 bis Bit 26 of P1 |
CCCCCCC | 28 Bits | Bit 27 bis Bit 31 von P1 (untere 5 Bits) |
Bit 0 bis Bit 22 von P2 (obere 23 bits) | ||
DDEEE | 17 Bits | Bit 23 bis Bit 31 von P2 (untere 9 bits) |
Bit 0 bis Bit 7 von P3 (obere 8 Bits) |
AAAAA | Offenbar immer 50293 (in XP Beta 2). Bei RC1 ist dies 55034 |
|---|---|
| |
BBB | die höherwertigen drei Ziffern des Raw Product Key |
CCCCCCC | die niederwertigsten sechs Ziffern des Raw Product Key plus Prüfziffer |
DD | Index des öffentlichen Schlüssels, mit dem der Product Key überprüft wird |
EEE | Zufallswert |
Wie ersichtlich ist, spielt der (unverschlüsselte) Product Key beim Erzeugen der Produkt-ID eine entscheidende Rolle.
Der Product Key
Der Raw Product Key steckt im Product Key, der hinten auf jeder XP-CD-Hülle aufgeklebt ist. Er besteht aus fünf Gruppen je fünf alphanummerischer Zeichen, getrennt durch jeweils einen Bindestrich:
FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK
Es gibt 24 gültige alphanummerische Zeichen für Product Keys:
B C D F G H J K M P Q R T V W X Y 2 3 4 6 7 8 9
Ganz ähnlich der Dezimalverschlüsselung der Installations-ID, bilden die 25 Zeichen des Product Key eine Base-24-Kodierung der Binärdarstellung des Product Key. Dekodiert man den Product Key, erhält man einen Multi-Precision-Integer-Wert von annähernd 115 Bits, der - wieder in Little-Endian-Byte-Reihenfolge - in einem Array von 15 Bytes gespeichert wird. Entschlüsseln wir unseren Product Key, erhalten wir folgende Byte-Sequenz:
0x6F 0xFA 0x95 0x45 0xFC 0x75 0xB5 0x52 0xBB 0xEF 0xB1 0x17 0xDA 0xCD 0x00
Von diesen 15 Bytes enthalten die niederwertigsten vier Bytes den Raw Product Key in Little-Endian-Byte-Reihenfolge. Das niederwertigste Bit wird entfernt, indem man diesen 32-Bit-Wert (0x4595FA6F - man denke an die Little-Endian-Byte-Reihenfolge) um ein Bit nach links verschiebt. Dadurch ergibt sich ein Raw Product Key von 0x22CAFD37 oder dezimal 583728439.
Die übrigen elf Bytes bilden eine digitale Unterschrift und erlauben so mit Hilfe eines öffentlichen Schlüssels eine Authentizitätsprüfung des Product Key. Da man den passenden privaten Schlüssel benötigt, um eine gültige Signatur zu erzeugen, lässt sich auf diese Weise verhindern, dass ein Angreifer gültige Product Keys generiert.
Details über das verwendete Schema der digitalen Signatur geben wir nicht bekannt.
Product Key zu Product ID
Die drei höchstwertigen Ziffern der neunstelligen dezimalen Darstellung des Raw Product Key (583 in unserem Beispiel) werden direkt auf die BBB-Komponente unserer Product ID abgebildet.
Um die CCCCCCC-Komponente zu erhalten, wird eine Prüfziffer an die übrigen sechs Ziffern 728439 angehängt. Die Prüfziffer wird so gewählt, dass die Summe aller Ziffern - inklusive der Prüfziffer - durch sieben teilbar ist. Im gewählten Beispiel beträgt die Summe der sechs Ziffern 7 + 2 + 8 + 4 + 3 + 9 = 33, wodurch sich die Prüfziffer 2 ergibt, denn 7 + 2 + 8 + 4 + 3 + 9 + 2 = 33 + 2 = 35. Und das lässt sich durch sieben teilen. Die CCCCCCC-Komponente der Product ID beträgt also 7284392.
Um einen Product Key zu überprüfen, gibt es mehr als einen öffentlichen Schlüssel. Falls die Verifizierung mit dem ersten öffentlichen Schlüssel fehlschlägt, kommt der zweite an die Reihe usw. Die DD-Komponente der Product ID beschreibt, welcher der öffentlichen Schlüssel in dieser Reihenfolge erfolgreich verwendet wurde, um den Product Key zu überprüfen.
Mit unterschiedlichen individuellen privaten Schlüsseln ließen sich durch diesen Mechanismus mehrere verschiedene Teilnehmer unterstützen, die gültige Product Keys erzeugen.
Die verschiedenen privaten Schlüssel könnten aber auch unterschiedliche Versionen eines Produkts darstellen. Ein Product Key für das "Professional" Release könnte mit einem anderen Schlüssel signiert sein als ein Product Key für das "Server" Release. Die DD-Komponente stünde dann für die Produktversion.
Schließlich könnte eine gültige Product ID aus unserem Beispiel auch 55034-583-7284392-00123 lauten. Das hieße, dass der erste öffentliche Schlüssel (DD=Index=0) gepasst hat und 123 als Zufallszahl EEE steht. Diese Zufallszahl (EEE) ist auch der Grund dafür, dass msoobe.exe bei jedem Start eine andere Installations-ID erzeugt.
Hardware-Information
Wie wir festgestellt haben, repräsentieren die zwei Double-Word-Werte H1 und H2 die Hardware-Konfiguration, die mit der Installations-ID verknüpft ist.
Bit-Felder
Zu diesem Zweck sind die Double-Word-Werte in zwölf Bit-Felder aufgeteilt. Die Beziehung zwischen der Computer-Hardware und den Bit-Feldern zeigt die folgende Tabelle:
Double Word | Offset | Länge | Bit-Feld-Wert basierend auf |
|---|---|---|---|
| |||
H1 | 0 | 10 | Volume-Seriennummer des System-Volumes (wird beim dir-Befehl angezeigt) |
H1 | 10 | 10 | die zehn niederwertigsten Bits der MAC-Adresse der Netzwerkkarte (wird bei netstat -r -n angezeigt) |
H1 | 20 | 7 | Identifikations-String des CD-ROM-Laufwerks |
H1 | 27 | 5 | Identifikations-String des Displays |
H2 | 0 | 3 | unbenutzt, steht auf 001 |
H2 | 3 | 6 | die sieben niederwertigsten Bits der CPU-Seriennummer |
H2 | 9 | 7 | Identifikations-String der Festplatte |
H2 | 16 | 5 | Identifikations-String des SCSI-Hostadapters |
H2 | 21 | 4 | Identifikations-String des IDE-Controllers |
H2 | 25 | 3 | String des Prozessormodells |
H2 | 28 | 3 | RAM-Größe |
H2 | 31 | 1 | 1 = Dockingstation, 0 = keine Dockingstation |
Das Bit 31 von H2 spezifiziert, ob es sich bei dem System um ein Notebook handelt, das sich an eine Dockingstation anschließen lässt. Wenn ja, ist der Aktivierungsmechanismus hinsichtlich Modifikationen der Hardware deutlich toleranter, da die Dockingstation ja eine Reihe zusätzlicher Komponenten enthalten könnte.
Wird ein Bit-Feld benutzt, enthält es einen Wert ungleich Null, der die entsprechende Hardware-Komponente beschreibt. Die Null gibt an, dass die entsprechende Komponente nicht vorhanden ist.
Die meisten Hardware-Komponenten liefern einen Identifikations-String wie "PLEXTOR CD-ROM PX-32TS". Der Wert des entsprechenden Bit-Feldes ergibt sich durch den Hash-Wert des Identifikations-Strings.
Hash-basierende Bit-Felder
Den Hash-Wert des Strings erhält man, indem man den MD5-Message-Digest-Algorithmus auf den String anwendet. Anschließend werden die für ein Bit-Feld erforderlichen Bits aus vorbestimmten Positionen in die resultierende Message Digest genommen. Für verschiedene Bit-Felder benutzt man unterschiedliche Positionen. Einen Hash-Wert von Null schließt man durch folgende Berechnung aus:
Hash = (Hash % BitFieldMax) + 1
BitFieldMax steht für den Maximalwert, der in dem betreffenden Bit-Feld gespeichert werden kann, etwa 1023 für ein 10-Bit-Feld. "x % y" steht für den Divisionsrest von x durch y. Das führt zu Werten zwischen 1 und BitFieldMax. Das Resultat wird dann im jeweiligen Bit-Feld gespeichert.
RAM Bit-Feld
Das Bit-Feld für die RAM-Größe wird anders berechnet als die übrigen. Die sieben gültigen Werte des RAM-Bit-Feldes geben die ungefähre RAM-Größe an:
Wert | RAM-Größe |
|---|---|
| |
0 | (unbenutztes Bit-Feld) |
1 | weniger als 32 MByte |
2 | zwischen 32 MByte und 64 MByte |
3 | zwischen 64 MByte und 128 MByte |
4 | zwischen 128 MByte und 256 MByte |
5 | zwischen 256 MByte und 512 MByte |
6 | zwischen 512 MByte und 1 GByte |
7 | mehr als 1 GByte |
Ein konkretes Beispiel
Schauen wir uns ein konkretes Beispiel an. Auf einem unserer Testsysteme ergibt sich die Hardware-Information aus den folgenden acht Bytes:
0xC5 0x95 0x12 0xAC 0x01 0x6E 0x2C 0x32
Konvertiert man die Bytes in H1 und H2, erhält man:
H1 = 0xAC1295C5 und H2 = 0x322C6E01
Teilt man H1 und H2 auf, ergibt sich folgende Tabelle, aus der man den Wert jedes Bit-Felds entnehmen kann:
Double Word | Offset | Wert | Hash von |
|---|---|---|---|
| |||
H1 | 0 | 0x1C5 | 1234-ABCD |
H1 | 10 | 0x0A5 | 00C0DF089E44 |
H1 | 20 | 0x37 | SCSI\\CDROMPLEXTOR_CD-ROM_PX-32TS__1.01 |
H1 | 27 | 0x15 | PCI\\VEN_102B&DEV_0519&SUBSYS_00000000&REV_01 |
H2 | 0 | 0x1 | (unbenutzt, immer 0x1) |
H2 | 3 | 0x00 | (processor serial number, nicht vorhanden) |
H2 | 9 | 0x37 | SCSI\\DISKIBM_____DCAS-34330______S65A |
H2 | 16 | 0x0C | PCI\\VEN_9004&DEV_7178&SUBSYS_00000000&REV_03 |
H2 | 21 | 0x1 | PCI\\VEN_8086&DEV_7111&SUBSYS_00000000&REV_01 |
H2 | 25 | 0x1 | GenuineIntel Family 6 Model 3 |
H2 | 28 | 0x3 | (128 MB RAM) |
H2 | 31 | 0x0 | (keine Dockingstation) |
Das XPDec-Utility
XPDec ist ein Kommandozeilen-Utility. Es lässt sich mit je einem von vier Parametern aufrufen.
XPDEc -i
Mit dieser Option greift man auf die Informationen zu, die sich in der Installations-ID verbergen. Die Installations-ID wird dekodiert, und die Werte der Hardware-Bit-Felder sowie die Product ID werden ausgegeben. Beachten Sie, dass die letzten drei Ziffern der Product-ID zufällig erzeugt werden und sich deshalb von denen im Internet Explorer unterscheiden.
Das einzige Argument, das -i benötigt, ist die Installations-ID:
XPDec -i 002666-077894-484890-114573-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XX
XPDec -p
Um die Herkunft des Product Key zu entschlüsseln, dekodiert dieser Aufruf einen Product Key und zeigt den Raw Product Key an, so wie er in einer Product ID verwendet werden würde.
Das einzige Argument, das -p benötigt, ist der Product Key:
XPDec -p FFFFF-GGGGG-HHHHH-JJJJJ-KKKKK
Bitte beachten Sie, dass diese Option nicht die digitale Signatur des Product Key überprüft.
XPDec -v
Diese Option berechnet den Hash-Wert einer bekannten Volume-Seriennummer. Wir haben diese Möglichkeit implementiert, um unsere Beschreibung des String-Hash-Werts zu veranschaulichen. Verwenden Sie zuerst -i, um die Hardware-Bit-Felder anzuzeigen, danach -v, um unsere Behauptung bezüglich des Hash-Werts der Volume-Seriennummer zu überprüfen. Die Seriennummer des System-Volumes erhalten Sie, indem Sie den dir-Befehl aufrufen.
Das einzige Argument, das -v benötigt, ist die Seriennummer Ihres System-Volumes:
XPDec -v 1263-18D1
XPDec -m
Diese Option berechnet den Bit-Feld-Wert der Netzwerkkarte aus einer bekannten MAC-Adresse. Ähnlich wie bei -v haben wir diese Option als "Proof of Concept" implementiert. Die MAC-Adresse erhalten Sie, indem Sie den Befehl netstat -r -n aufrufen.
Das einzige Argument, das -m benötigt, ist die MAC-Adresse Ihrer Netzwerkkarte:
XPDec -m 01-23-45-67-89-AB
Änderungen an der Hardware
Sieht man sich an, welche Auswirkungen Änderungen an der Hardware auf eine bereits aktivierte XP-Installation haben, fällt der Datei wpa.dbl aus dem Windows-System32-Verzeichnis eine zentrale Rolle zu. Bei dieser Datei handelt es sich um eine einfache RC4-verschlüsselte Datenbank. Darin finden sich neben anderen Informationen wie dem Ablaufdatum oder der Bestätigungs-ID einer aktivierten Installation:
a) die Bit-Felder-Werte, die für die aktuelle Hardware-Konfiguration stehen
b) die Bit-Felder-Werte, die für die Hardware-Konfiguration zum Zeitpunkt der Produktaktivierung stehen
Während a) bei jeder Modifikation der Hardware-Konfiguration automatisch aktualisiert wird, um die Änderungen zu dokumentieren, bleibt b) unangetastet. Man kann sich b) also wie eine Inventarliste der Hardware-Konfiguration zum Zeitpunkt der Produktaktivierung vorstellen. Diese Liste existiert vor der Produktaktivierung nicht in der Datenbank. Vergleichen Sie die Größe von wpa.dbl vor und nach der Aktivierung, werden Sie eine Zunahme der Dateigröße feststellen, da ja die "Inventarliste" hinzukommt.
Wenn es um die Entscheidung geht, ob eine erneute Aktivierung nötig ist, werden die zehn Bit-Felder-Werte von a) mit den entsprechenden Werten von b) verglichen. Die aktuelle Hardware-Konfiguration wird also mit der Hardware-Konfiguration zum Zeitpunkt der Aktivierung verglichen.
Dabei wird unterschieden, ob es sich um einen "dockbaren" Computer handelt oder nicht. Lässt sich der Computer nicht an eine Dockingstation anschließen, muss bei mehr als drei geänderten Bit-Feld-Werten eine erneute Aktivierung erfolgen. Das bedeutet in unserem konkreten Beispiel etwa, dass wir die Festplatte und das CD-ROM-Laufwerk austauschen sowie ordentlich RAM nachrüsten könnten, ohne die XP-Aktivierung noch einmal durchführen zu müssen. Wenn wir jedoch XP noch einmal komplett neu installieren würden, wären die Informationen in b) verloren, und wir müssten unsere Installation erneut aktivieren, obwohl wir nichts an unserer Hardware geändert haben.
Bei einem Notebook mit Dockingstation vergleicht Windows XP lediglich sieben der zehn Bitfelder. Die Felder für SCSI-Hostadapter, IDE-Controller und Grafikkarte werden ignoriert. Ändern sich mehr als drei der anderen sieben Bitfelder, ist dennoch eine Neuaktivierung notwendig.
Fazit
Wir haben einen technischen Überblick über die Windows-Produkt-Aktivierung (WPA) gegeben, so wie sie in Windows XP implementiert ist. Wir haben gezeigt, wie die während der Produktaktivierung übertragenen Informationen gewonnen werden und wie Hardware-Upgrades eine bereits aktivierte Installation beeinflussen.
Betrachtet man die technischen Details, so glauben wir nicht, dass die Produktaktivierung derart problematisch ist, wie viele erwartet haben. Wir denken dies, da WPA tolerant auf Hardware-Modifikationen reagiert.
Außerdem ist es wahrscheinlich, dass verschiedene Hardware-Komponenten auf denselben Wert eines bestimmten Bitfeldes verweisen. Aus unserem konkreten Beispiel wissen wir, dass das CD-ROM-Laufwerk PX-32TS mit dem Wert 0x37 (55) repräsentiert ist. Aber es gibt wahrscheinlich viele andere Laufwerke mit genau diesem Wert.
Daher erscheint es uns unmöglich, aus dem Bit-Feld-Wert zu schließen, ob wir ein PX-32TS benutzen oder ein anderes Laufwerk.
Kurz gesagt: Wir glauben, dass die Windows-Produkt-Aktivierung das Recht auf Privatsphäre nicht verletzt und niemanden davon abhält, typische Hardware-Änderungen vorzunehmen. (Fully Licensed GmbH)