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

我差點拍案而起，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秒鐘，馬上清醒過來，等等，我這版本好像不是最新的，我康康最新的版本還有沒有這個問題。

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

哎！與財富擦肩而過～