首页
社区
课程
招聘
[原创]调试实战——使用windbg调试崩溃在ole32!CStdMarshal::DisconnectSrvIPIDs
发表于: 2019-11-30 18:59 3206

[原创]调试实战——使用windbg调试崩溃在ole32!CStdMarshal::DisconnectSrvIPIDs

2019-11-30 18:59
3206

2020-02-21 更新:不知道为什么帖子少了一部分,偶然发现,特意来补全。给各位造成困扰,深表歉意。抱歉,抱歉。


前言

最近程序会不定期崩溃,很是头疼!今晚终于忍无可忍,下决心要干掉它!从之前的几个相关的dump可以猜到是有接口未释放导致的问题,但没有确认到底是哪个接口。本篇总结记录了找到这个接口的过程。

这是几年前在项目中遇到的一个问题。我对之前的笔记进行了整理重新发布于此。


初识问题

用windbg打开dump文件,显示如下:

从图中可以很明显的看出来是访问违例(因为红框标识的地址5bbc97f8的内容是????????),而且这是一条call指令,call调用的地址存储在ecx+8 (0x5bbc97f8) 处。我们可以用!address address来查看某个地址的信息,输入!address 5bbc97f8

从图中得知,地址5bbc97f8对应的内存已经被释放了(State 是 MEM_FREE)。windbg还贴心的给出了和此地址相关的一些模块信息。其中有几个是我们自己的模块,从Unloaded可以看出这几个模块曾经被卸载过。很有可能跟我们的崩溃相关。

至此,我们可以大胆猜测崩溃的原因是模块被卸载后,还要执行其中的代码!

下面让我们继续分析,为什么模块卸载后还会执行其中的代码!


寻根溯源

先用.ecxr切换到发生异常时的上下文,然后用kpn(k显示调用栈,p显示函数的参数,n显示栈帧编号)查看调用栈,如下图:

从上图可知,11号线程在调用CoUninitialize()执行COM的线程清理工作,frame 0在调用ole32!CStdMarshal::DisconnectSrvIPIDs()时崩溃了!从Disconnect猜测是要断开连接!使用ub 76f8bbe7 (76f8bbe7是由76f8bbe4 + 3得到的,在上一篇文章里介绍过了)查看崩溃前的几条指令:

红框内的指令非常像是虚函数的调用(调用约定是stdcall,不是thiscall) eax是调用类对象的指针(通过入栈方式传递), ecx指向虚函数表(vtable),dword ptr[ecx+8]是虚函数表中的第三项(32位下指针占4字节,第一项的偏移是+0,第二项的偏移是+4,第三项的偏移是+8)。回想IUnkown的前三个函数分别是QueryInterface(), AddRef() 和 Release(),可以大胆猜测这里是在调用Release(),跟上下文也很搭(从CoUninitialize()推断当前线程正在做COM清理工作)!我们的猜测很有可能是正确的!

我们先小小总结一下:整个过程应该是这样的,我们使用了一个COM接口,但是由于某些原因并没有释放,线程在退出的时候,调用CoUninitialize()做COM清理工作。当清理到我们的接口的时候,由于接口代码所在的dll已经被卸载了,从而导致了访问违例!下面我们的任务是找出到底是哪个接口没释放,然后对照代码验证我们的猜测是否正确!


验证

先用lm a 5bbc97f8确认下该地址属于哪个模块。

看来,地址5bbc97f8落在AccIME.dll中,由于AccIME.dll已经被卸载了,我们需要使用命令.reload /f AccIME.dll=5bbb0000,5bbd8000-5bbb0000来重新加载已经被卸载的模块,我们可以使用lm vm AccIME来确认加载成功与否。

从上图可知,我们成功的加载了AccIME模块,符号也加载成功了。

友情提示:如果遇到如下错误,说明我们成功加载了被卸载的dll,但是加载符号的时候遇到了问题。

可以使用!sym noisy开启嘈杂模式,然后再次执行.reload命令,通过输出日志来排查具体原因。排查完毕后可以使用!sym quiet来关闭嘈杂模式。具体使用方法可通过.hh !sym查看windbg帮助文档。

接下来我们用ln 5bbc97f8查一下该地址附近函数。

至此,我们可以看到是与AccIME!CCfgDpyScheme类相关的问题,接下来我们可以把重点放到对此类的引用计数的使用上了!

本篇总结暂时写到这,还需要弄明白几个问题:

涉及引用计数的相关代码是否有问题。

为什么有时候会崩溃,有时候不崩溃。

有结果后会再发一篇总结,敬请期待!(能力有限,没能查出来:cry:)


解决方案

由于没能查出代码哪里有问题。使用临时解决方案先绕过去了:在退出的时候,没有使用FreeLibrary()显示卸载该模块,交由操作系统来做模块清理工作)。

未弄明白的问题的可能原因:

涉及引用计数的相关代码是否有问题。

Oops, 没查出代码哪里有问题。无法确定问题的根本原因。:sob:

为什么有时候会崩溃,有时候不崩溃。
有时候崩溃应该是还没断开连接,对应的dll就被卸载了。有时候不崩溃应该是在卸载dll之前,已经成功的断开了连接。


命令总结

  • !address address可以查看对应地址的信息,如果一个地址不可访问,那么显示的内容会是????????。

  • .ecxr可以让windbg使用发生异常时的上下文,这样再使用k等命令时就是发生异常时的相关信息了。

  • u可以反汇编某个地址对应的代码,ub可以向前反汇编,b应该是backward的缩写。

  • lm a address可以查看address所属的模块。

  • ln可以查看某个地址附近的符号名。

  • .reload /f <image.ext>=<base>,<size>可以加载模块(甚至是已卸载的)到base指定的位置,并为之加载符号。

  • 关于各个windbg命令的用法,可以使用.hh command进行查看!非常方便,而且非常重要!


参考资料

  • 《格蠹汇编》
  • windbg帮助文档



[招生]科锐逆向工程师培训(2024年11月15日实地,远程教学同时开班, 第51期)

最后于 2020-2-21 22:37 被编程难编辑 ,原因:
收藏
免费 0
支持
分享
最新回复 (1)
雪    币: 12502
活跃值: (3048)
能力值: ( LV3,RANK:20 )
在线值:
发帖
回帖
粉丝
2
没继续具体定位代码,是哪个线程卸载的模块,哪个调用。。。
2019-11-30 20:36
0
游客
登录 | 注册 方可回帖
返回
//