Reading the loaded module list from the kernel is quite possible but not
SAFE :
typedef struct _PEB_LDR_DATA
{
ULONG Length;
BOOLEAN Initialized;
PVOID SsHandle;
LIST_ENTRY InLoadOrderModuleList;
LIST_ENTRY InMemoryOrderModuleList;
LIST_ENTRY InInitializationOrderModuleList;
PVOID EntryInProgress;
} PEB_LDR_DATA, *PPEB_LDR_DATA;
typedef struct _LDR_DATA_TABLE_ENTRY
{
LIST_ENTRY InLoadOrderLinks;
LIST_ENTRY InMemoryOrderLinks;
LIST_ENTRY InInitializationOrderLinks;
PVOID DllBase;
PVOID EntryPoint;
ULONG SizeOfImage;
UNICODE_STRING FullDllName;
UNICODE_STRING BaseDllName;
…
}
typedef struct _PEB
{
unsigned char _pad[0x00c]; //XP SP2 offset
PEB_LDR_DATA Ldr;
…
}
After you obtain the address of the PEB of the process, you can obtain the
address of the loader data encapsulated as
struct_PEB_LDR_DATA . Within this structure there are InXXXOrderModuleLists
links which links the module information in _LDR_DATA_TABLE_ENTRY
strucures.
I have not tested this but the strategy must work.
However, this method is not thread SAFE. The driver must ensure serial
access to these links and ensure that that data is valid!
When you look at the PEB structure, you see a member called LoaderLock which
is used by nt loader thorugh RTlXXXCriticalSection native api functions to
syncronize loader related operations on the PEB.
Indeed from the security point of view, PEB of a process is accessible from
the user mode so accessing and basing the operations on the user
manipulatable data from the driver is conceptually unsafe.
What if a rootkit changes the links in these data structure which may lead
to an infinite loop at the driver level or something else?
It is better to face such conditions at the user level.
Look at the documentation of PsSetLoadImageNotifyRoutine in DDK help. it may
be useful.
Good luck,
Egemen Tas
-------Original Message-------
From: xxxxx@wipro.com
Date: 01/18/05 10:40:52
To: Windows System Software Devs Interest List
Subject: [ntdev] KPEB
Hi,
I wanted to implement a hooking function same like Regmon. I could able to
hook to registry and could able to read the process information block (KPEB)
I want to know some of the clarifications and pointers.
Is it possible to read what are the modules(dll) that are loaded by the user
application from kernel mode ? If it is can we know which is the present
module that is running in the user space ?
Presently I have hooked to registry call. Any call to registry will invoke
my function first and from my function I will call the actual registry
function. The registry call from user application may be done from listed
dlls of a particular process. Is it possible to know which module has called
my registry function.
Any suggestions will be helpful.
Thanks and Regards,
Abhiman.
Questions? First check the Kernel Driver FAQ at http://www.osronline
com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
However with the