So I was digging around trying to identify the unknown data structure that we try to duplicate in CH2, pg. 10 and may have come across the actual windows structure that this is trying to simulate.
typedef struct _DRIVER_DATA
This is not the only book to reference this structure pointed to by DRIVER_OBJECT.DriverSection (at 0x014). Rootkits Subverting the Windows Kernel also references the structure in CH 7, pg 186.
typedef struct _MODULE_ENTRY
} MODULE_ENTRY, *PMODULE_ENTRY;[/
So I came across this obscure reference in a paper called GREPEXEC: Grepping Executive Objects from Pool Memory by Chris from bugcheck.org on May 30, 2006 in section 4.4.3, pg. 12 that claims the DRIVER_OBJECT.DriverSection (at 0x014) actually points to NT!_LDR_DATA_TABLE_ENTRY.
WinDbg shows that this structure consists of:
1: kd> dt nt!_LDR_DATA_TABLE_ENTRY
+0x000 InLoadOrderLinks : _LIST_ENTRY
+0x008 InMemoryOrderLinks : _LIST_ENTRY
+0x010 InInitializationOrderLinks : _LIST_ENTRY
+0x018 DllBase : Ptr32 Void
+0x01c EntryPoint : Ptr32 Void
+0x020 SizeOfImage : Uint4B
+0x024 FullDllName : _UNICODE_STRING
+0x02c BaseDllName : _UNICODE_STRING
+0x034 Flags : Uint4B
+0x038 LoadCount : Uint2B
+0x03a TlsIndex : Uint2B
+0x03c HashLinks : _LIST_ENTRY
+0x03c SectionPointer : Ptr32 Void
+0x040 CheckSum : Uint4B
+0x044 TimeDateStamp : Uint4B
+0x044 LoadedImports : Ptr32 Void
+0x048 EntryPointActivationContext : Ptr32 Void
+0x04c PatchInformation : Ptr32 Void
Everything seems to match up correctly. I wanted to test this new struct in place of _DRIVER_DATA or MODULE_ENTRY, but I was unsure what type to define Uint2B and Uint4B as. I believe they are unsigned ints but that is where I am stuck. Any ideas?
I thought Ric Vieler could use this information to update his book (online and in any future releases).