Before starting off, let me just thank Opc0de for being the original person who discovered this trick. I'm simply building upon his document to shed more light onto the structures involved.

As you've probably noticed, the structure defined in opcode.inc is different from the one in the wdbgexts.h file, which is mainly because of two false assumptions:

KdVersionBlock points to _KDDEBUGGER_DATA32. False
Debugger Data is stored in _KDDEBUGGER_DATA32. False

I will explain the true meaning of those variables, in the hope of getting the right structures and completing opc0de's great discovery.



Let's start with a dump:

Kernel base = 0x804d7000 PsLoadedModuleList = 0x805642e0
lkd> dt ffdff000 _KPCR
...
+0x034 KdVersionBlock : 0x805542b0
...

lkd> dd 0x805542b0
805542b0 0a28000f 00030006 030c014c 0000002d
805542c0 804d7000 ffffffff 805642e0 ffffffff
805542d0 806a0ff4 ffffffff 806a0ff4 806a0ff4
805542e0 00000000 00000000 4742444b 00000290
805542f0 804d7000 00000000 804de8d5 00000000
...

All right, so what do we see here? First of all, the Kernel Base appears twice. Once at 0x805542C0 and once at 0x805524F0...we also see the value 806a0ff4 repeated twice, followed by two 0 values. Let's see what that value is:

lkd> dd 806a0ff4 L 8
806a0ff4 805542d8 805542d8 00000000 00000000
806a1004 00000000 00000000 00000000 00000000

Hmmm... looks like two more pointers to 0x805542d8, which is above and beings with the pointer we've just visited. This smells like a LIST_ENTRY! Two more clues are critical...we've found the value 805642e0...which is PsLoadedModuleList, and also 4742444b, which in ASCII is "KDBG". So let's try to make a pseudo-structure:

KdVersionBlock points to:
0x0-0xC = Unknown
0x10 = KernelBase
0x18 = PsLoadedModuleList
0x20 = Pointer to Pointer to Debug Data
0x28 = LIST_ENTRY to Debug Data, Forward
0x38 = Debugger Tag.

What we then see are the exported variables, with zeroes in between.

Now...KdVersionBlock seems similar to a structure found in the file called _DBGKD_GET_VERSION... we have a 32 and 64-bit version of it. Aha...here's the thing! All our first variables in the pseudo-structure had 0xFFFFFFFF after them...a comment also tells us that the 32-bit versions are deprecated. With this, we can easily see that KdVersionBlock actually points to _DBGKD_GET_VERSION64. Let's have a rundown:

805542b0 0a28000f 00030006 030c014c 0000002d
805542c0 804d7000 ffffffff 805642e0 ffffffff
805542d0 806a0ff4 ffffffff

typedef struct _DBGKD_GET_VERSION64 {
USHORT MajorVersion = 0x0F00
USHORT MinorVersion = 0x280A
UCHAR ProtocolVersion = 0x06
UCHAR KdSecondaryVersion = 0x00
USHORT Flags = 0x03
USHORT MachineType = 0x4C01
UCHAR MaxPacketType = 0xC
UCHAR MaxStateChange = 0x0
UCHAR MaxManipulate = 0x2D
UCHAR Simulation = 0x00
USHORT Unused[1] = 0x00, 0x00
ULONG64 KernBase = 0x804D7000, 0xFFFFFFFF
ULONG64 PsLoadedModuleList = 0x805642E0, 0xFFFFFFFF
ULONG64 DebuggerDataList = 0x806A0FF4, 0xFFFFFFFF
} DBGKD_GET_VERSION64, *PDBGKD_GET_VERSION64;

Ah...makes much more sense now. What does this tell us? That we shouldn't rely on KdVersionBlock+an offset to give us the Variables...instead, we should define this structure, and read *(DBGKD_GET_VERSION64.DebuggerDataList)->Flink, which will guide us to the Variable Block itself.

Only one little obstacle remains... the Variable Structure itself, which we've seen is full of "holes". This is because it too, is 64-bit.
Let's see its header:

typedef struct _DBGKD_DEBUG_DATA_HEADER64 {
LIST_ENTRY64 List;
ULONG OwnerTag;
ULONG Size;
} DBGKD_DEBUG_DATA_HEADER64, *PDBGKD_DEBUG_DATA_HEADER64;

typedef struct _KDDEBUGGER_DATA64 {
DBGKD_DEBUG_DATA_HEADER64 Header;
ULONG64 KernBase;
ULONG64 BreakpointWithStatus;
ULONG64 SavedContext;
USHORT ThCallbackStack;
USHORT NextCallback;
USHORT FramePointer;
USHORT PaeEnabled:1;
...

The definitions given by opc0de were unforunately flawed, and worked because he adds up all the Version Data and half of the 64-bit List Entry structure in an array of 12 unknown DWORDs...well, not anymore :)
So let's match this with what remained of our dump:

... 806a0ff4 806a0ff4
805542e0 00000000 00000000 4742444b 00000290
805542f0 804d7000 00000000 804de8d5 00000000

LIST_ENTRY64 List. FLINK64 = 0x806A0FF4, 0x806A0FF4. BLINK64 = 0x0,0x0
ULONG OwnerTag = 4742444b = "KDBG"
ULONG Size = 0x290
ULONG64 KernBase = 0x804d7000
ULONG64 BreakpointWithStatus = 804de8d5

Yup, it all makes sense now...some debug data follows (Saved Context, Callbacks), followed by our precious variables.

And here's what you get for reading all this...a little perk. You see, because op0code originally hacked everythign to work as a 32-bit structure, he missed more then 3/4 of the exported variables. Here are all of them, in order:

ULONG64 KiCallUserMode;
ULONG64 KeUserCallbackDispatcher;
ULONG64 PsLoadedModuleList;
ULONG64 PsActiveProcessHead;
ULONG64 PspCidTable;

ULONG64 ExpSystemResourcesList;
ULONG64 ExpPagedPoolDescriptor;
ULONG64 ExpNumberOfPagedPools;

ULONG64 KeTimeIncrement;
ULONG64 KeBugCheckCallbackListHead;
ULONG64 KiBugcheckData;

ULONG64 IopErrorLogListHead;

ULONG64 ObpRootDirectoryObject;
ULONG64 ObpTypeObjectType;

ULONG64 MmSystemCacheStart;
ULONG64 MmSystemCacheEnd;
ULONG64 MmSystemCacheWs;

ULONG64 MmPfnDatabase;
ULONG64 MmSystemPtesStart;
ULONG64 MmSystemPtesEnd;
ULONG64 MmSubsectionBase;
ULONG64 MmNumberOfPagingFiles;

ULONG64 MmLowestPhysicalPage;
ULONG64 MmHighestPhysicalPage;
ULONG64 MmNumberOfPhysicalPages;

ULONG64 MmMaximumNonPagedPoolInBytes;
ULONG64 MmNonPagedSystemStart;
ULONG64 MmNonPagedPoolStart;
ULONG64 MmNonPagedPoolEnd;

ULONG64 MmPagedPoolStart;
ULONG64 MmPagedPoolEnd;
ULONG64 MmPagedPoolInformation;
ULONG64 MmPageSize;

ULONG64 MmSizeOfPagedPoolInBytes;

ULONG64 MmTotalCommitLimit;
ULONG64 MmTotalCommittedPages;
ULONG64 MmSharedCommit;
ULONG64 MmDriverCommit;
ULONG64 MmProcessCommit;
ULONG64 MmPagedPoolCommit;
ULONG64 MmExtendedCommit;

ULONG64 MmZeroedPageListHead;
ULONG64 MmFreePageListHead;
ULONG64 MmStandbyPageListHead;
ULONG64 MmModifiedPageListHead;
ULONG64 MmModifiedNoWritePageListHead;
ULONG64 MmAvailablePages;
ULONG64 MmResidentAvailablePages;

ULONG64 PoolTrackTable;
ULONG64 NonPagedPoolDescriptor;

ULONG64 MmHighestUserAddress;
ULONG64 MmSystemRangeStart;
ULONG64 MmUserProbeAddress;

ULONG64 KdPrintCircularBuffer;
ULONG64 KdPrintCircularBufferEnd;
ULONG64 KdPrintWritePointer;
ULONG64 KdPrintRolloverCount;

ULONG64 MmLoadedUserImageList;

// NT 5.1 Addition

ULONG64 NtBuildLab;
ULONG64 KiNormalSystemCall;

// NT 5.0 QFE addition

ULONG64 KiProcessorBlock;
ULONG64 MmUnloadedDrivers;
ULONG64 MmLastUnloadedDriver;
ULONG64 MmTriageActionTaken;
ULONG64 MmSpecialPoolTag;
ULONG64 KernelVerifier;
ULONG64 MmVerifierData;
ULONG64 MmAllocatedNonPagedPool;
ULONG64 MmPeakCommitment;
ULONG64 MmTotalCommitLimitMaximum;
ULONG64 CmNtCSDVersion;

// NT 5.1 Addition

ULONG64 MmPhysicalMemoryBlock;
ULONG64 MmSessionBase;
ULONG64 MmSessionSize;
ULONG64 MmSystemParentTablePage;

// Server 2003 addition

ULONG64 MmVirtualTranslationBase;

USHORT OffsetKThreadNextProcessor;
USHORT OffsetKThreadTeb;
USHORT OffsetKThreadKernelStack;
USHORT OffsetKThreadInitialStack;

USHORT OffsetKThreadApcProcess;
USHORT OffsetKThreadState;
USHORT OffsetKThreadBStore;
USHORT OffsetKThreadBStoreLimit;

USHORT SizeEProcess;
USHORT OffsetEprocessPeb;
USHORT OffsetEprocessParentCID;
USHORT OffsetEprocessDirectoryTableBase;

USHORT SizePrcb;
USHORT OffsetPrcbDpcRoutine;
USHORT OffsetPrcbCurrentThread;
USHORT OffsetPrcbMhz;

USHORT OffsetPrcbCpuType;
USHORT OffsetPrcbVendorString;
USHORT OffsetPrcbProcStateContext;
USHORT OffsetPrcbNumber;

USHORT SizeEThread;

ULONG64 KdPrintCircularBufferPtr;
ULONG64 KdPrintBufferSize;

ULONG64 KeLoaderBlock;

USHORT SizePcr;
USHORT OffsetPcrSelfPcr;
USHORT OffsetPcrCurrentPrcb;
USHORT OffsetPcrContainedPrcb;

USHORT OffsetPcrInitialBStore;
USHORT OffsetPcrBStoreLimit;
USHORT OffsetPcrInitialStack;
USHORT OffsetPcrStackLimit;

USHORT OffsetPrcbPcrPage;
USHORT OffsetPrcbProcStateSpecialReg;
USHORT GdtR0Code;
USHORT GdtR0Data;

USHORT GdtR0Pcr;
USHORT GdtR3Code;
USHORT GdtR3Data;
USHORT GdtR3Teb;

USHORT GdtLdt;
USHORT GdtTss;
USHORT Gdt64R3CmCode;
USHORT Gdt64R3CmTeb;

ULONG64 IopNumTriageDumpDataBlocks;
ULONG64 IopTriageDumpDataBlocks;

// Longhorn addition

ULONG64 VfCrashDataBlock;

The Server 2003 variables are amazing, because they will allow us to reliably get the pointers from KTHREAD, EPROCESS and KPCR :)

Well, this is all I had to add. You now have a reliable way to get the Variable Block (KPCR->Version Data->Debugger Data List Entry->Flink), which will continue to work in future versions of Windows (you shouldn't rely on offsets, as they might change), and you also have a full definition of variables to read.

I'm not going to post any application or include file for this, as all the data is actually in wdbgexts.h, available freely from Microsoft in your WinDBG\SDK\INC directory.

Have fun!
Alex Ionescu
http://www.relsoft.net

read comments (2) / write comment

recent comments:

Excellent

Opc0de

13.Jul:10:15

views: 6123   printer-friendly version