Windows kernel Object Management Learning notes

I am currently reading the chapter on the Object Management section of the Windows kernel scenario analysis by teacher Mao, making this note.

The win kernel uses object concepts to describe the data structures used in the management kernel. This object, which consists of the object header, is actually an optional component due to the special structure of the object header concept. So an object is actually divided into three parts.

The Object_header object header.

Data ontology (such as file objects, object, event, etc.)

Additional information (such as Object Header Name info, etc.)

The structure is as follows:

//Excerpt from ReactOS code
//Object Header
//
typedef struct _OBJECT_HEADER
{
LONG pointercount;
Union
{
LONG handlecount;
Volatile PVOID Nexttofree;
};
Pobject_type TYPE;
UCHAR Nameinfooffset;
UCHAR Handleinfooffset;
UCHAR Quotainfooffset;
UCHAR Flags;
Union
{
Pobject_create_information objectcreateinfo;
PVOID quotablockcharged;
};
Psecurity_descriptor SecurityDescriptor;
QUAD Body;
} object_header, *pobject_header;
When you debug Windows XP with WinDbg, you get the following structure.
lkd> DT _object_header
Nt!_object_header
+0x000 pointercount:int4b
+0x004 handlecount:int4b
+0x 004 Nexttofree:ptr32 Void
+0x008 type:ptr32 _object_type
+0x00c nameinfooffset:uchar
+0x00d HANDLEINFOOFFSE T:uchar
+0x00e quotainfooffset:uchar
+0x00f flags:uchar
+0x010 objectcreateinfo:ptr32 _OBJECT_CREATE_INFO Rmation
+0x010 quotablockcharged:ptr32 void
+0x014 securitydescriptor:ptr32 Void
+0x018 Body: _quad

It should look similar, ReactOS. The description of the object header is basically consistent with Windows. The body is the object body, because of the multiplicity of the ontology structure, the length is indeterminate. So the Windows kernel scenario analysis mentions, "Object_header_name_info and so on under Object_header, with 8-bit bytes to represent the amount of displacement." Structure

There are a few different small discoveries when using the WinDbg debug verification under XP systems. WinDbg is turned on in the XP system. Open Menu File->kernel dbug. Select Local debugging. Using!handle, we can get a list of WinDbg available handles, and we shift the handle to the object header structure analysis.

With a lot of handles, we select a handle of type file for easy analysis.

000c:object:81c53b70 grantedaccess:00100020 (Inherit) entry:e10d7018
Object:81c53b70 Type: (81feb040) File
Objectheader: 81c53b58 (old version)
Handlecount:1 pointercount:1
Directory object:00000000 Name: \program Files\Debugging Tools for Windows (x86) {HarddiskVolume1}
ld> DT _object_header 81c53b58
Nt!_object_header
+0x000 pointercount:1
+0x004 handlecount:1
+0x004 nexttofree:0x00000001
+0x008 type:0x81feb040 _object_type
+0x00c nameinfooffset:0 "
+0x00d handleinfooffset:0x8 "
+0x00e quotainfooffset:0 "
+0x00f flags:0x40 ' @ '
+0x010 Objectcreateinfo:0x81e900e8 _object_create_information
+0x010 Quotablockcharged:0x81e900e8
+0x014 SecurityDescriptor: (NULL)
+0x018 Body: _quad

Structure is +0x018 body: _quad is the object body, we know the object when the file object, so in WinDbg with the file object FileObject parse the address

Lkd> DT _file_object 81c53b58 +0x18
Ntdll!_file_object
+0x Type:5
+0x002 size:112
+0x004 deviceobject:0x81b2c900 _device_object
+0x008 vpb:0x81fe67c8 _VPB
+0 x00c fscontext:0xe1201510
+0x010 fscontext2:0xe12016a8
+0x014 sectionobjectpointer: (null)
+0x018 Privatecachemap: (null)
+0x01c finalstatus:0
+0x020 relatedfileobject: (null)
+0x024 lockoperation:0 "
+ 0x025 deletepending:0 "
+0x026 readaccess:0x1"
+0x027 writeaccess:0 "
+0x028 deleteaccess:0"
+0x029 sharedread:0x1 "
+0x02a sharedwrite:0x1"
+0x02b shareddelete:0 "
+0x02c flags:0x40002
+0x030 FileName : _unicode_string "\program Files\Debugging Tools for Windows (x86)"
+0x038 currentbyteoffset: _large_integer 0x0
+0x040 waiters:0
+0x044 busy:0
+0x048 lastlock: (null)
+0x04c Lock: _kevent
+0x05c Event: _kevent
+0 X06C Completioncontext: (null)

Then we look for those additional information. In the object header structure we can see

+0x00d handleinfooffset:0x8 "

_object_handle_information This structure is present, and the offset of the relative object head is 0x8. So does this structure precede the object's head or the object's head? Let's try it out.

lkd> DT _object_handle_information 81c53b58-0x8 ntdll!_object_handle_information +0x000 HandleAttributes: 0x81f33908 +0x004 grantedaccess:1

lkd> DT _object_handle_information 81c53b58+0x8+0x18 error ntdll!_object_handle_information +0x000 Handleattributes:0x81fe67c8 +0x004 grantedaccess:0xe1201510

lkd> DT _object_handle_information 81c53b58+0x8 error ntdll!_object_handle_information +0x000 handleattributes:0x81feb040 +0x004 grantedaccess:0x40000800

Obviously, the additional information is before the object header, the actual debugging in the XP system and teacher Mao's analysis of the ReactOS is slightly different, it should be the implementation of the two systems or there is a slight difference.

In this paper, we summarize the actual distribution of object header, Object ontology, additional information, and how to get the various information of the object corresponding to the handle.