之前遗留的一个问题

http://blog.csdn.net/qq_18218335/article/details/76400680
        之前实现Ring3 查找文件占用的时候发现对部分句柄进行NtQueryObject 操作的时候会造成调用者线程挂起&＃xff0c;从Ring3 解决问题的方法就是生成一个单独的工作线程&＃xff0c;代替我们执行NtQueryObject 函数&＃xff0c;如果工作线程挂起&＃xff0c;则调用KillThread 将其结束并新生成一个工作线程&＃xff0c;这种方法虽然可以解决死锁问题&＃xff0c;但是无法得到对象的所有信息。之后我们通过驱动调用ObQueryNameString 并与Ring3 交互成功得到了所有句柄对应的名称信息。这篇文章就来分析为什么同样是调用系统提供的接口函数&＃xff0c;Ring3 会导致线程死锁&＃xff0c;而Ring0 则可以直接得到对象名称。

实验环境

        Win7 X64 sp1&＃xff0c;wrk&＃xff0c;IDA&＃xff0c;vmware 12&＃xff0c;windbg。vs2015

实验思路

        之前尝试直接通过WinDbg 在NtQueryObject 函数下断点来分析其调用流程&＃xff0c;之后发现系统自己多次调用该函数来解析句柄的信息。如果想知道自己的函数调用为什么死锁&＃xff0c;必须要hook 该函数&＃xff0c;然后再判断是自己的程序进行的函数调用的时候中断系统&＃xff0c;之后再进行单步调试&＃xff0c;发现线程死锁的原因。整体流程就是&＃xff0c;Ring3 首先执行一遍查找操作&＃xff0c;判断出谁可能导致线程死锁&＃xff0c;之后加载我们的hook 驱动&＃xff0c;此时Ring3 程序针对特定的导致死锁的句柄调用NtQueryObject 函数&＃xff0c;我们的驱动在捕获此次调用的时候中断系统。此时我们已经得到了依次必然导致线程死锁的函数调用&＃xff0c;我们通过WinDbg 单步调试程序&＃xff0c;并结合wrk 中已经给出的函数实现来综合分析其死锁原因。
        

1. 找到导致死锁的句柄

2.编写驱动&＃xff0c;捕获我们对于该句柄的NtQueryObject 函数调用

3.综合利用各种工具进行分析

        到这里之后我们没有必要刚开始就一无所知去单步调试汇编&＃xff0c;可以借助wrk 源码和 IDA 来分析其行为&＃xff0c;之后再单步调试。首先看Wrk 中 NtQueryObject 的实现。

case ObjectNameInformation://// Call a local worker routine//Status &＃61; ObpQueryNameString( Object,(POBJECT_NAME_INFORMATION)ObjectInformation,ObjectInformationLength,&TempReturnLength,PreviousMode );break;

         我们看到&＃xff0c;当我们要去获得句柄对应的名称信息的时候&＃xff0c;函数转而去调用ObpQueryNameString函数。我们来看ObpQueryNameString 的函数实现&＃xff1b;

if (ObjectHeader->Type->TypeInfo.QueryNameProcedure !&＃61; NULL) {try {#if DBGKIRQL SaveIrql;
#endifObpBeginTypeSpecificCallOut( SaveIrql );ObpEndTypeSpecificCallOut( SaveIrql, "Query", ObjectHeader->Type, Object );Status &＃61; (*ObjectHeader->Type->TypeInfo.QueryNameProcedure)( Object,(BOOLEAN)((NameInfo !&＃61; NULL) && (NameInfo->Name.Length !&＃61; 0)),ObjectNameInfo,Length,ReturnLength,Mode );} except( EXCEPTION_EXECUTE_HANDLER ) {Status &＃61; GetExceptionCode();}ObpDereferenceNameInfo( NameInfo );return( Status );}


        从上面给出的代码实现来看&＃xff0c;该函数首先查看对象所对应的对象类型的QueryNameProcedure 函数&＃xff0c;如果有的话&＃xff0c;直接调用该函数&＃xff0c;我们看到这里的对象类型为File &＃xff0c;文件类型是肯定有其QueryNameProcedure 的&＃xff0c;但是我们需要通过WinDbg 函数验证这个调用过程&＃xff0c;并通过WinDbg 找到File 对应的QueryNameProcedure 函数的地址。

        单步F10 直到调用ObpQueryNameString &＃xff0c;验证了我们的思路&＃xff0c;之后F11 进入函数实现。

nt!ObpQueryNameString:
fffff800&＃96;041972f0 488bc4 mov rax,rsp
fffff800&＃96;041972f3 4c894820 mov qword ptr [rax&＃43;20h],r9
fffff800&＃96;041972f7 44894018 mov dword ptr [rax&＃43;18h],r8d
fffff800&＃96;041972fb 48895010 mov qword ptr [rax&＃43;10h],rdx
fffff800&＃96;041972ff 48894808 mov qword ptr [rax&＃43;8],rcx
fffff800&＃96;04197303 53 push rbx
fffff800&＃96;04197304 56 push rsi
fffff800&＃96;04197305 57 push rdi
fffff800&＃96;04197306 4154 push r12
fffff800&＃96;04197308 4155 push r13
fffff800&＃96;0419730a 4156 push r14
fffff800&＃96;0419730c 4157 push r15
fffff800&＃96;0419730e 4881ecc0000000 sub rsp,0C0h
fffff800&＃96;04197315 4c8bf2 mov r14,rdx
fffff800&＃96;04197318 c7442440010000c0 mov dword ptr [rsp&＃43;40h],0C0000001h
fffff800&＃96;04197320 33ff xor edi,edi
fffff800&＃96;04197322 897c2450 mov dword ptr [rsp&＃43;50h],edi
fffff800&＃96;04197326 48897c2448 mov qword ptr [rsp&＃43;48h],rdi
fffff800&＃96;0419732b 8d7701 lea esi,[rdi&＃43;1]
fffff800&＃96;0419732e 4088742431 mov byte ptr [rsp&＃43;31h],sil
fffff800&＃96;04197333 40887c2430 mov byte ptr [rsp&＃43;30h],dil
fffff800&＃96;04197338 4c8d79d0 lea r15,[rcx-30h]
fffff800&＃96;0419733c 4c897c2470 mov qword ptr [rsp&＃43;70h],r15
fffff800&＃96;04197341 410fb64718 movzx eax,byte ptr [r15&＃43;18h]
fffff800&＃96;04197346 4c8d2db33ccbff lea r13,[nt!KiSelectNextThread (nt&＃43;0x0) (fffff800&＃96;03e4b000)]
fffff800&＃96;0419734d 4d8b94c5807b2200 mov r10,qword ptr [r13&＃43;rax*8&＃43;227B80h]
fffff800&＃96;04197355 41f6471a02 test byte ptr [r15&＃43;1Ah],2
fffff800&＃96;0419735a 0f853b090000 jne nt!ObpQueryNameString&＃43;0x9ab (fffff800&＃96;04197c9b)
fffff800&＃96;04197360 488bdf mov rbx,rdi
fffff800&＃96;04197363 48895c2468 mov qword ptr [rsp&＃43;68h],rbx
fffff800&＃96;04197368 4d8b92a0000000 mov r10,qword ptr [r10&＃43;0A0h]
fffff800&＃96;0419736f 4c3bd7 cmp r10,rdi
fffff800&＃96;04197372 7445 je nt!ObpQueryNameString&＃43;0xc9 (fffff800&＃96;041973b9)
fffff800&＃96;04197374 483bdf cmp rbx,rdi
fffff800&＃96;04197377 7505 jne nt!ObpQueryNameString&＃43;0x8e (fffff800&＃96;0419737e)
fffff800&＃96;04197379 408af7 mov sil,dil
fffff800&＃96;0419737c eb06 jmp nt!ObpQueryNameString&＃43;0x94 (fffff800&＃96;04197384)
fffff800&＃96;0419737e 66397b08 cmp word ptr [rbx&＃43;8],di
fffff800&＃96;04197382 74f5 je nt!ObpQueryNameString&＃43;0x89 (fffff800&＃96;04197379)
fffff800&＃96;04197384 8a842420010000 mov al,byte ptr [rsp&＃43;120h]
fffff800&＃96;0419738b 88442428 mov byte ptr [rsp&＃43;28h],al
fffff800&＃96;0419738f 4c894c2420 mov qword ptr [rsp&＃43;20h],r9
fffff800&＃96;04197394 458bc8 mov r9d,r8d
fffff800&＃96;04197397 4c8bc2 mov r8,rdx
fffff800&＃96;0419739a 408ad6 mov dl,sil
fffff800&＃96;0419739d 41ffd2 call r10


        我们观察到其中一个比较特别的指令&＃xff0c;该指令通过硬编码从内存中取出一个值放到了r10。

fffff800&＃96;0419734d 4d8b94c5807b2200 mov r10,qword ptr [r13&＃43;rax*8&＃43;227B80h]

        同时查看IDA 给出的反汇编后发现&＃xff0c;IDA 解析处了该硬编码地址代表的含义为对象类型表。

        这样的话后面的指令就比较好理解了。如果对象对应的类型的ObpQueryNameString 不为NULL&＃xff0c;调用它即可。

        我们来看一看Wrk 中给出的IopQueryNameInternal 函数实现。

NTSTATUS
IopQueryName(IN PVOID Object,IN BOOLEAN HasObjectName,OUT POBJECT_NAME_INFORMATION ObjectNameInfo,IN ULONG Length,OUT PULONG ReturnLength,IN KPROCESSOR_MODE Mode)/*&＃43;&＃43;函数描述:This function implements the query name procedure for the Object Managerfor querying the names of file objects.此函数为对象管理器中文件对象的解析名称函数。
Arguments:Object - Pointer to the file object whose name is to be retrieved.HasObjectName - Indicates whether or not the object has a name.ObjectNameInfo - Buffer in which to return the name.Length - Specifies the length of the output buffer, in bytes.ReturnLength - Specifies the number of bytes actually returned in theoutput buffer.Mode &＃61; Processor mode of the callerReturn Value:The function return value is the final status of the query operation.--*/{UNREFERENCED_PARAMETER (Mode);return IopQueryNameInternal( Object,HasObjectName,FALSE,//第三个参数传FALSEObjectNameInfo,Length,ReturnLength,Mode );
}NTSTATUS
IopQueryNameInternal(IN PVOID Object,IN BOOLEAN HasObjectName,IN BOOLEAN UseDosDeviceName,OUT POBJECT_NAME_INFORMATION ObjectNameInfo,IN ULONG Length,OUT PULONG ReturnLength,IN KPROCESSOR_MODE Mode)/*&＃43;&＃43;UseDosDeviceName - 是否将文件对象的设备对象部分转换为dosdevice 形式的名称空间或者常规的\device 名称空间
--*/{// ...// 我们当前的函数调用UseDosDeviceName 为FALSEif (UseDosDeviceName) {// ...} else {status &＃61; ObQueryNameString( (PVOID) fileObject->DeviceObject,deviceNameInfo,Length,&lengthNeeded );}if (!NT_SUCCESS( status )) {if (status !&＃61; STATUS_INFO_LENGTH_MISMATCH) {return status;}}p &＃61; (PWSTR) (ObjectNameInfo &＃43; 1);try {if (UseDosDeviceName && dosLookupSuccess) {// 当前UseDosDeviceName 为FALSE} else {RtlCopyMemory( ObjectNameInfo,deviceNameInfo,lengthNeeded > Length ? Length : lengthNeeded );}ObjectNameInfo->Name.Buffer &＃61; p;p &＃61; (PWSTR) ((PCHAR) p &＃43; deviceNameInfo->Name.Length);deviceNameOverflow &＃61; FALSE;if (lengthNeeded > Length) {*ReturnLength &＃61; lengthNeeded;deviceNameOverflow &＃61; TRUE;}// ...if (((Mode &＃61;&＃61; UserMode) && (!UseDosDeviceName)) ||!(fileObject->Flags & FO_SYNCHRONOUS_IO)) {//// 如果从Ring3 调用的话&＃xff0c;是符合((Mode &＃61;&＃61; UserMode) && (!UseDosDeviceName)) 条件的// 如果不是同步I/O 操作的话&＃xff0c;同样也要走到这里// Query the name of the file based using an intermediary buffer.//status &＃61; IopQueryXxxInformation( fileObject,FileNameInformation,length,Mode,(PVOID) fileNameInfo,&lengthNeeded,TRUE );} else {//// 如果是内核请求&＃xff0c;而且文件是同步I/O 操作的话&＃xff0c;需要一种不需要获得文件锁就获取文件文件名的方法。如果需要获得文件锁的话&＃xff0c;可能导致死锁。因为文件锁可能已经被获得了。//status &＃61; IopGetFileInformation( fileObject,length,FileNameInformation,fileNameInfo,&lengthNeeded );}}finally {//// Finally, free the temporary buffer.//ExFreePool( buffer );}return status;
}

        下面我们简单验证上面的思路&＃xff0c;然后最后查看Wrk 给出的两种获得文件名称的方法。

        下面我们查看函数IopQueryXxxInformation 的实现。

ObReferenceObject( FileObject );//// 检查文件是否被同步打开&＃xff0c;如果是的话&＃xff0c;等待直到当前线程拥有该文件// 如果这个文件打开时指定的操作不是同步操作的话&＃xff0c;初始化一个本地的事件。//if (FileObject->Flags & FO_SYNCHRONOUS_IO) {BOOLEAN interrupted;if (!IopAcquireFastLock( FileObject )) {status &＃61; IopAcquireFileObjectLock( FileObject,Mode,(BOOLEAN) ((FileObject->Flags & FO_ALERTABLE_IO) !&＃61; 0),&interrupted );if (interrupted) {ObDereferenceObject( FileObject );return status;}}KeClearEvent( &FileObject->Event );synchronousIo &＃61; TRUE;} else {KeInitializeEvent( &event, SynchronizationEvent, FALSE );synchronousIo &＃61; FALSE;}

         现在查看另一个函数的操作。它为什么能够不获得锁而的到对象名称&＃xff1f;

NTSTATUS
IopGetFileInformation(IN PFILE_OBJECT FileObject,IN ULONG Length,IN FILE_INFORMATION_CLASS FileInformationClass,OUT PVOID FileInformation,OUT PULONG ReturnedLength)/*&＃43;&＃43;Routine Description:内核模式&＃xff0c;通过对象管理器&＃xff0c;想以异步方式获得同步打开的文件对象的信息的时候调用此函数。--*/{PIRP irp;NTSTATUS status;PDEVICE_OBJECT deviceObject;KEVENT event;PIO_STACK_LOCATION irpSp;IO_STATUS_BLOCK localIoStatus;PAGED_CODE();//// 操作之前引用对象&＃xff0c;防止其被删除//ObReferenceObject( FileObject );//// 同步事件&＃xff0c;通知我们的驱动&＃xff0c;操作已经完成。//KeInitializeEvent( &event, SynchronizationEvent, FALSE );//// 得到文件对应的设备对象//deviceObject &＃61; IoGetRelatedDeviceObject( FileObject );//// 盛情并初始化一个IRP//irp &＃61; IoAllocateIrp( deviceObject->StackSize, FALSE );if (!irp) {// 出错的话直接解引用文件对象并退出。ObDereferenceObject( FileObject );return STATUS_INSUFFICIENT_RESOURCES;}irp->Tail.Overlay.OriginalFileObject &＃61; FileObject;irp->Tail.Overlay.Thread &＃61; PsGetCurrentThread();irp->RequestorMode &＃61; KernelMode;//// 在IRP 中设置服务无关的参数。在irp 中设置特定的query name 标志可以确保将不会执行标准的同步文件的完成操作// 因为这个标志告诉I/O 完成不要这么做。// 这也就是为什么这个函数对于同步文件的操作与众不同// 设置异步APC 函数为NULL。irp->UserEvent &＃61; &event;irp->Flags &＃61; IRP_SYNCHRONOUS_API | IRP_OB_QUERY_NAME;irp->UserIosb &＃61; &localIoStatus;irp->Overlay.AsynchronousParameters.UserApcRoutine &＃61; (PIO_APC_ROUTINE) NULL;//// 设置主功能码。//irpSp &＃61; IoGetNextIrpStackLocation( irp );irpSp->MajorFunction &＃61; IRP_MJ_QUERY_INFORMATION;irpSp->FileObject &＃61; FileObject;//// 交互方式为缓冲区I/O //irp->AssociatedIrp.SystemBuffer &＃61; FileInformation;irp->Flags |&＃61; IRP_BUFFERED_IO;//// Copy the caller&＃39;s parameters to the service-specific portion of the// IRP.//irpSp->Parameters.QueryFile.Length &＃61; Length;irpSp->Parameters.QueryFile.FileInformationClass &＃61; FileInformationClass;//// 将IRP 插入到线程的IRP 列表的头部。//IopQueueThreadIrp( irp );//// 调用底层驱动//status &＃61; IoCallDriver( deviceObject, irp );//// 等待底层的驱动执行完毕后设置事件。//if (status &＃61;&＃61; STATUS_PENDING) {(VOID) KeWaitForSingleObject( &event,Executive,KernelMode,FALSE,(PLARGE_INTEGER) NULL );status &＃61; localIoStatus.Status;}*ReturnedLength &＃61; (ULONG) localIoStatus.Information;return status;
}

         通过上面的代码我们可以发现&＃xff0c;两个函数的实现的区别就是一个增加了同步的操作&＃xff0c;一个没有&＃xff0c;而且IopGetFileInformation 函数在irp 中设置IRP_OB_QUERY_NAME标志&＃xff0c;这个标志告诉I/O 完成不要执行通常的同步文件操作完成时执行的操作&＃xff0c;这也就是为什么这个函数对于同步文件的操作与众不同。
         通过上面的研究我们发现了&＃xff0c;当Ring3 对于同步文件执行NtQueryObject 以获得文件名的时候&＃xff0c;将导致线程死锁。而Ring0 获取文件名是不会导致线程死锁的&＃xff0c;无论是同步文件还是异步文件。