CH1 unidentified struct _DRIVER_DATA identified.

Lil_Ranger · #1 (**permalink**) January 20th, 2010, 03:37 AM

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.

Code:

typedef struct _DRIVER_DATA
{
	LIST_ENTRY listEntry;
	DWORD dwUnknown1;
	DWORD dwUnknown2;
	DWORD dwUnknown3;
	DWORD dwUnknown4;
	DWORD dwUnknown5;
	DWORD dwUnknown6;
	DWORD dwUnknown7;
	UNICODE_STRING path;
	UNICODE_STRING name;
} 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.

Code:

typedef struct _MODULE_ENTRY
{
	LIST_ENTRY module_list_entry;
	DWORD Unknown1[4];
	DWORD base;
	DWORD driver_start;
	DWORD unknown2;
	UNICODE_STRING driver_Path;
	UNICODE_STRING driver_Name;
             //..
} 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:

Code:

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).

Lil_Ranger · #2 (**permalink**) January 20th, 2010, 04:20 AM

Ok, so I was thinking too hard about the datatypes. Here is the complete structure:

Code:

typedef unsigned char BYTE, *PBYTE, *LPBYTE;
typedef int BOOL, *PBOOL, *LPBOOL;
typedef BYTE BOOLEAN, *PBOOLEAN;
typedef unsigned long DWORD, *PDWORD, *LPDWORD;
typedef unsigned long ULONG, *PULONG;
typedef unsigned short WORD, *PWORD, *LPWORD;
typedef char TCHAR;
typedef void *PVOID;
typedef unsigned short UINT2;
typedef unsigned int UINT4;

typedef struct _DRIVER_LDR_DATA_TABLE_ENTRY
{
   LIST_ENTRY InLoadOrderLinks;
   LIST_ENTRY InMemoryOrderLinks;
   LIST_ENTRY InInitializationOrderLinks;
   PVOID DllBase;
   PVOID EntryPoint;
   UINT4 SizeOfImage;
   UNICODE_STRING FullDllName;
   UNICODE_STRING BaseDllName;
   UINT4 Flags;
   UINT2 LoadCount;
   UINT2 TlsIndex;
   LIST_ENTRY HashLinks;
   PVOID SectionPointer;
   UINT4 CheckSum;
   UINT4 TimeDateStamp;
   PVOID LoadedImports;
   PVOID EntryPointActivationContext;
   PVOID PatchInformation;
} DRIVER_LDR_DATA_TABLE_ENTRY;

In WinDBG I left the existing Driver_Data struct and compared it with the new struct. They point to the same information and its correctly filled out for all entries in the new struct! YAY!

I'd love to hear from some of the more experienced rootkit writers if there are other methods to make a rootkit driver disapear more securely with this newly identified complete structure.

Need to download code?

Navigation