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,,)//创建一个原始套接字
使用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的使用非常简单，用它发送一个以太网帧的代码如下：
#include <stdlib.h>
#include <stdio.h> #include <pcap.h> void main(int argc, char **argv)
{
pcap_t *fp;
char errbuf[PCAP_ERRBUF_SIZE];
u_char packet[]; /* 打开输出设备 */
if ((fp = pcap_open(argv[], // 设备名
, // 要捕获的部分 (只捕获前100个字节)
PCAP_OPENFLAG_PROMISCUOUS, // 混杂模式
, // 读超时时间
NULL, // 远程机器验证
errbuf // 错误缓冲
)) == NULL)
{
fprintf(stderr, "\nUnable to open the adapter. %s is not supported by WinPcap\n", argv[]);
return;
}
/*
此处省略填充packet内容代码：填充以太网帧头、IP头等
*/ /* 发送数据包 */
if (pcap_sendpacket(fp, packet, /* size */) != )
{
fprintf(stderr, "\nError sending the packet: \n", pcap_geterr(fp));
return;
}
return;
}
上述代码发送了一个以太网帧，可分为三步：打开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) + ))
{
break;
} pEthType = (USHORT UNALIGNED *)((PUCHAR)&pEthHeader->EthType + ); 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