Tissue in WINDOWS NT / 2000 module
Webcrazy
http://webcrazy.yeah.net/)
in"
I don't have a more detailed description of the non-paged memory internal mechanism of the X86 platform Windows NT / 2000, which can also be seen from the address space and system space, each of which The process has its own process space, while all the processes share the same system space. Therefore, Windows NT / 2000 also involves the block management of module management and system sharing module management, below, and I will introduce from these two aspects.
Because all processes share the same system space, the system module is primarily the operating system code module or some device driver code, etc. (they are in general processes), which is located at the high end of the system 4G memory. The internal Windows NT / 2000 is pointed out by a system variable psloadedModuleList that the specific structure is a two-way linked list. Those familiar with Windows NT / 2000 know that when the system occurs when there is a blue screen crash, the system will be documented by the system at this time, and the system kernel modulator i366kd or windbg is also in debugging this dump file. The load module before the system crash will be reloaded according to this system variable. I will list the code of the system module according to this variable:
// -----------------------------------------------
//
// enumkernelmodules
// ONLY TEST ON Windows 2000 Server Chinese Edition
// build 2195 (free)! Programmed by Webcrazy
//
TSU00@263.net) on 10-27-2000!
//
// -----------------------------------------------
Ulong pslineedmodulelist = 0x8046a4c0; // fetch from symbol file
#define kernelmod_imagebase_offset 0x18
#define kernelmod_imagename_offset 0x24
Void enumkernelmodules ()
{
PLIST_ENTRY PKERNELMODULANLISTHEAD, PKERNELMODULELISTPTR;
PUNICODE_STRING PIMAGENAME;
IF ((USHORT) NTBUILDNUMBER! = 2195) {
DBGPRINT ("Only Test On Windows 2000 Server Build 2195! / N");
Return;
}
DBGPRINT ("/ n base addr / tmodule name);
DBGPRINT ("/ n -------- / t --------- / n");
PkerNelModuleListhead = PkerNelModuleListPtr = (PLIST_ENTRY) (Ulong *) PsloadedModuleList;
Do {
PkerNelModuleListPtr = PkerNelModuleListptr-> flink;
DBGPRINT ("% 08X",
* (Ulong *) ((char *) PkerNelModuleListPtr kernelmod_imagebase_offset);
PimageName = (PUNICODE_STRING) (Ulong *) ((char *)
PkerNelModuleListPtr kernelmod_imagename_offset);
DBGPRINT ("/ T% S / N", PimageName-> buffer;} while (pkernelmodulelistptr-> flink! = Pkernelmodulelisthead);
}
The value of the psloadedmodulelist on the top is obtained directly from the Symbol file, you can adjust it according to the actual situation. Ok, let's take a look at 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 Softice's mod command, but it is worth noting that Softice's mod command not only outputs a process kernel module, but also lists a list of user modules for specific processes, how is the system manages process specific modules?
Since each process has its own modules, all of these modules require access to the user state. Therefore, the data structure of the process module organization should be located in the user-state address space. The list of Windows NT / 2000 process module is specified by members in the PEB (Process Environment Block structure), and Windows NT / 2000 will have a user-state code. The PEB of the process is placed at 0x7ffdf000 (2G space or less, user code can be directly accessed). However, Windows NT / 2000 typically gets the address of the PEB through TEB, which is obtained by following the following code:
Mov Eax, FS: [18]
Mov Eax, [EAX 30]
The first statement gets the TEB address of the current thread. For the acquisition of TEB and TEB addresses, see "
Windows NT / 2000 Internal Data Structure Explorer ", the second statement obtains the PEB address at the TEB offset 30H. I think Windows NT / 2000 uses this method to consider compatibility, and the code provided below directly uses a constant address.
Take a look at WINDBG 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.INLOADORDERMODULANLIST: 71EE0. 727F8
LDR.INMEMORYORDERMODULIST: 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.dll77b30000 d: /winnt/system32/comctl32.dll
78000000 D: /Winnt/System32/msvcrt.dll
SubsystemData: 0
ProcessHeap: 70000
ProcessParameters: 2000
WindowTitle: 'D: /winnt/system32/calc.exe'
ImageFile: 'D: /winnt/system32/calc.exe'
.
.
.
Windbg's above output shows the PEB field value, after the data tracking analysis, I wrote the following blocks directly read the system structure acquisition 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 INLOADERMODULELIST;
List_ENTRY INMEMORYORDERMODULIST;
List_entry ininitializationOrderModuLIST;
} PEB_LDR_DATA, * PPEB_LDR_DATA;
#pragma pack ()
Void EnumuserModules (Void * KPEB)
{
PLIST_ENTRY PUSERMODULANLISTHEAD, PUSERMODULISTPTR;
PPEB_LDR_DATA PLDRDATA;
PUNICODE_STRING PIMAGENAME;
IF ((USHORT) NTBUILDNUMBER! = 2195) {
DBGPRINT ("Only Test On Windows 2000 Server Build 2195! / N");
Return;
}
KeattachProcess (KPEB);
PLDRDATA = (PPEB_LDR_DATA) (ULONG *) (PEBADDRESS PEB_LDR_DATA_OFFSET);
IF (! pldrtata-> initialized) {
DBGPRINT ("Process:% 08X Not Initialized! / N", (Ulong) KPEB);
KedetachProcess ();
Return;
}
DBGPRINT ("/ n base addr / tmodule name);
DBGPRINT ("/ n ------- / t ---------- / n"); PUSERMODULISTHEAD = PUSERMODULISTPTR =
(PLIST_ENTRY) & (PLDRDATA-> INMEMORYORDERMODULIST);
Do {
PUSERMODULISTPTR = PUSERMODULISTPTR-> FLINK;
DBGPRINT ("% 08X", * (Ulong *) ((char *)
PuserModuleListPtr LDRDATA_IMAGEBASE_OFFSET);
PimageName = (PUNICODE_STRING) (Ulong *) ((char *)
PusermoduleListPtr ldrdata_imagename_offset);
DBGPRINT ("/ T% S / N", PIMAGENAME-> BUFFER;
WHILE (PUSERMODULISTPTR-> FLINK! = PUSERMODULISTHEAD);
KedetachProcess ();
}
EnumuserModules program implementation enumeration for a specific process (specified by parameter KPEB) module, the function segment does not implement inspection of PEB legitimacy, such as the iDle and the System process is a pure kernel process, they do not have a user-state PEB The solution can be found by checking the legality of TEB, which is usually 0. EnumuserModules also did not check the legality check of KPEB, which assumes that all KPEBs currently exist in the system, otherwise unexpected results will occur. Although only the reader data read, the KEATTACHPROCESS / KEDETACHPROCESS file is used in the block, so the block can only be implemented in the drive code. EnumuserModules uses the INMEMORYORDERMODULIST member enumeration module list (see WindBG output results, EnumuserModules's output results are consistent), of course you can also use the INITIALIZATIONOrDerModuleList or InloadOrDerModuList member.
The MOD command in Softice has explained the system module and the process module, that is, it implements the two blocks I offer (Softice also outputs the PE HEADER segment of the PE module, which can be based on the PE specification according to Base Addr. Remove the position of the Pe Header, and I don't believe that Softice is implemented using the same method).
Regardless of the user-state executable Win32 module (.exe) or the core state driver (.SYS), or the system dynamic link library (.dll) is in the Windows NT / 2000 in the PE format, but it is not necessarily All modules are all formats, and all files can be actually appeared as modules, such as common NLS files, and more. With regard to the loading of the PE file, Windows NT / 2000 provides a function of LDR, as it is well known for its structure, and I will not introduce it.
The PSAPI and Toolhelp API of the Enterprise System Module in Windows 2000 have been implemented in Win9x, but Windows NT is only using the PSAPI function). When I trace the part of the code, I can see these functions. Some of the header files such as ModuleEntry32 or ModuleInfo et al, but the internal use of completely different formats. It can be said that the structure inside the system is large and only the Unicode format, and these APIs only present the partial definition used by the API, Hide a lot of internal features to users. However, ToolHelp et al. Uses the section object (Win32 API, called Filemapping object) maps the entire module to implement module enumeration, but it ultimately uses the PEB data referenced by EnumuserModules. About PEB also contains many system data, such as ProcessHeap, ProcessParameters, etc.
1.David solomb "inside windows nt, 2nd edition"
