[lorddoskias]

I'm trying to find information about those structures but I can't. The only place I've seen them discussed are the 2 rootkit books (subverting windows kernel and rootkit arsenal) but what I'm interested is if someone has written up the process of identification of those structs? For example in DRIVER_OBJECT you've got the DriverSection void pointer but then how do you manage to extract the exact layout of this structure?

[EP_X0FF]

Code: Select all

typedef struct _KLDR_DATA_TABLE_ENTRY {
    LIST_ENTRY InLoadOrderLinks;
    PVOID ExceptionTable;
    ULONG ExceptionTableSize;
    // ULONG padding on IA64
    PVOID GpValue;
    PNON_PAGED_DEBUG_INFO NonPagedDebugInfo;
    PVOID DllBase;
    PVOID EntryPoint;
    ULONG SizeOfImage;
    UNICODE_STRING FullDllName;
    UNICODE_STRING BaseDllName;
    ULONG Flags;
    USHORT LoadCount;
    USHORT __Unused5;
    PVOID SectionPointer;
    ULONG CheckSum;
    // ULONG padding on IA64
    PVOID LoadedImports;
    PVOID PatchInformation;
} KLDR_DATA_TABLE_ENTRY, *PKLDR_DATA_TABLE_ENTRY;

[lorddoskias]

Thanks. But what I was interested in was a blogpost or any other information as to how people have approached an undocumented variable in a structure and what they did in order to find the actual contents of the memory it points to and extract the function definition. It turns out it is also possible to utilize the KPCR trick in order to get to PsLoadedModuleList which is the head to all loaded driver instead of having to rely on this particular structure.

EDIT:

Also in your definitions there are 2 fields regarding DLLS, but dll's are not used when with KMD?

[EP_X0FF]

Thanks. But what I was interested in was a blogpost or any other information as to how people have approached an undocumented variable in a structure and what they did in order to find the actual contents of the memory it points to and extract the function definition. It turns out it is also possible to utilize the KPCR trick in order to get to PsLoadedModuleList which is the head to all loaded driver instead of having to rely on this particular structure.

EDIT:

Also in your definitions there are 2 fields regarding DLLS, but dll's are not used when with KMD?

What is the practical difference how does it named? This structure is KM variant of LDR_DATA_TABLE_ENTRY and has all fields properly initialized.

Regarding to your other questions:

1. Kernel debugger + Symbols + RE + leaked winnt sources in some cases
2. This structure is correct for all available Windows NT versions, all new fields always added to the end.

There was article from opc0de at rootkit.com (R.I.P.) regarding to this I believe.

KPCR trick

Yes this is the way how WinDBG works.