Re: Memory, Elephantine

["Matt Conover" <mconover () gmail com>]

> While we're at it, here's some advertisement for a small utility I wrote
a while ago.
> It parses the Intel system descriptor tables (IDT, LDT, GDT..) and
> prints the descriptors information.
> It'll dump the descriptor from /dev/kmem by default.
> http://cr0.org/progs/dtdumper/

 Here is also one for Windows. Though it has to use /dev/mem equivalent
rather than /dev/kmem since there isn't one for Windows (without using a
custom driver):
http://www.cybertech.net/~sh0ksh0k/projects/DumpCPU

It maps TSS, IDT, GDT, and LDT (no LDT by default).

Dump of GDT (0x8003F000-0x8003F400, 128 entries)
GDT[01] 0x8003F008
 Selector 0x08 (R0) CS
 Address: 0x00000000-0xFFFFFFFF (4294967295 bytes)
 Properties: code, execute, read, accessed
 Operand size: 32-bit
 DPL0
GDT[02] 0x8003F010
 Selector 0x10 (R0) DS
 Address: 0x00000000-0xFFFFFFFF (4294967295 bytes)
 Properties: data, read, write, accessed
 Data size: 32-bit
 DPL0
GDT[03] 0x8003F018
 Selector 0x1B (R3) CS
 Address: 0x00000000-0xFFFFFFFF (4294967295 bytes)
 Properties: code, execute, read, accessed
 Operand size: 32-bit
 DPL3
GDT[04] 0x8003F020
 Selector 0x23 (R3) DS ES SS
 Address: 0x00000000-0xFFFFFFFF (4294967295 bytes)
 Properties: data, read, write, accessed
 Data size: 32-bit
 DPL3
GDT[05] 0x8003F028
 Selector 0x28 (R0) TSS
 Address: 0x80042000-0x800440AB (8364 bytes)
 Properties: 32-bit tss (busy)
 DPL0
GDT[06] 0x8003F030
 Selector 0x30 (R0) PCR
 Address: 0xFFDFF000-0xFFE00FFF (8192 bytes)
 Properties: data, read, write, accessed
 Data size: 32-bit
 DPL0
GDT[07] 0x8003F038
 Selector 0x3B (R3) FS
 Address: 0x7FFDF000-0x7FFDFFFF (4096 bytes)
 Properties: data, read, write, accessed
 Data size: 32-bit
 DPL3
GDT[08] 0x8003F040
 Selector 0x43 (R3)
 Address: 0x00000400-0x000103FF (65536 bytes)
 Properties: data, read, write
 Data size: 16-bit
 DPL3
GDT[10] 0x8003F050
 Selector 0x50 (R0) DF_TSS
 Address: 0x80550480-0x805504E8 (105 bytes)
 Properties: 32-bit tss (available)
 DPL0
GDT[11] 0x8003F058
 Selector 0x58 (R0) NMI_TSS
 Address: 0x805504E8-0x80550550 (105 bytes)
 Properties: 32-bit tss (available)
 DPL0
...

Dump of IDT (0x8003F400-0x8003FC00)
IDT[000] = DIVIDE_ERROR
 Interrupt gate to 0x804DF350
 Properties: DPL 0, 32-bit
IDT[001] = INT1_BREAKPOINT
 Interrupt gate to 0x804DF4CB
 Properties: DPL 0, 32-bit
IDT[002] = NMI
 Task gate
 Properties: DPL 0, 16-bit
IDT[003] = INT3_BREAKPOINT
 Interrupt gate to 0x804DF89D
 Properties: DPL 3, 32-bit
...

NMI TSS (selector 0x58) @ 0x805504E8
 CS: 0x08, DS: 0x23, ES: 0x23, FS: 0x30, GS: 0x00, SS: 0x10
 EIP: 0x804DF5B6
 ESP (ring 0): 0x10:0x8054D480
 EFLAGS: 0x00
 CR3: 0x00039000

Double fault TSS (selector 0x50) @ 0x80550480
 CS: 0x08, DS: 0x23, ES: 0x23, FS: 0x30, GS: 0x00, SS: 0x10
 EIP: 0x804E069D
 ESP (ring 0): 0x10:0x8054D480
 EFLAGS: 0x00
 CR3: 0x00039000

TSS (selector 0x28) @ 0x80042000
Most of the real functionality is in:
http://www.cybertech.net/~sh0ksh0k/projects/win32toolkit/kernel.c

You can also extend it to lookup other things if they are exported via
KernelModuleImports[] array in kernel.c (in win32toolkit). This is needed to
map KPEB entries to find out the page directory table base if you want to
map memory addresses in an arbitrary process by physical address
(from user-mode). Though I only got process virtual memory lookup working
properly for Windows 2000, something strange happens on XPSP2 (correct
virtual address but data returned from corresponding physical address
doesn't match that in WinDbg. My guess is that the MMU somehow changed
between Windows 2000 and Windows XP SP2.. maybe something to do with
caching. If anyone else tried something like this and had a similar problem
(or knows why it happens) plz email me.