记一次 .NET某防伪验证系统 崩溃分析

这篇具有很好参考价值的文章主要介绍了记一次 .NET某防伪验证系统 崩溃分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一:背景

1. 讲故事

昨晚给训练营里面的一位朋友分析了一个程序崩溃的故障,因为看小伙子昨天在群里问了一天也没搞定,干脆自己亲自上阵吧,抓取的dump也是我极力推荐的用 procdump 注册 AEDebug 的方式,省去了很多沟通成本。

二:WinDbg分析

1. 为什么会崩溃

windbg有一个非常强大的点就是当你双击打开后,会自动帮你切换到崩溃的线程以及崩溃处的汇编代码,省去了 !analyze -v 命令的龟速输出,参考信息如下:


................................................................
...................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(10f4.f58): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
eax=00000000 ebx=00000000 ecx=00000040 edx=00000000 esi=004c1b98 edi=07a8ed4c
eip=7008508f esp=07a8ec74 ebp=07a8ec80 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
clr!Thread::GetSafelyRedirectableThreadContext+0x7c:
7008508f 8038eb          cmp     byte ptr [eax],0EBh        ds:002b:00000000=??
...

从卦中可以看到,当前崩溃是因为 eax=0 导致的,那为什么 eax 等于 0 呢?要想寻找这个答案,需要观察崩溃前的线程栈上下文,可以使用命令 .ecxr;k 9 即可。


0:009> .ecxr;k 9
eax=00000000 ebx=00000000 ecx=00000040 edx=00000000 esi=004c1b98 edi=07a8ed4c
eip=7008508f esp=07a8ec74 ebp=07a8ec80 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
clr!Thread::GetSafelyRedirectableThreadContext+0x7c:
7008508f 8038eb          cmp     byte ptr [eax],0EBh        ds:002b:00000000=??
 # ChildEBP RetAddr      
00 07a8ec80 6fe7f6cd     clr!Thread::GetSafelyRedirectableThreadContext+0x7c
01 07a8f030 6fe7f2f3     clr!Thread::HandledJITCase+0x31
02 07a8f0a4 6fee23da     clr!Thread::SuspendRuntime+0x260
03 07a8f184 6fedf72d     clr!WKS::GCHeap::SuspendEE+0x1fe
04 07a8f1b0 6fe309ca     clr!WKS::GCHeap::GarbageCollectGeneration+0x168
05 07a8f1c0 6fe30a2e     clr!WKS::GCHeap::GarbageCollectTry+0x56
06 07a8f1e4 6fe30a90     clr!WKS::GCHeap::GarbageCollect+0xa5
07 07a8f230 6f058b01     clr!GCInterface::Collect+0x5d
08 07a8f26c 055fa4b1     mscorlib_ni+0x3b8b01

从卦中信息看,尼玛,真无语了 GCInterface::Collect 说明有人用 GC.Collect() 手工触发GC,不知道为什么要这么做来污染GC内部的统计信息,不管怎么说这个肯定不是崩溃的原因。

2. GC正在干什么

我们继续观察线程栈,可以看到它的逻辑大概是这样的,通过 SuspendRuntime 把所有的托管线程进行逻辑上暂停,在暂停其中的一个线程时抛出了异常。

稍微提醒一下,这个 HandledJITCase 方法是用 ip 劫持技术将代码引入到 coreclr 中进行 GC完成等待,这种神操作有些杀毒软件会认为是病毒!!!

有些朋友肯定会说,有没有代码支撑。。。这里我就找一下 coreclr 的源码贴一下吧。


void ThreadSuspend::SuspendRuntime(ThreadSuspend::SUSPEND_REASON reason)
{
	while ((thread = ThreadStore::GetThreadList(thread)) != NULL)
	{
		...
		if (workingOnThreadContext.Acquired() && thread->HandledJITCase())
		{
			...
		}
		...
	}
}

结合源码分析思路就非常清晰了,这里的 thread->HandledJITCase() 中的 thread 到底是哪一个线程? 可以观察 kb 输出然后用 !t 去做比对。

记一次 .NET某防伪验证系统 崩溃分析

从卦中看,当前 GC 正在 Suspend 主线程,并且还看到了主线程有一个 System.AccessViolationException 异常,无语了。。。

3. 主线程到底怎么了

主线程进入到视野之后,那就重点关注一下它,可以用 k 看一下输出。


0:009> ~0s
eax=00000000 ebx=0029ea50 ecx=0029ea90 edx=00000000 esi=7efdb800 edi=000d0000
eip=00000000 esp=0029ea4c ebp=75146381 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210202
00000000 ??              ???
0:000> k
00 75146381 7efdb800     0x0
01 75146381 7517fa04     0x7efdb800
02 0029ea80 7736013a     user32!__fnHkINLPKBDLLHOOKSTRUCT+0x28
03 0029eae4 7514908d     ntdll!KiUserCallbackDispatcher+0x2e
04 0029eae4 076e3912     user32!CallNextHookEx+0x84
05 0029eb28 076e3064     0x76e3912
06 0029eb5c 0011d48f     xxx!xxx.ScanerHook.KeyboardHookProc+0xe4
07 0029eb8c 75146381     0x11d48f
08 0029eba8 7517fa04     user32!DispatchHookW+0x38
09 0029ebd8 7736013a     user32!__fnHkINLPKBDLLHOOKSTRUCT+0x28
0a 0029ec3c 751406eb     ntdll!KiUserCallbackDispatcher+0x2e
0b 0029ec3c 75140751     user32!_PeekMessage+0x88
0c 0029ec68 6d8af3bf     user32!PeekMessageW+0x108
...

从卦象看,这卦非常奇怪,有如下两点信息:

  • eip=00000000,这个很无语,线程已经疯了
  • KeyboardHookProc ,居然有键盘钩子

熟悉 eip 的朋友应该知道,它相当于一辆车的方向盘,一辆高速行驶的车突然没了方向盘,真的太可怕了,最后必然车毁人亡。

4. 是 eip=0 导致的崩溃吗

在汇编中是因为eax=0导致,而这里eip恰好也等于0,仿佛冥冥之中自有牵连,带着强烈的好奇心我们来反汇编下 GetSafelyRedirectableThreadContext 方法逻辑,简化后如下:


0:000> uf 7008508f
clr!Thread::GetSafelyRedirectableThreadContext:
6fe7f60e 55              push    ebp
6fe7f60f 8bec            mov     ebp,esp
6fe7f611 53              push    ebx
6fe7f612 56              push    esi
6fe7f613 57              push    edi
6fe7f614 8bf1            mov     esi,ecx
...
7008506d ffe9            jmp     rcx
7008506f fd              std
70085070 c1daff          rcr     edx,0FFh
70085073 f6450801        test    byte ptr [ebp+8],1
70085077 0f84efa5dfff    je      clr!Thread::GetSafelyRedirectableThreadContext+0xcc (6fe7f66c)
7008507d 8b8604010000    mov     eax,dword ptr [esi+104h]
70085083 3987b8000000    cmp     dword ptr [edi+0B8h],eax
70085089 0f85dda5dfff    jne     clr!Thread::GetSafelyRedirectableThreadContext+0xcc (6fe7f66c)
7008508f 8038eb          cmp     byte ptr [eax],0EBh  

从上面的汇编代码看eax的取值链条是: eax <- esi+104h <- ecx ,很显然这里的 ecx 是 thiscall 协议中的 Thread=004c1b98 参数,可以用 dp 验证下。


0:000> dp 004c1b98+0x104 L1
004c1c9c  00000000

从卦中看果然是 0,有些朋友好奇这个 104 偏移到底是个什么东西,参考 coreclr 源码其实就是 m_LastRedirectIP 字段,参考如下:


BOOL Thread::GetSafelyRedirectableThreadContext(DWORD dwOptions, CONTEXT* pCtx, REGDISPLAY* pRD)
{
    if (!EEGetThreadContext(this, pCtx))
    {
        return FALSE;
    }
    ... 
	if (GetIP(pCtx) == m_LastRedirectIP)
	{
		const BYTE short_jmp = 0xeb;
		const BYTE self = 0xfe;

		BYTE* ip = (BYTE*)m_LastRedirectIP;
		if (ip[0] == short_jmp && ip[1] == self)
			m_LastRedirectIP = 0;
		return FALSE;
	}
}

结合汇编代码其实我们崩溃在 ip[0] == short_jmp 这一句上,仔细分析上面的C++代码会发现一个很奇怪的信息,那就是为什么 GetIP(pCtx)= 0,接下来用 dt 观察下寄存器上下文。


0:009> kb 2
 # ChildEBP RetAddr      Args to Child              
00 07a8ec80 6fe7f6cd     00000003 07a8ed4c 07a8ecf0 clr!Thread::GetSafelyRedirectableThreadContext+0x7c
01 07a8f030 6fe7f2f3     004c1b98 0b367326 76a016a1 clr!Thread::HandledJITCase+0x31

0:009> dt _CONTEXT 07a8ed4c
ntdll!_CONTEXT
   +0x000 ContextFlags     : 0x10007
   ...
   +0x01c FloatSave        : _FLOATING_SAVE_AREA
   +0x08c SegGs            : 0x2b
   +0x090 SegFs            : 0x53
   +0x094 SegEs            : 0x2b
   +0x098 SegDs            : 0x2b
   +0x09c Edi              : 0xd0000
   +0x0a0 Esi              : 0x7efdb800
   +0x0a4 Ebx              : 0x29ea50
   +0x0a8 Edx              : 0
   +0x0ac Ecx              : 0x29ea90
   +0x0b0 Eax              : 0
   +0x0b4 Ebp              : 0x75146381
   +0x0b8 Eip              : 0
   +0x0bc SegCs            : 0x23
   +0x0c0 EFlags           : 0x210202
   +0x0c4 Esp              : 0x29ea4c
   ...

从卦中看果然 eip=0,这是一个非常错误的信息,还有一点就是 m_LastRedirectIP 字段一般用来处理一些比较诡异的兼容性问题,所以这里两个字段都是 0 导致崩溃的产生。

有了上面的信息,我们就知道了前因后果,原来是主线程车毁人亡(eip=0),导致GC无法暂停它,在内部抛出了代码异常,你可以说是 CLR 的bug,也可以说是主线程的Bug,所以给到的解决方案就是:

  1. 屏蔽掉 键盘钩子 的业务逻辑,肯定是它造成的。
  2. 不去掉的话,要重点观察 键盘盘子 ,是否是代码改动引发的。

三:总结

说实话要想解释这个程序为什么会崩溃,需要分析者对GC的SuspendRuntime运作逻辑有一定的了解,否则真抓瞎了,所以.NET调试训练营中的GC理论知识一定是分析这些 dump 的基石。文章来源地址https://www.toymoban.com/news/detail-844033.html

记一次 .NET某防伪验证系统 崩溃分析

到了这里,关于记一次 .NET某防伪验证系统 崩溃分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

原文地址:https://www.cnblogs.com/huangxincheng/p/18101375

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 记一次 .NET 某旅行社审批系统 崩溃分析

    前些天有位朋友找到我,说他的程序跑着跑着就崩溃了,让我看下怎么回事,其实没怎么回事,抓它的 crash dump 就好,具体怎么抓也是被问到的一个高频问题,这里再补一下链接: [.NET程序崩溃了怎么抓 Dump ? 我总结了三种方案] https://www.cnblogs.com/huangxincheng/p/14811953.html ,采用

    2024年02月09日
    浏览(16)
  • 记一次 .NET某新能源检测系统 崩溃分析

    前几天有位朋友微信上找到我,说他的程序会偶发性崩溃,一直找不到原因,让我帮忙看一下怎么回事,对于这种崩溃类的程序,最好的办法就是丢dump过来看一下便知,话不多说,上windbg说话。 对于一个崩溃类的dump,寻找崩溃点非常重要,常用的命令就是 !analyze -v ,输出如

    2024年02月08日
    浏览(10)
  • 记一次 .NET 某新能源材料检测系统 崩溃分析

    上周有位朋友找到我,说他的程序经常会偶发性崩溃,一直没找到原因,自己也抓了dump 也没分析出个所以然,让我帮忙看下怎么回事,那既然有 dump,那就开始分析呗。 一直跟踪我这个系列的朋友应该知道分析崩溃第一个命令就是 !analyze -v ,让windbg帮我们自动化异常分析。

    2024年02月05日
    浏览(10)
  • 记一次 .NET 某企业采购平台 崩溃分析

    前段时间有个朋友找到我,说他们的程序有偶发崩溃的情况,让我帮忙看下怎么回事,针对这种 crash 的程序,用 AEDebug 的方式抓取一个便知,有了 dump 之后接下来就可以分析了。 既然是程序的崩溃,我们可以像看蓝屏一下看dump文件,使用 !analyze -v 命令即可。 从上面的信息

    2024年02月11日
    浏览(10)
  • 记一次 .NET某股票交易软件 灵异崩溃分析

    在dump分析的旅程中也会碰到一些让我无法解释的灵异现象,追过这个系列的朋友应该知道,上一篇我聊过 宇宙射线 导致的程序崩溃,后来我又发现了一例,而这一例恰恰是高铁的 列控连锁一体化 程序,所以更加让我确定这是由于 电离辐射 干扰了计算机的 数字信号 导致程

    2024年02月04日
    浏览(10)
  • 记一次 .NET某工控 宇宙射线 导致程序崩溃分析

    为什么要提 宇宙射线 , 太阳耀斑 导致的程序崩溃呢?主要是昨天在知乎上看了这篇文章:莫非我遇到了传说中的bug? ,由于 rip 中的0x41变成了0x61出现了bit位翻转导致程序崩溃,截图如下: 下面的评论大多是说由于 宇宙射线 ,这个太玄乎了,说实话看到这个 传说bug 的提法

    2024年02月04日
    浏览(8)
  • 记一次 腾讯会议 的意外崩溃分析

    前段时间在用 腾讯会议 直播的时候,居然意外崩溃了,还好不是在训练营上课,不然又得重录了,崩完之后发现 腾讯会议 的 bugreport 组件会自动生成一个 minidump,截图如下: 作为一个.NET高级调试的技术博主,非 .NET 的程序也得要研究研究哈😄😄😄,有了这个好奇心,也

    2023年04月20日
    浏览(16)
  • 记一次 .NET某报关系统 非托管泄露分析

    前段时间有位朋友找到我,说他的程序内存会出现暴涨,让我看下是怎么事情?而且还告诉我是在 Linux 环境下,说实话在Linux上分析.NET程序难度会很大,难度大的原因在于Linux上的各种开源工具主要是针对 C/C++, 和 .NET 一毛钱关系都没有,说到底微软在 Linux 上的调试领域支持

    2024年02月14日
    浏览(9)
  • 记一次 .NET 某电力系统 内存暴涨分析

    前些天有位朋友找到我,说他生产上的程序有内存暴涨情况,让我帮忙看下怎么回事,最简单粗暴的方法就是让朋友在内存暴涨的时候抓一个dump下来,看一看大概就知道咋回事了。 这个问题说的再多也不为过,一定要看清楚这个程序是如何个性化发展的,可以使用 !address

    2024年02月08日
    浏览(7)
  • 记一次 .NET 某工控视觉系统 卡死分析

    前段时间有位朋友找到我,说他们的工业视觉软件僵死了,让我帮忙看下到底是什么情况,哈哈,其实卡死的问题相对好定位,无非就是看主线程栈嘛,然后就是具体问题具体分析,当然难度大小就看运气了。 前几天看一篇文章说现在的 .NET程序员 不需要学习 WinDbg ,理由就

    2024年02月12日
    浏览(11)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包