Windows kernel objects

WINDOWS Kernel objects

A Objective

There are many objects in Windows like process objects, thread objects, file objects, and so on, which we call Windows kernel objects. A kernel object is a block of memory in the system's address space that is created and maintained by the system. Kernel objects are owned by the kernel and are not owned by the process, so different processes can access the same kernel object.

Two Kernel object structure

Each object consists of an object header and an object body. All types of object header structures are the same, while the structure parts are different. The following is a diagram of the kernel object's structure:

Kernel Object Structure diagram

The gray part of the figure is possible. The presence of these parts in each object is primarily specified by the relevant flags in the object_header structure. The format of the above 5 structures is fixed, while the object structure part is different from each other. Note that the pointer to the object pobject to the body part of the object, not to the object header. So, if you need to access Object_header, you need to get pobjcect minus 0x18 .

The following is the structure of Object_header

typedef struct _object_header { DWORD Pointercount;//number of pointer references DWORD Handlecount;//number of open handles Pobject_type ObjectType; Pointer to type Object BYTE nameoffset;//Offset of object name BYTE handledboffset;//HANDLE db offset BYTE quotachargesoffset; offset of//quota charges BYTE objectflags;//Object Flag Union {//Ob_flag_create_info in object flags? Objectcreateinfo:quotablock Pquota_block Quotablock; Pobject_create_info Objectcreateinfo;  }; Psecurity_descriptor SecurityDescriptor; }object_header, *pobject_header;

Three directory objects

There are several types of kernel objects in WINDOWS , all of which exist independently in the system address space. The system uses directory objects to organize all of these objects. A directory object is a hash (hash) tree that consists ofa number of PNS elements. The data structure is as follows:

Typedef struct _object_directory_enty { Struct _object_directory_entry *nextentry; Pobject Object }object_directory_entry, *pobject_directory_entry,**ppobject_directory_entry; Typedef struct _object_directory { Pobject_directory_entry hashtable[37]; Pobject_directory_entry Currententry; BOOLEAN Currententryvalid; BYTE Reserved1; WORD Reserved2; DWORD Reserved3; }object_directory, *pobject_directory;

 

The system obtains a HASH value by the algorithm of the object name, the algorithm is as follows:

Calculates the hash value by name. hash = 0; p = (pshort) wstr; A WCHAR array that holds the name while (*P) { SYMB = (CHAR) *p; hash = hash * 3 + (hash >> 1); if (Symb < ' a ')//<a hash= hash + symb; else if (symb <= ' z ')//That is a~z hash = hash + symb-0x20; else//> Z hash = hash + (CHAR) Rtlupcaseunicodechar ((WCHAR) *p); p + +; } hash = hash% 37; The final hash value.

The system links all objects of the same hash value to the array item of the response, and all the elements in the system are arranged in the following structure:

The pointer to the system root object is specified by obprootdirectoryobject .

Logically, only one directory object is required in the system, and all kernel objects in the system are linked to this directory object. But for some reason, this is not the case in the system, where there are multiple directory objects, which are rooted in the root object and form an "object Tree". The calculation rules for the hash value of hash tree in each directory object are the same.

We can traverse all the objects in the system according to the structure of the "object Tree" in the system.

Four Type Object

There is also a special object-type object in the kernel object. There is only one type object for each type of object in the system, that is to say, there are only a few types of objects in the system. Each type of object has a pointer to its type object in its object body, because a type object has only one entity, so pointers to each type of object are fixed so that we can judge and access the type of the object through the type object pointer in the object body.

The object body of each type of object has no linked list structure so that they are linked to each other. But if the object has a object_creator_info structure in front of it (see table below), then the same type of object can be linked to each other through its member ObjectList . Unfortunately, by default, only objects of the type in Port and waitport two have this structure. So in general, we cannot traverse all objects in this system by Type objects.

typedef struct _OBJECT_CREATOR_INFO { List_entry ObjectList; Object_creator_info HANDLE Uniqueprocessid; WORD Reserved1; WORD Reserved2; }object_creator_info, *pobject_creator_info, **ppobject_creator_info;

Five Traversal of objects

The above analysis, the following can be a directory object traversal, to carry out all the objects in the system traversal.

Write a recursive function. Used to parse the tree directory. void Analysedirectory (Pobject_directory pdirectory, ULONG directorytype, int level) { Pobject_directory_entry Pdirectoryentry; Pobject_header Pobjectheader; Pobject_name Pobjectname; Pwchar wstr[200]; Char space[100]; Used to generate a space. int I, J; for (i = 0; i <; i + +) the object Body (body) of the//dir object is an array of 37 elements. { Pdirectoryentry = pdirectory->hashtable[i]; while (Pdirectoryentry) { Pobjectheader = (Pobject_header) ((ULONG) pdirectoryentry->pobject-sizeof (Object_header)); Generate spaces RtlZeroMemory (Space, 100); for (j = 0, J < 5 * level; J + +) SPACE[J] = "; if (Pobjectheader->nameoffset) { Pobjectname = (pobject_name) ((ULONG) pobjectheader-pobjectheader->nameoffset); RtlZeroMemory (WSTR, $ * sizeof (WCHAR)); Rtlcopymemory (Wstr, Pobjectname->name.buffer, pobjectname->name.length); Dbgprint ("%s pobject:0x%08x Name:%s", Space, Pdirectoryentry->pobject, WSTR); } Else Dbgprint ("%s pobject:0x%08x name:noname", Space, Pdirectoryentry->pobject); Is the Pobject object a Property object? if (ULONG) Pobjectheader->pobjecttype = = Directorytype) Analysedirectory (Pdirectoryentry->pobject, Directorytype, level + 1); Pdirectoryentry = pdirectoryentry->nextentry; } }//end of Traversal 37 records }

Six Access to Objects

The kernel object can be accessed directly by knowing the address of the kernel objects, but it cannot be accessed in the user program. Windows provides a series of functions for access to kernel objects. When a function is called to create a kernel object, a handle value is returned after the function call. The handle value is process independent, and the handle value in one process is not valid in another process.

The handle value is the index of a process handle table. Each process has a process handle table, and the handle table of all processes is strung into a handle bracelet. The header address of this chain is stored in the kernel variable handletablelisthead.

The following is a concrete look at the handle table structure. The system organizes the handle table into the same structure as the linear address resolution. The handle table is a three-layer table structure, and the handle value is divided into three parts, which are used to index the three parts separately. The following is a handle resolution diagram:

Seven Summarize

This article can be said to be a reading note. In reference to a lot of articles based on, and then make some experiments to complete this article. Kernel objects are important data structures inside windows. This article provides an overview of how Windows organizes numerous objects.

Eight Reference

1. "Undocumented Windows Secrets"

2. Anathema "Inside Windows Nt Object Manager"

3. Webcrazy Anatomy of the Windows nt/2000 core Object Organization

4. "Inside Windows 2000"

5. "Windows core Programming"

Note: The handle described in this section is the handle under Win2K. winxp the following handle table structure is completely different.

Windows kernel objects