Datenschutz bei Windows-Update hieß beim Start des Dienstes noch, dass keinerlei Informationen an Microsoft gesendet werden. Diese Aussage und das Fehlen verdächtiger Datenpakete beruhigten die Gemüter zunächst, doch die Zeiten haben sich geändert: Die neue Version des Update-ActiveX-Controls sendet eine ganze Menge Daten an den Microsoft-Server.
Bis vor kurzem gab es von Microsoft keine Informationen über die gesendeten Daten. Das hat sich geändert, seit Microsoft sein Privacy Whitepaper veröffentlicht hat. Dennoch bleibt ein Rest Unsicherheit, denn die Daten werden verschlüsselt übertragen, so dass der Benutzer nicht nachvollziehen kann, welche Informationen nun wirklich über die Leitung gehen. Dieser Artikel zeigt im Detail, welche Daten an den Update-Server übertragen werden.
Grundlegende Beobachtungen
Die Windows-Update-Site besteht aus ein paar HTML-Seiten mit viel Javascript-Code und einer zentralen COM-Komponente. Diese Bausteine werden beim Aufruf der Windows-Update-URL auf den Rechner des Benutzers übertragen. Die Hauptaufgabe des Javascript-Codes ist die Interaktion mit dem Benutzer. Das ist einfach herauszufinden, da der Sourcecode im Klartext vorliegt und ohne Probleme separat heruntergeladen werden kann. Erheblich interessanter ist die in der COM-Komponente versteckte Funktionalität.
Wenn der Benutzer sich die Liste der verfügbaren Updates anzeigen lässt, fließen nicht nur Daten vom Update-Server auf den Rechner des Benutzers - es werden auch einige Kilobyte in die andere Richtung übertragen. Und das sind die potenziell interessanten Informationen, die allerdings über eine SSL-verschlüsselte Verbindung gesendet werden. Aus diesem Grund lassen sie sich nicht per Netzwerk-Sniffer überprüfen. Es gilt also, sich in den Datenstrom einzuklinken, bevor er verschlüsselt wird.
Einhaken in die WinInet-API
Unser erster Ansatz nutzt die Tatsache, dass Windows-Update die in Windows integrierte WinInet-Programmierschnittstelle nutzt, um die SSL-Verbindung aufzubauen und die Daten zu transferieren. Glücklicherweise lässt es die API zu, sich in die Funktion HttpOpenRequest() einzuklinken, so dass wir die übergebenen Argumente untersuchen können. Hier stellt sich heraus, dass es sich dabei um HTTP-POST-Anfragen handelt, also einen Seitenaufruf mit Parameterübergabe. Diese Parameter erhält die WinInet-API von der Funktion InternetWriteFile(), in die wir uns als Nächstes einschalten. Damit erhalten wir Zugriff auf die gesendeten Daten, bevor sie verschlüsselt und übertragen werden.
Genau diese beiden Schritte übernimmt das kleine Utility tecDump, zunächst hakt es sich in die Funktionen HttpOpenRequest() und InternetWriteFile() ein. Danach startet es den Internet Explorer mit der URL von Windows-Update. Wenn Sie nun auf "Updates suchen" klicken, aktiviert sich das Tool und speichert die übertragenen Daten in der zuvor ausgewählten Datei.
Bitte beachten Sie: Alle Programme, die wir Ihnen mit diesem Artikel zur Verfügung stellen, basieren auf dieser undokumentierten Verhaltensweise von Windows-Update. Es ist möglich, dass ein Update wie beispielsweise ein Service Pack oder Hotfix dieses Verhalten verändert und die Programme dadurch nicht mehr funktionieren.
Das Kommunikations-Protokoll
Das Resultat des Programms tecDump zeigt, dass Windows-Update mittels einer POST-Anfrage SOAP-Nachrichten an den Microsoft-Server schickt. SOAP (Simple Object Access Protocol) ist ein XML-basiertes Protokoll zur Kommunikation mit Webdiensten und ein elementarer Baustein der .NET-Strategie von Microsoft. Die abgefangenen Nachrichten haben folgendes Format:
<SOAP:Envelope xmlns:SOAP="x-schema:http://schemas.xmlsoap.org/soap/envelope/">
<SOAP:Body>
<GetManifest>
<clientInfo [...]> [...] </clientInfo>
<systemInfo [...]>
<computerSystem [...]>
[...]
</computerSystem>
<platform [...]>
[...]
</platform>
<locale [...]>
[...]
</locale>
<devices [...]>
[...]
</devices>
</systemInfo>
<query [...]> [...] </query>
</GetManifest>
</SOAP:Body>
</SOAP:Envelope>
Die Tags SOAP:Envelope und SOAP:Body kapseln die zu transportierende Nutzlast, die den Namen der auf dem Server aufzurufenden Funktion und die zu übergebenden Argumente enthält. Der Server startet dann die gewünschte Funktion und kapselt wiederum das Ergebnis in eine SOAP-Meldung, die in der HTTP-Antwort an den Client geschickt wird.
Die nachfolgenden Seiten können Sie nur im Exklusivbereich für tecCHANNEL-Premiumkunden lesen. Der vollständige Artikel bleibt jedoch weiterhin als PDF-Download zugänglich. Klicken Sie einfach unten auf "Artikel Druck/Download".
Premium-Abonnenten haben zudem kostenlosen Zugriff auf die Analyse-Software. Im freien Bereich können Sie die Software für 4,90 Euro herunterladen. Nutzen Sie für die Downloads bitte die Links in der rechten Artikelnavigation. Mehr Infos zu tecCHANNEL-Premium gibt es hier.
Die Interaktion mit dem Microsoft-Server
In der abgefangenen Nachricht heißt die aufgerufene Funktion GetManifest, sie veranlasst den Server dazu, Informationen über verfügbare Updates zurückzuliefern. Als Argumente werden clientInfo, systemInfo und query übergeben. Die XML-Schemata für clientinfo und systeminfo sind an den folgenden URLs zu finden, das Schema für query ist nicht bekannt.
http://schemas.windowsupdate.com/iu/clientInfo.xml
http://schemas.windowsupdate.com/iu/systeminfoschema.xml
Der Parameter clientInfo soll scheinbar den zugreifenden Benutzer bei Microsoft identifizieren und authentifizieren. Derzeit ist der Server jedoch für jedermann zugänglich, und das Tag enthält lediglich die generische Kennung "IU_Site". Generell ist es aber möglich, den Zugang anhand von Benutzerkennungen zu regeln, beispielsweise bestimmte Updates nur Benutzern zur Verfügung zu stellen, die einen Support-Vertrag haben.
Die Programme nutzen undokumentierte Funktionen des Windows-Updates. Ein Service Pack oder ein Hotfix kann das ändern. Als Folge würden die Programme nicht mehr funktionieren. Wir können daher keinen Support und keine Funktionsgarantie für die Software tecControl.exe, tecDump.exe und tecDecode.exe übernehmen
Parameter: Query
Das Argument query spezifiziert, wie detailliert die zurückzugebenden Informationen sein sollen. Wir konnten vier verschiedene Stufen identifizieren: Provider, Products, Items und DriverUpdates:
Provider - Der Server liefert alle Produktkategorien zurück, für die er Updates bereitstellt, wie beispielsweise ie60x für den Internet Explorer 6.x oder winxp für die verschiedenen Versionen von Windows XP. Außerdem gibt er entsprechende Regeln aus, anhand derer der Client feststellen kann, ob ein bestimmtes Produkt installiert ist oder nicht. Bei den Regeln handelt es sich um Boolsche Ausdrücke in einer XML-basierten Sprache. So lautet die Regel für die Produktkategorie ie60x zum Beispiel, dass der Registry-Eintrag HKLM\\SOFTWARE\\Microsoft\\Internet Explorer\\Version einen Wert größer gleich 6.0 und kleiner 7.0 haben muss.
Products - Das Argument für query enthält eine Liste mit Produktkategorien, für die der Server eine Liste mit Updates schicken soll, also beispielsweise winxp.windowsxpcore für die XP-Komponenten, die in allen Windows-Versionen enthalten sind, winxp.windowsxp für Komponenten von Windows XP Home oder Professional und winxp.windowsnetserverfamily für Bestandteile der .NET-Server-Reihe.
Items - Das Argument enthält eine Liste von Produkten, und der Server antwortet mit detaillierten Informationen über die verfügbaren Updates.
DriverUpdates - Der Microsoft-Server liefert Informationen über relevante Treiber für dieses System. Die SOAP-Nachrichten für GetManifest-Aufrufe sind hier bedeutend länger als die anderen beobachteten Nachrichten.
Die Stufen Provider, Products und Items bilden eine Hierarchie. Windows-Update fragt den Microsoft-Server zunächst mittels "Provider" nach den unterstützten Produktkategorien und ermittelt dann anhand der gelieferten Regeln lokal die relevanten Kategorien. Anhand derer befragt es den Server über "Products" nach den Produkten in den Kategorien und letztlich nach den für die ermittelten Produkte verfügbaren Updates.
Parameter: systemInfo
Das Argument systemInfo besteht aus vier Teilen: computerSystem, platform, locale und devices.
computerSystem - Dieser Teil ist sehr kurz und enthält lediglich generelle Informationen über das System, wie beispielsweise Hersteller und Modell des Motherboards oder freier Platz auf den einzelnen Partitionen. Allerdings findet sich dort auch ein Element namens pid, bestehend aus 76 scheinbar zufälligen Bytes, die durch 152 Hex-Ziffern dargestellt sind. Der Verdacht drängt sich auf, dass hier verschlüsselte Informationen übertragen werden. Mit dieser pid beschäftigen wir uns später noch genauer.
platform - Dieses XML-Element beschreibt das verwendete Betriebssystem mit Versions- und Build-Nummer, Prozessorarchitektur und dem installierten Service Pack.
locale - Da die meisten Updates sprachspezifisch sind, enthält dieser Teil die Spracheinstellungen des Betriebssystems und des aktuellen Benutzers.
devices - Dieses Element ist der bei weitem größte Bestandteil der übertragenen Informationen. Es ist nur vorhanden, wenn GetManifest mit der Option "DriverUpdates" gestartet wurde. Um die für den Client relevanten Treiber-Updates ermitteln zu können, benötigt der Update-Server genaue Informationen über die installierte Hardware - im Gegensatz zur Produktaktivierung, bei der nur ein Hash-Wert übermittelt wird. Bei Massenspeichern wird beispielsweise die IDE- oder SCSI-ID übermittelt, die explizit Hersteller, Modell und Revision des Geräts enthält. Der folgende Ausschnitt zeigt eine IDE-ID, die das DVD-Laufwerk SD-C2002 von Toshiba repräsentiert:
<hwid rank="0">
IDE\\CdRomTOSHIBA_DVD-ROM_SD-C2002________________1120____
</hwid>
Für Plug-and-Play-Geräte werden die nummerische Hersteller- und Geräte-ID aufgelistet, über die sich das Gerät ermitteln lässt. Das folgende Beispiel repräsentiert einen Cyber 9397 Grafikchip (Geräte-ID 9397) von Trident (Hersteller-ID 1023):
<hwid rank="0">
PCI\\VEN_1023&DEV_9397&SUBSYS_00000000&REV_F3
</hwid>
Das pid-Feld
Die übertragenen XML-Daten sind mehr oder weniger einfach zu lesen und zu analysieren, sobald man sich in den SSL-Datenstrom eingeklinkt hat. Die einzige Ausnahme stellt das pid-Feld dar.
Die darin enthaltenen 76 Bytes sind mittels einer erweiterten Version des TEA (Tiny Encryption Algorithm) verschlüsselt. TEA ist ein in der Kopierschutzbranche weit verbreiteter symmetrischer Algorithmus. Die Wahl der Verschlüsselung überrascht nicht, da das pid-Feld von einer XP-Komponente erzeugt wird, die auch bei der Produktaktivierung Verwendung findet. Um das Feld zu entschlüsseln, können wir die folgenden C-Funktionen nutzen:
void xtea_decrypt(unsigned char *data, unsigned int *key)
{
[...]
}
void pid_decrypt(unsigned char *pid)
{
unsigned int key[4] = { [...] };
int i;
for (i = 68; i >= 0; i--)
xtea_decrypt(pid + i, key);
}
Das entschlüsselte Feld besteht aus drei Teilen. Die ersten acht Bytes enthalten einen Zeitstempel im FILETIME-Format (siehe Microsoft SDK), der den Zeitpunkt angibt, an dem das Feld erzeugt wurde. Aus diesem Grund wird auch bei mehrfachen Aufrufen von tecDump immer ein verschiedenes pid-Feld generiert.
Produkt-ID im pid-Feld
Die letzten 48 Bytes des Feldes enthalten die Produkt-ID von Windows XP als Null-terminierten Unicode-String. Produkt-IDs haben das folgende Format:
12345-123-1234567-12345
Die Produkt-ID lässt sich über Systemsteuerung/System ermitteln. Die zehn Ziffern der zweiten und dritten Gruppe werden dabei aus dem Produkt-Key ermittelt, der zur Installation von Windows verwendet wurde. Produkt-Keys sehen wie folgt aus:
ABCDE-ABCDE-ABCDE-ABCDE-ABCDE
Der durch die zehn Ziffern repräsentierte Wert wird mit einer digitalen Signatur kombiniert und dann mittels 25 Buchstaben und Ziffern kodiert, um den Produkt-Key zu erzeugen. Microsoft erzeugt die Signatur mit seinem geheimen Schlüssel, und Windows XP kann die Signatur über den passenden öffentlichen Schlüssel überprüfen. Nähere Details zum Zusammenhang zwischen Produkt-Key und Produkt-ID finden Sie in diesem Artikel über die Produkt-Aktivierung.
Also identifizieren die zweite und die dritte Zifferngruppe der Produkt-ID eindeutig den zur Installation verwendeten Key. Somit ist Microsoft in der Lage, illegale Keys, die beispielsweise durch Filesharing-Netze kursieren, zu identifizieren und zu sperren.
Absicherung der Produkt-ID im pid-Feld
Wäre lediglich die Produkt-ID im pid-Feld, könnten Hacker einfach ein Tool wie tecDump schreiben, das die an den Update-Server übermittelten Daten mit einer zufälligen Produkt-ID überschreibt, die wie eine gültige ID aussieht. Besser wäre es also, stattdessen den Produkt-Key zu übermitteln, weil dieser durch eine digitale Signatur geschützt ist. Doch dann könnten Hacker einen Trojaner entwickeln, um gültige Produkt-Keys von unwissenden Benutzern zu sammeln.
Also benötigt Microsoft einen Weg, die Produkt-ID zu übertragen und gleichzeitig sicherzustellen, dass es sich um die zum verwendeten Key passende ID handelt und nicht um irgendeine zufällig erzeugte. Dazu benutzt Microsoft die restlichen 20 Bytes im pid-Feld, also die Werte zwischen Offset 8 und 27. Diese enthalten einen SHA-1-Hash des Produkt-Keys.
Das pid-Feld lässt sich also mit folgenden einfachen Schritten validieren:
1. pid-Feld entschlüsseln
2. Produkt-ID extrahieren
3. Mittels des geheimen Schlüssels eine Signatur der ID erzeugen
4. Aus der ID und der Signatur den Produkt-Key erstellen
5. SHA-1 aus dem Key generieren und mit dem SHA-1 aus dem pid-Feld vergleichen
Stimmt der SHA-1 nicht überein oder ist der Produkt-Key gesperrt, verweigert der Windows-Update-Server die Zusammenarbeit.
Die COM-Komponente
Auf dem Client-Rechner ist die COM-Komponente iuctl.dll zentraler Bestandteil von Windows-Update. Normalerweise kann man solche Komponenten auch ohne Probleme von anderen Applikationen aus starten und die eingebetteten Objekte instanziieren, allerdings liegt der Fall hier etwas anders. Die DLL iuctl.dll überprüft explizit, ob sie vom Internet Explorer gestartet wurde und lässt sich nur mit URLs verwenden, die mit http://v4.windowsupdate.microsoft.com/ anfangen.
Dazu überprüft die Komponente die Sektion [IUServerURLs] in der Datei \\Programme\\WindowsUpdate\\V4\\iuident.txt. Dort sind die erlaubten Update-Server enthalten, per Default findet sich dort lediglich der Eintrag http://v4.windowsupdate.microsoft.com/.
Um die Komponente zu täuschen, erzeugen wir ein WebBrowserApp-Object und implementieren eine spezielle LocationUrl()-Funktion, die immer http://v4.windowsupdate.microsoft.com/ als aktuellen Server zurückliefert. Im nächsten Schritt gaukeln wir der iuctl.dll den Internet Explorer vor, indem wir die Methode SetSite() der IObjectWithSite-Schnittstelle mit unserem WebBrowserApp-Objekt füttern. Wenn nun iuctl.dll die URL ermitteln will, ruft es das gefälschte LocationUrl() auf und erhält das gewünschte Ergebnis.
Automatische Update-Aktualisierung
Die Komponente enthält eine Typbibliothek, die das IUpdate-Interface beschreibt, das wir nun benutzen können. Zwei Funktionen sind hier relevant für uns:
long Initialize(long flag, IUnknown *unk)
BSTR GetSystemSpec(BSTR classes)
Als Erstes ist Initialize() aufzurufen, um die Komponente zu initialisieren. Die genaue Bedeutung des Parameters flag ist nicht dokumentiert, aber wir übergeben einfach den Wert 0, wie es der Javascript-Code von windowsupdate.microsoft.com auch tut. Initialize kontaktiert nun den Microsoft-Server und sucht nach einer neueren Version der Komponente. Ist ein Update erforderlich, kommt der zweite Parameter ins Spiel. Dieser verweist auf die IUnknown-Schnittstelle eines UpdateCompleteListener-Objekts, das ebenfalls in der Typbibliothek definiert ist und scheinbar nach erfolgreicher Aktualisierung aufgerufen werden sollte. Der Einfachheit halber setzen wir diesen Parameter auf NULL, so dass Updates hier nicht möglich sind.
GetSystemSpec()
Nach erfolgreicher Initialisierung der Komponente können wir GetSystemSpec() aufrufen, um einen XML-String mit den Systeminformationen zu erhalten. Der Inhalt entspricht dem, was wir schon aus der Analyse des Datenverkehrs mit dem Update-Server wissen.
GetSystemSpec() nimmt einen Parameter, der die auszugebenden systemInfo-Argumente bestimmt. Es handelt sich dabei um einen XML-String, der eine Kombination aus den folgenden fünf Tags enthält:
<computerSystem/>, <platform/>, <locale/>, <devices/> und <regKeys/>
Diese Tags müssen von <classes> und </classes> eingeschlossen sein, also beispielsweise
<classes><computerSystem /><platform /><locale /><devices /></classes>
Die ersten vier Tags kennen wir schon, sie entsprechen den vier Teilen des systemInfo-Arguments in GetManifest(). Das letzte - <regKeys/> - wird zwar von der Komponente unterstützt, aber derzeit nicht von Windows-Update verwendet.
Das Utility tecControl
Die bereits beschriebenen Verfahren haben wir der Einfachheit halber in dem kleinen Tool tecControl implementiert, damit Sie herausfinden können, was gegebenenfalls über Ihre Hardware-Konfiguration an Microsoft gesendet wird.
Das Tool unterstützt wie schon beschrieben kein Update der COM-Komponente. Gegebenenfalls müssen Sie vor Benutzung des Utilitys einmal Windows-Update aufrufen, damit Sie die neueste Version des Update-Controls haben. Setzen Sie lediglich ein Häkchen vor die Informationen, die Sie sehen wollen, und wählen Sie einen Speicherort für das Ergebnis aus. Die XML-Datei können Sie mit dem Internet Explorer oder einem anderen Utility wie XML Spy nun genauer unter die Lupe nehmen.
Wie Sie nun feststellen werden, erzeugt das <regKeys/>-Tag eine Liste von Registry-Schlüsseln unterhalb HKLM\\SOFTWARE, also Informationen über die Hersteller aller auf dem Rechner installierten Software-Pakete.
Passend zu tecControl.exe finden Sie im Archiv das Programm tecDecode.exe. Dieses extrahiert das pid-Feld aus der XML-Datei und analysiert es. Wenn Sie noch den Produkt-Key angeben, vergleicht es diesen mit der Produkt-ID aus dem XML.
Fazit
Die von uns ermittelten Details bestätigen die vagen Informationen, die Microsoft über die neue Version von Windows-Update macht. Ein ungutes Gefühl bleibt allerdings, denn die Kombination aus eindeutiger Produkt-ID und der kompletten Liste von Hardware-Komponenten ermöglicht eine eindeutige Identifizierung des Rechners des Benutzers. Über die IP-Adresse ließe sich letztlich dann auch noch der Benutzer ermitteln. Allerdings betont Sascha Hanke, Datenschutzbeauftragter bei Microsoft Deutschland, dass die übertragenen Daten nicht bei Microsoft gespeichert werden.
Bei den älteren Versionen von Windows-Update wählte Microsoft einen anderen Ansatz. Dabei wurde die Liste mit allen verfügbaren Updates an den Client geschickt, der sich dann lokal die relevanten heraussuchen konnte, so dass keinerlei private Daten an Microsoft verschickt werden mussten. Leider fehlt beim "modernen" Windows-Update die Möglichkeit, sich nur über Betriebssystem-Aktualisierungen informieren zu lassen, also ohne Treiber. In dem Falle wäre es auch möglich, ohne die Liste mit Hardware-Komponenten auszukommen.
Weiterhin ließe sich die Server-seitige Filterung dazu missbrauchen, die auf dem Rechner installierte Software zu ermitteln. Angenommen Microsoft wollte herausfinden, ob auf dem Rechner Mozilla 1.0 läuft, müsste man lediglich eine Produktkategorie dafür erzeugen, also beispielsweise mo10, entsprechende Regeln hinzufügen, um Mozilla zu finden, etwa die Überprüfung auf den Registry-SchlüsselHKEY_LOCAL_MACHINE\\SOFTWARE\\Mozilla\\Mozilla 1.0, und dann bei einem Provider-Query die Kategorie mo10 mitliefern. Windows-Update würde nachschauen, ob Mozilla installiert ist und gegebenenfalls per Product-Query ein Update beim Microsoft-Server anfordern. Damit wüsste Microsoft, dass Mozilla auf dem Rechner installiert ist.
Neue Produktkategorien könnten allerdings für nützliche Zwecke verwendet werden. Mit ihnen lässt sich der Update-Service auf andere Software-Hersteller ausweiten, um dem Benutzer eine zentrale Stelle für all seine Software-Updates zu bieten. Außerdem könnte Microsoft damit sein Geschäftsmodell weiter in Richtung Dienste-Anbieter ausbauen und zusätzliche Einnahmen verbuchen. Laut Sascha Hanke erwägt man bei Microsoft, den Update-Dienst auch anderen Herstellern zu öffnen.
Die derzeit noch ungenutzte Möglichkeit, per <regKeys/>-Tag zudem die Liste aller Hersteller von installierter Software auszugeben, wirft für die Zukunft weitere Fragen auf. (mha)
Update: Beispielhafte HW-Config
Hier finden Sie eine Hardware-Konfiguration, wie sie vom Update-Control erstellt und an Microsoft übermittelt wird.
<?xml version="1.0"?>
<systemInfo xmlns="x-schema:http://schemas.windowsupdate.com/iu/systeminfoschema.xml">
<computerSystem xmlns="" manufacturer="MICRO-STAR INTERNATIONAL CO., LTD" model="MS-6163" supportSite="" pid="siehe Text" administrator="1">
<driveSpace drive="C:\" kbytes="903418"/>
<driveSpace drive="D:\" kbytes="1263540"/>
</computerSystem>
<platform xmlns="" name="VER_PLATFORM_WIN32_NT">
<processorArchitecture>x86</processorArchitecture>
<version major="5" minor="1" build="2600" servicePackMajor="1" servicePackMinor="0"/>
<suite>VER_SUITE_SINGLEUSERTS</suite>
<productType>VER_NT_WORKSTATION</productType>
</platform>
<locale xmlns="" context="OS">
<language>de-DE</language>
</locale>
<locale xmlns="" context="USER">
<language>de-DE</language>
</locale>
<devices xmlns="">
<device>
<hwid rank="0" driverVer="2001-06-06|5.1.2001.0">Monitor\\Default_Monitor</hwid>
</device>
<device>
<hwid rank="0">FDC\\GENERIC_FLOPPY_DRIVE</hwid>
<compid rank="1" driverVer="2001-07-01|5.1.2600.0">GenFloppyDisk</compid>
</device>
<device>
<hwid rank="0">IDE\\CdRomLITEON_CD-ROM_LTN382____________________UL28____</hwid>
<hwid rank="1">IDE\\LITEON_CD-ROM_LTN382____________________UL28____</hwid>
<hwid rank="2">IDE\\CdRomLITEON_CD-ROM_LTN382____________________</hwid>
<hwid rank="3">LITEON_CD-ROM_LTN382____________________UL28____</hwid>
<hwid rank="4" driverVer="2001-07-01|5.1.2535.0">GenCdRom</hwid>
</device>
<device>
<hwid rank="0">IDE\\DiskWDC_AC310200R___________________________17.01J17</hwid>
<hwid rank="1">IDE\\WDC_AC310200R___________________________17.01J17</hwid>
<hwid rank="2">IDE\\DiskWDC_AC310200R___________________________</hwid>
<hwid rank="3">WDC_AC310200R___________________________17.01J17</hwid>
<hwid rank="4" driverVer="2001-07-01|5.1.2535.0">GenDisk</hwid>
</device>
<device>
<hwid rank="0">ISAPNP\\CTL00f0_DEV0000</hwid>
<hwid rank="1" driverVer="2001-07-01|5.1.2535.0">*CTL0043</hwid>
</device>
<device>
<hwid rank="0">ISAPNP\\CTL00f0_DEV0001</hwid>
<hwid rank="1" driverVer="1998-09-23|5.0.0.0">*CTL7005</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">ISAPNP\\ReadDataPort</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">LPTENUM\\MicrosoftRawPort958A</hwid>
</device>
<device>
<hwid rank="0">PCI\\VEN_102B&DEV_0525&SUBSYS_0338102B&REV_05</hwid>
<hwid rank="1" driverVer="2001-09-28|5.72.21.0">PCI\\VEN_102B&DEV_0525&SUBSYS_0338102B</hwid>
</device>
<device>
<hwid rank="0">PCI\\VEN_10EC&DEV_8139&SUBSYS_813910EC&REV_10</hwid>
<hwid rank="1" driverVer="2001-07-01|5.396.530.2001">PCI\\VEN_10EC&DEV_8139&SUBSYS_813910EC</hwid>
</device>
<device>
<hwid rank="0">PCI\\VEN_8086&DEV_7110&SUBSYS_00000000&REV_02</hwid>
<hwid rank="1">PCI\\VEN_8086&DEV_7110&SUBSYS_00000000</hwid>
<hwid rank="2">PCI\\VEN_8086&DEV_7110&REV_02</hwid>
<hwid rank="3">PCI\\VEN_8086&DEV_7110</hwid>
<hwid rank="4">PCI\\VEN_8086&DEV_7110&CC_060100</hwid>
<hwid rank="5" driverVer="2001-07-01|5.1.2600.0">PCI\\VEN_8086&DEV_7110&CC_0601</hwid>
</device>
<device>
<hwid rank="0">PCI\\VEN_8086&DEV_7111&SUBSYS_00000000&REV_01</hwid>
<hwid rank="1">PCI\\VEN_8086&DEV_7111&SUBSYS_00000000</hwid>
<hwid rank="2">PCI\\VEN_8086&DEV_7111&REV_01</hwid>
<hwid rank="3" driverVer="2001-07-01|5.1.2600.0">PCI\\VEN_8086&DEV_7111</hwid>
</device>
<device>
<hwid rank="0">PCI\\VEN_8086&DEV_7112&SUBSYS_00000000&REV_01</hwid>
<hwid rank="1">PCI\\VEN_8086&DEV_7112&SUBSYS_00000000</hwid>
<hwid rank="2">PCI\\VEN_8086&DEV_7112&REV_01</hwid>
<hwid rank="3">PCI\\VEN_8086&DEV_7112</hwid>
<hwid rank="4" driverVer="2001-07-01|5.1.2600.0">PCI\\VEN_8086&DEV_7112&CC_0C0300</hwid>
</device>
<device>
<hwid rank="0">PCI\\VEN_8086&DEV_7190&SUBSYS_00000000&REV_03</hwid>
<hwid rank="1">PCI\\VEN_8086&DEV_7190&SUBSYS_00000000</hwid>
<hwid rank="2">PCI\\VEN_8086&DEV_7190&REV_03</hwid>
<hwid rank="3" driverVer="2001-07-01|5.1.2600.0">PCI\\VEN_8086&DEV_7190</hwid>
</device>
<device>
<hwid rank="0">PCI\\VEN_8086&DEV_7191&SUBSYS_00000000&REV_03</hwid>
<hwid rank="1">PCI\\VEN_8086&DEV_7191&SUBSYS_00000000</hwid>
<hwid rank="2">PCI\\VEN_8086&DEV_7191&REV_03</hwid>
<hwid rank="3" driverVer="2001-07-01|5.1.2600.0">PCI\\VEN_8086&DEV_7191</hwid>
</device>
<device>
<hwid rank="0">Intel-PIIX4</hwid>
<hwid rank="1" driverVer="2001-07-01|5.1.2600.0">Primary_IDE_Channel</hwid>
</device>
<device>
<hwid rank="0">Intel-PIIX4</hwid>
<hwid rank="1" driverVer="2001-07-01|5.1.2600.0">Secondary_IDE_Channel</hwid>
</device>
<device>
<hwid rank="0">PCI_HAL\\PNP0A03</hwid>
<compid rank="1" driverVer="2001-07-01|5.1.2600.0">*PNP0A03</compid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0000</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0100</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0200</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP030b</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0400</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0700</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0800</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0B00</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0C01</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0C02</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0C02</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0C04</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">*PNP0F03</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">ROOT\\DMIO</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">ROOT\\FTDISK</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">MS_MMACM</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">MS_MMDRV</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">MS_MMMCI</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">MS_MMVCD</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">MS_MMVID</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">ms_l2tpminiport</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">ms_ndiswanip</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">ms_pppoeminiport</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">ms_pptpminiport</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">ms_pschedmp</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">ms_ptiminiport</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">NTAPM</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">e_isa_up</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">ROOT\\RDPDR</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">ROOT\\RDP_KBD</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">ROOT\\RDP_MOU</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">root\\swenum</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">root\\update</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">STORAGE\\Volume</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2600.0">STORAGE\\Volume</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">SW\\{a7c7a5b0-5af3-11d1-9ced-00a024bf0407}</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">SW\\{b7eafdc0-a680-11d0-96d8-00aa0051e51d}</hwid>
</device>
<device>
<hwid rank="0" driverVer="2001-07-01|5.1.2535.0">SW\\{cd171de3-69e5-11d2-b56d-0000f8754380}</hwid>
</device>
<device>
<hwid rank="0">USB\\ROOT_HUB&VID8086&PID7112&REV0001</hwid>
<hwid rank="1">USB\\ROOT_HUB&VID8086&PID7112</hwid>
<hwid rank="2" driverVer="2001-07-01|5.1.2600.0">USB\\ROOT_HUB</hwid>
</device>
<device isPrinter="1">
<printerInfo driverProvider="Microsoft Windows XP" mfgName="HP" driverName="HP LaserJet 4050 Series PCL6"/>
<hwid rank="0" driverVer="2001-07-01">hewlett-packardhp_labb4e</hwid>
</device>
</devices>
</systemInfo>