Windows下底层数据包发送实战

时间:2023-12-24 12:25:07

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是如何实现的呢?

Windows下底层数据包发送实战

  左图是来自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下的网络操作也遵循上面那句话,一个简单的操作将会在若干个层次间传递,直到在最底层真正完成。

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”,说明环境已经配好,是不是很方便呢。

Windows下底层数据包发送实战

Step2 [修改&编译Ndisprot项目]

  从这里下载范例代码,解压后找到项目文件夹NDIS Connection-less Protocol Driver Sample,打开Solution\sys\630\ndisprot630.vcxproj

  首先选择合适的编译配置和平台,设置平台工具集为“WindowsKernelModeDriver8.1”,再按确认重新编译:

Windows下底层数据包发送实战

  再次打开ndisprot630的项目属性,可看到左侧多出了属性页。打开VC++目录属性页中“x86”为“x64”。打开属性页C/C++—>高级,检查调用约定是否设置为__stdcall,剩余设置基本上保持默认。

Windows下底层数据包发送实战

  打开Driver Signing—>General属性页,Sign Mode选择“Test Sign”,Test Certificate选择“Create Test Certificate”创建一个新的测试签名

Windows下底层数据包发送实战

  设置部分就到这里,下面对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;
}

  修改完后编译即可,编译完后生成如下文件:

Windows下底层数据包发送实战

ndisprot630.cer  ......    驱动的数字签名

ndisprot630.inf   ......    驱动信息(安装用)

ndisprot630.sys   ......    驱动程序

  查看sys文件属性中数字签名的详细信息,如果数字签名处显示“此数字签名正常”则该驱动已正常签名,可以安装了。如果未提示正常,则先安装cer证书文件,将证书导入到“受信任的根证书颁发机构”。(重启后生效)另外,如果后续安装中出现驱动无法启动的情况,多半因为签名无效问题,在Win7 64位之后,微软禁止具有无效数字签名的驱动运行(但可以安装)。除了测试签名外,还可以用专门的签名工具为驱动签名,比如“驱网签名工具”,用这些工具签名非常方便,但未付费版都有次数限制。

Step3 [安装 & 运行]

  首先启动Windows的测试模式,以管理员权限执行命令”bcdedit /set testsigning on“,重启后桌面右下角出现”测试模式“标签,命令中的on改成off可关闭测试模式。第二步需要禁止驱动程序强制签名:(Windows8.1 64位只能这么操作)

Windows下底层数据包发送实战

  点击“立即重启”后,按F7选择“禁止驱动程序强制签名”后系统重启。重启后可以就可以安装刚才编译的驱动了,步骤如下:打开网络适配器属性后,点击“安装”,选择“协议”安装,再选择“从磁盘安装”,再选择刚才编译完的inf准备安装,如果出现安装未签名的警告,选继续安装。
Windows下底层数据包发送实战  安装后所有适配器的协议中出现“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