|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.plus |
Für meine Familie: meine Frau Idit und unsere Kinder Danielle, Amit und Yoav. Danke für eure Geduld und eure Ermutigung während dieser anspruchsvollen Arbeit.
– Pavel Yosifovich
Für meine Eltern, die mich angeleitet und angeregt haben, meine Träume zu verfolgen, und für meine Familie, die während all dieser zahllosen Abende hinter mir gestanden hat.
– Alex Ionescu
Für unsere Eltern, die uns angeleitet und angeregt haben, unsere Träume zu verfolgen.
– Mark E. Russinovich und David A. Solomon
Band 1: Systemarchitektur, Prozesse, Threads, Speicherverwaltung, Sicherheit und mehr
Übersetzung der 7. englischsprachigen Auflage
Pavel Yosifovich
Alex Ionescu
Mark E. Russinovich
David A. Solomon
Lektorat: Sandra Bollenbacher
Übersetzung: G&U Language & Publishing Services GmbH, www.gundu.com
Copy-Editing: Petra Heubach-Erdmann
Satz: G&U Language & Publishing Services GmbH, www.gundu.com
Umschlaggestaltung: Helmut Kraus, exclam.de
Druckerei: C.H.Beck
ISBN:
Print978-3-86490-538-4
PDF978-3-96088-338-8
ePub978-3-96088-339-5
mobi978-3-96088-340-1
Translation Copyright für die deutschsprachige Ausgabe © 2018 dpunkt.verlag GmbH Wieblinger Weg 17
69123 Heidelberg
Authorized translation from the English language edition, entitled WINDOWS INTERNALS, PART 1: SYSTEM ARCHITECTURE, PROCESSES, THREADS, MEMORY MANAGEMENT, AND MORE, 7th Edition by PAVEL YOSIFOVICH, ALEX IONESCU, MARK RUSSINOVICH, DAVID SOLOMON, published by Pearson Education, Inc, publishing as Microsoft Press, Copyright © 2017 by Pavel Yosifovich, Alex Ionescu, Mark E. Russinovich and David A. Solomon
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.
German language edition published by dpunkt.verlag GmbH, Copyright © 2018
ISBN of the English language edition: 978-0-7356-8418-8
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buchs stehen.
5 4 3 2 1 0
Einleitung
Kapitel 1
Begriffe und Werkzeuge
Versionen des Betriebssystems Windows
Windows 10 und zukünftige Windows-Versionen
Windows 10 und OneCore
Grundprinzipien und -begriffe
Die Windows-API
Dienste, Funktionen und Routinen
Prozesse
Threads
Jobs
Virtueller Arbeitsspeicher
Kernel- und Benutzermodus
Hypervisor
Firmware
Terminaldienste und mehrere Sitzungen
Objekte und Handles
Sicherheit
Die Registrierung
Unicode
Die internen Mechanismen von Windows untersuchen
Leistungsüberwachung und Ressourcenmonitor
Kernel-Debugging
Windows Software Development Kit
Windows Driver Kit
Sysinternals-Werkzeuge
Zusammenfassung
Kapitel 2
Systemarchitektur
Anforderungen und Designziele
Das Modell des Betriebssystems
Die Architektur im Überblick
Portierbarkeit
Symmetrisches Multiprocessing
Skalierbarkeit
Unterschiede zwischen den Client- und Serverversionen
Testbuild
Die virtualisierungsgestützte Sicherheitsarchitektur im Überblick
Hauptsystemkomponenten
Umgebungsteilsysteme und Teilsystem-DLLs
Weitere Teilsysteme
Exekutive
Der Kernel
Die Hardwareabstraktionsschicht
Gerätetreiber
Systemprozesse
Zusammenfassung
Kapitel 3
Prozesse und Jobs
Prozesse erstellen
Argumente der CreateProcess*-Funktionen
Moderne Windows-Prozesse erstellen
Andere Arten von Prozessen erstellen
Interne Mechanismen von Prozessen
Geschützte Prozesse
Protected Process Light (PPL)
Unterstützung für Drittanbieter-PPLs
Minimale und Pico-Prozesse
Minimale Prozesse
Pico-Prozesse
Trustlets (sichere Prozesse)
Der Aufbau von Trustlets
Richtlinien-Metadaten für Trustlets
Attribute von Trustlets
Integrierte System-Trustlets
Trustlet-Identität
IUM-Dienste
Für Trustlets zugängliche Systemaufrufe
Der Ablauf von CreateProcess
Phase 1: Parameter und Flags konvertieren und validieren
Phase 2: Das auszuführende Abbild öffnen
Phase 3: Das Windows-Exekutivprozessobjekt erstellen
Phase 4: Den ursprünglichen Thread mit seinem Stack und Kontext erstellen
Phase 5: Spezifische Prozessinitialisierung für das Windows-Teilsystem durchführen
Phase 6: Ausführung des ursprünglichen Threads starten
Phase 7: Prozessinitialisierung im Kontext des neuen Prozesses durchführen
Einen Prozess beenden
Der Abbildlader
Frühe Prozessinitialisierung
DLL-Namensauflösung und -Umleitung
Die Datenbank der geladenen Module
Importanalyse
Prozessinitialisierung nach dem Import
SwitchBack
API-Sets
Jobs
Grenzwerte für Jobs
Umgang mit Jobs
Verschachtelte Jobs
Windows-Container (Serversilos)
Zusammenfassung
Kapitel 4
Threads
Threads erstellen
Interne Strukturen von Threads
Datenstrukturen
Geburt eines Threads
Die Threadaktivität untersuchen
Einschränkungen für Threads in geschützten Prozessen
Threadplanung
Überblick über die Threadplanung in Windows
Prioritätsstufen
Threadstatus
Die Dispatcherdatenbank
Das Quantum
Prioritätserhöhung
Kontextwechsel
Mögliche Fälle bei der Threadplanung
Leerlaufthreads
Anhalten von Threads
Einfrieren und Tiefgefrieren
Threadauswahl
Mehrprozessorsysteme
Threadauswahl auf Mehrprozessorsystemen
Prozessorauswahl
Heterogene Threadplanung (big.LITTLE)
Gruppengestützte Threadplanung
Dynamische gleichmäßige Planung (DFSS)
Grenzwerte für die CPU-Rate
Dynamisches Hinzufügen und Ersetzen von Prozessoren
Arbeitsfactories (Threadpools)
Erstellen von Arbeitsfactories
Zusammenfassung
Kapitel 5
Speicherverwaltung
Einführung in den Speicher-Manager
Komponenten des Speicher-Managers
Große und kleine Seiten
Die Speichernutzung untersuchen
Interne Synchronisierung
Vom Speicher-Manager bereitgestellte Dienste
Seitenstatus und Speicherzuweisungen
Gesamter zugesicherter Speicher und Zusicherungsgrenzwert
Seiten im Arbeitsspeicher festhalten
Granularität der Zuweisung
Gemeinsam genutzter Arbeitsspeicher und zugeordnete Dateien
Speicherschutz
Datenausführungsverhinderung
Kopieren beim Schreiben
AWE (Address Windowing Extensions)
Kernelmodusheaps (Systemspeicherpools)
Poolgrößen
Die Poolnutzung überwachen
Look-Aside-Listen
Der Heap-Manager
Prozessheaps
Arten von Heaps
NT-Heaps
Heapsynchronisierung
Der Low-Fragmentation-Heap
Segmentheaps
Sicherheitseinrichtungen von Heaps
Debugging einrichten für Heaps
Der Seitenheap
Der fehlertolerante Heap
Layouts für virtuelle Adressräume
x86-Adressraumlayouts
Das Layout des x86-Systemadressraums
x86-Sitzungsraum
System-Seitentabelleneinträge
ARM-Adressraumlayout
64-Bit-Adressraumlayout
Einschränkungen bei der virtuellen Adressierung auf x64-Systemen
Dynamische Verwaltung des virtuellen Systemadressraums
Kontingente für den virtuellen Systemadressraum
Layout des Benutzeradressraums
Adressübersetzung
Übersetzung virtueller Adressen auf x86-Systemen
Der Look-Aside-Übersetzungspuffer für die Übersetzung
Übersetzung virtueller Adressen auf x64-Systemen
Übersetzung virtueller Adressen auf ARM-Systemen
Seitenfehler
Ungültige PTEs
Prototyp-PTEs
Einlagerungs-E/A
Seitenfehlerkollisionen
Seitencluster
Auslagerungsdateien
Gesamter zugesicherter Speicher und systemweiter Zusicherungsgrenzwert
Der Zusammenhang zwischen dem gesamten zugesicherten Speicher und der Größe der Auslagerungsdatei
Stacks
Benutzerstacks
Kernelstacks
Der DPC-Stack
VADs
Prozess-VADs
Umlauf-VADs
NUMA
Abschnittsobjekte
Arbeitssätze
Auslagerung bei Bedarf
Der logische Prefetcher und ReadyBoot
Platzierungsrichtlinien
Verwaltung von Arbeitssätzen
Der Balance-Set-Manager und der Swapper
Systemarbeitssätze
Speicherbenachrichtigungsereignisse
Die PFN-Datenbank
Seitenlistendynamik
Seitenpriorität
Die Schreibthreads für geänderte und für zugeordnete Seiten
PFN-Datenstrukturen
Reservierungen in der Auslagerungsdatei
Grenzwerte für den physischen Speicher
Speichergrenzwerte für Windows-Clienteditionen
Speicherkomprimierung
Ablauf der Komprimierung
Komprimierungsarchitektur
Speicherpartitionen
Speicherzusammenführung
Die Suchphase
Die Klassifizierungsphase
Die Zusammenführungsphase
Vom privaten zum gemeinsamen PTE
Freigabe von zusammengeführten Seiten
Speicherenklaven
Programmierschnittstellen
Initialisierung von Speicherenklaven
Aufbau von Enklaven
Daten in eine Enklave laden
Eine Enklave initialisieren
Vorausschauende Speicherverwaltung (SuperFetch)
Komponenten
Ablaufverfolgung und Protokollierung
Szenarien
Seitenpriorität und Rebalancing
Leistungsstabilisierung
ReadyBoost
ReadyDrive
Prozessreflexion
Zusammenfassung
Kapitel 6
Das E/A-System
Komponenten des E/A-Systems
Der E/A-Manager
Typische E/A-Verarbeitung
IRQ-Ebenen und verzögerte Prozeduraufrufe
IRQ-Ebenen
Verzögerte Prozeduraufrufe
Gerätetreiber
Arten von Gerätetreibern
Aufbau eines Treibers
Treiber- und Geräteobjekte
Geräte öffnen
E/A-Verarbeitung
Verschiedene Arten der E/A
E/A-Anforderungspakete
E/A-Anforderungen an einen einschichtigen Hardwaretreiber
E/A-Anforderungen an geschichtete Treiber
Threadagnostische E/A
Abbrechen der E/A
E/A-Vervollständigungsports
E/A-Priorisierung
Containerbenachrichtigungen
Treiberüberprüfung
E/A-Überprüfungsoptionen
Speicherüberprüfungsoptionen
Der PnP-Manager
Der Grad der Unterstützung für Plug & Play
Geräteauflistung
Gerätestacks
Treiberunterstützung für Plug & Play
Installation von Plug-&-Play-Treibern
Laden und Installieren von Treibern
Treiber laden
Treiberinstallation
Windows Driver Foundation
Kernel-Mode Driver Framework
Das E/A-Modell von KMDF
User-Mode Driver Framework
Energieverwaltung
Verbundener und moderner Standbymodus
Funktionsweise der Energieverwaltung
Energieverwaltung durch die Treiber
Steuerung der Geräteenergiezustände durch den Treiber und die Anwendung
Das Framework für die Energieverwaltung
Energieverfügbarkeitsanforderungen
Zusammenfassung
Kapitel 7
Sicherheit
Sicherheitseinstufungen
Trusted Computer System Evaluation Criteria
Common Criteria
Systemkomponenten für die Sicherheit
Virtualisierungsgestützte Sicherheit
Credential Guard
Device Guard
Objekte schützen
Zugriffsprüfungen
Sicherheitskennungen
Virtuelle Dienstkonten
Sicherheitsdeskriptoren und Zugriffssteuerung
Dynamische Zugriffssteuerung
Die AuthZ-API
Bedingte Zugriffssteuerungseinträge
Privilegien und Kontorechte
Kontorechte
Privilegien
Superprivilegien
Zugriffstokens von Prozessen und Threads
Sicherheitsüberwachung
Überwachung des Objektzugriffs
Globale Überwachungsrichtlinie
Erweiterte Überwachungsrichtlinienkonfiguration
Anwendungscontainer
UWP-Apps im Überblick
Anwendungscontainer
Anmeldung
Initialisierung durch Winlogon
Die einzelnen Schritte der Benutzeranmeldung
Sichere Authentifizierung
Das Windows-Biometrieframework
Windows Hello
Benutzerkontensteuerung und Virtualisierung
Virtualisierung des Dateisystems und der Registrierung
Rechteerhöhung
Schutz gegen Exploits
Abwehrmaßnahmen auf Prozessebene
Control Flow Integrity
Zusicherungen
Anwendungsidentifizierung
AppLocker
Richtlinien für Softwareeinschränkung
Kernelpatchschutz
PatchGuard
HyperGuard
Zusammenfassung
Index
Dieses Buch ist für Computerexperten (Entwickler, Sicherheitsforscher und Systemadministratoren) gedacht, die die Funktionsweise der Kernkomponenten von Microsoft Windows 10 und Windows Server 2016 kennenlernen möchten. Mit diesen Kenntnissen können Entwickler beim Schreiben von Anwendungen für die Windows-Plattform die Gründe für bestimmte Designentscheidungen besser verstehen. Sie helfen ihnen auch beim Debugging komplizierter Probleme. Auch Systemadministratoren profitieren von diesen Informationen, da das Wissen, wie das System in seinem Inneren »tickt«, sein Verhalten verständlicher macht und die Störungssuche erleichtert. Sicherheitsforscher erfahren hier, welche Fehlverhalten Softwareanwendungen und das Betriebssystem an den Tag legen können, wie sie missbraucht werden können und welche Schutzmaßnahmen und Sicherheitsfunktionen moderne Windows-Versionen dagegen bieten. Nach der Lektüre dieses Buches haben Sie ein besseres Verständnis darüber, wie Windows funktioniert und welche Gründe hinter seinem Verhalten stehen.
Dies ist die siebente Ausgabe eines Buches, das ursprünglich Inside Windows NT hieß (Microsoft Press, 1992) und noch vor der Erstveröffentlichung von Windows NT 3.1 von Helen Custer geschrieben wurde. Es war das erste Buch, das es je über Windows NT gab, und es bot wichtige Einsichten in die Architektur und das Design des Systems. Inside Windows NT, Second Edition (Microsoft Press, 1998) wurde von David Solomon geschrieben. Es deckte auch Windows NT 4.0 ab und ging weit tiefer in die technischen Details.
Inside Windows 2000, Third Edition (Microsoft Press, 2000) wurde von David Solomon und Mark Russinovich geschrieben. Hier kamen viele neue Themen wie Starten und Herunterfahren, interne Mechanismen von Diensten und der Registrierung, Dateisystemtreiber und Netzwerkanbindung hinzu. Auch die Änderungen am Kernel in Windows 2000 wurden erläutert, darunter das Windows Driver Model (WDM), Plug & Play, Energieverwaltung, Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI), Verschlüsselung, Jobobjekte und Terminaldienste. Windows Internals, Fourth Edition (Microsoft Press, 2004) war die neue Ausgabe für Windows XP und Windows Server 2003 mit zusätzlichen Inhalten, um IT-Fachleuten zu helfen, ihre Kenntnisse über die internen Mechanismen von Windows praktisch anzuwenden, z. B. durch die Werkzeuge von Sysinternals und die Analyse von Absturzabbildern.
Mit Windows Internals, Fifth Edition (Microsoft Press, 2009) wurde das Buch auf Windows Vista und Windows Server 2008 aktualisiert. Da Mark Russinovich eine Vollzeitstelle bei Microsoft annahm (wo er jetzt als CTO für Azure arbeitet), kam der neue Co-Autor Alex Ionescu hinzu. Zu den neuen Inhalten gehörten der Abbildlader, Einrichtungen für das Debugging im Benutzermodus, ALPC (Advanced Local Procedure Call) und Hyper-V. Die nächste Ausgabe, Windows Internals, Sixth Edition (Microsoft Press, 2012) war komplett aktualisiert, um viele Änderungen am Kernel in Windows 7 und Windows Server 2008 R2 abzudecken. Außerdem kamen viele neue praktische Experimente hinzu, um die Änderungen an den Werkzeugen deutlich zu machen.
Seit der letzten Aktualisierung dieses Buches hat Windows mehrere neue Releases durchlaufen und ist jetzt bei Windows 10 und Windows Server 2016 angekommen. Dabei ist Windows 10 jetzt praktisch der neue Name für Windows. Seit der Produktionsfreigabe hat es wiederum mehrere Releases gegeben. Bezeichnet werden sie jeweils mit einer vierstelligen Zahl, die sich aus dem Jahr und dem Monat der Veröffentlichung zusammensetzt, also z. B. Windows 10 Version 1703 für die Version vom März 2017. Zum Zeitpunkt der Abfassung dieses Buches hat Windows also seit Windows 7 mindestens sechs Versionen durchlaufen.
Beginnend mit Windows 8 hat Microsoft mit einer Zusammenführung seiner Betriebssysteme begonnen, was für die Entwicklung und für das Windows-Konstruktionsteam von Vorteil ist. Windows 8 und Windows Phone 8 verwendeten bereits einen gemeinsamen Kernel, und mit Windows 8.1 und Windows Phone 8.1 kam auch eine Vereinheitlichung bei modernen Apps hinzu. Mit Windows 10 war die Zusammenführung abgeschlossen: Dieses Betriebssystem läuft auf Desktops, Laptops, Servern, der Xbox One, Smartphones (Windows Mobile 10), der Holo-Lens und verschiedenen IoT-Geräten (Internet of Things).
Angesichts dieser großen Vereinheitlichung war die Zeit reif für eine neue Ausgabe dieses Buches, um die Änderungen von fast einem halben Jahrzehnt aufzuarbeiten, die zu einer stabileren Kernelarchitektur geführt haben. Daher deckt dieses Buch verschiedene Aspekte des Betriebssystems von Windows 8 bis Windows 10 Version 1703 ab. Des Weiteren heißen wir Pavel Yosifovich als neuen Co-Autor willkommen.
Auch ohne Zugriff auf den Windows-Quellcode können Sie mithilfe des Kerneldebuggers, der Sysinternals-Tools und der eigens für dieses Buch entwickelten Werkzeuge viel über die internen Mechanismen von Windows herausfinden. Immer wenn ein Aspekt des internen Verhaltens von Windows mit einem der Tools sichtbar gemacht oder veranschaulicht werden kann, erfahren Sie in den mit »Experiment« betitelten Abschnitten, wie Sie dieses Tool selbst ausprobieren können. Diese Abschnitte sind über das ganze Buch verteilt, und wir raten Ihnen dazu, diese Experimente bei der Lektüre auszuführen. Es ist viel eindrucksvoller, die sichtbaren Auswirkungen der internen Mechanismen von Windows zu beobachten, als nur darüber zu lesen.
Windows ist ein umfangreiches und vielschichtiges Betriebssystem. In diesem Buch können wir nicht sämtliche internen Mechanismen von Windows abdecken, sondern konzentrieren uns auf die grundlegenden Systemkomponenten. Beispielsweise werden COM+, die verteilte objektorientierte Programmierinfrastruktur von Windows, und Microsoft .NET Framework, die Grundlage für Anwendungen mit verwaltetem Code, in diesem Buch nicht behandelt. Da es ein Buch über die »Interna« von Windows ist und kein Leitfaden für die Benutzung, die Programmierung oder die Systemadministration, erfahren Sie hier auch nicht, wie Sie Windows verwenden, programmieren oder konfigurieren.
Dieses Buch beschreibt nicht dokumentierte Aspekte der internen Architektur und Funktionsweise von Windows (wie interne Kernelstrukturen und -funktionen), die sich zwischen den einzelnen Releases ändern können.
Das soll nicht heißen, dass sie sich zwangsläufig ändern, sondern nur, dass Sie sich nicht auf ihre Unveränderbarkeit verlassen können. Software, die sich auf solche nicht dokumentierten Schnittstellen oder auf Insiderkenntnisse über das Betriebssystem verlässt, kann in zukünftigen Releases von Windows unter Umständen nicht mehr funktionieren. Software, die im Kernelmodus läuft (z. B. Gerätetreiber) und diese nicht dokumentierten Schnittstellen nutzt, kann bei der Ausführung in einer neueren Windows-Version sogar einen Systemabsturz und damit möglicherweise einen Datenverlust für den Benutzer hervorrufen.
Kurz: Bei der Entwicklung von Software für Endbenutzersysteme und allgemein für jegliche Zwecke außer Forschung und Dokumentation sollten Sie niemals auf die in diesem Buch erwähnten internen Windows-Einrichtungen, Registrierungsschlüssel, Verhaltensweisen, APIs oder sonstigen nicht dokumentierten Elemente zurückgreifen. Suchen Sie immer erst auf MSDN (Microsoft Software Developer Network) nach einer offiziellen Dokumentation.
In diesem Buch wird vorausgesetzt, dass die Leser mit Windows auf dem Niveau von »Power-Usern« vertraut sind und Grundkenntnisse über Betriebssystem- und Hardwareelemente wie CPU-Register, Arbeitsspeicher, Prozesse und Threads mitbringen. In einigen Abschnitten sind auch Grundkenntnisse über Funktionen, Zeiger und ähnliche Konstrukte der Programmiersprache C von Nutzen.
Ebenso wie die sechste Ausgabe ist auch diese in zwei Bände aufgeteilt, von denen Sie den ersten in Händen halten.
In diesem Buch gelten die folgenden Schreibweisen:
+ 
+ 
, dass Sie gleichzeitig die Tasten , und drücken müssen.Damit Sie aus diesem Buch noch größeren Nutzen ziehen können, haben wir Begleitmaterial zusammengestellt, das Sie von der folgenden Seite herunterladen können:
https://dpunkt.de/windowsinternals1
Den Quellcode der Tools, die wir eigens für dieses Buch geschrieben haben, finden Sie auf https://github.com/zodiacon/windowsinternals.
Als Erstes möchten wir Pavel Yosifovich dafür danken, dass er sich uns für dieses Projekt angeschlossen hat. Seine Beteiligung war für die Veröffentlichung entscheidend. Die vielen Nächte, die er damit zugebracht hat, Einzelheiten von Windows zu studieren und über Änderungen während der Zeit von sechs Releases zu schreiben, haben dieses Buch erst möglich gemacht.
Ohne die Rückmeldungen und die Unterstützung von wichtigen Mitgliedern des Windows-Entwicklungsteams und anderer Fachleute von Microsoft wäre dieses Buch auch technisch nicht so tief schürfend und nicht so präzise geworden, wie es ist. Daher möchten wir den folgenden Personen danken, die es auf technische Korrektheit durchgesehen, Informationen gegeben oder die Autoren auf andere Weise unterstützt haben: Akila Srinivasan, Alessandro Pilotti, Andrea Allievi, Andy Luhrs, Arun Kishan, Ben Hillis, Bill Messmer, Chris Kleynhans, Deepu Thomas, Eugene Bak, Jason Shirk, Jeremiah Cox, Joe Bialek, John Lambert, John Lento, Jon Berry, Kai Hsu, Ken Johnson, Landy Wang, Logan Gabriel, Luke Kim, Matt Miller, Matthew Woolman, Mehmet Iyigun, Michelle Bergeron, Minsang Kim, Mohamed Mansour, Nate Warfield, Neeraj Singh, Nick Judge, Pavel Lebedynskiy, Rich Turner, Saruhan Karademir, Simon Pope, Stephen Finnigan und Stephen Hufnagel.
Wir möchten auch Ilfak Guilfanov von Hex-Rays (http://www.hex-rays.com) für die IDA Pro Advanced- und Hey-Rays-Lizenzen danken, die er Alex Ionescu vor mehr als einem Jahrzehnt zur Verfügung gestellt hat, um das Reverse-Engineering des Windows-Kernels zu beschleunigen, und für die fortlaufende Unterstützung und Entwicklung der Decompilerfeatures, die es überhaupt erst möglich gemacht haben, ein solches Buch ohne Zugriff auf den Quellcode zu schreiben.
Zu guter Letzt möchten die Autoren den großartigen Mitarbeitern bei Microsoft Press denken, die dieses Buch verwirklicht haben. Devon Musgrave hat zum letzten Mal als unser Akquiseleiter gearbeitet, während Kate Shoup den Titel als Projektleiterin beaufsichtigt hat. Auch Shawn Morningstar, Kelly Talbot und Corina Lebegioara haben zu der Qualität dieses Buches beigetragen.
Wir haben uns gewissenhaft darum bemüht, dieses Buch und das Begleitmaterial so korrekt wie möglich zu gestalten. Jegliche Fehler in der englischen Originalausgabe, die seit der Veröffentlichung des Buches gemeldet wurden, sind auf der Website von Microsoft Press unter folgender Adresse aufgeführt:
https://aka.ms/winint7ed/errata
Mit Anmerkungen, Fragen oder Verbesserungsvorschlägen zu diesem Buch können Sie sich aber auch an den deutschen dpunkt.verlag wenden:
hallo@dpunkt.de
Bitte beachten Sie, dass über unsere E-Mail-Adressen kein Support für Software und Hardware angeboten wird.
Für Supportinformationen bezüglich der Soft- und Hardwareprodukte besuchen Sie die Microsoft-Website http://support.microsoft.com.
Bei Microsoft Press steht Ihre Zufriedenheit an oberster Stelle. Daher ist Ihr Feedback für uns sehr wichtig. Lassen Sie uns auf dieser englischsprachigen Website wissen, wie Sie dieses Buch finden:
https://aka.ms/tellpress
Wir wissen, dass Sie viel zu tun haben. Darum finden Sie auf der Webseite nur wenige Fragen. Ihre Antworten gehen direkt an das Team von Microsoft Press. (Es werden keine persönlichen Informationen abgefragt.) Im Voraus vielen Dank für Ihre Unterstützung.
Über Ihr Feedback per E-Mail freut sich außerdem der dpunkt.verlag über:
hallo@dpunkt.de
Falls Sie News, Updates usw. zu Microsoft Press-Büchern erhalten möchten, können Sie uns auf Twitter folgen:
http://twitter.com/MicrosoftPress (Englisch)
https://twitter.com/dpunkt_verlag (Deutsch)
In diesem Kapitel führen wir Kernbegriffe des Betriebssystems Microsoft Windows ein, die wir in dem gesamten Buch verwenden werden, z. B. Windows-API, Prozesse, Threads, virtueller Speicher, Kernel- und Benutzermodus, Objekte, Handles, Sicherheit und Registrierung. Außerdem stellen wir die Werkzeuge vor, mit denen Sie die inneren Mechanismen von Windows erkunden können, darunter den Kernel-Debugger, die Leistungsüberwachung und die wichtigsten Werkzeuge aus Windows Sysinternals (http://www.microsoft.com/technet/sysinternals). Des Weiteren erklären wir, wie Sie das Windows Driver Kit (WDK) und das Windows Software Developer Kit (SDK) verwenden können, um mehr über Windows-Interna zu erfahren.
In dem Rest dieses Buches wird vorausgesetzt, dass Sie die in diesem Kapitel eingeführten Begriffe kennen.
In diesem Buch geht es um die neueste Version der Client- und Serverbetriebssysteme von Microsoft, nämlich Windows 10 (eine 32-Bit-Version für x86 und ARM sowie eine 64-Bit-Version für x64) und Windows Server 2016 (wovon es nur eine 64-Bit-Version gibt). Sofern nicht ausdrücklich anders angegeben, bezieht sich der Text auf alle diese Versionen. Als Hintergrundinformation finden Sie in Tabelle 1–1 die Produktnamen, internen Versionsnummern und Veröffentlichungsdaten der bisherigen Windows-Versionen.
Produktname |
Interne Versionsnummer |
Veröffentlichungsdatum |
Windows NT 3.1 |
3.1 |
Juli 1993 |
Windows NT 3.5 |
3.5 |
September 1994 |
Windows NT 3.51 |
3.51 |
Mai 1995 |
Windows NT 4.0 |
4.0 |
Juli 1996 |
Windows 2000 |
5.0 |
Dezember 1999 |
Windows XP |
5.1 |
August 2001 |
Windows Server 2003 |
5.2 |
März 2003 |
Windows Server 2003 R2 |
5.2 |
Dezember 2005 |
Windows Vista |
6.0 |
Januar 2007 |
Windows Server 2008 |
6.0 (Service Pack 1) |
März 2008 |
Windows 7 |
6.1 |
Oktober 2009 |
Windows Server 2008 R2 |
6.1 |
Oktober 2009 |
Windows 8 |
6.2 |
Oktober 2012 |
Windows Server 2012 |
6.2 |
Oktober 2012 |
Windows 8.1 |
6.3 |
Oktober 2013 |
Windows Server 2012 R2 |
6.3 |
Oktober 2013 |
Windows 10 |
10.0 (Build 10240) |
Juli 2015 |
Windows 10 Version 1511 |
10.0 (Build 10586) |
November 2015 |
Windows 10 Version 1607 (Anniversary Update) |
10.0 (Build 14393) |
Juli 2016 |
Windows Server 2016 |
10.0 (Build 14393) |
Oktober 2016 |
Tabelle 1–1Windows-Betriebssysteme
Beginnend mit Windows 7 scheint bei der Vergabe der Versionsnummern von einem wohldefinierten Muster abgewichen worden zu sein. Die Versionsnummer dieses Betriebssystems lautete nicht 7, sondern 6.1. Als mit Windows Vista die Versionsnummer auf 6.0 erhöht wurde, konnten manche Anwendungen das richtige Betriebssystem nicht erkennen. Das lag daran, dass die Entwickler aufgrund der Beliebtheit von Windows XP nur auf eine Überprüfung auf Hauptversionsnummern größer oder gleich 5 und Nebenversionsnummern größer oder gleich 1 durchführten. Diese Bedingung aber war bei Windows Vista nicht gegeben. Microsoft hatte die Lektion daraus gelernt und im Folgenden die Hauptversion bei 6 belassen und die Nebenversionsnummer auf mindestens 2 (größer 1) festgelegt, um solche Inkompatibilitäten zu minimieren. Mit Windows 10 wurde die Versionsnummer jedoch auf 10.0 heraufgesetzt.
Beginnend mit Windows 8 gibt die Funktion GetVersionEx der Windows-API als Betriebssystemnummer unabhängig vom tatsächlich vorhandenen Betriebssystem standardmäßig 6.2 (Windows 8) zurück. (Diese Funktion ist außerdem als unerwünscht eingestuft.) Das dient zur Minimierung von Kompatibilitätsproblemen, zeigt aber auch, dass die Überprüfung der Betriebssystemversion in den meisten Fällen nicht die beste Vorgehensweise ist, weil manche Komponenten unabhängig von einem bestimmten offiziellen Windows-Release installiert werden können. Wenn Sie dennoch die tatsächliche Betriebssystemversion benötigen, können Sie sie indirekt bestimmen, indem Sie die Funktion VerifyVersionInfo oder die neuen Hilfs-APIs für die Versionsbestimmung wie IsWindows80rGreater, IsWindows8Point 10rGreater, IsWindows100rGreater, IsWindowsServer u. Ä. verwenden. Außerdem lässt sich die Betriebssystemkompatibilität im Manifest der ausführbaren Datei angeben, was die Ergebnisse dieser Funktion ändert. (Einzelheiten entnehmen Sie bitte Kapitel 8, »Systemmechanismen«, in Band 2.)
Informationen über die Windows-Version können Sie mit dem Befehlszeilenwerkzeug ver oder grafisch durch Ausführen von winver einsehen. Der folgende Screenshot zeigt das Ergebnis von winver in Windows 10 Enterprise Version 1511:
Das Dialogfeld zeigt auch die Buildnummer (hier 10586.218), die für Windows-Insider hilfreich sein mag (also für diejenigen, die sich registriert haben, um Vorabversionen von Windows zu erhalten). Sie ist auch praktisch für die Verwaltung von Sicherheitsaktualisierungen, da sie zeigt, welche Patches installiert sind.
Mit dem Erscheinen von Windows 10 hat Microsoft angekündigt, Windows jetzt in schnellerer Folge zu aktualisieren als zuvor. Es wird kein offizielles Windows 11 geben. Stattdessen wird Windows Update (oder ein anderes Bereitstellungsmodell) das vorhandene Windows 10 auf eine neue Version aktualisieren. Zurzeit hat es schon zwei solcher Aktualisierungen gegeben, nämlich im November 2015 (Version 1511, wobei sich die Nummer auf Jahr und Monat der Bereitstellung bezieht) und im Juli 2016 (Version 1607, die auch unter der Bezeichnung Anniversary Update vermarktet wurde).
Intern wird Windows nach wie vor phasenweise weiterentwickelt. Beispielsweise trug das ursprüngliche Release von Windows 10 den Codenamen Threshold 1 und die Aktualisierung von November 2015 die Bezeichnung Threshold 2. Die nächsten drei Phasen sind Redstone 1 (Version 1607), auf die Redstone 2 und Redstone 3 folgen werden.
Mit den Jahren wurden verschiedene Geschmacksrichtungen von Windows entwickelt. Neben dem Standard-Windows für PCs gibt es auch das Betriebssystem für die Spielkonsole Xbox 360, bei dem es sich um eine Fork von Windows 2000 handelt. Die Variante Windows Phone 7 basierte auf Windows CE (dem Echtzeit-Betriebssystem von Microsoft). Die Pflege und Erweiterung all dieses Codes ist naturgemäß nicht einfach. Daher hat man bei Microsoft entschieden, die Kernels und die Binärdateien für die grundlegende Plattform in einer einzigen zusammenfassen. Das begann bei Windows 8 und Windows Phone 8, die bereits über einen gemeinsamen Kernel verfügten (wobei Window 8.1. und Windows Phone 8.1 auch eine gemeinsame Windows-Laufzeit-API hatten). Mit Windows 10 ist diese Zusammenlegung abgeschlossen. Die gemeinsame Plattform heißt OneCore und läuft auf PCs, Smartphones, der Spielkonsole Xbox One, der HoloLens und auf IoT-Geräten (für das »Internet der Dinge«) wie dem Raspberry Pi 2.
Diese Geräte unterscheiden sich in ihrer physischen Gestalt sehr stark voneinander, weshalb einige Merkmale nicht überall zur Verfügung stehen. So ist es beispielsweise nicht sinnvoll, für HoloLens-Geräte eine Unterstützung für Maus und Tastatur anzubieten, weshalb diese Teile in der Windows 10-Version dafür nicht vorhanden sind. Aber der Kernel, die Treiber und die Binärdateien der grundlegenden Plattform sind im Prinzip identisch (mit registrierungs- oder richtliniengestützten Einstellungen, wo dies für die Leistung oder aus anderen Gründen sinnvoll ist). Ein Beispiel für solche Richtlinien finden Sie im Abschnitt »API-Sets« in Kapitel 3, »Prozesse und Jobs«.
In diesem Buch geht es um die inneren Mechanismen des OneCore-Kernels unabhängig von dem Gerät, auf dem er läuft. Die Experimente in diesem Buch sind jedoch für Desktop-Computer mit Maus und Tastatur ausgelegt, allerdings hauptsächlich aus praktischen Gründen, da es nicht einfach (und manchmal sogar unmöglich) ist, die gleichen Versuche auf Geräten wie Smartphones oder Xbox One durchzuführen.
In den folgenden Abschnitten geben wir eine Einführung in die Grundprinzipien und -begriffe von Windows, deren Kenntnis für das Verständnis dieses Buches unverzichtbar ist. Viele der hier genannten Elemente wie Prozesse, Threads und virtueller Speicher werden in den nachfolgenden Kapiteln noch ausführlicher dargestellt.
Die Windows-API ist die Systemprogrammierschnittstelle der Windows-Betriebssystemfamilie für den Benutzermodus. Vor der Einführung der 64-Bit-Versionen von Windows wurde die 32-Bit-APi als Win32API bezeichnet, um sie von der ursprünglichen 16-Bit-API zu unterscheiden. Die Bezeichnung Windows-API in diesem Buch bezieht sich sowohl auf die 32- als auch die 64-Bit-Programmierschnittstelle von Windows.
Manchmal verwenden wir auch den Begriff Win32API statt Windows-API. Aber auch dann ist sowohl die 32- als auch die 64-Bit-Variante gemeint.
Die Windows-API wird in der Dokumentation des Windows-SDK beschrieben (siehe den Abschnitt »Windows Software Development Kit« weiter hinten in diesem Kapitel), die kostenlos auf https://developer.microsoft.com/en-us/windows/desktop/develop zur Verfügung steht und in allen Abonnements von MSDN, dem Microsoft-Unterstützungsprogramm für Entwickler, eingeschlossen ist. Eine hervorragende Beschreibung der Programmierung für die grundlegende Windows-API finden Sie in dem Buch Windows via C/C++, Fifth Edition von Jeffrey Richter und Christophe Nasarre (Microsoft Press, 2007).
Die Windows-API bestand ursprünglich nur aus C-artigen Funktionen. Heutzutage können Entwickler auf Tausende solcher Funktionen zurückgreifen. Bei der Erfindung von Windows bot sich die Sprache C an, da sie den kleinsten gemeinsamen Nenner darstellte (weil sie auch von anderen Sprachen aus zugänglich war) und maschinennah genug, um Betriebssystemdienste bereitzustellen. Der Nachteil bestand in einer ungeheuren Menge von Funktionen ohne konsistente Benennung und logische Gruppierung (etwa durch einen Mechanismus wie die Namespaces von C++). Aufgrund dieser Schwierigkeiten wurden schließlich neuere APIs verwendet, die einen anderen API-Mechanismus einsetzten, nämlich das Component Object Model (COM).
COM wurde ursprünglich entwickelt, um Microsoft Office-Anwendungen die Kommunikation und den Datenaustausch zwischen Dokumenten zu ermöglichen (z. B. die Einbettung eines Excel-Diagramms in ein Word-Dokument oder eine PowerPoint-Präsentation). Diese Fähigkeit wird als OLE (Object Linking and Embedding) bezeichnet und wurde ursprünglich mit dem alten Windows-Messagingmechanismus DDE (Dynamic Data Exchange) implementiert. Aufgrund der Einschränkungen, die DDE zu eigen waren, wurde allerdings eine neue Kommunikationsmöglichkeit entwickelt, und das war COM. Als COM um 1993 veröffentlicht wurde, hieß es sogar ursprünglich OLE 2.
COM basiert auf zwei Grundprinzipien: Erstens kommunizieren Clients mit Objekten (manchmal COM-Serverobjekte genannt) über Schnittstellen. Dies sind wohldefinierte Kontrakte mit einem Satz logisch verwandter Methoden, die durch einen Zuteilungsmechanismus für virtuelle Tabellen gruppiert werden. Dies ist eine übliche Vorgehensweise von C++-Compilern zur Implementierung einer Zuteilung für virtuelle Funktionen. Sie resultiert in Binärkompatibilität und verhindert Probleme durch Namensverstümmelung im Compiler. Dadurch wird es möglich, die Methoden von vielen Sprachen (und Compilern) aufzurufen, z. B. C, C++, Visual Basic, .NET-Sprachen, Delphi usw. Das zweite Prinzip lautet, dass die Implementierung von Komponenten dynamisch geladen und nicht statisch mit dem Client verlinkt wird.
Der Begriff COM-Server bezieht sich gewöhnlich auf eine DLL (Dynamic Link Library) oder eine ausführbare Datei (EXE), in der die COM-Klassen implementiert sind. COM weist noch weitere wichtige Merkmale zu Sicherheit, prozessübergreifendem Marshalling, Threading usw. auf. Eine umfassende Darstellung von COM können wir in diesem Buch nicht leisten. Eine hervorragende Abhandlung über COM finden Sie in dem Buch Essential COM von Don Box (Addison-Wesley, 1998).
Über COM zugängliche APIs sind beispielsweise DirectShow, Windows Media Foundation, DirectX, DirectComposition, WIC (Windows Imaging Component) und BITS (Background Intelligent Transfer Service).
Mit Windows 8 wurden eine neue API und eine neue Laufzeitumgebung eingeführt, die Windows Runtime (manchmal auch als WinRT abgekürzt; nicht zu verwechseln mit dem inzwischen eingestellten Betriebssystem Windows RT für ARM-Prozessoren). Die Windows-Laufzeitumgebung besteht aus Plattformdiensten für die Entwickler von sogenannten Windows-Apps (die früher auch als Metro Apps, Modern Apps, Immersive Apps und Windows Store Apps bezeichnet wurden). Windows-Apps können auf unterschiedlichen physischen Geräten ausgeführt werden, von kleinen IoT-Geräten über Telefone und Tablets bis zu Laptop- und Desktop-Computern und sogar auf Geräten wie die Xbox One und die Microsoft HoloLens.
Aus der Sicht der API setzt WinRT auf COM auf und erweitert die grundlegende COM-Infrastruktur. Beispielsweise sind in WinRT vollständige Typmetadaten verfügbar (die im .NET-Metadatenformat in WINMDF-Dateien gespeichert werden), was die COM-Typbibliotheken erweitert. Mit Namespace-Hierarchien, konsistenter Benennung und Programmiermustern ist WinRT auch viel zusammenhängender gestaltet als klassische Windows-API-Funktionen.
Anders als normale Windows-Anwendungen (die jetzt als Windows-Desktop-Anwendungen oder klassische Windows-Anwendungen bezeichnet werden) unterliegen Windows-Apps neuen Regeln. Diese Regeln werden in Kapitel 9, »Verwaltungsmechanismen«, von Band 2 beschrieben.
Die Beziehungen zwischen den verschiedenen APIs und Anwendungen sind nicht offensichtlich. Desktop-Anwendungen können einen Teil der WinRT-APIs verwenden, Windows-Apps dagegen eine der Win32- und COM-APIs. Um jeweils genau zu erfahren, welche APIs für welche Anwendungsplattformen zur Verfügung stehen, schlagen Sie bitte in der MSDN-Dokumentation nach. Beachten Sie jedoch, dass die WinRT-API auf der grundlegenden binären Ebene immer noch auf den älteren Binärdateien und APIs von Windows basiert, auch wenn bestimmte APIs nicht unterstützt werden und ihre Verfügbarkeit nicht dokumentiert ist. Es gibt keine neue »native« API für das System. Das ist vergleichbar mit .NET, das nach wie vor auf die traditionelle Windows-API zurückgreift.
WinJS
