Registrierungsdatenbank

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Windows-Registrierungsdatenbank)
Wechseln zu: Navigation, Suche
Moderne Interpretation des Symbols

Die Windows-Registrierungsdatenbank (manchmal auch als Registrierdatenbank oder Registrierung bezeichnet, meist nur Registry genannt) ist seit der ersten Version von Windows NT die zentrale hierarchische Konfigurationsdatenbank des Betriebssystems Microsoft Windows. Hier werden sowohl Informationen von Windows selbst als auch Informationen von Programmen gespeichert. Mit Microsoft Windows 3.1 wurde die Windows-Registry 1992 auch im Bereich der Consumer-Betriebssysteme eingeführt. Während unter den frühen Windowssystemen hauptsächlich Dateierweiterungen gespeichert wurden, handelt es sich bei der Registry seit Windows 95 und Windows NT 4.0 um eine umfassende Datenbank für die Verwaltung des Systems und aller integrierten Systemdienste und -prozesse. Das Symbol der Registrierungsdatenbank ist ein Würfel, der aus vielen kleinen Würfeln zusammengesetzt wird.

Seit der Einführung der Registrierungsdatenbank wurden von Microsoft eine Reihe von Verbesserungen eingebracht, wie eine automatische Defragmentierung. Bis zur Version NT 5.2 (Microsoft Windows Server 2003) konnte der Startvorgang des Rechners scheitern, wenn Kernel und SYSTEM.DAT nicht in die ersten 16 MB Arbeitsspeicher passten. Mit der Einführung von Vista (NT6.0) fiel die Beschränkung weg, ferner kam durch Transactional NTFS die doppelte Transaktionsunterstützung. Mit Windows 7 (NT 6.1) fiel die Blockierung des Schlüsselpfades weg, wenn ein Unterschlüssel beschrieben wird. Ferner wurde der Synchronisierungszyklus und die Redundanz erhöht. Auch wurde nun jedem Hive eine eigene Hashtabelle gegeben, damit die Schlüsselsteuerblöcke schneller gefunden werden. Die so verbesserte Registrierungsdatenbank kommt in allen nachfolgenden Windows NT-Versionen zum Einsatz. Mit Microsoft Windows Phone 8 wurde die Registrierungsdatenbank erstmals auch in Smartphones verwendet.

Aufbau[Bearbeiten]

Struktur und Überblick[Bearbeiten]

Computer
 
 
 
 
 
 
 
 
 
 
 
 
HKEY_CLASSES_ROOT
 
 
 
 
 
 
 
 
 
 
 
 
 
HKEY_CURRENT_USER
 
 
 
 
 
 
 
 
 
 
 
 
 
HKEY_LOCAL_MACHINE
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BCD00000000
 
 
 
 
 
 
COMPONENTS
 
 
 
 
 
 
HARDWARE
 
 
 
 
 
 
SAM
 
 
 
 
 
 
Schema
 
 
 
 
 
 
SECURITY
 
 
 
 
 
 
SOFTWARE
 
 
 
 
 
 
SYSTEM
 
 
 
 
 
 
 
 
 
 
HKEY_USERS
 
 
 
 
 
 
 
 
 
 
 
 
 
 
.DEFAULT
 
 
 
 
 
 
S-1-5-18-...
 
 
 
 
 
 
S-1-5-19-...
 
 
 
 
 
 
 
 
 
 
HKEY_CURRENT_CONFIG
 
 
 

Die Registrierung beinhaltet wichtige Einstellungen einer Windows-Installation, der Startumgebung und der installierten Programme. Bevor sich in Windows das Konzept der Registry durchgesetzt hatte, wurden Parameter in Initialisierungsdateien separat für jedes einzelne Programm in dessen Verzeichnis gespeichert. Auch andere Systeme nutzten textbasierte Konfigurationsdateien. Diese haben jedoch nicht nur Vorteile: Die Speicherung und Auswertung der Einträge erfolgt üblichweise nicht binär, sondern in einem Textformat. Diese Dateien lassen sich zwar einfach mit jedem Texteditor öffnen und bearbeiten, da es sich um ASCII-Textdateien handelt, die fast beliebig strukturiert sein können. Die Umwandlung von Text in Binärcode bringt aber Performancenachteile (welche bei den in Konfigurationsdateien gespeicherten Datenmengen und geringen Zugriffszahlen allerdings kaum ins Gewicht fallen), und eine direkt weiterverarbeitbare Speicherung der Daten in Binärform ist meist nicht vorgesehen. Ferner können Berechtigungen nur auf Dateiebene, nicht auf Eintragsebene gesetzt werden[1], verschieden Berechtigungsstufen für einzelne Einträge ließen sich sonst - wo nötig - aber durch verschiedene Konfigurationsdateien abbilden.

Die Registrierungsdatenbank hat diese Nachteile nicht: Sie wird transaktionsunterstützt und in einem binären Format gespeichert (welches allerdings dazu führen kann, dass alle Betriebssystem-Konfigurationen verloren sind, falls diese Binär-Datei beschädigt wird), sodass ihre Inhalte direkt und ohne Konvertierung weiterverarbeitet werden können. Wenn die Windows-Systempartition mit NTFS formatiert ist, ergibt sich sogar eine doppelte Transaktionsunterstützung.[1] Vorteile der Registry offenbaren sich erst im Netzwerkverbund unter Verwendung des Verzeichnisdienstes Active Directory. Über Gruppenrichtlinien sind Administratoren in der Lage, die Einstellungen vieler tausend Client-Computer zentral und auf einmal zu steuern[2] (ähnlich wäre dies aber auch durch zentral im Netzwerk abgelegte Konfigurationsdateien möglich). Denn auf die Daten der Registry kann auch über ein Netzwerk zugegriffen werden, da die Pfade zu den Werten standardisiert sind: Ein Programm oder Script muss nicht wissen wo eine bestimmte Datei liegt, sie spricht nur die Standard-API an, welche den Registrywert in dem Schlüssel ausliest oder schreibt, sofern die Zugriffsrechte vorhanden sind.

Informationen, die in einer Konfigurationsdateien (z. B. INI-Datei) als langer Text nach dem Schema „Einstellung1=Wert1; Einstellung2=Wert2; usw.“ vorliegen, werden in der Registrierungsdatenbank quasi in „Einstellung1=Wert1“, „Einstellung2=Wert2“, „usw.“ zerstückelt. Dadurch können nicht nur Berechtigungen auf Eintragsebene gesetzt werden,[1] sondern eine Blockade durch gleichzeitigen Schreibzugriff zweier Programme wird vermieden, wenn diese unterschiedliche Einträge bearbeiten. In einer Konfigurationsdatei müssten beide dieselbe Datei öffnen und editieren, in der Registrierung sind beide Wertepaare nur logisch durch Listen-Zellen verbunden. Vor Windows 7 waren bei Schreibzugriffen auf einen Unterschlüssel alle Oberschlüssel des Pfades abgeschlossen; seitdem ist davon nur der Schlüssel betroffen, der tatsächlich auch beschrieben wird.[3] Um durch die „Zerstückelung“ keinen physikalischen Nachteil bei Zugriff auf die Daten zu haben, sorgt das System seit Windows XP von selbst für eine Defragmentierung.[4]

Die Registrierungsdatenbank in Windows NT 6.0 (Vista) und höher ist in fünf Hauptgruppen unterteilt: HKEY_CLASSES_ROOT enthält Informationen über jeden unterstützten Dateityp des Rechners, und wie dieser geöffnet werden soll. Der Wurzelschlüssel ist seit Windows 2000 nicht mehr real, sondern nur eine Spiegelung von HKEY_LOCAL_MACHINE\Software\Classes. Eine separate Classes.DAT gibt es nicht mehr; die Information wird seitdem in SOFTWARE.DAT abgelegt.[5] In HKEY_LOCAL_MACHINE werden alle Optionen und Einstellungen abgelegt, die sich alle Benutzer des Systems teilen - beispielsweise die Konfiguration der Windows Updates. Diejenigen Schlüssel, die nur auf einen einzigen Nutzer zutreffen, landen in der Gruppe HKEY_USERS. Dieser Ordner ist die Sammelstelle für alle Einstellungen, die ein Benutzer im System vorgenommen hat. Das Profil des aktuell angemeldeten Benutzers wird von HKEY_USERS auf HKEY_CURRENT_USER gespiegelt. Der Wurzelschlüssel HKEY_CURRENT_CONFIG ist ebenfalls nur eine Spiegelung, hier auf HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current.[6]

HKEY steht dabei für „handle to key“, also „übergebe an (Wurzel)schlüssel“. Dies ist ein formaler Ausdruck, weil der Object Manager des NT-Kernels nicht die Registry verwaltet, sondern der Configuration Manager des Kernels. In Mac OS X sind zum Beispiel die Verzeichnisstrukturen von .plist-Konfigurationsdateien mit den Verzeichnisstrukturen von anderen Dateien im Finder identisch. In Windows hat der Ablageort der Registry-Dateien (*.DAT) im Datei-Explorer, mit dem Verzeichnispfad der darin enthaltenen Informationen nichts gemein. Möchte man zum Beispiel einen Wert wissen, der in SYSTEM.DAT liegt, muss nicht \Windows\System32\config\SYSTEM.DAT, sondern \registry\machine\system übergeben werden. Der Object Manager des NT-Kernels gibt beim Parsen von \registry\ den Handle an den Configuration Manager weiter. Es existieren deshalb zwei Verzeichnisstrukturen: Einmal die des Object Manager wie sie im Datei-Explorer sichtbar wird, andermal die des Configuration Managers. Letztere kann auf verschiedenste Weise dargestellt werden, siehe den Abschnitt „Manuelle Bearbeitungsmöglichkeiten“.

Die Wurzelschlüssel werden auch als „Hives“, also Bienenstöcke bezeichnet. Manche sagen, dies sei von der Struktur der Registry abgeleitet, welche einen binären Suchbaum bildet, im englischen als B-Tree abgekürzt. B-Tree wird wie Bee Tree, also Bienen-Baum ausgesprochen.[7] Andere sagen, dass einer der Entwickler von Windows NT Bienen hasste, und diese deshalb sooft es ging referenzierte. Davon seien die Namen „Hive“ und „cell“ abgeleitet.[8] Fakt ist, dass die Registrierungsdatenbank sowohl den binären Suchbaum (z. B. durch den Begriff „Schlüssel“ für Knotenpunkte), als auch Bienen (hive, cell) referenziert.

Dateien der Registry[Bearbeiten]

Die Registrierungsdatenbank besteht aus mehreren Dateien, die in verschiedenen Verzeichnissen des Rechners abgelegt sind. Diese Dateien haben den Dateityp „Datei“, weswegen manchmal in der Literatur die Endung *.DAT vergeben wird. Um die Aufgaben und das Zusammenspiel der Registry-Dateien zu veranschaulichen, sind die Dateien BCD.DAT, SYSTEM.DAT und SOFTWARE.DAT gemäß der Nutzungsreihenfolge beim Startvorgang des Rechners angeordnet. Der Liegeplatz der *.DAT wird ebenfalls anzeigt.

BCD.DAT[Bearbeiten]

\Device\HarddiskVolume1\Boot\

Ab Vista kam die Boot Configuration Database (BCD) dazu, in welcher die Informationen abgelegt werden, wo Boot-Dateien und -Einstellungen zu finden sind. Die BCD.DAT liegt \Boot\BCD auf dem Systemvolume.[9] Bootmgr liest diese Datei aus, nachdem er selbst vom BIOS/EFI ausgeführt wurde. Durch diese Referenzen kann in alternative Umgebungen gebooted werden, z. B. in das Windows Recovery Environment, ein Aufwachen aus dem Ruhezustand, ein Speicherdiagnosestart usw. Die Datei kann eine Liste der Windows-Betriebssysteme enthalten, die entweder auf dem lokalen Rechner, oder via Netzwerk gestartet werden können.[10]

Die Binärdatei BCD.DAT wird dabei als BCD00000000 in den Maschinenhive geladen. Bootmgr sucht nun in BCD.DAT nach dem Ort von hiberfil.sys. Wird die Datei gefunden und ist mit einem aktuellen Speicherabbild bestückt, wird der Inhalt von winresume.exe in den Arbeitsspeicher des Rechners geladen, und die Sitzung vor dem Ruhezustand wird fortgeführt. Ist dies nicht der Fall, wird nach der Liste der installierten Betriebssysteme gesehen.[1] Wird mehr als eines gefunden, wird ein Auswahlmenü angezeigt.[10]

Nach der Wahl eines Betriebssystems wird dieses durch winload.exe in den Arbeitsspeicher geladen.[1] Dazu lädt winload.exe den Kernel ntoskrnl.exe, die Hardwareabstraktionsschicht hal.dll, den Kernel-Debugger kdcom.dll, die Startanimation („Windows wird gestartet“ oder Ähnliches) bootvid.dll und die Datei SYSTEM.DAT in das RAM. Wird in dieser Phase F8 gedrückt, erscheint das erweiterte Startmenü. Ferner wird die gesamte Hardware des Systems ausgelesen. Falls verschiedene Hardwareprofile eingerichtet sind, muss der Nutzer aus einem auswählen. Diese Informationen werden in HKLM\HARDWARE hinterlegt; es handelt sich dabei um keine Datei, sondern um flüchtige Informationen die nur im RAM hinterlegt werden, falls Programme die Hardwarekonfiguration des Rechners wissen möchten. Dazu werden serielle Schnittstellen nach Tastaturen usw. abgescannt. Die Ergebnisse werden unter HKLM\Hardware\ACPI wenn vorhanden, HKLM\HARDWARE\DESCRIPTION (Hardware, Chipsatz), HKLM\HARDWARE\DEVICEMAP (Tastatur, Monitor) und HKLM\HARDWARE\RESOURCEMAP (HAL, PnP) abgelegt.[11][10] Bootmgr und winload.exe teilen sich die Aufgaben, die in Windows XP und früher ntldr und NTDETECT.COM hatte.[9]

SYSTEM.DAT[Bearbeiten]

%systemroot%\System32\config\

Im nächsten Schritt des Bootens werden die Treiber in den Arbeitsspeicher geladen. Die Informationen dazu, zusammen mit den Infos zur Hardware und den Windows-Systemdiensten, werden in SYSTEM.DAT nachgesehen, welche in HKLM\SYSTEM eingehängt wird. Diese CurrentControlSets liegen redundant vor, falls die aktuelle Konfiguration das Hochfahren verhindert. Im Normalfall wird CurrentControlSet gewählt.[11] Welches ControlSet gewählt wird, wird unter HKLM\SYSTEM\Select gewählt: Default ist das Aktuelle. Wenn der Bootvorgang fehlschlägt hat der Nutzer die Option, die „Letzte als funktionierend bekannte Konfiguration“ zu wählen. In diesem Fall wird von Default auf LastKnownGood umgeschaltet, und ControlSet002 probiert. Hat der Startvorgang nun Erfolg, wird LastKnownGood zu Default.[10]

Während der Kernel-Phase des Bootens werden die Windows-Systemdienste aus der Liste HKLM\SYSTEM\CurrentControlSet\Services gestartet, wobei die Reihenfolge in HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder festgelegt ist. Der Startvorgang ist nun vom Bootloader zum NT-Kernel übergegangen. Der Kernel Process Manager initialisiert nun seine Subsysteme: Die Aufteilung des Arbeitsspeichers, und die Interrupt-Controller werden initialisiert. Der Memory Manager wird initialisiert und erzeugt den Cache, Paging, usw. Der Object Manager vergibt die ersten Security-Token. Der Process Manager, der Systemprozess und der Leerlaufprozess werden geschaffen. Dann werden die Treiber initialisiert. Sind alle geladen, startet der Kernel das Session Manager Subsystem (smss.exe). Dessen Aufgaben sind in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager festgelegt.[11][10]

Bevor Dateien geöffnet werden, startet der Windows Sitzungs-Manager (smss.exe) Autochk.exe. Autochk.exe mounted die Laufwerke und überprüft, ob diese beim letzten Herunterfahren ordnungsgemäß ausgehängt wurden. Ist dies nicht der Fall, startet Autochk.exe die Anwendung chkdsk.exe. Nach dem Einhängen der Laufwerke führt smss.exe folgende Operationen aus: Es schreibt die Umgebungsvariablen in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment. Ferner wird die Kernel-Seite von Win32 (win32k.sys) gestartet. Windows kann nun im Grafikmodus weiterarbeiten. Durch den Start der User-Seite von Win32, welche als Client/Server Runtime Server Subsystem (csrss.exe) bekannt ist, können nun auch Userland-Prozesse ausgeführt werden. Die virtuellen Speicherbereiche (Paging) werden von smss.exe in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management abgelegt. Wenn Programme umbenannt werden müssen, was während der Laufzeit vorher nicht möglich war, wird dies nun von smss.exe durchgeführt. So können auch Treiber ge-/entladen werden. Dann werden alle Programme ausgeführt, die in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute aufgeführt sind, z. B. wenn der Nutzer vor dem Herunterfahren autocheck.exe oder ähnliches angefordert hat. Im letzten Schritt startet smss.exe den Windows Logon Manager (winlogon.exe). Früher wurde auch noch die GINA-Bibliothek in Winlogon geladen, ab Vista existiert sie nicht mehr.[10]

Winlogon.exe startet nun den Local Security Authority Subsystem Service (lsass.exe) und den Service Control Manager (services.exe), welcher alle Windows-Systemdienste startet, die im Autostart sitzen. Winlogon.exe fängt die Secure Attention Sequence (SAS) ab, schließt den Rechner ab wenn ein Bildschirmschoner läuft, und steuert den Login-Vorgang. Winlogon aktualisiert auch das ControlSet auf LastKnownGood um zu zeigen, dass der Startvorgang erfolgreich war. Winlogon nimmt das Anmeldepasswort entgegen und übergibt dieses an lsass.exe. Liegt nichts im Cache, schaut lsass.exe unter HKLM/SYSTEM/CurrentControlSet/Control/Lsa, welches Protokoll genutzt werden soll (msv1_0.dll, Kerberos.dll, etc). Der Local Security Authority Subsystem Service prüft nun das Passwort in HKLM/SAM, verteilt Security Token, legt ein Audit-Trail an usw. Ist alles Okay, gibt lsass.exe die Kontrolle zurück an winlogon.exe, welche Vorbereitungen trifft, damit der Nutzer die Kontrolle übernehmen kann. Dazu erzeugt winlogon.exe drei virtuelle Desktops (Winlogon, Default, ScreenSaver), welche standardmäßig unter einem modernen Windows-System existieren: Erstens den Anmeldebildschirm, welcher Benutzer SYSTEM gehört, auf dem winlogon.exe ausgeführt wird. Wird die Secure Attention Sequence ausgeführt, erscheint auf diesem Desktop der Sicherheitsbildschirm, der ebenfalls zu winlogon.exe gehört. Der zweite Desktop ist die Windows-Shell, in der Regel explorer.exe, nicht zu verwechseln mit dem Datei-Explorer. Diese wird von userinit.exe gestartet. Der dritte ist der laufende Bildschirmschoner oder, beim Arbeiten am Rechner, der Sichere Desktop der Benutzerkontensteuerung, wo SYSTEM consent.exe ausführt. Als letztes startet winlogon.exe den Wert, der unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon bei Userinit eingetragen ist. Standardmäßig ist dies C:\Windows\System32\Userinit.exe.[10]

SOFTWARE.DAT[Bearbeiten]

%systemroot%\System32\config\

Nachdem winlogon.exe die Anwendung Userinit.exe unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon gestartet hat, beginnt diese die Windows-Shell einzurichten. Userinit.exe ist der erste Prozess, der mit Nutzerrechten ausgeführt wird, und startet alle Programme der Shell. Dazu schaut userinit.exe unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon nach der Zeichenfolge Shell, die normalerweise auf explorer.exe zeigt. Wird eine alternative Desktopumgebung wie KDE Plasma Workspaces, LiteStep, BumpTop usw. installiert, wird diese gestartet. Dann wird das Nutzerprofil NTUSER.DAT des angemeldeten Benutzers geladen. User- und Maschinenskripte werden ausgeführt, um die Gruppenrichtlinien anzuwenden, und die Autostartgruppen werden gestartet. Userinit.exe sieht dazu in folgende Hives und Verzeichnisse:[10]

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load
  • HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
  •  %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup
  •  %appdata%\Microsoft\Windows\Start Menu\Programs\Startup

Nachdem alle Autostartgruppen abgegrast wurden, beendet sich userinit.exe, und die Programme in der Shell laufen ohne den Vaterprozess weiter.[10] SOFTWARE.DAT dient hauptsächlich dazu, das Software ihre Einstellungen, sofern sie andere Programme oder das Betriebssystem betreffen, hier hinterlegen können. Der Unterschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ speichert zum Beispiel die Informationen für das Betriebssystem, welche Dateiendung wie geöffnet werden soll.[11] Aus Kompatibilitätsgründen (Windows 2000 usw.) wird der Inhalt auf den fiktiven Hive HKEY_CLASSES_ROOT gespiegelt. In ...\Classes\ steht zum Beispiel unter .odp bei installiertem LibreOffice, dass diese Dateien mit dem LibreOffice.ImpressDocument.1 geöffnet werden sollen. Der Schlüssel .123 ist beispielsweise die Dateiendung des Lotus 1-2-3-Formates. Die betriebssystemeigene Endung .exe wird auf exefile weiterverwiesen, welche unter HKEY_LOCAL_MACHINE\SOFTWARE\Classes\exefile\shell\open\command den Standardwert "%1" %* aufweist.

Drittanbietersoftware legt in SOFTWARE.DAT nur die nötigsten Informationen ab. Die Java-Laufzeitumgebung legt zum Beispiel nur die leeren Schlüssel „JreMetrics“ und „JavaSoft“ an, letzterer hat einen leeren Unterschlüssel „JavaUpdate“, der den Unterschlüssel „Policy“ enthält. Darin steht als einzige Information die Zeichenfolge „Country“ mit dem Wert „DE“. Andere Programme wissen nun, das die Java-Laufzeitumgebung installiert ist, in der deutschen Sprachausgabe. Der Unterschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ ist sehr umfangreich, weil hier Informationen zu Microsoft-Software abgelegt wird (Powershell, Defender, Mail, usw.). Unter ...\Microsoft\Windows NT\CurrentVersion\ bzw. ...\Microsoft\Windows\CurrentVersion\ werden Einstellungen des Betriebssystems abgelegt, die für die Laufzeit wichtig sind, z. B. unter ...\Windows\CurrentVersion\Policies\ die Einstellungen der Richtlinien.[12] Ferner sind noch Unterschlüssel für Open Database Connectivity (ODBC) und Clients (Mail, Medien, Newsclients) vorhanden.[11]

SAM.DAT[Bearbeiten]

%systemroot%\System32\config\

Im Security Accounts Manager SAM.DAT werden die Passworthashes der Nutzer für jedes Authentifizierungsprotokoll gespeichert, sowie Gruppen und Domäneninformationen, zum Beispiel, welcher Nutzer sich in dieser Domäne anmelden darf. Der Schlüssel kann mit regedit.exe nicht geöffnet werden.[11] Selbst Administratoren haben hier weder Schreib- noch Leserechte.

SECURITY.DAT[Bearbeiten]

%systemroot%\System32\config\

Diese Datei ist die Sicherheits-Datenbank der Domäne. Bei einem Rechner ohne Domäne wird diese Datei vom lokalen Administrator verwaltet, obwohl dieser sie über regedit.exe weder lesen noch beschreiben kann. Dies ist zum Beispiel mit einer administrativen Powershell möglich. SECURITY.DAT wird vom NT-Kernel gelesen, um die Sicherheitsrichtlinien durchzusetzen, welche Nutzer und Anwendungen betreffen. Der Hive enthält auch eine Kopie von SAM.DAT.[11] Im Unterverzeichnis .../Policy/PolEKList liegen weitere Passworthashes der Local Security Authority (lsass.exe). Unter ...\Policy\Secrets liegen die Geheimnisse der Server, des SharePoint-Timerdienstes usw.[13]

.DEFAULT.DAT[Bearbeiten]

%systemroot%\System32\config\

Es handelt sich um den Hive des Accounts Lokales System (LocalSystem), der sowohl NT-Autorität\SYSTEM als auch Administrator ist.[14] Schaltet sich der eigene Rechner mittels Remotedesktopverbindung auf einen Server auf, werden beispielsweise die Drucker unter HKEY_USERS\.DEFAULT\Printers\ eingetragen.[15] Das Profil .DEFAULT.DAT ist wie eine NTUSER.DAT und unter HKEY_USERS aufgeführt, ist aber nicht Teil der ProfileList.

NTUSER.DAT[Bearbeiten]

Die NTUSER.DAT enthält alle wichtigen benutzerdefinierten Einstellungen. Die Inhalte aller NTUSER.DAT aller lokalen Nutzerkonten werden unter HKEY_USERS aufgelistet. Meldet sich ein Benutzer am System an, wird sein Schlüssel (S-1-5-...) an die Stelle von HKEY_CURRENT_USER gespiegelt.[10] HKEY_CURRENT_USER bzw. NTUSER.DAT enthält Systemsound-Einstellungen (AppEvents), Werte zur Eingabeaufforderung (console), Einstellungen der Systemsteuerung (Control Panel), Umgebungsvariablen (Environment), gewählte Schriftart (EUDC), Identität und Passwort (Identities), Keyboard Layout, Netzwerk, Drucker, Software, gesperrte Systemtools (System) und Umgebungsvariablen (Volatile Environment). Unter HKEY_CURRENT_USER\Software\ legen Programme Informationen ab, die für andere Programme oder das System wichtig sind. LibreOffice legt beispielsweise nur einen leeren Unterschlüssel „The Document Foundation“ an, mit einem leeren Unterschlüssel „LibreOffice 4.3“, der den Unterschlüssel „StartMenu“ enthält. Hier sind alle EXE-Dateien von LibreOffice aufgeführt, die im Startmenü aufgelistet werden. Die unterschiedlichen Nutzerprofile an einem Rechner sind unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList abgelegt. Zu jeder aufgelisteten SID (S-1-5-...) wird hinter ProfileImagePath der Ort der NTUSER.DAT angezeigt:

  • S-1-5-18: Der Superuser SYSTEM. Sein „Benutzerverzeichnis“ liegt unter %systemroot%\System32\config\systemprofile. Das Benutzerprofil enthält seine NTUSER.DAT und ein paar Ordner, die in jedem Nutzerverzeichnis zu finden sind. „Eigene Bilder“ oder „Eigene Dokumente“ existieren hier nicht, AppData mit den Unterordnern Local, LocalLow und Roaming aber schon.
  • S-1-5-19: Der Benutzer Lokaler Dienst (LocalService). Sein „Benutzerverzeichnis“ liegt unter %systemroot%\ServiceProfiles\LocalService. Das Benutzerprofil enthält seine NTUSER.DAT und ein paar Ordner, die in jedem Nutzerverzeichnis zu finden sind, so auch die Ordner „Dokumente“, „Favoriten“, „Desktop“, „Downloads“ und sogar „Musik“ und „Gespeicherte Spiele“, die bis auf „AppData“ leer sind.
  • S-1-5-20: Der Benutzer Netzwerkdienst (NetworkService). Sein „Benutzerverzeichnis“ liegt unter %systemroot%\ServiceProfiles\NetworkService. Das Benutzerprofil enthält seine NTUSER.DAT und ein paar Ordner, die in jedem Nutzerverzeichnis zu finden sind. Auch hier sind dem Nutzer die Ordner „Dokumente“, „Favoriten“, „Desktop“, „Downloads“ und sogar „Musik“ und „Gespeicherte Spiele“ gegeben, die bis auf „AppData“ leer sind.
  • S-1-5-21-...-500: Das eingebaute Administratorkonto, wenn aktiviert. Seine NTUSER.DAT liegt unter %systemdrive%\Benutzer\Administrator, wenn es aktiviert wurde.
  • S-1-5-21-...-501: Der Benutzer Gast, dessen Gastkonto standardmäßig deaktiviert ist. Seine NTUSER.DAT liegt unter %systemdrive%\Benutzer\Gast.
  • S-1-5-21-...-1001: Ein Standardbenutzerkonto. Deren SIDs beginnen ab 1000. Da ab Vista alle Nutzer durch die Benutzerkontensteuerung nur noch Standardnutzer sind, sind praktisch alle Accounts -1000 und höher. Seine NTUSER.DAT liegt unter %systemdrive%\Benutzer\Mustermann. Versucht ein Programm ohne eine Rechteerhöhung anzufordern in administrative Pfade zu schreiben, werden Verzeichnisse und Registry virtualisiert. Dabei wird eine Kopie derselben vom Programm beschrieben, wobei der virtualisierte Registrypfad unter HKEY_CURRENT_USER\Software\Classes\VirtualStore\ liegt.

In Microsoft Windows 98 und Millennium Edition hieß diese Datei User.DAT, und hatte dieselbe Funktion. Die Einstellungen unter HKEY_CURRENT_USER\Software\Classes in der NTUSER.DAT überschreiben in HKEY_CLASSES_ROOT die Standardeinstellungen, welche von HKEY_LOCAL_MACHINE\Software\Classes gespiegelt wurden. Sie gelten damit nur für den angemeldeten Benutzer.[5]

Schema.DAT[Bearbeiten]

C:\Windows\System32\SMI\Store\Machine\

Temporärer Schlüssel, der unter HKEY_LOCAL_MACHINE\Schema\ eingehängt wird und für Windows Update benötigt werden soll.[16] Ist erst seit Windows Vista vorhanden.

COMPONENTS.DAT[Bearbeiten]

%systemroot%\System32\config\

Enthält ein Verzeichnis und Abhängigkeiten für Systemkomponenten. Hier werden Informationen über Updates und Windows-Features abgelegt. Die Konfiguration und der Zustand der Massenspeicher werden ebenso abgelegt wie die Speicher-Architektur und das Format. Bei Downloads, Installationen oder dem Entfernen von Features wird dieser Hive unter HKEY_LOCAL_MACHINE\COMPONENTS\ eingehängt.[17][11] Ist erst seit Windows Vista vorhanden.[18]

Technik[Bearbeiten]

Arbeitsweise der Registry[Bearbeiten]

Die Registrierungsdatenbank ist wie oben gezeigt auf mehrere Dateien verteilt. „Die Registry“ als monolithisches Objekt und Single Point of Failure gibt es deshalb im strengen Sinne nicht (je nach beschädigter Datei kann dies aber dennoch so betrachtet werden, z.B. bei der SYSTEM.DAT). Das was zum Beispiel mit dem Registry-Editor regedit.exe als monolithische Datenbank dargestellt wird, ist die Implementierung des Configuration Managers, der Teil des NT-Kernels ist. Die Registry besteht aus einzelnen Dateien, von denen einige oben aufgeführt sind, die als Hives bezeichnet werden. Jeder dieser Hives enthält einen Registry-Baum, wobei der erste Schlüssel in der Datei die Wurzel (root) des Baumes darstellt. Wie bereits oben erwähnt, sind nicht alle Registry-Bäume real, d. h. sie haben kein Wurzelverzeichnis. Manche sind nur Spiegelungen, oder volatil. Wenn in der Bootphase SYSTEM.DAT in den Arbeitsspeicher geladen wird, schaut der Configuration Manager unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist nach den Liegeplätzen der Hives.[19][20] An einem Beispielrechner:

\REGISTRY\MACHINE\BCD00000000         REG_SZ                \Device\HarddiskVolume1\Boot\BCD
\REGISTRY\MACHINE\HARDWARE         REG_SZ
\REGISTRY\MACHINE\SAM                  REG_SZ                \Device\HarddiskVolume2\Windows\System32\config\SAM
\REGISTRY\MACHINE\SECURITY           REG_SZ                \Device\HarddiskVolume2\Windows\System32\config\SECURITY
und so weiter...

Wie ersichtlich gibt es für den NT-Kernel keine Laufwerksbuchstaben, das Stammverzeichnis beginnt mit „\“. Der Configuration Manager legt nun Symbolische Verknüpfungen an, beispielsweise von \REGISTRY\MACHINE\SECURITY auf \Device\HarddiskVolume2\Windows\System32\config\SECURITY. Dies ist notwendig, weil der Object Manager des Kernels beim Parsen des Strings \REGISTRY\ den Handle an den Configuration Manager weitergibt.[19][20] Die Registry wird also wie ein Gerät („Device“) angesprochen.

Der Configuration Manager unterteilt jeden Hive in Datenblöcke zu je 4096 Bytes, wie es auch bei einer Festplatte der Fall ist. Der Hive kann nur blockweise vergrößert oder verkleinert werden, also in Schritten zu ±4kB. Der erste Block eines Hives ist der Basisblock, der die Signatur „regf“, Sequenznummern, Zeitstempel des letzten Schreibzugriffes im Hive, die Versionsnummer des Hives, eine Prüfsumme, und dessen vollen Name (z. B. %SystemRoot%\CONFIG\SAM) enthält. Die Daten der Registry werden in Zellen (cells) abgelegt, welche Schlüssel, Wert, Security Descriptor, eine Liste der Unterschlüssel oder Schlüsselwerte enthalten können. Ein Feld am Anfang der Zelle beschreibt den Typ und die Größe. Wird eine neue Zelle in den Hive gelegt, und ist dafür eine Expansion des Hives nötig (+4096 Bytes), wird ein Behälter (bin) geschaffen, der die Zelle und den Leerraum des Blockes beinhaltet. Der Raum zwischen dem Ende der Zelle und dem Ende des Behälters kann später mit weiteren Zellen gefüllt werden. Behälter (bins) haben ebenfalls einen Header der die Signatur „hbin“ beinhaltet, sowie den Offset vom Beginn des Behälters/Zelle zum Leerraum hinter der Zelle, sowie die Größe des Behälters.[19][20]

Die Unterteilung der Registry in Behälter (bin) und Zellen (cell) ermöglicht eine effiziente Arbeitsweise: Da Behälter seltener neu zugewiesen werden wie Zellen, kann der Configuration Manager entscheiden, statt den Zellen die Behälter in den Arbeitsspeicher zu laden, um die Zahl der (Ent)ladevorgänge zu senken. Beim Einlesen kann der Configuration Manager auch entscheiden, nur Behälter die Schlüssel enthalten in den Arbeitsspeicher zu laden, und die leeren Behälter zu ignorieren. Wenn eine Zelle angelegt oder entfernt wird, fragmentiert der Inhalt der Behälter mit der Zeit, ähnlich wie bei einem Laufwerk. Der Configuration Manager defragmentiert die Registry deshalb kontinuierlich selbst: Wenn ein Behälter leer wird, werden die leeren Behälter in möglichst zusammenhängende Anschnitte gelegt. Ferner führt er Zellen zusammen, die durch Löschungen fragmentiert wurden.[19][20][4]

Das Finden von Zellen und Werten findet durch Anspringen statt: Eine Schlüssel-Zelle enthält einen Zellen-Index, der Zeiger (Informatik) auf Unterschlüssel-Zellen enthält. Um die Unterschlüssel zu finden, ist in den Zellen auch eine Liste der Unterschlüssel enthalten, welche mit dem jeweiligen Zellen-Index verknüpft sind. Um die Suche zu beschleunigen, sortiert der Configuration Manager die Listen alphabetisch. Die Listen werden durch binäre Suche nach dem Zielwert abgesprungen: Der Configuration Manager springt zuerst in die Mitte der Liste, prüft dann, ob der Wert vor oder nach dem Zielwert im Alphabet kommt, und springt dann in die Mitte der oberen bzw. unteren Hälfte. Die Halbierung läuft so lange weiter, bis der Zielwert gefunden wird. Dann wird der Zellen-Index des Ziels ausgelesen, und diese Zelle angesprungen. Der Vorgang wird so lange wiederholt, bis die Zielzelle gefunden ist, oder das Ziel nicht in der Liste der Unterschlüssel auftaucht. In diesem Fall wird eine Fehlermeldung zurückgegeben.[19] Die folgende Grafik veranschaulicht die Sprünge von Zelle zu Zelle in einem Registry-Hive, um Werte (Val 1, Val 2) oder Unterschlüssel (root, Sub Key) auszulesen.[20]

Registry structure.jpg

Es gibt fünf verschiedene Arten von Zellen, der Einfachheit halber ist die Sicherheitsbeschreibungszelle in der Grafik nicht abgebildet. Der Configuration Manager springt erst den Basisblock an, und springt dann auf den Wurzelschlüssel. Von diesem Schlüssel aus springt er zum einen zu einer Wert-Listen-Zelle (hellblau), welche ihn zu den Wert-Zellen Val 1 und Val 2 springen lässt. Andererseits wird vom Wurzelschlüssel aus eine Unterschlüssel-Listen-Zelle (dunkelblau) angesprungen, welche ihn zum nächsten Unterschlüssel (Sub Key) springen lässt. Die fünf verschiedenen Zellenarten sind:[19][20]

  • Die Schlüssel-Zellen (key cell), welche in regedit.exe in der linken Fensterseite als Baumstruktur eingeblendet werden. Sie haben die Signatur kn für Schlüssel oder kl, wenn sie nur eine symbolische Verknüpfung zu einem Schlüssel sind. In diesen Schlüssel-Zellen werden ein Zeitstempel der letzten Aktualisierung, ein Zellen-Index der Über- und Unterzellen, und ein Index zur Sicherheitsbeschreibungszelle (security descriptor cell) sowie der Name des Schlüssels (z. B. CurrentControlSet) abgelegt.
  • Die Wert-Zellen (value cell) enthalten die Werte des Schlüssels, welche in regedit.exe auf der rechten Fensterseite eingeblendet werden. Die Signatur der Zelle ist kv, sie enthält auch Typ (REG_DWORD, REG_BINARY) und Namen des Wertes (z. B. debugger).
  • Unterschlüssel-Listen-Zellen (Subkey-list cell) enthalten eine Liste der Unterschlüssel eines Schlüssels, mit deren Zellen-Index.
  • Wert-Listen-Zellen (Value-list cell) enthalten eine Liste der Werte ihres Schlüssels und ihres Zellen-Indexes.
  • Sicherheitsbeschreibungszellen (Security-descriptor cell) enthalten die Zugriffssteuerungsliste und andere sicherheitsrelevante Einstellungen eines Schlüssels. Die Signatur ist ks. Mehrere Knoten können sich eine Sicherheitsbeschreibungszelle teilen, deshalb enthalten diese auch eine Liste der Knoten.

Der Configuration Manager greift nicht bei jeder Suche auf das Festplatten-Abbild des Hives zu. Stattdessen werden alle nötigen Hives in den Adressraum des Kernels einbezogen, indem diese in den Auslagerungsspeicher (pagefile.sys) geladen werden. Nur beim Booten wird der System-Hive komplett in den Arbeitsspeicher geladen. Der Configuration Manager betreibt aufgrund der Fragmentierung im Auslagerungsspeicher Cell Index Mapping, was der virtuellen Speicherverwaltung entspricht, nur eben für die Zellen der Registry. Er unterteilt auch jeden Hive im Auslagerungsspeicher in Blöcke zu 512 Bytes, und weist ihnen je ein Bit zu. Wird dieser Abschnitt modifiziert, wird das Bit von 0 auf 1 gedreht, und der Abschnitt zur Synchronisierung freigegeben. Der Hive-Sync findet 5 Sekunden nach dem Ereignis statt, und synchronisiert alle geänderten Hive-Abschnitte zwischen Auslagerungsspeicher und Image. Finden derweil oder danach weitere Modifikationen an Hives statt, so werden diese erst nach weiteren 5 Sekunden synchronisiert. Um sicherzugehen, dass eine Wiederherstellung auch nach einem Abschmieren des Rechners während der Synchronisierung möglich ist, werden die geänderten Abschnitte zuerst in die *.log-Dateien geschrieben, die neben allen Hive-Dateien vorhanden sind. Danach erhöht der Configuration Manager eine fortlaufende Nummer im Hive, schreibt den modifizierten Abschnitt vom *.log in die Hive-Datei *.DAT, und erhöht eine zweite fortlaufende Nummer im Hive. Stürzt der Rechner während des Schreibvorganges ab, sieht der Configuration Manager nach dem Reboot dass die fortlaufenden Nummern nicht passen, und aktualisiert weiter von *.log in *.DAT.[19][20]

Früher hatte jede Datei des Maschinenhives und die .DEFAULT.DAT eine *.sav und *.log als Redundanz, wobei SYSTEM.DAT zusätzlich noch SYSTEM.alt als Redundanz besaß. Nur NTUSER.DAT war auf eine *.log beschränkt.[19][20] Dies wurde bis einschließlich Windows Vista beibehalten.[18] Moderne NT-Systeme ab Windows 7 haben als Redundanz *.log, *.log1, *.log2 für jede Registry-Datei, nicht nur SYSTEM.DAT.

Für jeden geöffneten Registry-Schlüssel legt der Configuration Manager einen Key Control Block (KCB) an. Dieser enthält den kompletten Pfad des Schlüssels, einen Zellen-Index des Knotenpunktes, und eine Flag ob der Schlüsselsteuerblock gelöscht werden soll wenn der letzte Handle beendet wurde. Windows legt alle Schlüsselsteuerblöcke in einer alphabetisch geordneten Hashtabelle[21] ab, um schnelleren Zugriff zu ermöglichen. Wenn der Object Manager des Kernels von einer Anwendung \REGISTRY\Namenspfad zu parsen bekommt, übergibt er den Namenspfad an den Configuration Manager. Dieser springt wie oben beschrieben die Schlüssel und Unterschlüssel durch, bis der Zielschlüssel (Ziel-Zelle) gefunden wurde. Danach prüft der Configuration Manager, ob der Schlüssel bereits geöffnet wurde. Wenn ja, wird der Zähler im Schlüsselsteuerblock um 1 erhöht. Wenn nicht, erstellt der Configuration Manager einen weiteren Schlüsselsteuerblock, und fügt diesen in die Hashtabelle ein. Dann erstellt er ein Schlüsselobjekt, das auf den Schlüsselsteuerblock zeigt, und übergibt dieses an den Object Manager, der es an die Anwendung weitergibt. Wenn noch eine andere Anwendung auf denselben Schlüssel zugreifen möchte, bekommt sie ebenfalls das Schlüsselobjekt zu sehen. Soll ein neuer Schlüssel erstellt werden, springt der Configuration Manager zuerst den letzten bestehenden Schlüssel der Sprungkette an. Dann prüft er, ob der Raum in der Liste der freien Zellen ausreichend ist, um den neuen Schlüssel aufzunehmen. Wenn nicht, wird ein neuer Behälter eröffnet. Ansonsten wird der neue Schlüssel mit allen Daten angelegt, und in die Index-Liste des Vaterschlüssels eingetragen.[19][20]

Bis Windows NT 6.1 gab es nur eine globale Hashtabelle für alle KCBs. Ab Windows 7 besitzt jeder Hive eine eigene Hashtabelle, ferner wurde der Zugriff auf Schlüssel verbessert: Bei Schreibzugriffen auf einen Unterschlüssel waren früher alle Oberschlüssel des Pfades abgeschlossen; nun ist davon nur der Schlüssel betroffen, der tatsächlich auch beschrieben wird. Ferner wurde der Synchronisierungszyklus erhöht.[3]

Datentypen in der Registry[Bearbeiten]

Jede Wert-Zelle hat eine theoretische Größe von 1024 kB, die meisten Werte sind aber deutlich kleiner, und bestehen nur aus wenigen Bits. Es sind folgende Datentypen in den Wert-Zellen für Windows NT 6.0 und höher möglich:[11]

  • REG_BINARY: Roher Binärcode, der ohne Formatierung oder Parsen verarbeitet werden kann. Die Daten können entweder direkt binär (Nullen und Einsen) oder mit einem Hex-Editor angesehen werden.
  • REG_DWORD: Ein Binärdatentyp, bei dem 32-bittige Integer-Werte als 4-Byte lange Hexadezimalwerte speichert. Wird für inkrementelle Werte, 4-Byte-Statuscodes oder boolesche Variablen (0=falsch, 1=wahr) genommen.
  • REG_QWORD: Ein Binärdatentyp, bei dem 64-bittige Integer-Werte als 8-Byte lange Hexadezimalwerte speichert. Wird wie DWORD eingesetzt, nur für größere Werte.
  • REG_SZ: Eine Zeichenkette aus Unicode-Schriftzeichen. Für Namen, Beschreibungen, Systempfade usw.
  • REG_EXPAND_SZ: Eine Zeichenkette variabler Länge die Umgebungsvariablen wie %systemroot% enthält, die beim Lesezugriff expandiert werden.
  • REG_MULTI_SZ: Multi-Parameter-String, dessen einzelne Elemente durch Standard-Trennzeichen abgetrennt werden, sodass diese einzeln aus der Zelle herausgepickt werden können.
  • REG_FULL_RESOURCE_DESCRIPTOR: Ein Wert der eine kodierte Beschreibung der Hardware-Ressource enthält, z. B. eines Laufwerkes, Chipsatzes usw.

Speicherung von Programmeinstellungen[Bearbeiten]

Ein weiter verbreiteter Irrglaube ist, dass Programme all ihre Einstellungen in der Registrierungsdatenbank speichern würden. Tatsächlich werden dort im Idealfall von Nicht-Betriebssystemsoftware nur die nötigsten Informationen abgelegt. Diese Informationen sind entweder für Windows, oder andere Programme von Interesse. Die Registry speichert meist weder die Spielstände des Ego-Shooters, noch je die Themes des Firefox, welche Software aber wirklich wieviel in der Registry ablegt ist vom System nicht beschränkt und daher kaum pauschal hervorzusagen. Die Registrierungsdatenbank ist für Anwendungen mehr eine Pinnwand oder ein Schwarzes Brett. Nur betriebssystemeigene Komponenten wie der Internet Explorer oder betriebssystemnahe Komponenten wie Treiber machen stark von der Registry gebraucht. Für die Masse der Anwendungen gibt es folgende Pfade, um Informationen und Dateien abzulegen:

  • C:\Programme, was allerdings ungünstig ist, da hier nur mit Adminrechten geschrieben werden kann. Wenn hier Programmeinstellungen geändert werden müssen, meist im Zuge von Updates, kommt der Dialog der Benutzerkontensteuerung.
  • %userprofile%\AppData\Roaming wird meist gewählt. Die hier hinterlegten Ordner ziehen mit dem Benutzer um, wenn sich dieser an einem anderen Rechner der Domäne anmeldet. LibreOffice legt hier Konfigurationsdaten ab.
  • %userprofile%\AppData\Local wird seltener gewählt, da dieser Ordner bzw. sein Inhalt nicht mit dem Benutzer wandert. JRE und LibreOffice legen hier nichts ab, aber zum Beispiel der Ressourcen-Monitor (resmon.exe) seine Konfigurationsdatei.
  • %userprofile%\AppData\LocalLow ist ein Sandbox-Verzeichnis mit niedriger Verbindlichkeitsstufe. Die Java-Laufzeitumgebung legt hier ihre Konfigurationsdateien und weitere ab.
  • C:\Programdata ist das Verzeichnis der Daten, die alle Benutzer betreffen. LibreOffice legt hier zum Beispiel nichts ab, aber die Java-Laufzeitumgebung eine XML-Datei mit Update-Einstellungen.

Manuelle Bearbeitungsmöglichkeiten[Bearbeiten]

Registrierungs-Editor[Bearbeiten]

Icon von regedit.exe

Um manuell in der Registrierungsdatenbank zu editieren, stellt Windows den Registrierungs-Editor regedit.exe bereit. Dieser kann in der Suchleiste durch Eingabe von regedit aufgerufen werden. In der linken Spalte werden die Hives und Schlüssel-Zellen hierarchisch abgebildet, rechts werden die dazugehörigen Wert-Zellen eines Schlüssels samt ihres Inhaltes einzeln aufgelistet. Die Schlüssel-Listen-Zellen werden nicht dargestellt, sondern nur durch die Baumstruktur der Schlüssel abstrahiert. Die Wert-Listen-Zellen sind ebenfalls nicht sichtbar, bilden aber die Struktur der Liste rechts. Die Sicherheits-Beschreibungs-Zellen werden durch das Kontextmenü abstrahiert, wenn auf einen Schlüssel Rechtsklick > Berechtigungen... ausgeführt wird.

Die gesamte Registry kann exportiert werden wenn auf das Symbol „Computer“ Rechtsklick > Exportieren ausgeführt wird. Gerade nicht eingehängte Teile, z. B. Schema.DAT und Components.DAT bleiben dabei aber unberücksichtigt. Wird ein (Unter)Schlüssel angewählt und exportiert, wird dieser samt seiner Unterstrukturen in eine Registrierungsdatei mit der Dateiendung *.reg geschrieben, welche in Unicode kodiert, und damit menschenlesbar ist. Wird ein Schlüssel gewählt und im Fenstermenü Datei > Drucken... gewählt, werden auch die Informationen der Schlüssel-Zellen ausgedruckt, welche im Registrierungs-Editor nicht angezeigt werden, aber Teil der Zelle sind. Zum Beispiel den letzten Schreibzugriff und der Klassenname.[22] Die *.reg-Dateien sind Unicode-Textdateien mit der Zeichenfolge „Windows Registry Editor Version 5.00“ in der ersten Zeile. Die Syntax ist wie folgt:

[<Hivename>\<Schlüsselname>\<Unterschlüsselname>]
"Wertname"=<Werttyp>:<Wertdaten>

Wenn der Standardwert eines Schlüssels bearbeitet werden soll, wird ein At-Zeichen vorangestellt:

[<Hivename>\<Schlüsselname>\<Unterschlüsselname>]
@=<Werttyp>:<Wertdaten>

String-Werte benötigen keine Werttyp-Angabe. Pfade in Wert-Zellen müssen aber mit Doppelbackslash „\\“ geschrieben werden, einzelne „"“ als „\"“. Für den Werttyp gibt es folgende hex()-Abkürzungen:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Wikipedia]
"PathToExe"="C:\\Program Files (x86)\\ACME Corp\\ACE.exe"
"haenschen"=hex:<Binär-Wert>
"klein"=dword:<DWORD-Wert>
"geht"=hex(0):<REG_NONE-Wert>
"allein"=hex(1):<REG_SZ-Wert>
"in"=hex(2):<REG_EXPAND_SZ Wert>
"die"=hex(3):<Binär-Wert> ; identisch mit "hex:"
"weite"=hex(4):<DWORD-Wert> ; Little-Endian
"Welt"=hex(5):<DWORD-Wert> ; Big-Endian
"hinein"=hex(7):<REG_MULTI_SZ-Werte> ; getrennt durch Komma
"Stock"=hex(8):<REG_RESOURCE_LIST-Werte> ; getrennt durch Komma
"und"=hex(a):<REG_RESOURCE_REQUIREMENTS_LIST-Werte> ; getrennt durch Komma
"Hut"=hex(b):<QWORD-Wert> ; acht Hex-Werte getrennt durch Komma

Ein vorangestelltes Minus entfernt den Schlüssel:

[-HKEY_LOCAL_MACHINE\SOFTWARE\Wikipedia]

Werte in einem Schlüssel werden durch ein „-“ nach dem Wertname entfernt:[22]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wikipedia]
@=-
"MeineMeinung"=-

wobei @=- den Standardwert entfernt, und "MeineMeinung"=- den String MeineMeinung und seinen Wert. In die Reg-Daten können auch Kommentare einfließen:

; Dies ist ein Kommentar. Er fällt vergleichsweise lang aus
[HKEY_LOCAL_MACHINE\SOFTWARE\Wikipedia]
"MeineMeinung"="WikipediaIstGut"

Die Reg-Dateien werden in die Registrierungsdatenbank gelesen, wenn sie doppelt geklickt werden. Ein Editieren ist mit Rechtsklick > Bearbeiten möglich.

PowerShell[Bearbeiten]

Hauptartikel: Windows PowerShell

Seit dem Erscheinen der Windows PowerShell gibt es eine weitere sehr einfache Möglichkeit, die Registry zu verwalten. Dabei kann man auf die Registry direkt über die Konsole oder durch ein Shellskript wie auf ein herkömmliches Laufwerk zugreifen. Die PowerShell kann quasi zwischen den Verzeichnis-Welten des Object Managers und des Configuration Managers wechseln. Im „normalen“ Verzeichnis navigiert man mit den Aliassen ls um sich Unterverzeichnisse anzeigen zu lassen, cd <ziel> um ein Unterverzeichnis anzunavigieren, cd .. um ein Verzeichnis zurückzugehen usw. Gibt man beispielsweise cd HKLM: ein, wechseln man auf den Hauptschlüssel HKEY_LOCAL_MACHINE. Zu den Unterschlüsseln gelangt man ebenfalls über den Befehl cd oder in der Langform Set-Location. Der Befehl Get-ItemProperty . zeigt alle Eigenschaften (Registry-Einträge), die für den aktuellen Registryschlüssel gespeichert sind. Auf diese Weise lassen sich beispielsweise durch Eingabe der folgenden Befehlsfolge in der PowerShell alle Einträge des Run-Schlüssels anzeigen:

cd HKLM:
cd Software\Microsoft\Windows\CurrentVersion\Run
Get-ItemProperty .
Navigieren mit der PowerShell

Nach dem Eingeben erfolgt unter anderem (PSPath, PSParentPath, PSChildName, PSProvider) als Ausgabe PSDrive: HKCU. Gleiches gilt, wenn man die Laufwerke des Rechners durch den Befehl Get-PSDrive anzeigen lässt, wobei hier nicht alle Registry-Laufwerke angezeigt werden. Wie bereits oben im Anschnitt „Arbeitsweise der Registry“ gezeigt, wird die Registry von Windows selbst wie ein Laufwerk/Gerät verwaltet, was in der PowerShell auch sichtbar wird. Mit dem Befehl cd C:\ oder einem anderen Laufwerksbuchstaben wechselt die PowerShell wieder in die Welt des Object Managers / Datei-Explorers zurück.

Auch ein indirektes Auslesen der Registry wird damit möglich: Mit den Befehlen $key="HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" wird der Pfad geholt und in die Variable $key geschrieben, $wert="Test" holt den Wert „Test“ und steckt ihn in die Variable $wert, und mit (Get-ItemProperty $key).$wert kann die Eigenschaft „Test“ im Schlüssel „Run“ ausgegeben werden, hier also der Pfad des Autostarteintrages.

Der Befehl New-Item HKCU:\Software\Wikipedia (Alias: md) legt einen neuen Schlüssel namens „Wikipedia“ an, Remove-Item HKCU:\Software\Wikipedia (Alias: del) entfernt ihn wieder. Mit New-ItemProperty -Path HKCU:\SOFTWARE\Wikipedia -Name MeineMeinung -PropertyType String -Value WikipediaIstGut wird eine Zeichenfolge namens „MeineMeinung“ mit dem Wert „WikipediaIstGut“ im Schlüssel „Wikipedia“ abgelegt. Neben String (REG_SZ) sind ExpandString (REG_EXPAND_SZ), Binary (REG_BINARY), DWord (REG_DWORD), MultiString (REG_MULTI_SZ) und QWord (REG_QWORD) ebenfalls zulässig.

Konsolenregistrierungsprogramm[Bearbeiten]

Das Konsolenregistrierungsprogramm reg.exe läuft nur innerhalb einer Eingabeaufforderung cmd.exe, wobei die Befehle auch in der PowerShell eingesetzt werden können. Die Syntax ist dabei sehr einfach, der Nachteil aber die fehlende Befehlszeilenergänzung, was das Risiko von Schreibfehlern erhöht. Die Syntax zum Abfragen von Schlüsseln ist wie folgt:REG QUERY Schlüssel(pfad), mit den angehängten optionalen Parametern /v Wert (sucht nach einem bestimmten Registrierungswert), /ve (sucht nach dem Standard- oder leeren Wert), und /s (sucht nach allen Unterschlüsseln und Werten). Der Befehl

reg query HKCU\Software\Microsoft\Windows\Currentversion\run

in einer cmd.exe eingegeben gibt eine Liste aller Autostarteinträge des Run-Schlüssels im Benutzer-Hive zurück. Die Syntax zum Anlegen von Schlüsseln ist wie folgt: REG ADD Schlüssel mit den angehängten optionalen Parametern /v Wert (hinzuzufügender Wert unter dem Schlüssel), /ve (fügt einen Standardwert hinzu), /t (Datentypen: REG_SZ | REG_MULTI_SZ | REG_DWORD_BIG_ENDIAN | REG_DWORD | REG_BINARY | REG_DWORD_LITTLE_ENDIAN | REG_NONE | REG_EXPAND_SZ), /s (bestimmt das Trennzeichen in der Datenzeichenfolge), /d (Daten), und /f (Überschreiben). Der Befehl

reg add HKCU\Software\Microsoft\Windows\Currentversion\run /v Test /t REG_SZ /d calc.exe

legt im Autostartschlüssel „Run“ die Zeichenfolge (REG_SZ) namens „Test“ an, welche als Wert „calc.exe“ hat. Würde dieser Schlüssel beibehalten, würde sofort nach dem Einloggen des Users der Taschenrechner aufpoppen. Die Syntax zum Entfernen von Schlüsseln ist wie folgt: REG delete Schlüssel mit den angehängten optionalen Parametern /v Wert (zu löschender Wert unter dem Schlüssel), /ve (löscht den Wert des Standardwertes), /va (löscht alle Einträge des Schlüssels), und /f (für “mit Gewalt”). Der Befehl

reg delete HKCU\Software\Microsoft\Windows\Currentversion\run /v Test

löscht die Zeichenfolge „Test“ mit ihrem Wert „calc.exe“. Der böse Taschenrechner ist gebannt. Mit dem Befehl REG COPY Schlüssel1 Schlüssel2 wird der Schlüssel 1 an die Position von Schlüssel2 kopiert. Mit dem Parameter /s werden die kompletten Unterschlüssel mitgenommen, /f erzwingt das Kopieren. Weitere Befehle wie Save, Load, Unload, Restore, Compare, Export, Import, usw. usf. sind möglich.

Registry-Cleaner[Bearbeiten]

Vielfach wird damit geworben, dass eine „Reinigung“ der Registrierungsdatenbank notwendig oder wünschenswert sei, um einen Geschwindigkeits- und Stabilitätsvorteil zu erhalten. Konkrete Tests zeigen aber keinen greifbaren Unterschied: Die Webseite Windows Secrets setzte ein frisches Windows 7 auf, und konnte eine Bootzeit von 32 Sekunden bis zum Anmeldebildschirm, und 39 Sekunden bis zum Desktop erreichen. Die Registry war 99 MB klein, das System 12,2 GB groß. Nach der Installation der 20 beliebtesten Windows-Anwendungen stieg die Zeit auf 61 und 629 Sekunden, die Größe der Registry stieg auf 169 MB an, die des Systems auf 15,4 GB. Nach der Deinstallation aller Anwendungen schrumpfte die Zeit auf 37 bzw. 83 Sekunden, die Registry schrumpfte auf 105 MB zusammen, und die Größe des Systems auf der Festplatte auf 13,6 GB. Nach dem Klonen des Abbildes wurden drei verschiedene Reinigungsprogramme getestet (Datenträgerbereinigung, CCleaner, jv16 PowerTools 2011). Danach konnten jeweils wieder die Bootzeiten vor dem Test erreicht werden.[23]

Überflüssig: Programme zur Defragmentierung der Registry

Die Windows-interne Datenträgerbereinigung besitzt keine Möglichkeit, vermeintlich überflüssige Einträge aus der Registry zu löschen. Der CCleaner und andere Programme bieten dies aber an. Der Sinn dieser Maßnahme ist umstritten. Bis NT 5.2 (Windows XP) konnte der Bootvorgang scheitern, wenn Kernel und SYSTEM.DAT mehr als die ersten 16 MB Arbeitsspeicher belegten, bei Windows 2000 scheiterte er definitiv.[24] Microsoft bot auch deshalb das hauseigene Tool „RegClean“ zum Entfernen unnötiger Registryeinträge an. Dies ist bei allen modernen NT-Versionen überflüssig.

Windows-Registrierungsdatenbank ohne Windows[Bearbeiten]

Das für Linux- und Unix-Systeme verfügbare Win32-API namens Wine enthält eine eigene Implementation der Windows-Registrierungsdatenbank. Wine selbst legt seine eigenen Einstellungen darin ab. Daneben können andere Windows-Programme, die auf Wine laufen, ihre Einstellungen dort eintragen. Für Win32-Anwendungen erscheint die Registrierungsdatenbank genau gleich wie auf einem Windows-NT-System. Im Hintergrund befindet sich aber – anders als bei Windows-NT-Systemen und wie in unixoiden System für Einstellungen üblich – keine Datenbank, sondern einfache ASCII-Textdateien. In den folgenden Dateien im Verzeichnis ~/.wine ist die Registrierungsdatenbank von Wine in Form lesbarer Texte enthalten:[25]

Datei Schlüssel
system.reg HKEY_LOCAL_MACHINE
user.reg HKEY_CURRENT_USER
userdef.reg HKEY_USERS\.Default

Das ReactOS-Projekt, das versucht Windows-NT nachzubauen, übernimmt Teile von Wine, darunter auch die Umsetzung der Windows-Registrierungsdatenbank.[26]

Alternativen[Bearbeiten]

In den meisten unixoiden Betriebssystemen, wie FreeBSD, Mac OS X oder linuxbasierten gibt es keine zentrale Konfigurationsdatenbank, sondern zahlreiche zentral abgelegte Konfigurationsdateien.

Jedoch gibt es Projekte die Registry-artige Datenbanken auch für unixoide Systeme bereitstellen wollen, beispielsweise Elektra[27][28] oder die Gnome-Konfigurationsdatenbank GConf bzw. der Nachfolger DConf. GConf baute im Gegensatz zur Windows-Registry und DConf konsequent auf XML-Dateien auf, was die Möglichkeit bot, die Schlüssel mit jedem Texteditor oder XML-Parser zu lesen und bearbeiten. Ebenso legt Elektra die Schlüssen in Plain-text-Dateien ab, die z. B. mit Editoren wie vi bearbeitet werden können.[29]

Apple setzt bei Mac OS X teilweise auf sogenannte Property Lists, die im XML-, JSON- oder in einem proprietären Binär-Format vorliegen können.[30]

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. a b c d e  Martin Grotegut: Windows 7 in Unternehmensnetzen mit Service Pack 1, IPv4, IPv6. Springer, 2011, ISBN 3-642-01034-2.
  2. Vorlage:Internetquelle/Wartung/Datum nicht im ISO-FormatTools rund um die Windows-Registry. Computerwoche, 28.05.2013, abgerufen am 18. Januar 2015 (deutsch).
  3. a b Windows 7 / Windows Server 2008 R2: Upgrade Paths, Registry Enhancements, Crash Dumps and Page File Sizing. Microsoft TechNet, 1. Oktober 2009, abgerufen am 18. Januar 2015 (englisch).
  4. a b Ingo Böttcher (MVP): Die besten Windows Tuning Tipps... 7. Juni 2011, abgerufen am 18. Januar 2015 (deutsch).
  5. a b Windows-Registrierungsinformationen für Benutzer mit fortgeschrittenen Kenntnissen. Microsoft Support, 6. Mai 2013, abgerufen am 11. Februar 2015 (englisch).
  6. Netzwelt-Wissen: Die Registrierungsdatenbank in Windows. Netzwelt, 16. Mai 2011, abgerufen am 18. Januar 2015 (deutsch).
  7.  Paul Robichaux: Managing The Windows 2000 Registry. O’Reilly & Associates, 30. Juni 2000, ISBN 1-56592-943-8.
  8. Vorlage:Internetquelle/Wartung/Datum nicht im ISO-FormatWhy is a registry file called a "hive"? Comment List MSDN TechNet, 8 Aug 2003, abgerufen am 18. Januar 2015 (englisch).
  9. a b Einblick in den Windows Vista-Kernel: Teil 2. Microsoft TechNet, März 2007, abgerufen am 20. Januar 2015 (englisch).
  10. a b c d e f g h i j  Mark Russinovich, David Solomon, Alex Ionescu: Windows Internals, Part 2. Microsoft Press, 2012, ISBN 0-7356-6587-7.
  11. a b c d e f g h i  William Stanek: Windows Server 2008 Inside Out. Microsoft Press, 2008, ISBN 0-7356-2438-0.
  12. Windows-Registrierung: Richtlinien auf Wikibooks
  13. Use PowerShell to Decrypt LSA Secrets from the Registry. Microsoft TechNet, 12. Juli 2012, abgerufen am 18. Januar 2015 (englisch).
  14. LocalSystem Account. Microsoft, abgerufen am 18. Januar 2015 (englisch).
  15. The size of the "HKEY_USERS\.DEFAULT" registry hive continuously increases on a Windows Server-based server. Microsoft Hilfe und Support, abgerufen am 18. Januar 2015 (englisch).
  16. What does "HKEY_LOCAL_MACHINE\Schema" do? Microsoft TechNet, 4. Juli 2008, abgerufen am 18. Januar 2015 (englisch).
  17.  Andrew S. Tanenbaum: Moderne Betriebssysteme. Addison-Wesley Verlag, 2009, ISBN 3-8273-7342-5, S. 954.
  18. a b  Paul McFedries: Microsoft Windows Vista Unleashed. Sams, 2008, ISBN 0-672-33013-X, S. 299ff.
  19. a b c d e f g h i  Mark Russinovich, David Solomon, Alex Ionescu: Windows Internals, Part 1. Microsoft Press, 2012, ISBN 0-7356-4873-5.
  20. a b c d e f g h i Vorlage:Internetquelle/Wartung/Datum nicht im ISO-FormatMark Russinovich: Inside the Registry. 2000?, abgerufen am 18. Januar 2015 (englisch).
  21.  Tarik Soulami: Inside Windows Debugging. Microsoft Press, 2012, ISBN 0-7356-6278-9.
  22. a b  Holger Schwichtenberg u. weitere: Windows Vista Business. Addison-Wesley Verlag, 2007, ISBN 3-8273-2422-X.
  23. Putting Registry-/system-cleanup apps to the test. Windows Secrets, 10. November 2011, abgerufen am 18. Januar 2015 (englisch).
  24. System may not start when creating a large number of logical units and volumes. Support Microsoft, abgerufen am 20. Januar 2015 (englisch).
  25. Using the Registry and Regedit (englisch)
  26. Using ReactOS Registry format (englisch)
  27. Interview: Elektra, die Linux Registry auf golem.de (2004)
  28. www/ Software/ Elektra auf Freedesktop.org (englisch)
  29. Interview: Elektra, die Linux Registry auf golem.de (2004)
  30. The plist(5) manual page auf developer.apple.com. Abgerufen am 23. Januar 2014.