Crash ohne CtrlScroll

Windows zu einem Absturz zu zwingen, ist ein probates Mittel, um ein Speicherabbild für eine forensische Untersuchung zu erzeugen. Unglücklicherweise erfordert dies jedoch eine rechtzeitige Konfiguration des Computers vor einem Sicherheitsvorfall. In einem Beitrag fragt sich C4RTMAN, wie der Tastaturtreiber den Absturz hervorruft und ob es hierfür nicht auch eine andere Möglichkeit gäbe. Hier ist eine Antwort.

Sofern das System korrekt konfiguriert wurde, genügt ein zweimaliger Druck auf die Tasten Steuerung (Control) und Rollen (Scroll), um einen Systemabsturz auszulösen. Wenn Sie dann das resultierende Speicherabbild in einem Debugger öffnen, so finden Sie schnell einen Hinweis auf die Routine I8xProcessCrashDump des Tastaturtreibers i8042prt.sys:

BugCheck E2, {0, 0, 0, 0}
Probably caused by : i8042prt.sys ( i8042prt!I8xProcessCrashDump+53 )

Betrachtet man sich nun diese Routine etwas genauer, dann erkennt man zunächst allerlei Fallunterscheidungen von Tastaturcodes. Schließlich erkennt man aber, dass der Absturz durch einen Aufruf der Routine KeBugCheckEx mit dem Code 0xE2 eingeleitet wird.

.text:000127D6 Prepare_BugCheck_E2:                    
.text:000127D6                 or      esi, 300h
.text:000127DC                 add     eax, 220h
.text:000127E1                 cmp     [eax], esi
.text:000127E3                 pop     esi
.text:000127E4                 pop     ebx
.text:000127E5                 jnz     short done
.text:000127E7                 xor     ecx, ecx
.text:000127E9                 push    ecx             ; BugCheckParameter4
.text:000127EA                 push    ecx             ; BugCheckParameter3
.text:000127EB                 push    ecx             ; BugCheckParameter2
.text:000127EC                 push    ecx             ; BugCheckParameter1
.text:000127ED                 push    0E2h            ; BugCheckCode
.text:000127F2                 mov     [eax], ecx
.text:000127F4                 call    ds:__imp__KeBugCheckEx@20

Der Tastaturtreiber (und seine Konfiguration durch einen Eintrag in der Registry) werden also eigentlich gar nicht benötigt; wenige Zeilen Code mit einem Aufruf von KeBugCheck oder KeBugCheckEx reichen völlig aus. Falls Sie ein entsprechendes Programm nicht selbst schreiben möchten, so können Sie hierzu NotMyFault der Sysinternals verwenden und es mit der Option /crash aufrufen. (Anmerkung: der Gerätetreiber ruft KeBugCheck nicht direkt auf, sondern greift nicht reservierten Speicher zu.)

Aber löst das nun wirklich das Problem? Leider nicht, denn BugCheck wird zwar den bekannten blauen Bildschirm erscheinen lassen, das Speicherabbild erstellt der Kernel aber erst nach entsprechender Konfiguration - und einem anschließenden Neustart.

Archiv

Impressum

Dieses Blog ist ein Projekt von:
Andreas Schuster
Im Äuelchen 45
D-53177 Bonn
impressum@forensikblog.de

Copyright © 2005-2012 by
Andreas Schuster
Alle Rechte vorbehalten.
Powered by Movable Type 5.12