1、簡介
所謂“底層數據包”指的是在“運行”於數據鏈路層的數據包，簡單的說就是“以太網幀”，而我們常用的Socket只能發送“運行”在傳輸層的TCP、UDP等包，這些傳輸層數據包已經能滿足絕大部分需求，但是有些時候還是需要發送底層數據包的（例如SYN掃描），那么如何發送呢？
本文記錄了我試圖實現的過程中遇到的一些問題以及解決辦法，需要注明：①本文只考慮Windows上的實現 ②本文主要目的是實現發送部分 ③本文假定讀者理解網絡分層結構和一些基本的網絡編程方法 ④本文只是在討論常規技術，切勿用作不法用途。
2、實現底層數據包發送的簡單方法
A)Raw Socket
Raw Socket是實現底層（網絡層）數據包最輕松方便的途徑，在使用WSASoccket（或socket）創建Socket時，可以用SOCK_RAW將Socket類型設置為Raw：
socket = WSASoccket(AF_INET,SOCK_RAW,IPPROTO_IP,NULL,0,0)//創建一個原始套接字
使用IPPROTO_RAW初始化的原始套接字可以直接收發網絡層數據包，發送一個TCP包時需要手工構造IP頭、TCP頭、內容以及各校驗和，構造完數據包后，用sendto方法將該包發送（注意到，手工構造的IP包頭中已經包含了目的IP地址，所以sendto的目的地址參數是無意義的）。Raw Socket非常方便，其他平台下的socket()函數也有類似功能。那么，用Raw Socket是否就可以達到目的呢？答案是否定的。
從Windows XP SP2開始，以后的操作系統（除了部分Server系統外），出於安全考慮，微軟對Raw Socket加了若干限制[3]，主要的限制如下：
a)無法使用Raw Socket發送TCP包。(ﾟДﾟ)!?
b)無法使用Raw Socket發送源IP地址不正確的UDP包。（意思是不能用它偽造源地址）
c)無法在一個類型為IPPROTO_TCP的Raw Socket上調用bind()函數。
加上限制以后，Raw Socket的功能就十分有限了，但也有幾個方法可以繼續使用：
①手動修改tcpip.sys，使用Cracker的思路，所謂“限制”反映到代碼中，是幾條if語句，再反映到PE文件上，則是一些jz\jne等指令，那么修改tcpip.sys的特定字節就可以解除這些限制，這個方法很早之前已被人實現過，雖然很巧妙，但缺點也顯而易見。
②使用虛擬機，里面裝一個Windows XP SP2以前的系統即可，這個方法理論上應該可行，但會犧牲效率和便捷。
那么還有沒有其他方法呢？
B)Winpcap
Winpcap是一個由多組件（動態鏈接庫+驅動程序）和相關SDK組成的"庫"。它可以提供監聽底層數據包、發送底層數據包的功能，但要注意，Winpcap不能提供底層包過濾等功能，所以不能用它做防火牆。Winpcap的使用非常簡單，用它發送一個以太網幀的代碼如下：
1 #include <stdlib.h> 2 #include <stdio.h> 3 4 #include <pcap.h> 5 6 void main(int argc, char **argv) 7 { 8 pcap_t *fp; 9 char errbuf[PCAP_ERRBUF_SIZE]; 10 u_char packet[100]; 11 12 /* 打開輸出設備 */ 13 if ((fp = pcap_open(argv[1], // 設備名 14 100, // 要捕獲的部分 (只捕獲前100個字節) 15 PCAP_OPENFLAG_PROMISCUOUS, // 混雜模式 16 1000, // 讀超時時間 17 NULL, // 遠程機器驗證 18 errbuf // 錯誤緩沖 19 )) == NULL) 20 { 21 fprintf(stderr, "\nUnable to open the adapter. %s is not supported by WinPcap\n", argv[1]); 22 return; 23 } 24 /* 25 此處省略填充packet內容代碼：填充以太網幀頭、IP頭等 26 */ 27 28 /* 發送數據包 */ 29 if (pcap_sendpacket(fp, packet, 100 /* size */) != 0) 30 { 31 fprintf(stderr, "\nError sending the packet: \n", pcap_geterr(fp)); 32 return; 33 } 34 return; 35 }
上述代碼發送了一個以太網幀，可分為三步：打開WinPcap設備（句柄/描述符？）、手工構造一個底層數據包、發送！整個過程沒有多余動作，非常簡單。那么Winpcap是如何實現的呢？
左圖是來自Winpcap官方文檔的一個架構圖，Winpcap最底層是一個NPF（Netgroup Packet Filter，網絡組包過濾）驅動，這是一個NDIS中間件驅動，所有經過網卡的數據包都會“途經”該驅動，在收到路過的數據包時，NPF可以選擇僅僅統計一下包的情況或寫入文件（做流量監控），或者寫到一個環形緩沖區中，然后用戶態程序調用wpcap.dll中一些函數，使用WinAPI和驅動程序交互，獲取驅動緩沖區中的數據，則達到了監控底層數據包的目的。至於發送數據包，用戶態程序調用Winpcap的SDK函數，這些函數調用dll中的方法，dll再用API和NPF通信，NPF是很最低層的驅動了，但它並不負責直接收發數據，NPF再調用更底層的網卡驅動實現數據包的發送。
值得注意的是，Winpcap中NPF的數據包過濾部分十分有趣，它基於BSD Packet Filter（BPF），這是一種能實現極高效率數據過濾的方案，在BPF中，一個復雜的過濾（匹配）規則被轉化成一個規則符號串（或稱BPF程序），然后在過濾的時候並不會對原過濾規則進行計算，而是將數據送入一個由規則符號串控制的狀態機中進行處理，這種符號串可由狀態機表示，在NPF中則進行了進一步優化，匹配規則轉化為符號串再生成為機器碼。過濾規則由用戶態程序給出，在傳入驅動之前，wpcap.dll將其轉換為BPF程序，NPF收到后，在調用它過濾之前將其轉換為機器碼，再調用轉換后的“過濾函數”匹配底層數據包，以追求高效率。
Winpcap使用NDIS驅動來做到監聽、發送底層數據包，已經是一種很好的解決方案了，說起Windows上的軟件對網絡設備的操控已經無出其右。但是，如果我們不希望使用像這樣的第三方工具呢？或者希望在收發、過濾底層包時做一些自己的處理，甚至在驅動層實現更復雜的邏輯呢？如果是這樣，使用Winpcap還不夠，我們需要自己寫一個驅動來完成這個任務。
3、基於NDIS Protocol Driver的底層數據包發送
"All problems in computer science can be solved by another level of indirection."，Windows下的網絡操作也遵循上面那句話，一個簡單的操作將會在若干個層次間傳遞，直到在最底層真正完成。
右圖展現了一般程序調用Socket操作時大致的調用層次，其中橙色部分（最頂上2層）為用戶態，藍色部分（中間4層）為內核態運行的驅動程序，最底層為網卡硬件。
AFD驅動是一個未公開接口的驅動層次（系統的一部分），由Winsock等調用，這方面的知識很多源自對ReactOS的源碼分析，參考文獻[7]對這個話題做了很好的說明。TDI（Transport Driver Interface）即傳輸層驅動接口，該層由AFD調用，用於實現傳輸層邏輯並和上層程序聯系，一些防火牆和大部分流量監控軟件均基於TDI層驅動，在該層的優勢是在監控、攔截和執行網絡行為的同時，仍可以獲得相關進程信息。TDI的層次比較低，如果程序直接調用該層進行網絡操作，那么基於TDI以上層次的防火牆和監控程序將無法檢測到。此外，在微軟的文檔中，TDI層是被標記為即將棄用的技術，文獻[8]對該技術介紹很全。TDI仍不是最底層的驅動，TDI之下是NDIS層，該層由分為三個子層，即NDIS協議驅動（例如TCP/IP協議棧驅動tcpip.sys）、NDIS中間層驅動、NDIS微端口驅動，微端口驅動則負責直接和NIC（網卡）驅動打交道，再之下則是硬件部分了，但直到硬件層次網絡操作才會真正意義上的被執行。一次Socket操作竟然需要跨過如此多的抽象層次，這的確有些讓人驚訝，但每層應該自有其存在的道理，限於能力本文在此處不作深入。
回到本文的目的：發送底層數據包。為實現該目的，我們的程序不能使用右圖的調用方式，正如Winpcap的NPF驅動一樣，我們應跨過中間幾層直接從應用層調用NDIS層。
本文采用編寫NDIS協議驅動+應用層直接調用的模式，但本文不會詳細講解NDIS層驅動的具體細節，文獻[6]對基本原理講的很好。（新內容請參考WDK文檔）其實，只需要了解大致架構，不需要了解過多NDIS層的細節就可以“編寫”達到本文目的驅動！WDK（Windows Driver Kit）的Sample代碼中，包含一個名為Ndisprot的工程，該工程已經實現了一個最基本的無連接NDIS協議驅動，支持收/發以太網幀。
下面請看Ndisprot工程目錄下的說明文件：
“This sample demonstrates a connection-less NDIS 6.0 protocol. The driver supports sending and receiving raw Ethernet frames using ReadFile/WriteFile calls from user-mode. It only receives frames with a specific EtherType field. As an NDIS protocol......”
可見這個樣例驅動基本符合我們的要求，另外，該工程還附帶了測試程序prottest.exe，也就是說明文件中的用戶態程序，既然有了這么方便的資源，下面需要做的就是對它稍作修改，然后編譯運行！
4、Hello “NDIS Protocol Driver”
Step1 [安裝WDK環境]
我的安裝環境是：Windows 8.1 x64 + Visual Studio 2013，先從這里下載Windows Driver Kit 8.1 Update1，Visual Studio 2012/2013可自動與WDK 8.1整合，前提是先將VS裝好，再安裝WDK。安裝后打開VS2013可以看到已安裝的模板中出現“Windows Driver”，說明環境已經配好，是不是很方便呢。
Step2 [修改&編譯Ndisprot項目]
從這里下載范例代碼，解壓后找到項目文件夾NDIS Connection-less Protocol Driver Sample，打開Solution\sys\630\ndisprot630.vcxproj
首先選擇合適的編譯配置和平台，設置平台工具集為“WindowsKernelModeDriver8.1”，再按確認重新編譯：
再次打開ndisprot630的項目屬性，可看到左側多出了屬性頁。打開VC++目錄屬性頁中“x86”為“x64”。打開屬性頁C/C++—>高級，檢查調用約定是否設置為__stdcall，剩余設置基本上保持默認。
打開Driver Signing—>General屬性頁，Sign Mode選擇“Test Sign”，Test Certificate選擇“Create Test Certificate”創建一個新的測試簽名
設置部分就到這里，下面對Sample代碼做一些修改：
注釋掉send.c文件中122-135行
//if (pEthHeader->EthType != Globals.EthType) //檢查以太網幀類型，如果不為0x8e88則停止發送 //{ // DEBUGP(DL_WARN, ("Write: Failing send with EthType %x\n", // pEthHeader->EthType)); // NtStatus = STATUS_INVALID_PARAMETER; // break; //} //if (!NPROT_MEM_CMP(pEthHeader->SrcAddr, pOpenContext->CurrentAddress, NPROT_MAC_ADDR_LEN)) //{ //檢查以太網幀源Mac地址，不為真實地址則停止發送 // DEBUGP(DL_WARN, ("Write: Failing with invalid Source address")); // NtStatus = STATUS_INVALID_PARAMETER; // break; //}
注釋掉send.c文件中第238行
//SendFlags |= NDIS_SEND_FLAGS_CHECK_FOR_LOOPBACK; //設置發送Flag，發送后產生回環接收包 NdisSendNetBufferLists( pOpenContext->BindingHandle, pNetBufferList, NDIS_DEFAULT_PORT_NUMBER, SendFlags);
注釋掉recv.c文件中第539、544行
if (pEthHeader->EthType == NPROT_8021P_TAG_TYPE) { USHORT UNALIGNED *pEthType; if (BufferLength < (sizeof(NDISPROT_ETH_HEADER) + 4)) { break; } pEthType = (USHORT UNALIGNED *)((PUCHAR)&pEthHeader->EthType + 4); if (*pEthType != Globals.EthType) { //break; //若以太網幀類型不等於0x8e88則停止接收 } } else if (pEthHeader->EthType != Globals.EthType) { //break; }
修改完后編譯即可，編譯完后生成如下文件：
ndisprot630.cer ...... 驅動的數字簽名
ndisprot630.inf ...... 驅動信息（安裝用）
ndisprot630.sys ...... 驅動程序
查看sys文件屬性中數字簽名的詳細信息，如果數字簽名處顯示“此數字簽名正常”則該驅動已正常簽名，可以安裝了。如果未提示正常，則先安裝cer證書文件，將證書導入到“受信任的根證書頒發機構”。（重啟后生效）另外，如果后續安裝中出現驅動無法啟動的情況，多半因為簽名無效問題，在Win7 64位之后，微軟禁止具有無效數字簽名的驅動運行（但可以安裝）。除了測試簽名外，還可以用專門的簽名工具為驅動簽名，比如“驅網簽名工具”，用這些工具簽名非常方便，但未付費版都有次數限制。
Step3 [安裝 & 運行]
首先啟動Windows的測試模式，以管理員權限執行命令”bcdedit /set testsigning on“，重啟后桌面右下角出現”測試模式“標簽，命令中的on改成off可關閉測試模式。第二步需要禁止驅動程序強制簽名：（Windows8.1 64位只能這么操作）
點擊“立即重啟”后，按F7選擇“禁止驅動程序強制簽名”后系統重啟。重啟后可以就可以安裝剛才編譯的驅動了，步驟如下：打開網絡適配器屬性后，點擊“安裝”，選擇“協議”安裝，再選擇“從磁盤安裝”，再選擇剛才編譯完的inf准備安裝，如果出現安裝未簽名的警告，選繼續安裝。
安裝后所有適配器的協議中出現“Sample NDIS Protocol Driver”一項，表示已經剛才的驅動已經安裝上了，然后用管理員身份執行"net start ndisprot"命令，如果出現“ Sample NDIS Protocol Driver服務已成功啟動。”則表示驅動已成功運行。
打開\Solution\test\prottest.vcxproj，這是Sample中帶的測試程序，生成prottest.exe后，執行“prottest.exe -e”，如果驅動成功安裝並運行，應該能看到枚舉出的網卡接口。通過分析prottest代碼，整個操作過程主要用到如下幾個函數：CreateFileA（打開驅動句柄）、DeviceIoControl（發送特定控制字到驅動程序，例如IOCTL_NDISPROT_OPEN_DEVICE打開指定網絡適配器）、WriteFile（發送以太網幀）等等。
基於這個Sample項目，很容易實現用戶態程序操控驅動進行底層數據包發送（當然包括接收）這個目的，限於篇幅這里就不詳細貼出細節了。（例如如何構造一個TCP包、如何發送等，也許以后會有另一篇隨筆說明:) ）經過實際測試后發現，使用這種方式發送數據包效率並不算很高，主要原因是發送接收過程仍涉及到用戶態和內核態的切換，如果要達到網卡的最高效率，必須在驅動層面實現更復雜的邏輯。
---by shenck
參考文獻：
[1]：Windows 2000下的Raw Socket編程| http://www.cnblogs.com/painmoth/articles/137819.html
[2]：Raw socket編程例解| http://blog.chinaunix.net/uid-21237130-id-159816.html
[3]：MSDN文檔 Tcp/Ip Raw Sockets| http://msdn.microsoft.com/en-us/library/ms740548.aspx
[4]：WinPcap官方技術文檔（中文版）| http://www.ferrisxu.com/WinPcap/html/main.html
[5]：NPF驅動核心指南| http://www.cnblogs.com/coolzgx/archive/2010/01/23/1654537.html
[6]：基於PassThru的NDIS中間層驅動程序擴展| http://www.xfocus.net/articles/200605/865.html
(防掛轉載地址：http://www.cnblogs.com/dubingsky/archive/2009/08/20/1550910.html)
[7]：從Socket Api到Tdi驅動| http://bbs.pediy.com/showthread.php?t=144493
[8]：TDI Overview @CodeMachine| http://codemachine.com/article_tdi.html