Creopard header Logo

Der Bootprozess von Windows 95 & 98 erklärt

Update: 13.07.2023 | Erstellt: 06.07.2020 von creopard

Unterstüzen Sie dieses Projekt mit Ihrer Spende

Herzlichen Glückwunsch,
Ihr Werbeblocker funktioniert!

Wenn Sie unsere Inhalte nützlich finden, würden wir uns über eine kleine Unterstützung freuen. Sie können auch gerne Ihren Werbeblocker für diese Seite deaktivieren, um kostenlose Dienste weiterhin zu ermöglichen.

Dieser Hinweis erscheint, weil Sie einen Werbeblocker verwenden.


Der Bootprozess von Windows 95 & 98 erklärt
Klick zum Vergrößern
Bild: www.creopard.de

Der Startprozess von Windows 9x Systemen lässt sich in 6 Phasen einteilen:

  1. Phase der Stromversorgung
  2. BIOS-Phase
    • BIOS-POST
    • BIOS-PnP
    • BIOS-Boot-Geräte
  3. Betriebssystem unabhängige Boot-Phase
    • Master Boot Record
  4. Betriebssystem Real-Modus-Phase
    • Partition Boot Record
    • IO.SYS
    • WinBoot.ini und MSDOS.sys
    • Config.sys
    • Command.com und AutoExec.bat
    • ScanDisk.ini (Win95 OSR2 bis Win98SE)
    • WinStart.bat
  5. Windows-Phase
    • HKEY_LOCAL_MACHINE
    • WinInit.ini
    • System.ini
    • Win.ini
    • AllUsers Autostart
  6. Windows Login
    • HKEY_CURRENT_USER
    • Autostart Gruppe

(Diese Beschreibung skizziert den normalen Windows-Startvorgang. Mehrere Faktoren können allerdings einen Ausflug in den DOS-Modus verursachen.)

Phase der Stromversorgung

Das Netzteil prüft die Spannungen auf Stabilität und Masse, bevor es das System einschaltet und das Power-Good-Signal aktiviert, damit der Prozessor mit der Verarbeitung beginnt.

Wenn es Probleme auf dieser Ebene gibt, z.B. ein Kurzschluss, ein falsch ausgerichtetes IDE-Datenkabel oder ein Masseversatz von etwas, das von einer anderen Steckdose an den Parallelport angeschlossen ist, dann sollte das Netzteil das System nicht einschalten.

Dies ist dann der Fall, wenn die Netzspannung an den Monitor weiterleitet wird, aber das System ansonsten völlig tot ist; keine Lüfter- oder Festplattenaktivität, keine LED-Reaktionen der Tastatur.

Gewöhnlich ist das erste Anzeichen dafür, dass dieser Punkt überschritten wird, wenn alle drei Tastaturstatus-LEDs gleichzeitig kurz aufblinken; das ist wahrscheinlich das Ende dieser Phase des Bootvorgangs.

BIOS-POST

Das System-BIOS (Basic Input/Output System) ist ein Satz von betriebssystemunabhängigen Programmen im ROM, die das System konfigurieren, ein Betriebssystem (BS) suchen/booten und Serviceroutinen bereitstellen, die das BS verwenden kann. Die erste BIOS-Aufgabe ist der "Power On Self Test" (POST), der seinen Ursprung in der 286-Ära hat!

Zunächst wird ein Scan des Speichers zwischen 640k und 1M durchgeführt, wobei nach 55AA (hex)-Markierungen am Ende von Adressblöcken gesucht wird. Wenn sie gefunden werden, erkennt das BIOS dies als ein zusätzliches ROM und gibt an diesem Punkt die Kontrolle weiter (da SVGA-BIOS-Textnachrichten oft die ersten Zeichen sind, die auf dem Bildschirm erscheinen). Zusätzlich zum Grafik-Controller-BIOS können ROMs für LAN- und Festplatten-(Raid)Controller Steckkarten vorhanden sein.

Anschließend wird die Größe des RAM wird bestimmt und ein oberflächlicher Test durchgeführt, der auch eine Ausrüstungsliste von erkannten Geräten erstellt, z.B.: die Tastatur, die ersten drei parallelen Anschlüsse, die ersten vier seriellen Anschlüsse, die ersten zwei Diskettenlaufwerke und bis zu vier IDE-Geräte.

Einstellungen im CMOS-Speicher, können dieses Verhalten beeinflussen, so z.B. die Unterdrückung der Diskettensuchtests, die zur Unterscheidung von 40-Spur- von 80-Spur-Diskettenlaufwerken verwendet wurden. Die meisten generischen Systeme enthalten Programme innerhalb des BIOS, die CMOS-Setup-Menüs anzeigen, um diese Einstellungen zu steuern.

BIOS-PnP

Plug-n-Play verbindet mehrere "intelligente Geräte"-Hardwarestandards wie PCI, PCMCIA usw. zu einem zusammenhängenden System. PnP-Geräte, die nicht gebootet werden müssen, sollen so lange inaktiv bleiben, bis der PnP-Manager sie nach ihrer bevorzugten und alternativen Auswahl an Hardwareressourcen abfragt. Anschließend werden nacheinander die Ressourcen zugewiesen und jedes Gerät initialisiert.

Diese Zuweisungen werden im nichtflüchtigen RAM (NVRAM) gespeichert, das auch als PnP-Konfigurationsdaten oder "ESCD" bezeichnet wird.

Der PnP-Manager kann sich innerhalb des Betriebssystems befinden (PnP wurde zuerst in Windows 95 implementiert), innerhalb des BIOS oder als dritte Softwareschicht, die von einem Nicht-PnP-Betriebssystem aufgerufen wird (z. B. DOS- oder DOS-Modus).

Da verschiedene PnP-Manager ihre Informationen leicht unterschiedlich im NVRAM speichern können, ist es vorteilhaft, nur einen aktiven PnP-Manager zu haben. Deshalb besitzen viele BIOSe eine CMOS-Einstellung, die standardmäßig auf "PnP OS Present" (PnP-Betriebssystem vorhanden) gesetzt ist, wodurch BIOS-PnP im Prinzip deaktiviert und die PnP-Verwaltung dem Betriebssystem überlassen wird. Das bedeutet jedoch, dass PnP-Geräte im reinen DOS-Modus möglicherweise nicht verfügbar sind, da es dort keinen eingebauten PnP-Manager gibt.

Oft ist die allerletzte Bildschirmmeldung aus der BIOS-Phase etwas wie "Updating ESCD...", auf die in derselben Zeile "Success!" folgen kann.

BIOS Boot-Geräte

Nach Abschluss des POST, Erstellung einer Geräteliste und optionalem PnP-Management sucht das BIOS dann ein Boot-Gerät gemäß den im CMOS gespeicherten Einstellungen. Traditionell war das erste Boot-Gerät entweder ein LAN-Boot-ROM oder das erste Diskettenlaufwerk, aber normalerweise kann man andere Geräte wie Festplatten, CD-ROM-, LS120- oder Zip-Laufwerke auswählen, um davon direkt zu booten.

Auch wenn Diskettenviren heutzutage eher selten sind, war es früher eine gute Praxis, das Booten von Wechseldatenträgern jeglicher Art zu vermeiden. Fall man eine Virus infizierte Diskette in einem bootfähigem Laufwerk belässt, bekommt der Virus Zugang zum System, wenn man davon booten würde.

Wenn es sich bei dem Boot-Gerät um ein Plattenlaufwerk handelt, wird das Ende des ersten Sektors dieser Platte auf eine 55AA-Hex-Boot-Signatur überprüft. Wenn dieser Sektor gefunden wurde, wird er in den RAM-Speicher geladen und ausgeführt - womit die BIOS-Hardware-Phase des Boot-Vorgangs beendet wird.

Master Boot Record (MBR)

Im Falle von Festplatten wird der erste Sektor als Master Boot Record bezeichnet. Dieser soll einem bestimmten Muster folgen, unabhängig davon welche Betriebssysteme (BS) installiert sind. Tatsächlich ist der MBR neutrales Territorium. Er "gehört" keinem Betriebssystem, allerdings kann von jedem Betriebssystem erwartet werden, dass es vollständigen Standardprogrammcode in ihn einbettet.

Aufbau des MBR:

Innerhalb des ersten Sektors einer bootfähigen Festplatte befindet sich eine Tabelle mit vier Einträgen, die bis zu vier Partitionen (Adressbereiche) auf der Festplatte beschreiben. Jeder beginnt mit einem Markierungsbyte, das die untersten 7 Bits zur Identifizierung des Betriebssystems und des Partitionstyps verwendet. Das höchstwertige Bit wird gesetzt, wenn die Partition gebootet werden soll. Andernfalls wird es zurückgesetzt, um anzuzeigen, dass sie nicht gebootet werden soll. Es sollte dabei nur eine als "aktiv" markierte Partition vorhanden sein.

Der MBR-Code schlägt in der Partitionstabelle nach, um festzustellen, welche Partition aktiv ist und herauszufinden, wo diese Partition beginnt. Als nächstes wird er den ersten Sektor dieser Partition in den RAM-Speicher ziehen und prüfen, ob die letzten zwei Bytes einer 55AA-Hex-Boot-Signatur entsprechen. Wenn dies der Fall ist, handelt es sich um einen gültigen Bootsektor und der Code springt an den Anfang dieses Sektors und wird von dort aus ausgeführt. Damit markiert er das Ende der betriebssystemunabhängigen Bootphase der Festplatte.

Der MBR kann jedoch mit Programmcode überschrieben werden, der diesem Schema nicht folgt. So z.B. mit Code, der die BIOS-Festplattenbehandlungsroutinen umgeht, um Kompatibilitätsprobleme zu umgehen oder mit Malware-Code. Tatsächlich könnte es in diesem Sektor völliger Müll liegen, aber solange er in 55AA Hex endet, wird er vom BIOS angesprungen.

Wenn solche Umstände auftreten, hängt das System normalerweise mit einem schwarzen Bildschirm der nur die zuletzt angezeigte Textnachricht (typischerweise "Updating ESCD...") anzeigt. Einige moderne BIOS-Systeme sind hilfreicher und zeigen eine Meldung an von welches Gerät gebootet wird.

Partition Boot Record

Wenn man so weit gekommen ist, befindet man sich (zum ersten Mal) innerhalb eines Betriebssystems (BS). Bei den Betriebssystemen der DOS-Win9x-Reihe bis FAT32 passte der Partitions-Boot-Record in den ersten Sektor des Volumes und die FAT folgte unmittelbar danach. FAT32 ist anders; es verwendet die ersten drei Sektoren für den Boot-Record, verhält sich aber ansonsten gleich.

Vom Bootcode einer bootfähigen Microsoft DOS/Win9x-Partition wird erwartet, dass er eine Datei namens IO.SYS sucht und in diese springt. Win9x-Bootloader können eine IO.SYS innerhalb eines Dateisystem laden, egal wo sie sich innerhalb des Plattenvolumens befindet. Einige frühere DOS-Versionen verlangten jedoch, dass die Datei zusammenhängend ist und direkt nach dem Ende des Stammverzeichnisses beginnt.

Sowohl der Boot-Record der Partition, als auch der MBR sind seit langem traditionelle Einstiegsziele für Malware.

IO.sys

IO.sys ist die erste Datei, die im DOS- oder Win9x-Bootprozess geladen wird. Sie beinhaltet auch den ersten Code, der auf den Bildschirm geschrieben wird, seit das BIOS die Kontrolle an den MBR übergeben hat. Wenn also bis zu diesem Zeitpunkt etwas schief geht, gibt es keine sichtbaren Hinweise darauf, wo das Problem aufgetreten ist. Tatsächlich zeigten auch wirklich alte Versionen von MS-DOS hier nichts an. Bis zum Aufruf von "Command.com" wäre nichts sichtbar, es sei denn, ein geladener Gerätetreiber in der Config.sys gäbe etwas auf dem Bildschirm aus.

Win9x IO.sys zeigt eine Textmeldung wie "Windows 98 wird gestartet..." an, bevor es zur Sache geht. Während dieses Vorgangs sucht es nach einer Logo.sys-Datei und zeigt diese als Bitmap mit niedriger Auflösung und 256 Farben an, falls sie gefunden wird und "animiert" die Unterseite davon.

In MS-DOS vor Windows 95 hat IO.sys mehr Code geladen, der in MSDOS.sys enthalten war. Dann wurde die Config.sys geladen und interpretiert, aber das hat sich in MS-DOS 6 mit dem Aufkommen der mitgelieferten Plattenkomprimierung leicht geändert. Unter Windows 95 änderte sich dies vollständig, da der gesamte Code, der sich früher in IO.sys und MSDOS.sys befand, jetzt in einer einzigen IO.sys-Datei enthalten ist. In Windows ME hat sie sich erneut geändert. Hier scheint die IO.sys die gesamte Code-Funktionalität zu enthalten, die sich früher in IO.sys, HiMem.sys, IFSHlp.sys und vermutlich SetVer.exe befand.

WinBoot.ini und MSDOS.sys

Unter Windows 9x handelt es sich bei beiden Dateien um Text-Konfigurationsdateien mit der gleichen .ini-Datei-Syntax. Normalerweise ist WinBoot.ini nicht vorhanden und es wird stattdessen MSDOS.sys verwendet. Falls aber Winboot.ini vorhanden ist, wird sie statt MSDOS.sys verwendet. Zu beachten ist hierbei, dass das eben gestartete Betriebssystem (BS) zu diesem Zeitpunkt noch keine anderen Verzeichnisse kennt als das Stammverzeichnis (z.B. "C:\") des gebooteten Festplattenvolumens.
Die beiden Dateien sind vom Aufbau her identisch.

Diese Konfigurationsdateien können keinen Programmcode laden, aber der Abschnitt [Paths] informiert IO.sys darüber, wo sich Windows befindet. Der Abschnitt [Options] steuert verschiedene Dinge, z.B. ob als Reaktion auf einen F8-Tastendruck ein Boot-Menü angezeigt werden soll, welcher Boot-Menü-Eintrag als Standard genommen werden soll, ob Plattenkompressionstreiber geladen werden sollen, ob ein Bootlogo angezeigt werden soll und ob das System in den Windows- oder DOS-Modus booten soll.

Diese Einstellungen sind im Resource Kit und auf zahlreichen anderen Seiten und unter KB118579 dokumentiert, daher wird an dieser Stelle nicht näher auf dieses Thema eingegangen. Wissenswert: IO.sys überprüft die Registry, bevor das Boot-Menü angezeigt wird.

Wenn weder die Datei WinBoot.ini noch MSDOS.sys vorhanden ist, kann das System Windows nicht starten, da es dessen Pfad nicht kennt.

Config.sys

Nach der Verarbeitung der Datei WinBoot.ini oder MSDOS.sys wird Config.sys geladen und von IO.sys interpretiert. Die Dateierweiterung ".sys" deutet darauf hin, dass es sich um einen Real-Modus-Gerätetreiber handelt, tatsächlich handelt es sich jedoch um eine Text-Konfigurationsdatei, die die Geräteverwaltungsebene des Real-Modus Bootprozesses steuert. Die Datei verwendet auch hier die standardmäßige .ini-Syntax ist aber eigentlich ein Relikt aus den frühen Tagen von MS-DOS.

Der Aufbau und die Einsatzmöglichkeiten einer möglichen Config.sys sind hier beschrieben.

Zwei bestimmte Einstellungen sind explizit DOS interessant.

DOS=Single 

bewirkt, dass Windows 95 bis Windows 98 SE Systeme in den DOS-Modus und nicht in den Windows-Modus booten.

DOS=NoAuto

kehrt die implizite Voreinstellung "DOS=Auto" um und veranlasst den Bootvorgang, die Standardeinstellungswerte und das Laden der Dateien HiMem.sys, IFSHlp.sys und Setver.exe aus dem Windows-Teilbaum zu überspringen.

Wenn in Config.sys ein [Menu] vorhanden ist, wird die dort getroffene Auswahl über die Umgebungsvariable %Config% weitergegeben.

Um die Config.sys zu bearbeiten, kann in allen Versionen von Windows 9x das Programm "SysEdit.exe" oder "MSConfig.exe" in Windows 98 und höher verwendet werden. SysEdit.exe ermöglicht die direkte Bearbeitung und erstellt zudem ein Backup der Originaldatei als Config.syd.

Hinweis: Da Config.sys das Laden und Ausführen von Code ermöglicht, ist kann es auch ein Einstiegspunkt für Malware sein.

Command.com und AutoExec.bat

An diesem Punkt des Boot-Prozesses ist ein funktionsfähiger DOS-Modus vorhanden.

Wenn unter C:\ eine AutoExec.bat existiert (auch falls diese leer ist), wird ein Befehlsinterpreter geladen, um sie zu verarbeiten. Sofern eine Einstellung in der Config.sys die Standardeinstellung nicht überschreibt, wird dieser Interpreter "Command.com" sein. Ein Programm, das Batch-Dateien interpretiert und die Eingabeaufforderung in DOS und Windows bereitstellt.

Wenn unter C:\ keine AutoExec.bat existiert und das System auf dem Weg ist, Windows zu laden, dann wird Command.com nicht unter Windows geladen.

AutoExec.bat ist eine Batch-Datei und kann alle möglichen Befehle ausführen oder Programme starten, wobei zu bedenken ist, dass hier alle Einschränkungen des DOS-Modus gelten. Es gibt nur eine Besonderheit: Das Windows-Basisverzeichnis und sein Unterverzeichnis Command werden als Stub verwendet, wenn die erste Pfadangabe nicht %Path% verwendet, um diese einzuschließen. Wenn nachfolgende Pfadanweisungen innerhalb der Autoexec.bat diese Verzeichnisse nicht in den Pfad einschließen, werden sie ausgelassen.

Um die AutoExec.bat zu bearbeiten, kann in allen Versionen von Windows 9x das Programm "SysEdit.exe" oder "MSConfig.exe" in Windows 98 und höher verwendet werden. SysEdit.exe ermöglicht die direkte Bearbeitung und erstellt zudem ein Backup der Originaldatei als AutoExec.syd.

WinStart.bat

WinStart.bat ist interessant, da sie in einer Zwischenwelt von DOS und Windows lebt. Lange Dateinamen können als Parameter verwendet und auch vom Befehl "dir" angezeigt werden, aber es gibt noch kein Multitasking (Set-Anweisungen gelten global) und Win32-Befehlszeilen-Dienstprogramme wie WinSet.exe beenden sich über ihren "Dieses Programm erfordert Windows" Real-Modus-Stub. Er wird normalerweise von Installationsprogrammen der Windows 3.x Ära verwendet und ist ähnlich zu der Art und Weise, wie Win9x-Installationsprogramme die Datei Wininit.ini oder die "RunOnce"-Einträge in der Registry verwenden würden.

Nachdem WinStart.bat interpretiert wurde, wird Windows geladen und das Multitasking beginnt.

Hinweis: Da WinStart.bat die Ausführung von Code ermöglicht, ist kann es auch ein Einstiegspunkt für Malware sein.

ScanDisk.ini

Es ist unklar, ob Win.com erforderlich ist, um Windows in Windows 9x zu starten, aber es scheint notwendig zu sein, um Dateisystemfehler auszugeben und eine eventuell vorhandene WinStart.bat zu interpretieren.

Wenn ScanDisk.exe mit der Befehlszeilenoption /Custom ausgeführt wird, verwendet es ScanDisk.ini, um dessen Reaktion auf Fehler zu bestimmen und festzustellen, ob es die Ergebnisse des Scans protokollieren soll. Wenn Win.com den Windows-Prozess startet, prüft es die Bits innerhalb der FAT jedes Festplattenvolumens auf zwei Markierungen.

Die erste Markierung wird gesetzt, wenn das System aufgrund physikalischer Fehler keinen lesenden oder schreibenden Zugriff auf die Festplatte hatte. Ist sie gesetzt, führt ScanDisk eine Oberflächenprüfung aller Volumes auf dieser physikalischen Platte durch.

Die zweite Markierung wird gesetzt, wenn Windows mit dem Schreiben einer Datei beginnt und wird zurückgesetzt, wenn dieser Schreibvorgang abgeschlossen ist. Wenn sie also beim Systemstart gesetzt wird, bedeutet dies, dass das Schreiben einer Datei während der letzten Sitzung unterbrochen wurde (z.B. durch einen Absturz oder fehlerhaftes Beenden). Daher ist mindestens eine beschädigte Datei auf diesem Volume vorhanden, so dass ScanDisk auf dem betroffenen Volume Dateisystemprüfungen auf logische Fehler durchführt.

Wenn ScanDisk.exe auf diese Weise automatisch ausgeführt wird, wird der Schalter /Custom verwendet, so dass ScanDisk.ini den Prozess steuert. Die Standardeinstellungen für verschiedene Versionen von Windows 9x sind wie folgt:

  • Windows 95 und Windows 95 SP1: keine automatische Ausführung von ScanDisk.exe
  • Windows 95 OSR2.x: Eingabeaufforderung bei allen Fehlern und bei der Datenwiederherstellung, aber die Protokollierung nicht aktiv
  • Windows 98 und Windows 98 SE - Repariert alles ohne Aufforderung, Löschen der wiederhergestellten Daten, Überschreiben des Protokolls
  • Windows ME: wie unter Windows98, allerdings wird ScanDisk.ini nicht zur Steuerung des Prozesses verwendet

Es liegt in der Natur vieler logischer Dateifehler und fast aller physischer Fehler, dass Informationen verloren gehen und somit eine perfekte Reparatur unmöglich ist. Solange der Fehler nicht repariert ist, kann ScanDisk ihn erkennen. Sobald ScanDisk ihn "repariert", wird die Datei von ScanDisk nicht mehr als Fehler gekennzeichnet, ist aber wahrscheinlich (noch) defekt. Ohne ein Protokoll des Scanvorgangs, hat man also keine Möglichkeit mehr herauszufinden, welche Dateien ersetzt werden müssten. Wenn es ScanDisk erlaubt ist, wiederhergestellte Daten-Cluster mit physischen Fehlern oder verlorene Clusterketten, zu löschen, geht eine weitere Gelegenheit zur Reparatur von Schäden verloren.

Aus diesen Gründen sind die Standardeinstellungen der ScanDisk.ini eigentlich unverantwortlich und haben sich in späteren Versionen noch verstärkt.

HKEY_LOCAL_MACHINE

Zu diesem Zeitpunkt läuft Windows bereits. Multitasking ist vorhanden, Set-Anweisungen von DOS-Anwendungen sind nicht mehr global und Windows-Programme können gestartet werden.

Die einzige Möglichkeit, die Ausführung von Windows-Programmen nacheinander abzuarbeiten, besteht darin, diese von einer Batch-Datei aus zu starten und dabei mit "Start /W" zu veranlassen, die weitere Verarbeitung der Batch-Datei zu verzögern, bis der Prozess beendet ist.

Die Runxxx-Schlüssel sind Variationen von Run, RunEx, RunOnce, RunServices und RunNetworkServices (z.B. gibt es oft auch einen RunServicesOnce). Es ist unklar, ob diese eine Bedeutung für die Reihenfolge haben, obwohl sie sich in anderer Hinsicht unterscheiden. Die hier behandelten Schlüssel befinden sich in: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion

RunOnce-Einträge (und Variationen) werden nach ihrer Ausführung aus der Registrierung gelöscht und werden daher häufig von Installationsprogrammen (und Malware) verwendet.

RunServices (und Variationen) können dazu führen, dass ihre Prozesse vor der Strg-Alt-Entf-Taskleiste verborgen werden. Diese Schlüssel werden häufig von Antiviren-Programmen und Malware verwendet.

RunEx (und Variationen) sind von Microsoft als die neue und bevorzugte Form der Ausführung dokumentiert.

HKEY_LOCAL_MACHINE ist in der Registrierungsdatei System.dat enthalten. Diese Datei kann allerdings nicht direkt bearbeitet werden, da es sich um eine "strukturierte" Datei mit undokumentierter Struktur handelt. Man kann jedoch RegEdit.exe in allen Versionen von Windows 9x oder MSConfig.exe in Windows 98 verwenden, um diese Runxxx-Schlüssel zu bearbeiten. RegEdit erlaubt eine direktere Bearbeitung der Daten. Allerdings werden diese Änderungen "live" vorgenommen und es gibt keine Plausibilitätsprüfung, die verhindert, dass versehentlich etwas zerschossen wird.

Windows 95 hält sich einen Sicherungssatz der Registrierungsdateien System.dat und User.dat mit der Erweiterung .da0 vor, geht aber eher voreilig von einem Erfolg aus, bevor es diese Sicherungen mit dem aktuellen Satz erstellt. Die ursprüngliche, frisch installierte System.dat wird als C:\System.1 aufbewahrt.

Windows 98 und Windows ME halten auch das Original als C:\System.1 vor, behalten aber auch mehrere Sicherungen auf andere Weise.

Hinweis: Da diese Runxxx-Schlüssel die Ausführung von Code ermöglichen, stellen sie einen Einstiegspunkt für Malware dar.

Wininit.ini

Irgendwo in der Voranmeldephase von Windows interpretiert Wininit.exe die Datei Wininit.ini, falls diese im Windows-Basisverzeichnis vorhanden ist. Diese Datei wird in der Regel von Installationsprogrammen verwendet und es ist möglich, dass diese Datei nach der Verwendung geleert oder gelöscht wird.

Hinweis: Da Wininit.ini die Ausführung und Installation von Code erlaubt, stellt sie einen Einstiegspunkt für Malware dar.

System.ini

Die Datei System.ini stammt noch aus Windows 3.x Zeiten und kann daher auch von Windows 16Bit-Programmen verwendet werden (die keine Registry kennen). Die Funktion der System.ini innerhalb von Windows 3.x ist analog zu der Funktion der Config.sys unter DOS. Hier werden Gerätetreiber- und Systemeinstellungen vorgenommen. Die Registry ist normalerweise der übliche Ort für solche Einstellungen, aber die Windows 3.x -Konfigurationsdateien werden für die Legacy-Unterstützung beibehalten.

Innerhalb des [Boot]-Abschnitts befindet sich eine "Shell="-Direktive, die bestimmt, welches Programm die Benutzerschnittstellen-Shell sein wird.

Die "Shell="-Zeile wird häufig von Malware ausgenutzt, wobei "Expiorer.exe" (mit einem großen "i" geschrieben) eines der hinterhältigsten Beispiele ist. Wenn Sie Explorer.exe nicht durch eine eigene Shell ersetzt haben, sollte die Zeile Shell=Explorer.exe lauten, danach bis zur nächsten Zeile nichts mehr.

Weitere wichtige Einstellungen und das Laden von Gerätetreibern können im Abschnitt [386Enh] folgen (Windows 9x läuft immer im "386 Enhanced Mode", da der "Standard Mode" in Windows for Workgroups 3.11 und der "Real Mode" in Windows 3.1 aufgegeben wurde). Interner Code verwendet "illegale" Dateinamen, die mit * beginnen, z.B. device=*ebios.vxd, und es gibt andere Hinweise, um wahrscheinliche Add-Ins zu erkennen:

  • Explizite Pfade, z.B. device=C:\Pfad\irgendwas.vxd
  • Großbuchstaben, z.B. Device=VFINDT.VXD
  • Verwendung der Erweiterung .386, die normalerweise alten Windows 16Bit-Code angibt, z.B. Device=DATEI.386
  • Kommentare mit ";" die ggf. von einer Installationsroutie hinzugefügt wurden

Windows 9x kann die Einstellungen zwischen den .ini-Dateien der Windows 16Bit-Ära und der Registry jeweils aktualisieren. Wenn also Änderungen an der einen aber nicht an der anderen Stelle eingetragen werden, sollte die andere Stelle gegen geprüft werden.

Um die System.ini zu bearbeiten, kann in allen Versionen von Windows 9x das Programm "SysEdit.exe" oder "MSConfig.exe" in Windows 98 und höher verwendet werden. SysEdit.exe ermöglicht die direkte Bearbeitung und erstellt zudem ein Backup der Originaldatei. Darüber hinaus wird eine Kopie der ursprünglichen, frisch installierten System.ini als System.cb aufbewahrt und andere Installationsprogramme können Sicherungskopien mit anderen Erweiterungen hinterlassen (allerdings nicht .dat oder .da0!).

Hinweis: Da die System.ini die Ausführung und Installation von Code erlaubt, stellt sie einen Einstiegspunkt für Malware dar.

Win.ini

Win.ini stammt ebenfalls noch aus Windows 3.x Zeiten und kann daher ebenfalls von Windows 16Bit-Programmen verwendet werden (die keine Registry kennen). Die Funktion der Win.ini innerhalb von Windows 3.x ist analog zur Funktion der AutoExec.bat in DOS. Hier werden Benutzereinstellungen vorgenommen und Programme gestartet. Die Registry ist auch hier normalerweise der übliche Ort für solche Einstellungen, insbesondere wenn sie in Verbindung mit Benutzerprofilen verwendet wird, aber die Konfigurationsdateien von Windows 3.x werden für die Legacy-Unterstützung beibehalten.

Die "Run="- und "Load="-Zeilen bewirken, dass andere Dateien beim Start geladen werden (und sollten auf Malware überprüft werden). Dies ist eine besonders verbreitete Methode der Erweiterung im LAN.

Windows 9x kann die Einstellungen zwischen den .ini-Dateien der Windows 16Bit-Ära und der Registry jeweils aktualisieren. Wenn also Änderungen an der einen aber nicht an der anderen Stelle eingetragen werden, sollte die andere Stelle gegen geprüft werden.

Um die System.ini zu bearbeiten, kann in allen Versionen von Windows 9x das Programm "SysEdit.exe" oder "MSConfig.exe" in Windows 98 und höher verwendet werden. SysEdit.exe ermöglicht die direkte Bearbeitung und erstellt zudem ein Backup der Originaldatei. Andere Installationsprogramme können Sicherungen von Win.ini mit anderen Erweiterungen (allerdings nicht .com oder .bat!) aufbewahren.

Hinweis: Da Win.ini die Ausführung von Code erlaubt, stellt sie einen Einstiegspunkt für Malware dar.

All Users Autostart

Jeglicher Inhalt dieses Ordners "C:\Windows\All Users" wird wie der in der Autostart-Gruppe behandelt, allerdings unabhängig von der verwendeten Anmeldeidentität, sprich: für alle Benutzer. Wenn man also nach Malware Ausschau hält, sollte auch das Verzeichnis All Users in Augenschein genommen werden.

Hinweis: Da AllUsers es ermöglicht, Dateien auf dem Desktop zu starten oder zu belassen, stellt sie einen Einstiegspunkt für Malware dar.

Windows Login

Dies kann unbemerkt bleiben, wenn kein LAN vorhanden ist oder wenn es von "TweakUI" unterdrückt wird, aber dieser Punkt des Windows Bootvorgangs markiert die Trennung zwischen dem Teil für alle Benutzer dem Teil für ein bestimmtes Benutzerprofil, das je nach Anmeldeidentität variiert.

Jedes Benutzerprofil wird als ein Zweig von HKEY_USERS gesichert und das angemeldete Benutzerprofil wird als HKEY_CURRENT_USER geführt. Dies ist wichtig, wenn man versucht, Elemente vom Startvorgang auszuschließen oder wenn man Registrierungseinstellungen über Benutzerprofile hinweg migrieren möchte (z.B. als Teil der Administration, nachdem eine Anwendung, die unter einem Benutzerprofil installiert wurde, in anderen Benutzerprofilen nicht vorhanden ist).

Man sollte sich auch die ShellFolder-Einträge in jedem Profil ansehen, um zu prüfen, wo sich der Desktop, Senden an, das Startmenü und die Autostart-Gruppe für jedes Profil befinden könnte.

Eine abgebrochener Login verhindert den Zugriff auf das LAN und die gespeicherten Netzwerk-/Internet-Passwörter, hindert aber andere Systeme nicht daran, von außen auf gemeinsame Ordner oder Drucker dieses Systems zuzugreifen. Wenn der Login abgebrochen wird, kommt das Standardbenutzerprofil zur Anwendung. Dieses könnte dann z.B. sehr restriktiv konfiguriert werden.

HKEY_CURRENT_USER

Diese Einträge sind ähnlich wie die in HKEY_LOCAL_MACHINE abgesehen davon, dass sie nur für den aktuellen Benutzer gelten. Einige Malwareprogramme und Anwendungen benutzen die, weshalb man auch hier die Einträge prüfen sollte und nicht nur in der HKEY_LOCAL_MACHINE.

HKEY_USERS (und damit HKEY_CURRENT_USER) ist in der Registrierungsdatei User.dat enthalten. Diese Datei kann allerdings nicht direkt bearbeitet werden, da es sich um eine "strukturierte" Datei mit undokumentierter Struktur handelt. Man kann jedoch RegEdit.exe in allen Versionen von Windows 9x oder MSConfig.exe in Windows 98 verwenden, um diese Runxxx-Schlüssel zu bearbeiten. RegEdit erlaubt eine direktere Bearbeitung der Daten. Allerdings werden diese Änderungen "live" vorgenommen und es gibt keine Plausibilitätsprüfung, die verhindert, dass versehentlich etwas zerschossen wird.

Windows 95 hält sich einen Sicherungssatz der Registrierungsdateien System.dat und User.dat mit der Erweiterung .da0 vor, geht aber eher voreilig von einem Erfolg aus, bevor es diese Sicherungen mit dem aktuellen Satz erstellt. Die ursprüngliche, frisch installierte System.dat wird als C:\System.1 aufbewahrt.

Windows 98 und Windows ME halten auch das Original als C:\System.1 vor, behalten aber auch mehrere Sicherungen auf andere Weise.

Hinweis: Da diese Runxxx-Schlüssel die Ausführung von Code ermöglichen, stellen sie einen Einstiegspunkt für Malware dar.

Autostart Gruppe

Jeglicher Inhalt dieses Ordners wird beim Start von Windows entsprechend den Dateizuordnungen gestartet (z.B. führen Verknüpfungen zu Ordnern zur Anzeige von Ordnerfenstern usw.) Wenn man einfach davon ausgeht, dass sich der Speicherort direkt unter dem Windows-Basisverzeichnis befindet, bearbeitet man möglicherweise den falschen Ordner, wenn Benutzerprofile den Speicherort des Autostart-Objekts umgeleitet haben. Man kann auch MSConfig.exe in Windows 98 und höher verwenden, um diese Einträge zu aktivieren oder zu deaktivieren.

Hinweis: Da Autostart das Starten von Dateien ermöglicht, stellt es einen Einstiegspunkt für Malware dar.






Ähnliche Artikel anzeigen:




Unterstüzen Sie dieses Projekt mit Ihrer Spende

Herzlichen Glückwunsch,
Ihr Werbeblocker funktioniert!

Wenn Sie unsere Inhalte nützlich finden, würden wir uns über eine kleine Unterstützung freuen. Sie können auch gerne Ihren Werbeblocker für diese Seite deaktivieren, um kostenlose Dienste weiterhin zu ermöglichen.

Dieser Hinweis erscheint, weil Sie einen Werbeblocker verwenden.