BUG的详情
被调试机:7600.16385.x86fre.win7_rtm.090713-1255
调试机:win10,
调试工具:windbg proview
导致蓝屏的软件:pchunter
视频:https://www.youtube.com/watch?v=8tBRtlvapWU
运行pchunter,点击“网络”卡片页时,系统就会蓝屏。
对第一次蓝屏捕捉到的信息进行分析。这里只列出了一些重点信息及描述。
BUG的概述
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: fffffff5, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 840bf2ee, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved) PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: fffffff5, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 840bf2ee, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
BugCheckCode:PAGE_FAULT_IN_NONPAGED_AREA 是微软定义的Bug编码,其值为0x00000050.下面英文说的是,系统使用了无效的系统内存导致触发异常,且该异常没能被处理。可能是内存地址被破坏了或被释放了。
Arguments,为参数错误检查。这里检测到的信息是,参数1:指出当前系统访问当地址是0xfffffff5;参数2:是说当前的操作是读;参数3:是说当前指令的地址是0x840bf2ee;参数4:保留。
BUG的详情
Debugging Details:
------------------
KEY_VALUES_STRING: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 7600.16385.x86fre.win7_rtm.090713-1255
DUMP_TYPE: 0
BUGCHECK_P1: fffffffffffffff5
BUGCHECK_P2: 0
BUGCHECK_P3: ffffffff840bf2ee
BUGCHECK_P4: 0
READ_ADDRESS: fffffff5
FAULTING_IP:
nt!ObpQueryNameString+2b
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch]
......
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: PCHunter32.exe
BUILD_VERSION_STRING:指出了运行的系统版本信息。
BUGCHECK_P1~4:和BUG概述中的基本一致。
READ_ADDRESS:读地址为0xfffffff5的内存。
FAULTING_IP:导致Bug的地址。即该bug发生在nt!ObpQueryNameString+2b处,该地址的需要执行的指令是 movzx eax,byte ptr [esi+0Ch]
DEFAULT_BUCKET_ID:故障类型。这里指出是win7驱动发生故障。
PROCESS_NAME:与该BUG相关的进程。
陷阱帧
TRAP_FRAME: 98926954 -- (.trap 0xffffffff98926954)
.trap 0xffffffff98926954
ErrCode = 00000000
eax=98926a1c ebx=00000000 ecx=98926abc edx=98926a6c esi=ffffffe9 edi=00000001
eip=840bf2ee esp=989269c8 ebp=98926a2c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ObpQueryNameString+0x2b:
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ds:0023:fffffff5=??
.trap
Resetting default scope
LAST_CONTROL_TRANSFER: from 83f1ee71 to 83ead394
TRAP_FRAME :陷阱帧,是一个nt!_KTRAP_FRAME结构体。
KTRAP_FRAME 用于在系统处理异常或中断期间,保存CPU的寄存器的内容。 KTRAP_FRAME结构通常分配在线程的内核模式堆栈中。陷阱帧的一小部分由CPU填充,作为其自身中断和异常处理的一部分,陷阱帧的其余部分由Windows提供的软件异常和中断处理程序
创建
(例如KiTrap0E()、KiPageFault
KiInterruptDispatch
等函数)。
LAST_CONTROL_TRANSFER:最后的控制权转让,也就是调用栈中的最后一个CALL。这里,在地址0x83f1ee71调用了0x83ead394
调用堆栈
STACK_TEXT:
9892649c 83f1ee71 00000003 21db833f 00000065 nt!RtlpBreakWithStatusInstruction
989264ec 83f1f96d 00000003 88621d48 00000000 nt!KiBugCheckDebugBreak+0x1c
989268b0 83ec78e3 00000050 fffffff5 00000000 nt!KeBugCheck2+0x68b
9892693c 83e885f8 00000000 fffffff5 00000000 nt!MmAccessFault+0x106
9892693c 840bf2ee 00000000 fffffff5 00000000 nt!KiTrap0E+0xdc
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
98926af4 8bc77245 03fc016c 001ffeb4 00000000 PCHunter32aq+0x52887
98926b2c 8bc772d3 00000010 0000013c 98926bfc PCHunter32aq+0x53245
98926b3c 8bca740b 00000000 00000000 03fc0020 PCHunter32aq+0x532d3
98926bfc 83e7e4bc 886240d8 88722178 88722178 PCHunter32aq+0x8340b
98926c14 8407feee 8862cc68 88722178 887221e8 nt!IofCallDriver+0x63
98926c34 8409ccd1 886240d8 8862cc68 00000000 nt!IopSynchronousServiceTail+0x1f8
98926cd0 8409f4ac 886240d8 88722178 00000000 nt!IopXxxControlFile+0x6aa
98926d04 83e8542a 00000258 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
98926d04 779464f4 00000258 00000000 00000000 nt!KiFastCallEntry+0x12a
001263e0 77944cac 75d0a08f 00000258 00000000 ntdll!KiFastSystemCallRet
001263e4 75d0a08f 00000258 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
00126444 768eec25 00000258 04470140 00126538 KERNELBASE!DeviceIoControl+0xf6
00126470 008cf640 00000258 04470140 00126538 kernel32!DeviceIoControlImplementation+0x80
00126520 00409ffa 00000000 0012c400 00000000 PCHunter32+0x4cf640
...
前面5个函数是系统用来保存现场(寄存器)以及检测崩溃信息。
从BUG详情中已经知道,崩溃地址是nt!ObpQueryNameString+0x2b。是由于[esi+0Ch]=0xfffffff5导致的。
追踪崩溃源头
Debugging Details:
------------------
KEY_VALUES_STRING: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 7600.16385.x86fre.win7_rtm.090713-1255
DUMP_TYPE: 0
BUGCHECK_P1: fffffffffffffff5
BUGCHECK_P2: 0
BUGCHECK_P3: ffffffff840bf2ee
BUGCHECK_P4: 0
READ_ADDRESS: fffffff5
FAULTING_IP:
nt!ObpQueryNameString+2b
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch]
......
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: PCHunter32.exe
BUILD_VERSION_STRING:指出了运行的系统版本信息。
BUGCHECK_P1~4:和BUG概述中的基本一致。
READ_ADDRESS:读地址为0xfffffff5的内存。
FAULTING_IP:导致Bug的地址。即该bug发生在nt!ObpQueryNameString+2b处,该地址的需要执行的指令是 movzx eax,byte ptr [esi+0Ch]
DEFAULT_BUCKET_ID:故障类型。这里指出是win7驱动发生故障。
PROCESS_NAME:与该BUG相关的进程。
陷阱帧
Debugging Details:
------------------
KEY_VALUES_STRING: 1
TIMELINE_ANALYSIS: 1
DUMP_CLASS: 1
DUMP_QUALIFIER: 0
BUILD_VERSION_STRING: 7600.16385.x86fre.win7_rtm.090713-1255
DUMP_TYPE: 0
BUGCHECK_P1: fffffffffffffff5
BUGCHECK_P2: 0
BUGCHECK_P3: ffffffff840bf2ee
BUGCHECK_P4: 0
READ_ADDRESS: fffffff5
FAULTING_IP:
nt!ObpQueryNameString+2b
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch]
......
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
PROCESS_NAME: PCHunter32.exe
BUILD_VERSION_STRING:指出了运行的系统版本信息。
BUGCHECK_P1~4:和BUG概述中的基本一致。
READ_ADDRESS:读地址为0xfffffff5的内存。
FAULTING_IP:导致Bug的地址。即该bug发生在nt!ObpQueryNameString+2b处,该地址的需要执行的指令是 movzx eax,byte ptr [esi+0Ch]
DEFAULT_BUCKET_ID:故障类型。这里指出是win7驱动发生故障。
PROCESS_NAME:与该BUG相关的进程。
陷阱帧
TRAP_FRAME: 98926954 -- (.trap 0xffffffff98926954)
.trap 0xffffffff98926954
ErrCode = 00000000
eax=98926a1c ebx=00000000 ecx=98926abc edx=98926a6c esi=ffffffe9 edi=00000001
eip=840bf2ee esp=989269c8 ebp=98926a2c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ObpQueryNameString+0x2b:
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ds:0023:fffffff5=??
.trap
Resetting default scope
LAST_CONTROL_TRANSFER: from 83f1ee71 to 83ead394
TRAP_FRAME :陷阱帧,是一个nt!_KTRAP_FRAME结构体。
KTRAP_FRAME 用于在系统处理异常或中断期间,保存CPU的寄存器的内容。 KTRAP_FRAME结构通常分配在线程的内核模式堆栈中。陷阱帧的一小部分由CPU填充,作为其自身中断和异常处理的一部分,陷阱帧的其余部分由Windows提供的软件异常和中断处理程序
创建
(例如KiTrap0E()、KiPageFault
KiInterruptDispatch
等函数)。
LAST_CONTROL_TRANSFER:最后的控制权转让,也就是调用栈中的最后一个CALL。这里,在地址0x83f1ee71调用了0x83ead394
TRAP_FRAME: 98926954 -- (.trap 0xffffffff98926954)
.trap 0xffffffff98926954
ErrCode = 00000000
eax=98926a1c ebx=00000000 ecx=98926abc edx=98926a6c esi=ffffffe9 edi=00000001
eip=840bf2ee esp=989269c8 ebp=98926a2c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!ObpQueryNameString+0x2b:
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ds:0023:fffffff5=??
.trap
Resetting default scope
LAST_CONTROL_TRANSFER: from 83f1ee71 to 83ead394
TRAP_FRAME :陷阱帧,是一个nt!_KTRAP_FRAME结构体。
KTRAP_FRAME 用于在系统处理异常或中断期间,保存CPU的寄存器的内容。 KTRAP_FRAME结构通常分配在线程的内核模式堆栈中。陷阱帧的一小部分由CPU填充,作为其自身中断和异常处理的一部分,陷阱帧的其余部分由Windows提供的软件异常和中断处理程序
创建
(例如KiTrap0E()、KiPageFault
KiInterruptDispatch
等函数)。
LAST_CONTROL_TRANSFER:最后的控制权转让,也就是调用栈中的最后一个CALL。这里,在地址0x83f1ee71调用了0x83ead394
调用堆栈
STACK_TEXT:
9892649c 83f1ee71 00000003 21db833f 00000065 nt!RtlpBreakWithStatusInstruction
989264ec 83f1f96d 00000003 88621d48 00000000 nt!KiBugCheckDebugBreak+0x1c
989268b0 83ec78e3 00000050 fffffff5 00000000 nt!KeBugCheck2+0x68b
9892693c 83e885f8 00000000 fffffff5 00000000 nt!MmAccessFault+0x106
9892693c 840bf2ee 00000000 fffffff5 00000000 nt!KiTrap0E+0xdc
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
98926af4 8bc77245 03fc016c 001ffeb4 00000000 PCHunter32aq+0x52887
98926b2c 8bc772d3 00000010 0000013c 98926bfc PCHunter32aq+0x53245
98926b3c 8bca740b 00000000 00000000 03fc0020 PCHunter32aq+0x532d3
98926bfc 83e7e4bc 886240d8 88722178 88722178 PCHunter32aq+0x8340b
98926c14 8407feee 8862cc68 88722178 887221e8 nt!IofCallDriver+0x63
98926c34 8409ccd1 886240d8 8862cc68 00000000 nt!IopSynchronousServiceTail+0x1f8
98926cd0 8409f4ac 886240d8 88722178 00000000 nt!IopXxxControlFile+0x6aa
98926d04 83e8542a 00000258 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
98926d04 779464f4 00000258 00000000 00000000 nt!KiFastCallEntry+0x12a
001263e0 77944cac 75d0a08f 00000258 00000000 ntdll!KiFastSystemCallRet
001263e4 75d0a08f 00000258 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
00126444 768eec25 00000258 04470140 00126538 KERNELBASE!DeviceIoControl+0xf6
00126470 008cf640 00000258 04470140 00126538 kernel32!DeviceIoControlImplementation+0x80
00126520 00409ffa 00000000 0012c400 00000000 PCHunter32+0x4cf640
...
前面5个函数是系统用来保存现场(寄存器)以及检测崩溃信息。
从BUG详情中已经知道,崩溃地址是nt!ObpQueryNameString+0x2b。是由于[esi+0Ch]=0xfffffff5导致的。
追踪崩溃源头
STACK_TEXT:
9892649c 83f1ee71 00000003 21db833f 00000065 nt!RtlpBreakWithStatusInstruction
989264ec 83f1f96d 00000003 88621d48 00000000 nt!KiBugCheckDebugBreak+0x1c
989268b0 83ec78e3 00000050 fffffff5 00000000 nt!KeBugCheck2+0x68b
9892693c 83e885f8 00000000 fffffff5 00000000 nt!MmAccessFault+0x106
9892693c 840bf2ee 00000000 fffffff5 00000000 nt!KiTrap0E+0xdc
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
98926af4 8bc77245 03fc016c 001ffeb4 00000000 PCHunter32aq+0x52887
98926b2c 8bc772d3 00000010 0000013c 98926bfc PCHunter32aq+0x53245
98926b3c 8bca740b 00000000 00000000 03fc0020 PCHunter32aq+0x532d3
98926bfc 83e7e4bc 886240d8 88722178 88722178 PCHunter32aq+0x8340b
98926c14 8407feee 8862cc68 88722178 887221e8 nt!IofCallDriver+0x63
98926c34 8409ccd1 886240d8 8862cc68 00000000 nt!IopSynchronousServiceTail+0x1f8
98926cd0 8409f4ac 886240d8 88722178 00000000 nt!IopXxxControlFile+0x6aa
98926d04 83e8542a 00000258 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
98926d04 779464f4 00000258 00000000 00000000 nt!KiFastCallEntry+0x12a
001263e0 77944cac 75d0a08f 00000258 00000000 ntdll!KiFastSystemCallRet
001263e4 75d0a08f 00000258 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
00126444 768eec25 00000258 04470140 00126538 KERNELBASE!DeviceIoControl+0xf6
00126470 008cf640 00000258 04470140 00126538 kernel32!DeviceIoControlImplementation+0x80
00126520 00409ffa 00000000 0012c400 00000000 PCHunter32+0x4cf640
...
前面5个函数是系统用来保存现场(寄存器)以及检测崩溃信息。
从BUG详情中已经知道,崩溃地址是nt!ObpQueryNameString+0x2b。是由于[esi+0Ch]=0xfffffff5导致的。
追踪崩溃源头
追踪崩溃源头
查看
nt!ObpQueryNameString ~ nt!ObpQueryNameString+0x2b的
反汇编:
查看
nt!ObpQueryNameString ~ nt!ObpQueryNameString+0x2b的
反汇编:
查看
nt!ObpQueryNameString ~ nt!ObpQueryNameString+0x2b的
反汇编:
uf nt!ObpQueryNameString
nt!ObpQueryNameString:
840bf2c3 6a44 push 44h
840bf2c5 68f0c3e583 push offset nt! ?? ::FNODOBFM::`string'+0x1790 (83e5c3f0)
840bf2ca e83932dfff call nt!_SEH_prolog4 (83e72508)
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8]
840bf2d2 c745d8010000c0 mov dword ptr [ebp-28h],0C0000001h
840bf2d9 33db xor ebx,ebx
840bf2db 895dc4 mov dword ptr [ebp-3Ch],ebx
840bf2de 895de0 mov dword ptr [ebp-20h],ebx
840bf2e1 c645e701 mov byte ptr [ebp-19h],1
840bf2e5 885de6 mov byte ptr [ebp-1Ah],bl
840bf2e8 8d77e8 lea esi,[edi-18h]
840bf2eb 8975d0 mov dword ptr [ebp-30h],esi
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch]
uf nt!ObpQueryNameString
nt!ObpQueryNameString:
840bf2c3 6a44 push 44h
840bf2c5 68f0c3e583 push offset nt! ?? ::FNODOBFM::`string'+0x1790 (83e5c3f0)
840bf2ca e83932dfff call nt!_SEH_prolog4 (83e72508)
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8]
840bf2d2 c745d8010000c0 mov dword ptr [ebp-28h],0C0000001h
840bf2d9 33db xor ebx,ebx
840bf2db 895dc4 mov dword ptr [ebp-3Ch],ebx
840bf2de 895de0 mov dword ptr [ebp-20h],ebx
840bf2e1 c645e701 mov byte ptr [ebp-19h],1
840bf2e5 885de6 mov byte ptr [ebp-1Ah],bl
840bf2e8 8d77e8 lea esi,[edi-18h]
840bf2eb 8975d0 mov dword ptr [ebp-30h],esi
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] uf nt!ObpQueryNameString
nt!ObpQueryNameString:
840bf2c3 6a44 push 44h
840bf2c5 68f0c3e583 push offset nt! ?? ::FNODOBFM::`string'+0x1790 (83e5c3f0)
840bf2ca e83932dfff call nt!_SEH_prolog4 (83e72508)
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8]
840bf2d2 c745d8010000c0 mov dword ptr [ebp-28h],0C0000001h
840bf2d9 33db xor ebx,ebx
840bf2db 895dc4 mov dword ptr [ebp-3Ch],ebx
840bf2de 895de0 mov dword ptr [ebp-20h],ebx
840bf2e1 c645e701 mov byte ptr [ebp-19h],1
840bf2e5 885de6 mov byte ptr [ebp-1Ah],bl
840bf2e8 8d77e8 lea esi,[edi-18h]
840bf2eb 8975d0 mov dword ptr [ebp-30h],esi
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] uf nt!ObpQueryNameString
nt!ObpQueryNameString:
840bf2c3 6a44 push 44h
840bf2c5 68f0c3e583 push offset nt! ?? ::FNODOBFM::`string'+0x1790 (83e5c3f0)
840bf2ca e83932dfff call nt!_SEH_prolog4 (83e72508)
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8]
840bf2d2 c745d8010000c0 mov dword ptr [ebp-28h],0C0000001h
840bf2d9 33db xor ebx,ebx
840bf2db 895dc4 mov dword ptr [ebp-3Ch],ebx
840bf2de 895de0 mov dword ptr [ebp-20h],ebx
840bf2e1 c645e701 mov byte ptr [ebp-19h],1
840bf2e5 885de6 mov byte ptr [ebp-1Ah],bl
840bf2e8 8d77e8 lea esi,[edi-18h]
840bf2eb 8975d0 mov dword ptr [ebp-30h],esi
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] 上述代码有关esi的整理如下:
------------------------------------------------------------------------------------------
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8] ;edi=arg1
840bf2e8 8d77e8 lea esi,[edi-18h] ;esi=[arg1-18h]
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ;eax=*(byte*)(esi+0c) error
------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8] ;edi=arg1
840bf2e8 8d77e8 lea esi,[edi-18h] ;esi=[arg1-18h]
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ;eax=*(byte*)(esi+0c) error
------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8] ;edi=arg1
840bf2e8 8d77e8 lea esi,[edi-18h] ;esi=[arg1-18h]
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ;eax=*(byte*)(esi+0c) error
------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------
840bf2cf 8b7d08 mov edi,dword ptr [ebp+8] ;edi=arg1
840bf2e8 8d77e8 lea esi,[edi-18h] ;esi=[arg1-18h]
840bf2ee 0fb6460c movzx eax,byte ptr [esi+0Ch] ;eax=*(byte*)(esi+0c) error
------------------------------------------------------------------------------------------
这说明,导致esi+0ch崩溃的是因为arg1=1 。通过查看调用栈可知:arg1 是 nt!ObQueryNameString 传递给 nt!ObpQueryNameString 的第一个参数。
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
这说明,导致esi+0ch崩溃的是因为arg1=1 。通过查看调用栈可知:arg1 是 nt!ObQueryNameString 传递给 nt!ObpQueryNameString 的第一个参数。
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
这说明,导致esi+0ch崩溃的是因为arg1=1 。通过查看调用栈可知:arg1 是 nt!ObQueryNameString 传递给 nt!ObpQueryNameString 的第一个参数。
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
这说明,导致esi+0ch崩溃的是因为arg1=1 。通过查看调用栈可知:arg1 是 nt!ObQueryNameString 传递给 nt!ObpQueryNameString 的第一个参数。
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18 98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
uf nt!ObQueryNameString
nt!ObQueryNameString:
840bfa62 8bff mov edi,edi
840bfa64 55 push ebp
840bfa65 8bec mov ebp,esp
840bfa67 6a00 push 0
840bfa69 ff7514 push dword ptr [ebp+14h] ;
840bfa6c ff7510 push dword ptr [ebp+10h] ;
840bfa6f ff750c push dword ptr [ebp+0Ch] ;
840bfa72 ff7508 push dword ptr [ebp+8] ;arg1:
840bfa75 e849f8ffff call nt!ObpQueryNameString (840bf2c3)
840bfa7a 5d pop ebp
840bfa7b c21000 ret 10h
分析
nt!ObQueryNameString
传给
nt!ObpQueryNameString的第一个参数是从哪里来的?都做了什么操作?
从汇编代码中很容易看出,传递给
nt!ObpQueryNameString的第一个参数也是
nt!ObQueryNameString的第一个参数,而且 nt!ObQueryNameString 未修改参数1.
补充:
ObQueryNameString 函数:返回指定内核对象的名称。
uf nt!ObQueryNameString
nt!ObQueryNameString:
840bfa62 8bff mov edi,edi
840bfa64 55 push ebp
840bfa65 8bec mov ebp,esp
840bfa67 6a00 push 0
840bfa69 ff7514 push dword ptr [ebp+14h] ;
840bfa6c ff7510 push dword ptr [ebp+10h] ;
840bfa6f ff750c push dword ptr [ebp+0Ch] ;
840bfa72 ff7508 push dword ptr [ebp+8] ;arg1:
840bfa75 e849f8ffff call nt!ObpQueryNameString (840bf2c3)
840bfa7a 5d pop ebp
840bfa7b c21000 ret 10h
分析
nt!ObQueryNameString
传给
nt!ObpQueryNameString的第一个参数是从哪里来的?都做了什么操作?
从汇编代码中很容易看出,传递给
nt!ObpQueryNameString的第一个参数也是
nt!ObQueryNameString的第一个参数,而且 nt!ObQueryNameString 未修改参数1.
补充:
ObQueryNameString 函数:返回指定内核对象的名称。
uf nt!ObQueryNameString
nt!ObQueryNameString:
840bfa62 8bff mov edi,edi
840bfa64 55 push ebp
840bfa65 8bec mov ebp,esp
840bfa67 6a00 push 0
840bfa69 ff7514 push dword ptr [ebp+14h] ;
840bfa6c ff7510 push dword ptr [ebp+10h] ;
840bfa6f ff750c push dword ptr [ebp+0Ch] ;
840bfa72 ff7508 push dword ptr [ebp+8] ;arg1:
840bfa75 e849f8ffff call nt!ObpQueryNameString (840bf2c3)
840bfa7a 5d pop ebp
840bfa7b c21000 ret 10h
分析
nt!ObQueryNameString
传给
nt!ObpQueryNameString的第一个参数是从哪里来的?都做了什么操作?
从汇编代码中很容易看出,传递给
nt!ObpQueryNameString的第一个参数也是
nt!ObQueryNameString的第一个参数,而且 nt!ObQueryNameString 未修改参数1.
补充:
ObQueryNameString 函数:返回指定内核对象的名称。
NTKERNELAPI NTSTATUS ObQueryNameString(
PVOID Object,
POBJECT_NAME_INFORMATION ObjectNameInfo,
ULONG Length,
PULONG ReturnLength
);
参数
Object:内核对象的指针,该值不能为NULL.
ObjectNameInfo:由用户提供的存放返回值得缓冲区,若不知大小则可以为NULL,由ReturnLength返回需要的缓冲区大小。
NTKERNELAPI NTSTATUS ObQueryNameString(
PVOID Object,
POBJECT_NAME_INFORMATION ObjectNameInfo,
ULONG Length,
PULONG ReturnLength
);
参数
Object:内核对象的指针,该值不能为NULL.
ObjectNameInfo:由用户提供的存放返回值得缓冲区,若不知大小则可以为NULL,由ReturnLength返回需要的缓冲区大小。
参数
Object:内核对象的指针,该值不能为NULL.
ObjectNameInfo:由用户提供的存放返回值得缓冲区,若不知大小则可以为NULL,由ReturnLength返回需要的缓冲区大小。
[招生]科锐逆向工程师培训(2024年11月15日实地,远程教学同时开班, 第51期)
最后于 2018-6-2 09:26
被Koorey编辑
,原因: 上传了当时的dump文件
上传的附件: