In-depth organization of Windows NT/2000 modules (http://webcrazy.yeah.net)

In-depth organization of the Windows NT/2000 Module
WebSphere (http://webcrazy.yeah.net /)

In Windows NT/2000 paging mechanism, I have described in detail the non-Paging Memory Internal Mechanism of Windows NT/2000 on the X86 platform, the address space can be divided into process space and system space. Each process has its own process space, while all processes share the same system space. Therefore, when Windows NT/2000 involves module management, it also involves two parts: Process private module Management and System Shared module management. I will introduce these two parts separately.
Because all processes share the same system space, the system module mainly involves some operating system code modules or some device driver code (which are usually used by all processes ), it is located in the high-end 4G memory of the system. In Windows NT/2000, a system variable psloadedmodulelist points out that the specific structure is a two-way linked list. Anyone familiar with Windows NT/2000 knows that when a blue screen crashes, the system will be dumped to memory by default. in the DMP file, the system kernel debugger imongokd or windbg will reload the mounted modules before the system crash according to the system variables when debugging and tracking this dump file. The code for listing system modules based on this variable is as follows:

//-----------------------------------------------
//
// Enumkernelmodules
// Only test on Windows 2000 Server Chinese edition
// Build 2195 (free )! Programmed by webcrazy
// (Tsu00@263.net) on 10-27-2000!
//
//-----------------------------------------------

Ulong psloadedmodulelist = 0x8046a4c0; // fetch from symbol File
# Define kernelmod_imagebase_offset 0x18
# Define kernelmod_imagename_offset 0x24

Void enumkernelmodules ()
{

Plist_entry pkernelmodulelisthead, pkernelmodulelistptr;
Punicode_string pimagename;

If (ushort) ntbuildnumber )! = 2195 ){
Dbuplint ("only test on Windows 2000 Server build 2195! /N ");
Return;
}

Dbuplint ("/N base ADDR/tmodule name ");
Dbuplint ("/n ---------/T -----------/N ");

Pkernelmodulelisthead = pkernelmodulelistptr = (plist_entry) (ulong *) psloadedmodulelist;

Do {
Pkernelmodulelistptr = pkernelmodulelistptr-> flink;
Dbuplint ("% 08x ",
* (Ulong *) (char *) pkernelmodulelistptr + kernelmod_imagebase_offset ));
Pimagename = (punicode_string) (ulong *) (char *)
Pkernelmodulelistptr + kernelmod_imagename_offset );
Dbuplint ("/T % s/n", pimagename-> buffer );
} While (pkernelmodulelistptr-> flink! = Pkernelmodulelisthead );
}

The above psloadedmodulelist value is obtained directly from the symbol file. You can adjust it according to your actual situation. Well, let's take a look at the enumkernelmodules output:

Base ADDR Module name
--------------------
80400000/winnt/system32/ntoskrnl.exe
80062000/winnt/system32/hal. dll
..
..
Fd0f8000/SYSTEMROOT/system32/Drivers/CDFs. sys
Fcdb1000/SYSTEMROOT/system32/Drivers/IPSec. sys
..
..

It is basically the same as the MOD command of SoftICE, but it is worth noting that the MOD command of SoftICE not only outputs the process kernel module, but also lists the user-mode modules of specific processes, how does the system manage specific process modules?

Each process has its own modules, and all these modules require access from the user State. Therefore, the data structure of the process module should be in the user-state address space. In fact, the Windows NT/2000 process module list is specified by members in the peb (process environment block) structure, in Windows NT/2000, each peb of a process with user-state code is placed at 0x7ffdf000 (less than 2 GB space, and user-state code can be accessed directly ). However, in Windows NT/2000, The peb address is indirectly obtained through Teb, that is, obtained through the following code:
MoV eax, FS: [18]
MoV eax, [eax + 30]
The first statement obtains the Teb address of the current thread. For information about how to obtain the Teb and Teb addresses, see Windows NT/2000 Internal data structure inquiry. the second statement obtains the peb address at 30 h of the Teb offset. I think Windows NT/2000 may consider compatibility when using this method. The code below uses a constant address directly.

Let's take a look at windbg's analysis:

>! Ntsdexts. Version
Version 5.0 (build 2195) uniprocessor free

>! Ntsdexts. peb
Peb at 7ffdf000
Inheritedaddressspace: No
Readimagefileexecoptions: No
Beingdebugged: Yes
Imagebaseaddress: 01000000
LDR. initialized: Yes
LDR. ininitializationordermodulelist: 71f80. 72808
LDR. inloadordermodulelist: 71ee0. 727f8
LDR. inmemoryordermodulelist: 71ee8. 72800
01000000 D:/winnt/system32/calc.exe
77f80000 D:/winnt/system32/NTDLL. dll
77560000 D:/winnt/system32/shell32.dll
77f40000 D:/winnt/system32/gdi32.dll
77e60000 D:/winnt/system32/kernel32.dll
77df0000 D:/winnt/system32/user32.dll
77d90000 D:/winnt/system32/advapi32.dll
77d20000 D:/winnt/system32/rpcrt4.dll
77c50000 D:/winnt/system32/shlwapi. dll
77b30000 D:/winnt/system32/comctl32.dll
78000000 D:/winnt/system32/msvcrt. dll
Subsystemdata: 0
Processheap: 70000
Processparameters: 20000
Windowtitle: 'd:/winnt/system32/calc.exe'
Imagefile: 'd:/winnt/system32/calc.exe'
..
..
..

The above output of windbg shows the peb Field Values in detail. After tracking and analyzing the data, I wrote the following program section to directly read the system structure and obtain the process module list:

//-----------------------------------------------
//
// Enumusermodules-information from peb
// Only test on Windows 2000 Server Chinese edition
// Build 2195 (free )! Programmed by webcrazy
// (Tsu00@263.net) on 10-27-2000!
//
//-----------------------------------------------

# Define pebaddress 0x7ffdf000
# Define peb_ldr_data_offset 0x0c
# Define ldrdata_imagebase_offset 0x10
# Define ldrdata_imagename_offset 0x1c

# Pragma pack (4)
Typedef struct _ peb_ldr_data
{
Ulong length;
Boolean initialized;
Pvoid sshandle;
List_entry inloadordermodulelist;
List_entry inmemoryordermodulelist;
List_entry ininitializationordermodulelist;
} Peb_ldr_data, * ppeb_ldr_data;
# Pragma pack ()

Void enumusermodules (void * kpeb)
{
Plist_entry pusermodulelisthead, pusermodulelistptr;
Ppeb_ldr_data pldrdata;
Punicode_string pimagename;

If (ushort) ntbuildnumber )! = 2195 ){
Dbuplint ("only test on Windows 2000 Server build 2195! /N ");
Return;
}

Keattachprocess (kpeb );

Pldrdata = (ppeb_ldr_data) (ulong *) (* (ulong *) (pebaddress + peb_ldr_data_offset ));
If (! Pldrdata-> initialized ){
Dbuplint ("process: % 08x not initialized! /N ", (ulong) kpeb );
Kedetachprocess ();
Return;
}

Dbuplint ("/N base ADDR/tmodule name ");
Dbuplint ("/n ---------/T -----------/N ");

Pusermodulelisthead = pusermodulelistptr =
(Plist_entry) & (pldrdata-> inmemoryordermodulelist );

Do {
Pusermodulelistptr = pusermodulelistptr-> flink;
Dbuplint ("% 08x", * (ulong *) (char *)
Pusermodulelistptr + ldrdata_imagebase_offset ));
Pimagename = (punicode_string) (ulong *) (char *)
Pusermodulelistptr + ldrdata_imagename_offset );
Dbuplint ("/T % s/n", pimagename-> buffer );
} While (pusermodulelistptr-> flink! = Pusermodulelisthead );

Kedetachprocess ();
}

The enumusermodules program section enumerates specific processes (specified by the kpeb parameter). The function section does not check the legality of peb. For example, the idle and system processes are pure kernel processes, they do not have user-mode peb. The solution is to check the legality of Teb. These processes are generally 0 for Teb. Enumusermodules does not check the validity of kpeb. It assumes that all kpeb instances exist in the system. Otherwise, unexpected results may occur. Although it only involves reading user-state data, the program segment uses the keattachprocess/kedetachprocess kernel routine, so the program segment can only be implemented in the driver code. Enumusermodules uses the inmemoryordermodulelist member to enumerate the list of modules (see the windbg output result and the enumusermodules output result is consistent with it). Of course, you can also use the ininitializationordermodulelist or inloadordermodulel.

The above shows that the MOD command in SoftICE lists the system module and process module, that is, it implements the two program segments that I provide (SoftICE also outputs the PE Header segments of the PE module, the location of the PE Header can be retrieved according to the base ADDR according to the PE specification, and I am not sure whether SoftICE is implemented using the same method ).

If the user State is not described, you can execute win321_(.exe) or the driver in the core State (. sys), or the system dynamic link library (. DLL) in Windows NT/2000, all are in PE format, but not all modules are in this format. In fact, all files can be used as modules, such as common NLS files. For PE file loading, Windows NT/2000 provides a function family starting with LDR. As for its structure, I will not introduce it.

Windows 2000 implements the psapi and toolhelp API of the enumeration system module (toolhelp API has already been implemented in Win9x, but Windows NT only uses psapi functions ), when tracking and analyzing this part of code, I thought I could refer to some definitions in the header files of these functions, such as moduleentry32 or moduleinfo, but the system uses completely different formats. it can be said that the internal structure of the system is large and complete, and only the unicode format is used, and these Apis only present some definitions used by the API, hiding a lot of internal features from the user. However, toolhelp uses section objects (called filemapping objects by Win32 APIs) to map the entire module to implement module enumeration. However, it eventually uses the peb data referenced by enumusermodules. Peb also contains a lot of system data, such as processheap and processparameters. If you are interested, you can use windbg/SoftICE for better mining!

References:
1. David solomom inside Windows NT, 2nd Edition