當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

windbg 分析pchunter导致的蓝屏

發布時間：2023/12/9 编程问答 30 豆豆

生活随笔收集整理的這篇文章主要介紹了 windbg 分析pchunter导致的蓝屏小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

轉載自：https://bbs.pediy.com/thread-227076.htm

環境

被調試機：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)

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導致的。

追蹤崩潰源頭

查看?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]

上述代碼有關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

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

這說明，導致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

查看 nt!ObQueryNameString~ 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 函數：返回指定內核對象的名稱。

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返回需要的緩沖區大小。

Length：?緩沖區的字節數.該值必須包括OBJECT_NAME_INFORMATION結構和對象名稱的長度。根據DDK上推薦該值為1024?

ReturnLength：返回的數據的大小。此值包括OBJECT_NAME_INFORMATION結構和對象名稱的長度?

接下來分nt!ObQueryNameString 的參數1的來歷。?

98926a48?8bc76887?00000001?98926a6c?00000050?nt!ObQueryNameString+0x18

98926af4?8bc77245?03fc016c?001ffeb4?00000000?PCHunter32aq+0x52887

98926b2c?8bc772d3?00000010?0000013c?98926bfc?PCHunter32aq+0x53245

使用 ub 8bc77245 找到 nt!ObQueryNameString 的父函數的入口地址：

1:?kd>?ub?8bc77245

PCHunter32aq+0x53233:

8bc77233?7230????????????jb??????PCHunter32aq+0x53265?(8bc77265)

8bc77235?03f0????????????add?????esi,eax

8bc77237?2bf8????????????sub?????edi,eax

8bc77239?83ff0c??????????cmp?????edi,0Ch

8bc7723c?7227????????????jb??????PCHunter32aq+0x53265?(8bc77265)

8bc7723e?57??????????????push????edi

8bc7723f?56??????????????push????esi

8bc77240?e84bf5ffff??????call????PCHunter32aq+0x52790?(8bc76790)//8bc76790為nt!ObQueryNameString的父函數入口

把 PCHunter32aq+0x52790 (8bc76790)記作 function_1。用uf? PCHunter32aq+0x52790命令查看function_1的匯編代碼，這里主要關注?PCHunter32aq+0x52790 ~PCHunter32aq+0x52887之間的代碼，分析 function_1 在調用nt!ObQueryNameString函數前對 nt!ObQueryNameString函數的參數1做了哪些操作？

由于 PCHunter32aq+0x52790~PCHunter32aq+0x5282c之間的代碼沒有對 nt!ObQueryNameString函數的參數1做操作，所以下文的代碼省略了該部分內容

PCHunter32aq+0x5282c:

8bc7682c?57??????????????push????edi

8bc7682d?8d3c00??????????lea?????edi,[eax+eax]

8bc76830?e8fb780200??????call????PCHunter32aq+0x7a130?(a287e130)????;Pchunter獲取一些內核信息

8bc76835?8945ec??????????mov?????dword?ptr?[ebp-14h],eax????????????;ebp-14h=PCHunter32aq+0x7a130返回的緩沖區地址，是一個數組

8bc76838?85c0????????????test????eax,eax

8bc7683a?0f84c8000000????je??????PCHunter32aq+0x52908?(8bc76908)??Branch

PCHunter32aq+0x52840:

8bc76840?8b08????????????mov?????ecx,dword?ptr?[eax]

8bc76842?894df0??????????mov?????dword?ptr?[ebp-10h],ecx

8bc76845?c745f400000000??mov?????dword?ptr?[ebp-0Ch],0

8bc7684c?85c9????????????test????ecx,ecx

8bc7684e?0f849f000000????je??????PCHunter32aq+0x528f3?(8bc768f3)??Branch

PCHunter32aq+0x52854:

8bc76854?56??????????????push????esi

8bc76855?8d700c??????????lea?????esi,[eax+0Ch]

8bc76858?eb06????????????jmp?????PCHunter32aq+0x52860?(8bc76860)??Branch

;------------------------------

;分析1

;8bc76840?8b08????????????mov?????ecx,dword?ptr?[eax]

;8bc76855?8d700c??????????lea?????esi,[eax+0Ch]

;通過這兩處推測?eax?為一個結構體

;------------------------------

PCHunter32aq+0x52860:

8bc76860?0fb656fc????????movzx???edx,byte?ptr?[esi-4]

8bc76864?3b55f8??????????cmp?????edx,dword?ptr?[ebp-8]

8bc76867?7576????????????jne?????PCHunter32aq+0x528df?(8bc768df)??Branch

PCHunter32aq+0x52869:

8bc76869?8b06????????????mov?????eax,dword?ptr?[esi]

8bc7686b?85c0????????????test????eax,eax

8bc7686d?7470????????????je??????PCHunter32aq+0x528df?(8bc768df)??Branch

PCHunter32aq+0x5286f:

8bc7686f?8b4004??????????mov?????eax,dword?ptr?[eax+4]

8bc76872?85c0????????????test????eax,eax????????;只判斷了eax=0的情況，而當前情況是eax=1，所以導致崩潰

8bc76874?7469????????????je??????PCHunter32aq+0x528df?(8bc768df)??Branch

;------------------------------

;分析2

;EAX=[EBP-14H]

;ESI=&[EAX+0CH]?ESI存放一個指針，這個指針指向一個結構體,這個結構體就是數組單個元素的結構體

;@$t4:arg1?LPVOID?object

;r?@$t0=EBP

;r?@$t1=ESI

;r?@$t2=EBP-8=00000007?//通過內存查看到該處的值為7

;.if(?by(@$t1-4)==7?)

;{

;????r?@$t3=poi(@$t1);

;????.if(@$t3!=0)

;????{

;???????r?@$t4=poi(@$t3+4);

;???????dd?@$t3?L4;

;????????r?@$t4;

;????}

;}

;------------------------------

PCHunter32aq+0x52876:

8bc76876?8d4dc8??????????lea?????ecx,[ebp-38h]

8bc76879?51??????????????push????ecx????????????????????;?arg4:ReturnLength

8bc7687a?6a50????????????push????50h????????????????????;?arg3:Length

8bc7687c?8d9578ffffff????lea?????edx,[ebp-88h]

8bc76882?52??????????????push????edx????????????????????;?arg2:ObjectNameInfo

8bc76883?50??????????????push????eax????????????????????;?arg1:object

8bc76884?ff55e8??????????call????dword?ptr?[ebp-18h]????;?call?nt!ObpQueryNameString

8bc76887?85c0????????????test????eax,eax

8bc76889?7554????????????jne?????PCHunter32aq+0x528df?(8bc768df)??Branch

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

....該處代碼與nt!ObQueryNameString的參數1無關

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

PCHunter32aq+0x528df:

8bc768df?8b45f4??????????mov?????eax,dword?ptr?[ebp-0Ch]

8bc768e2?40??????????????inc?????eax

8bc768e3?83c610??????????add?????esi,10h

8bc768e6?8945f4??????????mov?????dword?ptr?[ebp-0Ch],eax

8bc768e9?3b45f0??????????cmp?????eax,dword?ptr?[ebp-10h]

8bc768ec?0f826effffff????jb??????PCHunter32aq+0x52860?(8bc76860)??Branch

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

;分析3

;8bc76842?894DF0??????????MOV?????DWORD?PTR?[EBP-10H],ECX

;8bc768E9?3B45F0??????????CMP?????EAX,DWORD?PTR?[EBP-10H]

;通過這兩處判斷?EBP-10H?為一個?DWORD?值，

;8bc76860?與?8bc768E2?構成了一個循環

;而?EBP-0CH?為循環計數器

;而?EBP-10H?就是這個循環的最大次數?=>?推測?EBP-14H?為一個數組類型?而?EBP-10H?為該數組的元素個數

;8bc768E3?83C610??????????ADD?????ESI,10H?=>?推測?數組中的單個元素的大小為?10H

;@$t5=EAX=[ebp-0ch]=0?初始值為0;?此時為?61H

;查看數組中第61H個元素的內容

;數組的起始地址為?ESI=?[EAX+0CH]

分析到這里function_1在調用?call? ? dword ptr [ebp-18h]; call nt!ObpQueryNameString時只檢驗了參數1是否為0，并沒有校驗是否為有效地址。

但我認為導致 nt!ObpQueryNameString的參數1位“1”的原因應該是在調用PCHunter32aq+0x7a130函數時造成的。有時間再研究吧，暫時到這里吧。

1 2	8bc76830?e8fb780200??????call????PCHunter32aq+0x7a130?(a287e130)????;獲取一些內核信息 8bc76835?8945ec??????????mov?????dword?ptr?[ebp-14h],eax????????????;ebp-14h=獲取的內核信息地址

dump文件下載：050718-19328-01.dmp?（148.47kb，18次下載）

總結

以上是生活随笔為你收集整理的windbg 分析pchunter导致的蓝屏的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：串行线路上传输数据报的非标准协议：SLI
下一篇：网易云分析