Mariusz Burdach bietet auf seiner Website ein kleines Toolkit an, das ein Speicherabbild nach Prozessen und Modulen durchsucht. Ein kurzer Artikel beschreibt den Hintergrund des Toolskits und hilft, die zu seinem Einsatz benötigten Adressen einiger Kernel-Variablen zu bestimmen.
Am 9. Juli 2005 veröffentlichte Mariusz Burdach seinen Artikel über die Analyse des Windows-Speichers. Er verfolgt insgesamt einen einfachen Ansatz. Das Speicherabbild wird mittels "dd" erstellt. Bei der Auswertung traversiert er die für den Windows-Kernel typischen doppelt verketteten Listen für Prozesse und Module.
Als Einstieg in diese Listen verwendet Burdach die Kernel-Variablen PsActiveProcessHead und PsLoadedModuleList. Beide Adressen lassen sich den Debugsymbolen des Kernels entnehmen. Um diese Adressen in Offsets des Speicherabbilds (und damit von virtuellen Adressen des Systems in physische Adressen) umzurechnen, bestimmt er nach einem einfachen Verfahren die Differenz beider Adressen. Hierzu werden zwei Prozesse benötigt, deren EPROCESS-Strukturen aufeinander verweisen. Hierfür bieten sich "smss.exe" und das von ihm gestartete "csrss.exe" an. Burdach durchsucht das Speicherabbild nach diesen beiden Strings und überprüft, dass es sich tatsächlich um EPROCESS-Strukturen handelt.
Aus der Position der Strukturen im Speicherabbild ergeben sich direkt die physischen Adressen, da das Abbild eine 1:1 Kopie des Arbeitsspeichers ist und keine weiteren Informationen wie Abschnittsheader enthält. Die Links auf die benachbarten Prozesse ergeben die virtuellen Adressen. Burdach nennt die Differenz von korrespondierender virtueller und physischer Adresse den "special offset". Diesen Wert subtrahiert er von den Adressen der Kernel-Variablen, um ihre Position im Abbild zu erhalten.
Analog wendet Burdach sein Verfahren auch auf Module an. Sein Toolkit enthält zwei Programme, die jeweils eine Liste traversieren und somit aktive Prozesse beziehungsweise geladene Module enumerieren.
Dieses Verfahren setzt voraus, dass der "special offset" über den gesamten virtuellen Adressraum des Systemprozesses konstant ist. Burdach zeigt jedoch nicht, ob diese Voraussetzung gegeben ist. Statt dessen beschreibt er, ohne hierfür eine Begründung zu geben, den korrekten Weg über das Page Directory. Er implementiert dieses zuverlässige, aber auch aufwändigere Vorgehen allerdings nicht in seinen Tools.
Ein Manko der Arbeit sehe ich darin, dass nur Prozesse (also die Ausführungsumgebung), nicht aber Threads (die eigentlichen Arbeiter) untersucht werden. Dies sollte mit der gleichen Methode möglich sein.
Auf das größte Problem weist Burdach selbst hin: sein Verfahren ist anfällig gegenüber Manipulationen der Listen. Rootkits wie FU von fuzen_op nutzen genau diese Schwäche aus, um sich vor den Funktionen des Windows API zu verbergen. Das Verfahren der Direct Kernel Object Manipulation (DKOM) ist zu verbreitet, um es in der Entwicklung eines forensischen Instruments unberücksichtigt zu lassen. Zu berücksichtigen ist, dass sich das Toolkit noch im Beta-Stadium befindet.
Ich halte Burdachs Toolkit daher derzeit ungeeignet für den Einsatz im Labor. Sein Artikel kann einen Zugang zur Analyse des Arbeitsspeichers eröffnen, sofern man keine Schritt-für-Schritt Anleitung erwartet. Hierfür ist der Artikel mit knappen acht Seiten einfach zu kurz.
