首页
社区
课程
招聘
[原创]windbg 分析pchunter导致的蓝屏
发表于: 2018-5-29 23:40 7122

[原创]windbg 分析pchunter导致的蓝屏

2018-5-29 23:40
7122

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)

  1. BugCheckCode:PAGE_FAULT_IN_NONPAGED_AREA 是微软定义的Bug编码,其值为0x00000050.下面英文说的是,系统使用了无效的系统内存导致触发异常,且该异常没能被处理。可能是内存地址被破坏了或被释放了。
  2. 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
  1. BUILD_VERSION_STRING:指出了运行的系统版本信息。
  2. BUGCHECK_P1~4:和BUG概述中的基本一致。
  3. READ_ADDRESS:读地址为0xfffffff5的内存。
  4. FAULTING_IP:导致Bug的地址。即该bug发生在nt!ObpQueryNameString+2b处,该地址的需要执行的指令是
    movzx   eax,byte ptr [esi+0Ch]
  5. DEFAULT_BUCKET_ID:故障类型。这里指出是win7驱动发生故障。
  6. 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
  1. TRAP_FRAME :陷阱帧,是一个nt!_KTRAP_FRAME结构体。 KTRAP_FRAME 用于在系统处理异常或中断期间,保存CPU的寄存器的内容。 KTRAP_FRAME结构通常分配在线程的内核模式堆栈中。陷阱帧的一小部分由CPU填充,作为其自身中断和异常处理的一部分,陷阱帧的其余部分由Windows提供的软件异常和中断处理程序 创建 (例如KiTrap0E()、KiPageFault KiInterruptDispatch 等函数)。
  2. 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
...
  1. 前面5个函数是系统用来保存现场(寄存器)以及检测崩溃信息。
  2. 从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
  1. BUILD_VERSION_STRING:指出了运行的系统版本信息。
  2. BUGCHECK_P1~4:和BUG概述中的基本一致。
  3. READ_ADDRESS:读地址为0xfffffff5的内存。
  4. FAULTING_IP:导致Bug的地址。即该bug发生在nt!ObpQueryNameString+2b处,该地址的需要执行的指令是
    movzx   eax,byte ptr [esi+0Ch]
  5. DEFAULT_BUCKET_ID:故障类型。这里指出是win7驱动发生故障。
  6. 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
  1. BUILD_VERSION_STRING:指出了运行的系统版本信息。
  2. BUGCHECK_P1~4:和BUG概述中的基本一致。
  3. READ_ADDRESS:读地址为0xfffffff5的内存。
  4. FAULTING_IP:导致Bug的地址。即该bug发生在nt!ObpQueryNameString+2b处,该地址的需要执行的指令是
    movzx   eax,byte ptr [esi+0Ch]
  5. DEFAULT_BUCKET_ID:故障类型。这里指出是win7驱动发生故障。
  6. 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
  1. TRAP_FRAME :陷阱帧,是一个nt!_KTRAP_FRAME结构体。 KTRAP_FRAME 用于在系统处理异常或中断期间,保存CPU的寄存器的内容。 KTRAP_FRAME结构通常分配在线程的内核模式堆栈中。陷阱帧的一小部分由CPU填充,作为其自身中断和异常处理的一部分,陷阱帧的其余部分由Windows提供的软件异常和中断处理程序 创建 (例如KiTrap0E()、KiPageFault KiInterruptDispatch 等函数)。
  2. 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
  1. TRAP_FRAME :陷阱帧,是一个nt!_KTRAP_FRAME结构体。 KTRAP_FRAME 用于在系统处理异常或中断期间,保存CPU的寄存器的内容。 KTRAP_FRAME结构通常分配在线程的内核模式堆栈中。陷阱帧的一小部分由CPU填充,作为其自身中断和异常处理的一部分,陷阱帧的其余部分由Windows提供的软件异常和中断处理程序 创建 (例如KiTrap0E()、KiPageFault KiInterruptDispatch 等函数)。
  2. 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
...
  1. 前面5个函数是系统用来保存现场(寄存器)以及检测崩溃信息。
  2. 从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
...
  1. 前面5个函数是系统用来保存现场(寄存器)以及检测崩溃信息。
  2. 从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的整理如下:
上述代码有关esi的整理如下:
上述代码有关esi的整理如下:
上述代码有关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文件
上传的附件:
收藏
免费 1
支持
分享
最新回复 (5)
雪    币: 171
活跃值: (519)
能力值: ( LV4,RANK:50 )
在线值:
发帖
回帖
粉丝
2
楼主没有dmp么??
2018-6-1 22:23
0
雪    币: 347
活跃值: (57)
能力值: ( LV4,RANK:45 )
在线值:
发帖
回帖
粉丝
3
有dump,我找找,看还能找到不
2018-6-2 09:15
0
雪    币: 347
活跃值: (57)
能力值: ( LV4,RANK:45 )
在线值:
发帖
回帖
粉丝
4
dump文件已上传,分析dump文件和双机调试会有写不同。
2018-6-2 09:29
0
雪    币: 171
活跃值: (519)
能力值: ( LV4,RANK:50 )
在线值:
发帖
回帖
粉丝
5
感谢楼主!!!!顶啊!!!!
2018-6-2 11:03
0
雪    币: 2694
活跃值: (80)
能力值: ( LV2,RANK:15 )
在线值:
发帖
回帖
粉丝
6
2018-6-3 12:11
0
游客
登录 | 注册 方可回帖
返回
//