首页
社区
课程
招聘
问答 CTF 排行榜 知识库 工具下载 峰会 看雪商城 证书查询
  1. 社区
  2. 软件逆向
    3. 发新帖
1
[原创]windbg 分析pchunter导致的蓝屏
发表于: 2018-5-29 23:40 7369

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

Koorey 活跃值
2018-5-29 23:40
7369

BUG的详情

被调试机：7600.16385.x86fre.win7_rtm.090713-1255
调试机：win10,
调试工具：windbg proview
导致蓝屏的软件：pchunter
视频：https://www.youtube.com/watch?v=8tBRtlvapWU
运行pchunter，点击“网络”卡片页时，系统就会蓝屏。
对第一次蓝屏捕捉到的信息进行分析。这里只列出了一些重点信息及描述。
BUG的概述
1
2
3
4
5
6
7
8
9
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
2
3
4
5
6
7
8
9
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的详情

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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相关的进程。
陷阱帧

1
2
3
4
5
6
7
8
9
10
11
12
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
调用堆栈
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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导致的。

追踪崩溃源头
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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相关的进程。
陷阱帧
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
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相关的进程。
陷阱帧
1
2
3
4
5
6
7
8
9
10
11
12
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
1
2
3
4
5
6
7
8
9
10
11
12
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
调用堆栈
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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导致的。

追踪崩溃源头
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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的 反汇编：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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的整理如下：
1
2
3
4
5
------------------------------------------------------------------------------------------
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
------------------------------------------------------------------------------------------
1
2
3
4
5
------------------------------------------------------------------------------------------
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
------------------------------------------------------------------------------------------
1
2
3
4
5
------------------------------------------------------------------------------------------
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
------------------------------------------------------------------------------------------
1
2
3
4
5
------------------------------------------------------------------------------------------
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 的第一个参数。
1
2
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 的第一个参数。
1
2
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 的第一个参数。
1
2
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 的第一个参数。
1
2
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
1
2
98926a2c 840bfa7a 00000001 98926a6c 00000050 nt!ObpQueryNameString+0x2b
98926a48 8bc76887 00000001 98926a6c 00000050 nt!ObQueryNameString+0x18
1
2
3
4
5
6
7
8
9
10
11
12
13
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 函数：返回指定内核对象的名称。
1
2
3
4
5
6
7
8
9
10
11
12
13
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 函数：返回指定内核对象的名称。
1
2
3
4
5
6
7
8
9
10
11
12
13
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 函数：返回指定内核对象的名称。
1
2
3
4
5
6
7
NTKERNELAPI NTSTATUS ObQueryNameString(
  PVOID                    Object,
  POBJECT_NAME_INFORMATION ObjectNameInfo,
  ULONG                    Length,
  PULONG                   ReturnLength
);<span style="color:rgb(0, 0, 0); font-family:none; font-size:15px;">
</span>
参数
Object：内核对象的指针，该值不能为NULL.
ObjectNameInfo：由用户提供的存放返回值得缓冲区，若不知大小则可以为NULL，由ReturnLength返回需要的缓冲区大小。
1
2
3
4
5
6
7
NTKERNELAPI NTSTATUS ObQueryNameString(
  PVOID                    Object,
  POBJECT_NAME_INFORMATION ObjectNameInfo,
  ULONG                    Length,
  PULONG                   ReturnLength
);<span style="color:rgb(0, 0, 0); font-family:none; font-size:15px;">
</span>
参数
Object：内核对象的指针，该值不能为NULL.
ObjectNameInfo：由用户提供的存放返回值得缓冲区，若不知大小则可以为NULL，由ReturnLength返回需要的缓冲区大小。
参数
Object：内核对象的指针，该值不能为NULL.
ObjectNameInfo：由用户提供的存放返回值得缓冲区，若不知大小则可以为NULL，由ReturnLength返回需要的缓冲区大小。

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课

最后于 2018-6-2 09:26 被Koorey编辑 ，原因： 上传了当时的dump文件
上传的附件：
收藏
免费 ・1
支持
分享
赞赏记录
参与人
雪币
留言
时间
PLEBFE
为你点赞~
2023-2-5 02:25
最新回复 (5)
Lthis
雪    币： 180
活跃值： (584)
能力值： ( LV4，RANK：50 )
在线值：
发帖
回帖
粉丝
私信
2 楼
楼主没有dmp么？？
2018-6-1 22:23
0
Koorey
雪    币： 347
活跃值： (57)
能力值： ( LV4，RANK：45 )
在线值：
发帖
回帖
粉丝
私信
3 楼
有dump，我找找，看还能找到不
2018-6-2 09:15
0
Koorey
雪    币： 347
活跃值： (57)
能力值： ( LV4，RANK：45 )
在线值：
发帖
回帖
粉丝
私信
4 楼
dump文件已上传，分析dump文件和双机调试会有写不同。
2018-6-2 09:29
0
Lthis
雪    币： 180
活跃值： (584)
能力值： ( LV4，RANK：50 )
在线值：
发帖
回帖
粉丝
私信
5 楼
感谢楼主！！！！顶啊！！！！
2018-6-2 11:03
0
BlackJZero
雪    币： 2694
活跃值： (80)
能力值： ( LV2，RANK：15 )
在线值：
发帖
回帖
粉丝
私信
6 楼
2018-6-3 12:11
0
游客
登录 | 注册 方可回帖
回帖 表情 雪币赚取及消费
高级回复
返回

账号登录
验证码登录

忘记密码？
没有账号？立即免费注册
我已同意 《看雪服务条款》 《看雪课程免责声明》 《看雪隐私政策》