[[392695]]

在某一個平行宇宙中，各位讀者大大現在看到的應該是一篇關于網絡協議的文章。

這個平行宇宙與當前宇宙的分叉點來源于2個小時前，我點了一下Wireshark抓包，一剎那，藍屏了，那篇文章中近一段時間寫的內容沒了。

我差點拍案而起，WTF!保存啊保存，一個不留神就忘記了。

事情是這樣的：

我想抓一些DHCP協議的數據包，于是將網卡禁用，然后開啟Wireshark，打算把一會兒啟用網卡后的通信過程抓下來。然而等我雙擊網卡開始抓包的一瞬間，藍了!

捶足頓胸之際，不小心瞅見了藍屏界面上藍屏的驅動程序名字：npcap.sys，看來是Wireshark用的抓包驅動有問題呀!

這家伙害我害得這么慘，我不打算放過它，決定找出來到底這程序哪里寫的有問題。

等了幾分鐘，電腦重啟后，在C:\Windows目錄下找到了系統崩潰后產生的核心存儲文件：MEMORY.dmp，這個文件是操作系統崩潰后，Windows將內核的數據、所有進程、線程的執行上下文進行了保存，相當于對“案發現場”進行了“拍照”，用于事后定位問題。

注意，這個得提前設置好才會存儲，默認情況下只會存儲一個很簡單的mini dump文件，不利于問題分析。

祭出內核分析神器：WinDbg，來加載分析dump文件。

因為已經知道崩潰位置位于npcap.sys文件，所以先去簡單了解了一下這個東西。

Linux上咱們使用tcpdump抓取數據包時，底層使用的核心庫就是libpcap，這是一個開源項目，在Windows上對應的就是winpcap。后來在Win7之后，Windows上使用了更現代化的抓包接口，Wireshark默認使用npcap來代替了傳統的winpcap。

既然是開源項目，事情就好辦了，有源碼，有PDB符號文件。

源碼大家知道，PDB文件可能有些人不知道。我們知道C/C++這類語言編譯完成后，所有的函數名字、參數、數據結構定義等信息就丟失了，剩下的都是CPU指令了。那萬一程序出了問題程序員怎么分析呢?這就需要pdb文件了，pdb是程序數據庫的意思，這里面有前面說的那些信息。

在npcap項目的官網，找到了npcap.sys驅動程序對應版本的npcap.pdb文件，下載后，載入WinDbg中，可以看到程序崩潰的函數調用堆棧：

看到了吧，有了PDB文件，連源代碼路徑都顯示出來了。

在GitHub上找到了這個openclos.c文件，定位到最后導致崩潰的函數：NPF_FreeCapData

具體是崩潰在哪一行呢?

回頭看看windbg可以告訴我們具體那一行指令的地址，在上下文的RIP寄存器中可以看到：

看一下這個位置的指令是個啥：

導致藍屏的是這一條指令：

mov rbx, [rdx+18h] 

這條指令的意思是把rdx+18指向位置的內容，讀取到rbx寄存器中。又看了一下崩潰代碼是內存訪問異常，那肯定就是rdx+18這個地址有問題了。

地址有問題，那現在rdx是個啥呢?

我去，居然是0，空指針NULL啊!那不崩潰就怪了!

結合匯編指令和數據結構定義，就能鎖定源碼中的具體位置了：在源碼中的三級指針訪問中，第二級指針的pNBLCopy字段為空!而代碼中又沒有判斷為空指針的情況，就崩潰了～

再次結合函數調用棧和GitHub中的源代碼，可以看到這是在清理釋放抓取到的所有數據包時出現的問題，看下面代碼，這是在一個循環中，挨個釋放每個數據包所占據的資源，所有數據包以雙鏈表形式串聯了起來。

問題分析到這里，我已經按捺不住心里的激動了，難道我發現了一個0day漏洞?要知道，驅動程序空指針bug用的好可是能做內核級攻擊的!一個漏洞都是值不少$的。

剛剛幻想了1秒鐘，馬上清醒過來，等等，我這版本好像不是最新的，我康康最新的版本還有沒有這個問題。

結果潑了我一盆冷水，新的版本，已經增加了對這個指針是否為空的判斷了：

哎!與財富擦肩而過～

本文轉載自微信公眾號「編程技術宇宙」，可以通過以下二維碼關注。轉載本文請聯系編程技術宇宙公眾號。