在某个平行宇宙中，读者现在看到的应该是网络协议的文章。这个平行宇宙和当前宇宙的分叉点来自2小时前。我点击了Wireshark来捕获数据包。瞬间，蓝屏出现，最近写在文章中的内容消失了。我差点跳到桌子上，卧槽！留着，留着，一不留神就忘了。事情是这样的：我要抓一些DHCP协议包，所以禁用了网卡，然后打开Wireshark，打算抓取网卡启用一段时间后的通信过程。然而，当我双击网卡开始抓包的那一刻，却是蓝色的！捶胸顿足的时候，无意间在蓝屏界面看到了蓝屏驱动名称：npcap.sys。看来是Wireshark使用的抓包驱动有问题。啊!这个人给我带来了太多的痛苦。我不打算放手。我决定找出这个程序有什么问题。等待几分钟，重启电脑后，在C:\Windows目录下找到了系统崩溃后的核心存储文件：MEMORY.dmp。保存执行上下文，相当于给“案发现场”拍了一张“照片”，方便事后定位问题。请注意，只有提前设置才会存储。默认情况下只会存储一个非常简单的minidump文件，不利于问题分析。使用内核分析神器：WinDbg加载分析dump文件。因为我已经知道崩溃位置在npcap.sys文件中，所以我们先简单的看一下这个东西。我们在Linux上使用tcpdump抓取数据包时，底层使用的核心库是libpcap，它是一个开源项目，在Windows上对应的是winpcap。后来在Win7之后，Windows上使用了更现代的抓包接口，Wireshark默认使用npcap，而不是传统的winpcap。既然是开源项目，东西好办，有源代码和PDB符号文件。每个人都知道源代码，但有些人可能不知道PDB文件。我们知道，C/C++等语言编译后，函数名、参数、数据结构定义等信息全部丢失，剩下的就是CPU指令。那么万一程序出了问题，程序员怎么分析呢？这需要pdb文件，也就是程序数据库，里面包含了上面提到的信息。在npcap项目官网上找到了对应版本的npcap.sys驱动的npcap.pdb文件。下载后加载到WinDbg中，可以看到程序崩溃的函数调用栈：看到了吧，连同PDB文件，连源码路径都显示出来了。我在GitHub上找到了这个openclos.c文件，定位到最后导致崩溃的函数：NPF_FreeCapData，是在哪一行崩溃的？回过头来看，windbg可以告诉我们具体那行指令的地址，可以在context的RIP寄存器中看到To:看看这个位置的指令是什么：就是这条指令导致蓝屏：movrbx,[rdx+18h]该指令表示将rdx+18指向的内容读入rbx寄存器。又看了下crash代码，是内存访问异常，肯定是地址rdx+18有问题。地址有问题，那么rdx现在是什么？放开我，其实是0，一个空指针NULL！那不崩溃才怪！结合汇编指令和数据结构定义，可以锁定源码中的具体位置：在源码中的三级指针访问中，二级指针的pNBLCopy字段为空！而且代码没有判断为空指针，所以崩溃了~再次结合函数调用栈和GitHub中的源码，可以看到这是在清理释放所有捕获的数据包时出现的问题。看下面的代码，在循环中一个一个释放每个数据包占用的资源，所有的数据包以双链表的形式串联起来。问题分析到这里，我已经抑制不住内心的激动了。我是否发现了0day漏洞？要知道，drivernullpointerbug用的很好，但是可以用来进行内核级的攻击！一个漏洞值很多。刚才幻想了1秒，立马醒悟过来，等等，我的版本好像不是最新的，我最新版的康康是不是还有这个问题。结果给我泼了一盆冷水。新版本增加了这个指针是否为空的判断：哎！错过了财富~二维码关注。转载本文请联系编程技术宇宙公众号。
