Für forensische Untersuchungen des Arbeitsspeicherinhalts bietet sich unter Microsoft Windows auch ein Crashdump an. Allerdings sind hierfür einige Vorbereitungen notwendig.
Die einzelnen Schritte beschreibt Microsoft in der Knowledge Base im Artikel 244139. Zunächst ist ein Parameter in der Registry zu setzen:
REGEDIT4[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
"CrashOnCtrlScroll"=dword:00000001
Der Parameter wird durch den Treiber des Tastaturcontrollers ausgewertet. Bei Verwendung einer USB-Tastatur ist die Einstellung deshalb leider wirkungslos.
Wird nun die rechte Ctrl-Taste gedrückt gehalten und zweimal ScrollLock betätigt, so generiert der Treiber einen STOP-Error 0x000000E2. Das Betriebssystem erstellt daraufhin einen Crashdump.
Windows kennt mehrere Arten von Crashdumps:
- Das kleine Speicherabbild umfasst bei 32bit-Systemen nur 64 kiB (bei 64bit-Systemen ist es doppelt soviel, 128 kiB). Es enthält gerade einmal den Fehlercode, eine Liste der geladenen Gerätetreiber sowie der Datenstrukturen EPROCESS und ETHREAD, die den aktuellen Prozess und Thread beschreiben.
- Das Kernelspeicherabbild beinhaltet bereits alle Seiten des physischen Arbeitsspeichers, die dem Kernel zugeordnet sind. Der Usermode-Prozessen zugewiesene Speicher fehlt also in einem derartigen Abbild.
- Das vollständige Speicherabbild schließlich enthält alle Seiten des physischen Speichers.
Für forensische Zwecke ist also nur das vollständige Speicherabbild brauchbar. Für seine Erstellung benötigt Windows eine Auslagerungsdatei, die mindestens 1 MiB größer als der physische Speicher sein muss. Die Auslagerungsdatei muss zudem auf dem Startvolume, also dem Volume mit dem \WINDOWS beziehungsweise \WINNT-Verzeichnis, angelegt sein.
Der Grund dafür liegt auf der Hand. Üblicherweise erstellt das Betriebssystem dann einen Crashdump, wenn es zu einem schwerwiegenden Fehler gekommen ist und beinahe nichts mehr geht. Für die forensische Auswertung ist es wünschenswert, dass sich während der Erstellung des Dumps möglichst wenig im System ändert. Beide Situationen lassen sich gleichermaßen gut handhaben, indem man möglichst wenig Funktionalität des Betriebssystems nutzt. Konkret bedeutet das den Verzicht auf Disk-Caching, NTFS und FAT32. Lediglich der Miniport-Treiber - und auch hier nur eine Arbeitskopie und nicht das Original für die gewöhnlichen Plattenzugriffe - wird benutzt.
Ohne Dateisystem-Treiber gibt es aber auch die so vertrauten Objekte "Verzeichnis" und "Datei" nicht mehr. Als einzige Möglichkeit bleibt, in vorher festgelegte Bereiche auf der Festplatte zu schreiben. Genau hierfür bietet sich die Auslagerungsdatei an. Woher kommt dann aber nach dem provozierten Crash und dem sich anschließenden Neustart die Datei mit dem Speicherabbild?
Beim nächsten Systemstart erkennt Windows (genauer der SMSS), dass ein Crashdump in die Auslagerungsdatei geschrieben wurde. Um die Informationen zu bewahren, schützt es die Datei vor Schreibzugriffen der Speicherverwaltung.
Später überprüft dann auch Winlogon die Auslagerungsdatei. Es ruft dann das Dienstprogramm Savedump.exe auf, das den Crashdump aus der Auslagerungsdatei in eine normale Datei umkopiert.
Das erklärt, warum nicht nur der Bluescreen beim Erstellen des Crashdumps so lange auf dem Bildschirm erscheint, sondern auch warum der Anmeldebildschirm nach dem denn fälligen Neustart so lange auf sich warten lässt.
