-------- ObReferenceObjectByName () troubleshooting for driver development --------,

-------- ObReferenceObjectByName () troubleshooting for driver development --------,

------------------------------------------------------

 

When writing a filter driver or rootkit, you often need to attach it to the target device in the device stack to intercept the passing IRP (I/O Request Packet) and implement the filtering function.
First, you must know that the target device is registered with the global namespace maintained by Windows Object Manager._ DEVICE_OBJECTName, such information can beWinObj.exe.

CallObReferenceObjectByName ()This function stores the obtained target object address in its last parameter (pointer) and returns it to the caller.
In practice, we will find that_ DRIVER_OBJECTAlmost always succeeded._ DEVICE_OBJECTIs not necessarily successful.NTSTATUSStatus Codes are generally two types:

1 C0000022（STATUS_ACCESS_DENIED）2 C0000024（STATUS_OBJECT_TYPE_MISMATCH）

 

The first case is usually because the target is created_ DEVICE_OBJECTThe specified session id is inconsistent with the current session id, or the target object holds a special security access token/Security Attribute, so we cannot get it in the regular way, and this error occurs frequently inIoGetDeviceObjectPointer ()During the call, most of the books about the filter driver and rootkit are used.IoGetDeviceObjectPointer ()As part of the sample code, it is a bit mistaken.

In the second caseObReferenceObjectByName ()Reference certain _DEVICE_OBJECTReason andObReferenceObjectByName ()Using other execution body component routines, the name search logic executed in the global namespace is closely related and will be explained later.

It should be noted that sinceObReferenceObjectByName ()Reference vast majority_ DRIVER_OBJECTAnd_ DRIVER_OBJECT.DeviceObjectPointing to the first device chain created by the driver_ DEVICE_OBJECT, so this is the most stable method. But we still need to knowSTATUS_OBJECT_TYPE_MISMATCH.

 ObReferenceObjectByName ()Is an undisclosed routine, which is not described in MSDN. On the other hand, the header file ntddk. h or wdm. h contains no prototype Declaration;

However, the kernel image ntoskrnl.exe and other versions indeed export its symbols. In other words, we only need to tell the linker to parse the function name as an external symbol.
In addition,ObReferenceObjectByName ()The fifth parameter is also an undocumented data type (POBJECT_TYPE), So the related declaration is required, as shown in:

 

-------------------------------------------------------------

Please note that we have declared a pointing type"POBJECT_TYPE"Pointer --IoDeviceObjectType-- And"POBJECT_TYPE"Pointing to the type itself"OBJECT_TYPESo when you pass in the fifth parameter, be careful to use the operator"*"IoDeviceObjectTypeAnd Its Parameter type (POBJECT_TYPE). OtherwiseObReferenceObjectByName ()Failed, interfering with our judgment on the cause of returned NTSTATUS!

 

Assume that our own driver needs to obtain\ Device \ QQProtect"Corresponding_ DEVICE_OBJECTPointer, and then check the returnedNTSTATUSStatus Code, as shown in:

("\ Device \ QQProtect"Is one of the two filter drivers installed with the instant messaging software QQ:QQProtect. sysName of the created device object,
It is also our goal of the IRP Dispatch Routine Hook experiment later !)

 

 

We can see that when testing in a virtual machine,Dbuplint ()The returned status code C0000024 (STATUS_OBJECT_TYPE_MISMATCH) indicates that the object type does not match, as shown in:

 

 

At hand, there is a source code for the NT 5.2 kernel, which is used to compile the Kernel used by Windows XP/Server 2003. Although it is different from the NT 6.1 kernel of my testing machine
Let's take a look.ObReferenceObjectByName ()What exactly has been done internally.ObReference *()Most of the series of routines are stored in the kernel source code"Obref. c"And"Obdir. c"
File. Shows how to analyze the call chain:

There are two key points: one isObpLookupObjectName ()Check the initialization settings of the target object type (Use_ OBJECT_TYPE_INITIALIZERWhether the ParseProcedure routine is specified. For a "device" class object, the pointer to this function value is alwaysIopParseDevice (), Eventually causing the callIopParseDevice ().

We can see from the previous figure thatObReferenceObjectByName ()At the beginning, it is passed in NULL for its seventh parameter ParseContext, and ParseContext will be passed one by one in the call chain.IopParseDevice ()Accept and verify the parameter. If it is null, returnSTATUS_OBJECT_TYPE_MISMATCH.

Now you know whyObReferenceObjectByName ()It is always so painful to reference the target device. The key is to allocate and initialize the ParseContext...

-------------------------------------------

I extracted the relevant code snippets from the source code, as shown in the following figures. It is best to compare them with the preceding flowchart for better understanding,
Later, I will debug Windows 7 (based on the NT 6.1 kernel) on the virtual machine. You will be surprised to find that when tracing stack tracing information,
It is very similar to the call chain in the source code of the NT 5.2 kernel. This shows that the migration between versions does not change the object name search and verification logic too much.
(This is the case from Windows XP to 7 at least. It is not clear that later versions have not been tested !)

 

 

 

 

 

SlaveIopParseDevice ()The internal comment I vaguely got the idea of bypassing the call source detection-that is, trackingNtCreateFile (), SeeOPEN_PACKETWhere is it?

Assigned and initialized.IopParseDevice ()Will detectPOPEN_PACKETSome fields of the structure instance to ensureObReferenceObjectByName () Call
YesfromNtCreateFile ()Initiated,NtCreateFile ()Implemented in NT 5.2 kernel source codeCreater. c, It simply executes the call chain
IoCreateFile ()-> IopCreateFile ()(BOTH routines are implemented in the source codeIosubs. cAndIopCreateFile ()Allocate and initializeOPEN_PACKETStructure.

Therefore, we only need to copyIopCreateFile ()To allocate and initializeOPEN_PACKET, AndObReferenceObjectByName ()
Will BypassIopParseDevice ()Call source detection logic.
This part of the Patch will be republished later. We need to verify that the "ParseProcedure" of the "device" Class Object is indeedIopParseDevice ().....

--------------------------------------------------

In the kernel debugging environment,\ Device \ QQProtect"Get the information of the corresponding object:

After obtaining the object header address, format and dump the fields in it. What we are interested in is"TypeIndex"Field, which is used to index the corresponding" Object Type "in the" Object Type table ":

 

The WInodws kernel uses a Data Structure --ObTypeIndexTableStores information about various object types, essentiallyObTypeIndexTableIs a pointer array. In the 32-bit architecture, each pointer is 4 bytes in size, and the index number (SubscriptStarting from 0) 19, the two expressions in calculate the address of the "Object Type" accordingly:

We can see that the address of the corresponding "Object Type" structure is0x855cef78-- Data Structure for Windows Kernel_ OBJECT_TYPEObject type.
Format and dump the fields. The fields we are interested in areTypeInfoAs mentioned above, it is an object type initialization setting structure, which is used by the kernel
_ OBJECT_TYPE_INITIALIZERObject Type initialization settings. Note that,TypeInfoOffset the starting address of its parent structure 0x28 bytes, so add this
Offset and check again. As you can see, "ParseProcedure" isIopParseDevice ().

 

 

The next article will discuss how to bypass the call source detection of IopParseDevice (), debug our results, and apply it to rootkit development technology.