當(dāng)前位置：首頁 > 科技 > 軟件

記一次 .NET某工控WPF程序被人惡搞的卡死分析

來源：責(zé)編：時間：2024-05-29 08:57:02 133觀看

導(dǎo)讀一、背景1. 講故事這一期程序故障除了做原理分析，還順帶吐槽一下，熟悉我的朋友都知道我分析dump是免費的，但免費不代表可以濫用我的寶貴時間，我不知道有些人故意惡搞卡死是想干嘛，不得而知，希望后面類似的事情越來越少吧！廢

一、背景

1. 講故事

這一期程序故障除了做原理分析，還順帶吐槽一下，熟悉我的朋友都知道我分析dump是免費的，但免費不代表可以濫用我的寶貴時間，我不知道有些人故意惡搞卡死是想干嘛，不得而知，希望后面類似的事情越來越少吧！廢話不多說，我們來看看是如何被惡搞的。

二、WinDbg 分析

1. 程序是如何卡死的

既然是窗體程序自然就是看主線程，我們使用 k 命令即可。

0:000> k  # Child-SP          RetAddr               Call Site00 00000036`e1f7da18 00007ffe`70bf30ce     ntdll!NtWaitForSingleObject+0x1401 00000036`e1f7da20 00007ffd`eff74910     KERNELBASE!WaitForSingleObjectEx+0x8e...05 (Inline Function) --------`--------     coreclr!CLREventBase::Wait+0x12 [D:/a/_work/1/s/src/coreclr/vm/synch.cpp @ 412] 06 00000036`e1f7db20 00007ffd`f00c9afa     coreclr!Thread::WaitSuspendEventsHelper+0xc8 [D:/a/_work/1/s/src/coreclr/vm/threadsuspend.cpp @ 4626] 07 (Inline Function) --------`--------     coreclr!Thread::WaitSuspendEvents+0x8 [D:/a/_work/1/s/src/coreclr/vm/threadsuspend.cpp @ 4663] 08 00000036`e1f7dbe0 00007ffd`f0009c80     coreclr!Thread::RareEnablePreemptiveGC+0x7d99a [D:/a/_work/1/s/src/coreclr/vm/threadsuspend.cpp @ 2414] 09 (Inline Function) --------`--------     coreclr!Thread::EnablePreemptiveGC+0x16 [D:/a/_work/1/s/src/coreclr/vm/threads.h @ 2044] 0a 00000036`e1f7dc20 00007ffd`f0075d10     coreclr!Thread::RareDisablePreemptiveGC+0xc8 [D:/a/_work/1/s/src/coreclr/vm/threadsuspend.cpp @ 2156] 0b 00000036`e1f7dca0 00007ffd`f0096a5f     coreclr!JIT_ReversePInvokeEnterRare2+0x18 [D:/a/_work/1/s/src/coreclr/vm/jithelpers.cpp @ 5462] 0c 00000036`e1f7dcd0 00007ffd`907afe09     coreclr!JIT_ReversePInvokeEnterTrackTransitions+0xaf [D:/a/_work/1/s/src/coreclr/vm/jithelpers.cpp @ 5509] 0d 00000036`e1f7dd00 00007ffe`72e0e858     0x00007ffd`907afe090e 00000036`e1f7dd80 00007ffe`72e0e3dc     user32!UserCallWinProcCheckWow+0x2f80f 00000036`e1f7df10 00007ffe`72e20c93     user32!DispatchClientMessage+0x9c10 00000036`e1f7df70 00007ffe`730f0e64     user32!_fnDWORD+0x3311 00000036`e1f7dfd0 00007ffe`70b31104     ntdll!KiUserCallbackDispatcherContinue12 00000036`e1f7e058 00007ffe`72e21c0e     win32u!NtUserGetMessage+0x1413 00000036`e1f7e060 00007ffe`711e28f2     user32!GetMessageW+0x2e...1d 00000036`e1f7e460 00007ffd`f009ba53     xxx!xxx.App.Main+0x5e...2a 00000036`e1f7f140 00007ffe`4cd4e1e6     hostfxr!execute_app+0x2fa [D:/a/_work/1/s/src/native/corehost/fxr/fx_muxer.cpp @ 145] ...34 00000036`e1f7f890 00000000`00000000     ntdll!RtlUserThreadStart+0x21

從卦中的調(diào)用棧可以看到，主線程通過 GetMessageW 從消息隊列中拿到了數(shù)據(jù)，在處理時被 coreclr 押解到 WaitSuspendEventsHelper 處等待一個event事件，接下來看下這個方法的源碼到底是怎么寫的？簡化后如下：

BOOL Thread::WaitSuspendEventsHelper(void){    if (m_State & TS_DebugSuspendPending)    {        ThreadState oldState = m_State;        while (oldState & TS_DebugSuspendPending)        {            ThreadState newState = (ThreadState)(oldState | TS_SyncSuspended);            if (InterlockedCompareExchange((LONG*)&m_State, newState, oldState) == (LONG)oldState)            {                result = m_DebugSuspendEvent.Wait(INFINITE, FALSE);                break;            }            oldState = m_State;        }    }    return result != WAIT_OBJECT_0;}

從上面的代碼可以明顯的看到當(dāng)前Thread 處于 TS_DebugSuspendPending 狀態(tài)，從名字上看貌似和調(diào)試有關(guān)，接下來查下這個枚舉的注解。

enum ThreadState{    TS_DebugSuspendPending = 0x00000008,    // Is the debugger suspending threads?}

從注解看是因為調(diào)試器阻塞了這個線程，我去，哪里來的調(diào)試器呢？這引起了我的巨大興趣。。。

2. 哪里來的調(diào)試器

我剛開始是抱有巨大的善意，我以為他的程序被人惡意注入導(dǎo)致卡死，但分析下來我還是太單純了，繼續(xù)往下看吧，既然有調(diào)試器，一般來說PEB.BeingDebugged=Yes狀態(tài)，命令的輸出結(jié)果也得到了證實。

0:000> !pebPEB at 00000036e1c11000    ...    BeingDebugged:            Yes    ...                    Base TimeStamp                     Module            7ff7f5230000 65310000 Oct 19 18:08:00 2023 G:/xxx/C#/Projects/NugetApplications/Applications/xxx/bin/Debug/net6.0-windows/xxx.exe            ...

我以為到這里就可以告訴朋友答案，你的程序可能被人惡意注入了，但眼尖的我發(fā)現(xiàn)了一點異常，他的 xxx.exe 啟動目錄怎么會有 /bin/Debug/net6.0-windows/ 呢？很明顯這是用 VS 直接跑起來的呀。。。。

3. 真的是 VS 跑起來的嗎

首先大家要知道 Visual Studio 是托管調(diào)試器，托管調(diào)試器在調(diào)試程序的時候會在 coreclr 層面設(shè)置一個全局變量 g_CORDebuggerControlFlags=0x0200，這也是 Debugger.IsAttached 的底層判斷依據(jù)，不相信的朋友可以看下這個方法的底層實現(xiàn)：

FCIMPL0(FC_BOOL_RET, DebugDebugger::IsDebuggerAttached){    CORDebuggerAttached();}inline bool CORDebuggerAttached(){    return (g_CORDebuggerControlFlags & DBCF_ATTACHED);}enum DebuggerControlFlag{    DBCF_ATTACHED                   = 0x0200,};

有了這些基礎(chǔ)知識之后，接下來就可以用 x 命令去驗證下。

看到上面的答案基本就可以實錘了，有些朋友可能還是不大相信，我們可以這樣看，VisualStudio 是 WPF 寫的，如果用 VS 來調(diào)試，那么線程棧里面應(yīng)該會有很多類似的 VisualStudio 字符串。

從卦中看，你說正常發(fā)布的程序怎么可能會有 9 個 Microsoft.VisualStudio.DesignTools 字符串呢？

4. 這個dump是如何生成的

這個問題我相信可能有一些朋友會比較疑惑，其實沒什么疑惑的，Visual Studio 有生成Dump的功能，操作步驟為：Debug -> Save Dump As... , 接下來通過一個小例子觀察一下。

internal class Program    {        static void Main(string[] args)        {            Console.WriteLine($"托管調(diào)試器：{Debugger.IsAttached}");            Console.WriteLine($"非托管調(diào)試器：{IsDebuggerPresent()}");            Console.ReadLine();        }        [DllImport("kernel32.dll")]        static extern bool IsDebuggerPresent();    }

調(diào)試起來后，截圖如下：

最后打開生成好的 Dump 文件，使用 kc 觀察主線程的輸出：

0:000> kc # Call Site00 ntdll!NtWaitForSingleObject01 KERNELBASE!WaitForSingleObjectEx02 coreclr!CLREventWaitHelper203 coreclr!CLREventWaitHelper04 coreclr!CLREventBase::WaitEx05 coreclr!CLREventBase::Wait06 coreclr!Thread::WaitSuspendEventsHelper07 coreclr!Thread::WaitSuspendEvents08 coreclr!Thread::RareEnablePreemptiveGC09 coreclr!Thread::EnablePreemptiveGC0a coreclr!Thread::RareDisablePreemptiveGC0b coreclr!Thread::DisablePreemptiveGC...19 ConsoleApp4!ConsoleApp4.Program.Main...30 ntdll!RtlUserThreadStart

從卦中看，正是停留在 WaitSuspendEventsHelper 函數(shù)里，一摸一樣，徹底被360°無死角的證實......

三、總結(jié)

這是一次人為的故意惡搞，大概率就是想看下我到底是騾子是馬。我分析的結(jié)果對他和他所在的公司來說沒有任何價值，只能白白的浪費我的時間，真是分析多了，什么樣的人都能遇到，謹(jǐn)以此文告知后來者，免費但請不要濫用！

本文鏈接：http://www.tebozhan.com/showinfo-26-91362-0.html記一次 .NET某工控WPF程序被人惡搞的卡死分析

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：每個前端開發(fā)人員都應(yīng)該了解的軟件工程原理

下一篇：面試官：你能實現(xiàn)一個 JavaScript 模板引擎嗎？

標(biāo)簽：

熱門焦點

直屏旗艦來了 iQOO 12和K70 Pro同臺競技

旗艦機(jī)基本上使用的都是雙曲面屏幕，這就讓很多喜歡直屏的愛好者在苦等一款直屏旗艦，這次，你們等到了。據(jù)博主數(shù)碼閑聊站帶來的最新爆料稱，Redmi下代旗艦K70 Pro和iQOO 12兩款手
紅魔電競平板評測：大屏幕硬實力

前言：三年的疫情因為要上網(wǎng)課的原因激活了平板市場，如今網(wǎng)課的時代已經(jīng)過去，大家的生活都恢復(fù)到了正軌，這也就意味著，真正考驗平板電腦生存的環(huán)境來了。也就是面對著這種殘酷的
6月安卓手機(jī)性價比榜：Note 12 Turbo斷層式碾壓

6月份有一個618，雖然這是京東周年慶的日子，但別的電商也都不約而同的跟進(jìn)了，反正促銷沒壞處，廠商和用戶都能滿意。618期間一些產(chǎn)品也出現(xiàn)了歷史低價，那么各個價位段的產(chǎn)品性價比
一年經(jīng)驗在二線城市面試后端的經(jīng)驗分享

忠告這篇文章只適合2年內(nèi)工作經(jīng)驗、甚至沒有工作經(jīng)驗的朋友閱讀。如果你是2年以上工作經(jīng)驗，請果斷劃走，對你沒啥幫助~主人公這篇文章內(nèi)容來自「升職加薪」星球星友的投稿，坐
一個注解實現(xiàn)接口冪等，這樣才優(yōu)雅！

場景碼猿慢病云管理系統(tǒng)中其實高并發(fā)的場景不是很多，沒有必要每個接口都去考慮并發(fā)高的場景，比如添加住院患者的這個接口，具體的業(yè)務(wù)代碼就不貼了，業(yè)務(wù)偽代碼如下：圖片上述代碼有
簽約井川里予、何丹彤，單視頻點贊近千萬，MCN黑馬永恒文希快速崛起！

來源：視聽觀察永恒文希傳媒作為一家MCN公司，說起它的名字來，可能大家會覺得有點兒陌生，但是說出來下面一串的名字之后，或許大家就會感到震驚，原來這么多網(wǎng)紅，都簽約這家公司了。根
花7萬退貨退款無門：誰在縱容淘寶珠寶商家造假？

來源：極點商業(yè)作者：楊銘在淘寶購買珠寶玉石后，因為保證金不夠賠付，店鋪關(guān)閉，退貨退款難、維權(quán)無門的比比皆是。“提供相關(guān)產(chǎn)品鑒定證書，支持全國復(fù)檢，可以30天無理由退換貨。&
阿里大調(diào)整

來源：產(chǎn)品劉有媒體報道稱，近期淘寶天貓集團(tuán)啟動了近年來最大的人力制度改革，涉及員工績效、層級體系等多個核心事項，目前已形成一個初步的“征求意見版”：1、取消P序列
回歸OPPO兩年，一加贏了銷量，輸了品牌

成為OPPO旗下主打性能的先鋒品牌后，一加屢創(chuàng)佳績。今年618期間，一加手機(jī)全渠道銷量同比增長362%，憑借一加 11、一加 Ace 2、一加 Ace 2V三款爆品，一加

AVt天堂网手机版,亚洲va久久久噜噜噜久久4399,天天综合亚洲色在线精品,亚洲一级Av无码毛片久久精品

記一次 .NET某工控WPF程序被人惡搞的卡死分析

一、背景

1. 講故事

二、WinDbg 分析

1. 程序是如何卡死的

2. 哪里來的調(diào)試器

3. 真的是 VS 跑起來的嗎

4. 這個dump是如何生成的

三、總結(jié)

直屏旗艦來了 iQOO 12和K70 Pro同臺競技

紅魔電競平板評測：大屏幕硬實力

6月安卓手機(jī)性價比榜：Note 12 Turbo斷層式碾壓

一年經(jīng)驗在二線城市面試后端的經(jīng)驗分享

一個注解實現(xiàn)接口冪等，這樣才優(yōu)雅！

簽約井川里予、何丹彤，單視頻點贊近千萬，MCN黑馬永恒文希快速崛起！

花7萬退貨退款無門：誰在縱容淘寶珠寶商家造假？

阿里大調(diào)整

回歸OPPO兩年，一加贏了銷量，輸了品牌

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊