Object Management in the NT kernel [2]: Object table

A process may open many kernel objects within its lifecycle. These objects need to be well managed to ensure efficiency. The NT kernel uses the table to save these open objects. The table pointer is stored in eprocess-> objecttable.Gussing.cnblogs.com

When accessing objecttable, we need to determine two types of information: Table address and table level. Object table is not always a huge and flat linear list, because sometimes the number of kernel objects is very large and a linear list is not enough. When the number of objects is greater than 512, eprocess-> objecttable points to a second-level table. When the number of objects exceeds 512*1024, eprocess-> objecttable points to a third-level table. The object Table value must be a multiple of 8, that is, the last three digits must be 0. Therefore, the last three digits of the eprocess-> objecttable field can be used to record additional information, that is, the level of the table, 0 indicates the first-level table, 1 indicates the second-level table, and 2 indicates the third-level table.Gussing.cnblogs.com

Structure of a level-1 table:

The size of the entire table is calculated as 4096b, which is 1 page. The memory management component is managed on pages. Limiting the size of a piece of information to one page can effectively improve efficiency.

Insert an advertisement: in order to learn the NT kernel, I wrote a cottage
Processexplorer, which can be used to view process information, thread information, handle list, loaded DLL list, loaded driver list, and other information. All information is collected manually.
Only one deviceiocontrol API is used. Of course, many kernel export functions are used. It can inject a specified DLL into a specified process, and can also prevent some anti-virus software. Note! Currently
Only XP SP3 is supported. windows of other versions are not tested.

This toySource codePut inHttp://code.google.com/p/yasi/. In addition, this is my work, the experts are not allowed to laugh...

 

Structure of the second-level table:Gussing.cnblogs.com

In the second-level table, objectcode points not to the object table itself, but to a pointer array composed of the addresses of the 1024 object tables. Each table item is a pointer of the handletable * type, pointing to a first-level table.

There is also a trap: Not every item in the pointer array is a valid value. For example, if you open three kernel objects and disable the second one, the first and third items of the array are still valid, but the second item is invalid, this is the so-called "holes". When traversing objecttable, you must skip these holes. Otherwise, the blue screen will crash.

Three-Level Table StructureGussing.cnblogs.com

 

 

 

 

A high-level table in a level-2 table or level-3 table is a pointer array of 4 bytes each, so it can contain 4096/4 = 1024 items in total.

The structure of the object table is quite simple.Gussing.cnblogs.com

Let's take a look at what exists in handle_table_entry. The handle_table_entry structure is defined as follows:

Typedef struct _ handle_table_entry
{
Union {
Pvoid object;
Ulong obattributes;
Pvoid infotable;
Ulong value;
} U1; Gussing.cnblogs.com
Union {
Struct _ S1
{
Union {
Ulong grantedaccess;
Struct _ s2 {
Unsigned short grantedaccessindex;
Unsigned short greatorbacktraceindex;
} S2;
} U2;
} S1;
Int nextfreetableentry;
} U3;
} Handle_table_entry, * phandle_table_entry;

This is an 8-byte memory area. The first four bytes are the address of the object header, and the last four bytes are some management fields. It should be noted that handle_table_entry-> object is also 8-byte alignment, so the last three digits are cleared as the real object header address.

Finally, let's take a look at the entire process from handle to object:Gussing.cnblogs.com