Einführung in IceSword - Dump GDT/IDT

Beschreibung
Diese Funktion erzeugt zwei Textdateien im IceSword-Verzeichniss: GDT.log und IDT.log. Diese geben den Inhalt der jeweiligen Systemtabellen wieder.

Die Global Descriptor Table (GDT) ist ein Teil der Speicherverwaltung von Intel 80386 (alias 386 alias IA-32 alias x86) Prozessoren. Die GDT ist im Grunde eine Altlast und wird von modernen Systemen nicht mehr wirklich verwendet. Da die GDT aber von der Hardware vorgegeben ist, wird sie von Windows implementiert.

Die Interrupt Descriptor Table (IDT) ist auch Teil der x86-Architektur. Nähere Erklärungen siehe Links unter Informationen. In Multiprozessorsystemen hat jeder Prozessor seine eigene IDT.

Hinweis
Prozessor-Interrupts (Ints) sind nicht zu verwechseln mit den berüchtigten "Interrupt-Konflikten" von PCI-Karten oder den INT-Leitungen des PCI-Busses. Nennt sich zwar genauso, ist aber was völlig anderes.

Wenn die Funktion Dump GDT/IDT eine Fehlermeldung auswirft, läuft Windows entweder in einer virtuellen Maschine oder man hat ein sehr komisches Problem. Unter VMware funktioniert Dump GDT/IDT, wenn man die Beschleunigung ausschaltet.

Das Rustock.A-Rootkit manipuliert die IDT und erzeugt gelegentlich einen Bluescreen wenn man versucht die IDT zu dumpen.


Global Descriptor Table (GDT)

Die Datei GDT.log hat sechs Spalten. Hier ein Beispiel eines Eintrags:

1	2	3	4	5	6
028	Sys	802D8000: 000020AB (Base:Limit)	P	0(DPL)	B(type)
Index	Sys (System- funktion wie Call Gate) oder Mem (Speicher)	(Virtuelle) Adresse und Größe des Bereichs im Speicher	Present- Bit	DPL (Descriptor Privilege Level): Ring 0 (Kernel) oder Ring 3 (User)	IceSword zeigt hier bei System- funktionen den Typ als Hex-Wert an sonst ein Binärwert

Es gibt zwei grundsätzlich verschiedene Arten von GDT-Deskriptoren: In Spalte 2 werden diese Mem und Sys genannt. Die Mem-Einträge kann man ignorieren (siehe unten).

Spalte 4 zeigt an ob sich der entsprechende Bereich momentan im Speicher befindet (Present-Bit) oder ausgelagert wurde. Was IceSword anzeigt wenn der Bereich ausgelagert wurde, ist mir nicht bekannt.

Spalte 5: DPL ist der Descriptor Privilege Level. Bei Codesegmenten dürfen nur Prozesse mit diesem Level auf den Speicher zugreifen (d.h. der Kernel kann keinen Ring 3 Code ausführen und umgekehrt). Bei Datensegmenten ist es die Mindestberechtigung. Windows kennt hier Ring 0 (Kernel Mode) und Ring 3 (User Mode). Ring 1 und 2 werden von Windows nicht benutzt (sind aber theoretisch möglich).


Übersicht Systemfunktionen (Hex)

• 0 - Ungültig - ?
• 2 - LDT - Harmlos
• 5 - Task gate - Standard in IDT-Index 2 und 8
• 9 - Verfügbares TSS (386) - Harmlos
• B - Belegtes TSS (386) - Harmlos
• C - Call gate (386) - Kritisch
• E - Interrupt gate (386) - Standard in IDT
• F - Trap gate (386) - Ungewöhnlich

Andere Typen sollten eigentlich nicht vorkommen. Erweiterte Übersicht siehe Links unter Informationen.

Äußert bedenklich ist vor allem Typ C: Call Gate. Diese Funktion ist für Betriebssysteme gedacht, wird aber heute kaum noch verwendet. Windows verwendet von sich aus niemals Call Gates.

Mit einem Call Gate kann ein User-Mode Prozess ansonsten verbotene Kernel-Funktionen aufrufen.

Das Rootkit Gurong.a (vermutlich ein Vorläufer der Rustock-Serie) benutzt ein GDT-Call Gate um sich zu installieren. Leider habe ich keine Kopie dieses seltenen Rootkits zum testen.

Der Binärwert von Mem-Einträgen entspricht vermutlich den Bits 0-3 des Access Bytes des Gate Descriptors. Erläuterungen dazu siehe Links unter Informationen.

Der erste Eintrag der Liste (000) ist der "Null Segment Selector" und immer "Reserved". Wenn man die Binärwerte der nächsten vier Einträge studiert, könnte man glauben, dass jedes beliebige Programm auf den gesamten Speicher zugreifen kann. Das ist auch so, hat aber keine Bedeutung. Windows benutzt die nicht die GDT, sondern Page Tables zum Speicherschutz. Daher sind die GDT-Einträge vom Typ Mem weitgehend unbedeutend.

Bei x86 (32 Bit) Systemen lebt der Kernel normalerweise im (virtuellen) Bereich ab 80000000. Wenn die /3GB-Option in der boot.ini benutzt wird, im Bereich ab C0000000.

Der Bereich 80000000 bis 9FFFFFFF entspricht normalerweise dem Physikalischen Bereich 00000000 bis 0x1FFFFFFF.


Interrupt Descriptor Table (IDP)

Die Datei IDT.log hat fünf Spalten.

Für jeden der 256 Interrupts gibt es einen Handler (auch Gate genannt). Man kann sich den Handler ansehen, indem man einfach den Offset als Startadresse in den Disassembler eingibt (Prozess ist egal, siehe unten).

Die anderen Spalten entsprechen denen der GDT.

Interessant ist unter Windows 2000 vor allem Index 046 (Hex 2E). Das ist die Schnittstelle zu KiSystemService. Diverse Rootkits (unter anderem Rustock.A und Rustock.B) benutzen unter Windows 2000 Int 2E-Hooks.

Unter Windows XP und neueren Systemen wird der Sysenter-Befehl von neueren x86-Prozessoren verwendet (ist effizienter).

IceSword kann Sysenter-Hooks nicht anzeigen.


Auf was man achten sollte

Call Gates in der GDT. Ein "C(type)" ist praktisch immer Malware.

GDT Base (erste Zeile): Unnormale Adressen sind nicht gut.
Standard ist (soviel ich weiss):
Windows 2000 SP4 - GDT Base:0x80036000
Windows XP SP2 - GDT Base:0x8003F000

Die IDT kommt immer direkt danach (keine Ahnung wie es bei Multiprozessorsystemen gehandhabt wird).

Es gilt folgende Formel: GDT Base + GDT Limit + 1 = IDT Base

Das "0x" bedeutet, dass die Zahlen Hexadezimal sind, es ist nicht Teil der Zahl. Die Berechnung kann man mit dem Windows Rechner im Wissenschaftlichen Modus durchführen.

Wenn die IDT nicht direkt nach der GDT kommt, wurde sie vermutlich kopiert und verschoben. Es gibt keinen Grund das zu tun, der nichts mit Malware zu tun hat.

Komische Einträge in der IDT. Die Index-Spalte ist der Dezimalwert des Interrupts.

Kritisch sind (Hex / Dezimal):

• Int 0E / 14 - Page Fault. Wird möglicherweise manipuliert vom Shadow Walker Rootkit.
• Int 2E / 46 - KiSystemService. Diverse Rootkits unter Windows 2000. Windows XP und neuere benutzen Int 2E nicht.

IDT-Hooks kann man theoretisch mit dem eingebauten Disassembler finden. Damit in diesen Artikel mal ein Bild kommt, habe ich den Int 2E-Handler von Windows 2000 disassembliert:



Was IceSword nicht findet
Die IDT/ Int 2E-Manipulation von Rustock.A unter Windows 2000 ist mit IceSword 1.20 nicht zu finden.

Rustock.A hat einen Implementationsspezifischen Angriff gegen IceSword. Sobald IceSword startet, entfernt das Rootkit unter Windows 2000 seinen Int 2E-Hook und entlädt seinen Treiber. Deswegen sieht IDT.log unauffällig aus. Wenn man IceSword beendet, wird das Rootkit nicht wieder hergestellt. Mit Autoruns kann man jetzt leicht den nicht mehr versteckten Treiber deaktivieren.


Andere Werkzeuge
Rootkit Unhooker (findet Sysenter-Hooks)
GMER (findet auch Sysenter-Hooks)


Informationen
Einführung in Protected Mode (mit Systemsegment Typen-Übersicht)
Gates, Interrupts und Exceptions (IDT)
Playing with Windows /dev/(k)mem (siehe 4.2 What's a Callgate ff.). Phrack
From Russia with Rootkit (Informationen zum Gurong.a Rootkit). F-Secure

• Einführung in IceSword
• Übersicht: Rootkits