Seite 2: Festplattenzugriffe

Inhaltsverzeichnis

Sklavenarbeit

Ein Interrupt-Handler stellt dazu via ExQueueWorkItem beziehungsweise IoQueueWorkItem ein sogenanntes Work-Item mit einem Zeiger auf eine Callback-Routine in die Warteschlange. Kommt das Work-Item an die Reihe, entfernt einer der System Worker Threads es aus der Warteschlange und führt dann die Callback-Routine aus, die die anstehende Arbeit für den Handler erledigt. Diese Threads laufen immer unter dem System-Prozess mit der Prozess-ID 4.

Genau solche Work-Items legt TDL über den Umweg sogenannter Asynchronous Process Calls (APCs) an. Mal sehen, ob ich auf Hansens PC wirklich welche finde. Dazu lasse ich mir mit !process 0 f system  möglichst detailliert Thread- und Stack-Zustände des System-Prozesses anzeigen.

Die Ausgabe ist entsprechend lang und unübersichtlich. Während ich seitenweise durch die Ausgabe zurückblättere, bleibt mein Blick an der Meldung „Warning: Frame IP not in any module. Following frames may be wrong.“ hängen. Die dazugehörige Adresse 0x820d873b liegt sehr nah bei der, die ich bereits als Load-Image-Notify-Routine identifiziert habe. Ich schätze mal, es handelt sich dabei tatsächlich um den Callback-Handler aus dem Work-Item eines Rootkits.

Als Nächstes will ich kontrollieren, ob das Rootkit auf irgendeine Art und Weise Festplattenzugriffe beziehungsweise das Dateisystem überwacht. Hierzu besorge ich mir als Erstes das Geräteobjekt der Festplatte und über dessen Adresse mit !devstack dann die Liste der dafür registrierten Gerätetreiber.

PartMgr.sys und Disk.sys sind o.k., doch statt des erwarteten IDE-Miniport-Treibers Atapi.sys, der dann direkt mit dem physikalischen Gerät kommuniziert, erscheint die Meldung „Invalid type for DeviceObject 0x8217eaf0“. Da passiert etwas sehr Seltsames, dem ich weiter nachgehen sollte.

Also lasse ich mir mit dt _device_object die Datenstruktur dieses ungültigen Geräte-Objekts anzeigen. Da hat definitiv jemand am Typ rumgefummelt. Der korrekte Wert wäre 3, doch stattdessen steht er auf 0, was sich mit den normalen API-Funktionen des Kernels gar nicht bewerkstelligen lässt. Ich vermute mal, dass das ein Versuch ist, sich vor Rootkit-Scannern zu verstecken, die im Nonpaged Pool des Kernelspeichers nach derartigen Objekten suchen. Robuste Tools dürften damit zwar nicht ausgetrickst werden, aber versuchen kann man es ja.