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

记一次 .NET某工控WPF程序被人恶搞的卡死分析已关闭评论
32 次浏览

A+

所属分类：.NET技术

摘要

这一期程序故障除了做原理分析，还顺带吐槽一下，熟悉我的朋友都知道我分析dump是免费的，但免费不代表可以滥用我的宝贵时间，我不知道有些人故意恶搞卡死是想干嘛，不得而知，希望后面类似的事情越来越少吧！废话不多说，我们来看看是如何被恶搞的。

一：背景

1. 讲故事

这一期程序故障除了做原理分析，还顺带吐槽一下，熟悉我的朋友都知道我分析dump是免费的，但免费不代表可以滥用我的宝贵时间，我不知道有些人故意恶搞卡死是想干嘛，不得而知，希望后面类似的事情越来越少吧！废话不多说，我们来看看是如何被恶搞的。

二：WinDbg 分析

1. 程序是如何卡死的

既然是窗体程序自然就是看主线程，我们使用 k 命令即可。

 0:000> k   # Child-SP          RetAddr               Call Site 00 00000036`e1f7da18 00007ffe`70bf30ce     ntdll!NtWaitForSingleObject+0x14 01 00000036`e1f7da20 00007ffd`eff74910     KERNELBASE!WaitForSingleObjectEx+0x8e ... 05 (Inline Function) --------`--------     coreclr!CLREventBase::Wait+0x12 [D:a_work1ssrccoreclrvmsynch.cpp @ 412]  06 00000036`e1f7db20 00007ffd`f00c9afa     coreclr!Thread::WaitSuspendEventsHelper+0xc8 [D:a_work1ssrccoreclrvmthreadsuspend.cpp @ 4626]  07 (Inline Function) --------`--------     coreclr!Thread::WaitSuspendEvents+0x8 [D:a_work1ssrccoreclrvmthreadsuspend.cpp @ 4663]  08 00000036`e1f7dbe0 00007ffd`f0009c80     coreclr!Thread::RareEnablePreemptiveGC+0x7d99a [D:a_work1ssrccoreclrvmthreadsuspend.cpp @ 2414]  09 (Inline Function) --------`--------     coreclr!Thread::EnablePreemptiveGC+0x16 [D:a_work1ssrccoreclrvmthreads.h @ 2044]  0a 00000036`e1f7dc20 00007ffd`f0075d10     coreclr!Thread::RareDisablePreemptiveGC+0xc8 [D:a_work1ssrccoreclrvmthreadsuspend.cpp @ 2156]  0b 00000036`e1f7dca0 00007ffd`f0096a5f     coreclr!JIT_ReversePInvokeEnterRare2+0x18 [D:a_work1ssrccoreclrvmjithelpers.cpp @ 5462]  0c 00000036`e1f7dcd0 00007ffd`907afe09     coreclr!JIT_ReversePInvokeEnterTrackTransitions+0xaf [D:a_work1ssrccoreclrvmjithelpers.cpp @ 5509]  0d 00000036`e1f7dd00 00007ffe`72e0e858     0x00007ffd`907afe09 0e 00000036`e1f7dd80 00007ffe`72e0e3dc     user32!UserCallWinProcCheckWow+0x2f8 0f 00000036`e1f7df10 00007ffe`72e20c93     user32!DispatchClientMessage+0x9c 10 00000036`e1f7df70 00007ffe`730f0e64     user32!_fnDWORD+0x33 11 00000036`e1f7dfd0 00007ffe`70b31104     ntdll!KiUserCallbackDispatcherContinue 12 00000036`e1f7e058 00007ffe`72e21c0e     win32u!NtUserGetMessage+0x14 13 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_work1ssrcnativecorehostfxrfx_muxer.cpp @ 145]  ... 34 00000036`e1f7f890 00000000`00000000     ntdll!RtlUserThreadStart+0x21

从卦中的调用栈可以看到，主线程通过 GetMessageW 从消息队列中拿到了数据，在处理时被 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; }

从上面的代码可以明显的看到当前Thread 处于 TS_DebugSuspendPending 状态，从名字上看貌似和调试有关，接下来查下这个枚举的注解。

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

从注解看是因为调试器阻塞了这个线程，我去，哪里来的调试器呢？这引起了我的巨大兴趣。。。

2. 哪里来的调试器

我刚开始是抱有巨大的善意，我以为他的程序被人恶意注入导致卡死，但分析下来我还是太单纯了，继续往下看吧，既然有调试器，一般来说PEB.BeingDebugged=Yes状态，命令的输出结果也得到了证实。

 0:000> !peb PEB at 00000036e1c11000     ...     BeingDebugged:            Yes     ...                     Base TimeStamp                     Module             7ff7f5230000 65310000 Oct 19 18:08:00 2023 G:xxxC#ProjectsNugetApplicationsApplicationsxxxbinDebugnet6.0-windowsxxx.exe             ...

我以为到这里就可以告诉朋友答案，你的程序可能被人恶意注入了，但眼尖的我发现了一点异常，他的 xxx.exe 启动目录怎么会有 binDebugnet6.0-windows 呢？很明显这是用 VS 直接跑起来的呀。。。。

3. 真的是 VS 跑起来的吗

首先大家要知道 Visual Studio 是托管调试器，托管调试器在调试程序的时候会在 coreclr 层面设置一个全局变量 g_CORDebuggerControlFlags=0x0200，这也是 Debugger.IsAttached 的底层判断依据，不相信的朋友可以看下这个方法的底层实现：

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

有了这些基础知识之后，接下来就可以用 x 命令去验证下。

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

看到上面的答案基本就可以实锤了，有些朋友可能还是不大相信，我们可以这样看，VisualStudio 是 WPF 写的，如果用 VS 来调试，那么线程栈里面应该会有很多类似的 VisualStudio 字符串。

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

从卦中看，你说正常发布的程序怎么可能会有 9 个 Microsoft.VisualStudio.DesignTools 字符串呢？

4. 这个dump是如何生成的

这个问题我相信可能有一些朋友会比较疑惑，其实没什么疑惑的，Visual Studio 有生成Dump的功能，操作步骤为： Debug -> Save Dump As... , 接下来通过一个小例子观察一下。

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

调试起来后，截图如下：

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

最后打开生成好的 Dump 文件，使用 kc 观察主线程的输出：

 0:000> kc  # Call Site 00 ntdll!NtWaitForSingleObject 01 KERNELBASE!WaitForSingleObjectEx 02 coreclr!CLREventWaitHelper2 03 coreclr!CLREventWaitHelper 04 coreclr!CLREventBase::WaitEx 05 coreclr!CLREventBase::Wait 06 coreclr!Thread::WaitSuspendEventsHelper 07 coreclr!Thread::WaitSuspendEvents 08 coreclr!Thread::RareEnablePreemptiveGC 09 coreclr!Thread::EnablePreemptiveGC 0a coreclr!Thread::RareDisablePreemptiveGC 0b coreclr!Thread::DisablePreemptiveGC ... 19 ConsoleApp4!ConsoleApp4.Program.Main ... 30 ntdll!RtlUserThreadStart

从卦中看，正是停留在 WaitSuspendEventsHelper 函数里，一摸一样，彻底被360°无死角的证实。。。。