下载文档原格式
NDIS中间层驱动包截获技术摘要:简要概括了NDIS的概念，阐述了NDIS的工作流程，详细说明了如何编写NDIS中间层驱动程序以获得网络封包的详细信息。
并且给出了一些代表性的示例代码，供读者参考。
一.NDIS驱动模型简介NDIS(Network Driver InterfaceSpecification)是网络驱动程序接口规范的简称。
它横跨传输层、网络层和数据链路层，定义了网卡或网卡驱动程序与上层协议驱动程序之间的通信接口规范,屏蔽了底层物理硬件的不同,使上层的协议驱动程序可以和底层任何型号的网卡通信。
NDIS为网络驱动程序创建了一个完整的开发环境，只需调用NDIS 函数,而不用考虑操作系统的内核以及与其他驱动程序的接口问题，从而使得网络驱动程序可以从与操作系统的复杂通讯中分离，极大地方便了网络驱动程序的编写。
另外，利用NDIS的封装特性，可以专注于一层驱动的设计，减少了设计的复杂性，同时易于扩展驱动程序栈。
防火墙的开发一般采用的是中间驱动程序。
通过NDIS中间层驱动,我们可以截获来自网卡的所有原始数据包。
图1则是NDIS中间层驱动的工作过程图图1NDIS中间层驱动程序是工作在MINIPROT和PROTOCOL接口之间的,驱动程序必须向下导出一个PROTOCOL接口,向上导出一个MINIPORT接口。
将自己创建的驱动程序插入到网卡驱动程序与传输驱动程序之间。
如此一来，当下层的网卡驱动程序接收到数据后会通过MINIPORT接口发送到我们导出的PROTOCOL接口上，NDIS中间层驱动程序便接收到了来自网卡的数据并调用我们准备好的回调函数处理数据包信息。
接着NDIS中间层驱动在处理数据包完毕后再继续把数据通过导出的MINIPROT接口向PROTOCOL接口发送。
这样就完成了一个截获数据包的过程。
二.NDIS中间层驱动的工作流程在开始学习NDIS中间层驱动之前，我们有必要了解下NDIS是怎样工作的。
当然这就包括了它的接收数据包的流程了。
文章编号：2095-6835（2023）11-0167-03NDIS中间层驱动在防御SQL注入攻击方面的应用李洋，刘婷（湖南信息职业技术学院，湖南长沙410200）摘要：随着Web系统日益普及，它面临的安全风险也越来越受到人们的重视。
以SQL（Structured Query Language，结构化查询语言）注入攻击风险为研究对象，在分析其攻击原理及归纳常见的防御手段后，提出了基于NDIS（Network Driver Interface Specification，网络驱动程序接口规范）中间层驱动的检测和防御技术，为防御SQL注入攻击提供理论参考。
关键词：Web系统；SQL注入攻击；NDIS中间层驱动；防御手段中图分类号：TP393文献标志码：A DOI：10.15913/ki.kjycx.2023.11.051随着信息技术日益发展，越来越多的团体或机构将日常业务放到Web系统上处理，这对Web系统的安全性提出了更高更严的要求。
然而，很多程序员在开发Web系统的过程中没有树立足够的安全意识，使得这些Web系统中或多或少存在着一些安全漏洞。
其中一个比较常见的是SQL注入漏洞，攻击者利用SQL 注入漏洞发起SQL注入攻击以达到窃取用户敏感数据的目的[1]。
本文在分析目前主流的防SQL注入攻击技术的基础上，提出了基于NDIS中间层驱动的防御SQL注入攻击的技术，并对此进行了详细阐述。
1SQL注入攻击以及常见的防御手段1.1SQL注入攻击的原理SQL注入攻击是常见的攻击Web系统的手段之一，非法用户利用程序员在编写代码时没有对用户输入数据的合法性进行漏洞判断，通过提交一段针对性强的数据库查询代码，就可根据程序返回的结果获得想获取的数据[2]。
由于SQL注入是从正常的WWW端口访问，表面上看起来与一般的Web页面访问没什么区别，因此部署在网络上的防御设备不会对这种渗透式的攻击发出警报，SQL注入也就很难在第一时间被发现。
NDIS中间层驱动程序解读第一次接触NDIS是四年前的事了，那时正在做本科毕业设计，题目就是写一块FDDI网卡的NT驱动程序，当时还是NT3.51+NDIS3呢！资料少得可怜，不知从哪里找了一张NT3.51DDK的光盘，如获至宝，夜以继日地研读，有许多地方不知所云，就生吞下去，以盘上唯一的以太网卡例程SONIC为蓝本进行改造，在完成绝大部分功能的编写调试后，终因时间和知识水平的限制，没能完成一个稳定的版本。
在以后的日子里，一直都在与DDK和NDIS打交道，写了几个象样的东西，对它们的了解也有所增加。
早就想把自己的一些心得体会记录下来，与广大同行交流交流，但都因自己的懒惰而没有付诸实现。
此间的斑竹与我有很深的渊源，最近一次见面他说希望我能写些东西以帮助他把这个版办得更好，我想这对我也正好是个促进，就答应了下来，结合我刚刚结束的一个工作，与大家讨论一下NDIS中间层驱动程序的工作原理和编写方法。
以下所写都是我个人的理解，如有不对之处，请大家直言指出，不胜感谢！好了，废话少说，言归正传。
发信人: oneseven (5417), 信区: SysInternals WWW-POST标题: NDIS中间层驱动程序解读（二）发信站: 武汉白云黄鹤站 (Sat Jun 17 22:27:36 2000) , 站内信件中间层驱动程序与其说是一种单独类型的驱动程序，不如说是巧妙地利用NT的网络组件绑定规则对操作系统的欺骗，它非常类似于UNIX的在流机制中压入一个中间处理模块，从原理上讲，它最为关键的地方就是修改NT系统原有的网络组件绑定规则，把自己嵌入已有的处理流程中，所以我想从BIND过程开始讨论。
在Jim matter提供的较早的IMSAMP中，没有提供完善的安装方法，而是在README中教大家手动修改注册表来完成安装，这种方法看起来不太地道（难怪微软没有把其收在DDK中发行）。
好在Jim matter在其后续的版本imdrv中弥补了这个不足，提供了一个INF文件来完成自动安装过程，这个长达112K的文件的确有些晦涩难懂，但是我们可以通过跟踪注册表的变化的方法来清楚地看到整个绑定过程。
NDIS规范下的网络驱动程序设计
冯志林
【期刊名称】《杭州电子科技大学学报》
【年(卷),期】2001(021)004
【摘要】网络驱动程序接口规范(NDIS)是一个较为成熟的网络标准,它包含局域网络网卡驱动程序标准、广域网络驱动程序标准以及存在于协议和网卡之间的中间驱动程序标准.它的一个主要目的就在于将NDIS驱动程序中的一些公用代码提取出来,使得NDIS驱动程序只需和硬件特性有关的少量的代码即可,从而降低了开发的难度并能提高开发效率.本文介绍NDIS 驱动程序的类型,然后以NDIS微端口驱动程序为例介绍NDIS驱动程序的设计,最后介绍NDIS 驱动程序的应用.
【总页数】3页(P61-63)
【作者】冯志林
【作者单位】杭州电子工业学院计算机分院,
【正文语种】中文
【中图分类】TP311.52
【相关文献】
1.基于NDIS hook的Windows防火墙驱动程序设计 [J], 谭丹;鲜继清
2.基于WDM-NDIS体系的USB网卡驱动程序设计 [J], 杨家蓉
3.NDIS中间层驱动程序设计和虚拟专用网客户端的实现 [J], 徐大为;龚玲;杨宇航
4.基于WDM-NDIS体系的USB网卡驱动程序设计 [J], 杨家蓉
5.NDIS驱动程序研究和基于NDIS网络监测程序实现 [J], 孙华领; 顾景文
因版权原因，仅展示原文概要，查看原文内容请购买。
在编写windows网络驱动之前，需要具有必然的运算机网络知识。
包括OSI/ISO 七层体系结构，常见的网络协议TCP/TP, UDP,ICMP,HTTP,FTP,SMTP/POP3等。
因为整个windows网络驱动就是建立在网络协议栈基础之上的。
Windows网络驱动有两个重要的规范：TDI,NDIS。
TDI(Transport Driver Interface)传输层接口，顾名思义，那个技术是成立在传输层之上的。
传输层位于七层协议的第三次，常见的TCP/UDP协议就属于传输层。
咱们明白，传输层提供的服务包括：连接管理、过失检测、按端口号寻址。
事实上，TDI驱动主要作用就是过滤端口。
TDI是即将被淘汰的技术，微软宣布，vista以后的操作系统将再也不提供TDI支持，取代它的是Windows Filter Platform和Winsock Kernel，有兴趣的朋友能够搜集一下相关的资料。
这里注重分析一下NDIS驱动框架。
NDIS（Network Driver Interface Specification）网络驱动接口标准，相较TDI，它位于七层协议的更低层次。
能够捕捉更详细的信息。
能够做更多的事。
它是微软联合3com公司发布的一个标准。
NDIS网络驱动有3种表现形式：协议驱动、中间层驱动、小端口驱动。
它们的作用范围大致依照传输层、网络层、数据链路层依次往下排。
小端口驱动miniport，一般是网卡厂商提供，协议层驱动一般用来捕捉数据包，赫赫出名的winpcap就是基于协议层驱动编写，而本文主要关心中间层驱动。
WDK文档的例子中，提供了一个中间层驱动,我的电脑中的路径是C:\WinDDK\\src\network\ndis\passthru。
Passthru位于协议驱动和小端口驱动之间，比较灵活。
类似于它们两个的综合体。
它能捕捉所有流入流出本机的数据，超级强悍。
常见的个人防火墙大体都是用中间层驱动写的。
NDIS驱动框架探究By AntBeanFearless，Passion，Endure在我看来NDIS驱动有几个难点：1.框架难，NDIS驱动的整体框架跟接触的文件过滤驱动很不一样，你需要考虑的比较多，整个框架的堆叠不再是向文件过滤驱动那样，使用AttachDevice堆叠设备，然后IoCallDriver传递请求；2.硬件操作的敏感性，网卡设备的热插拔，电源状态的变化都会影响到驱动程序；3.系统资源使用的敏感性，NDIS驱动本身是要收包发包，网络包的数据量是非常大的，如果在分配网络封包时没有及时释放，很有可能导致系统资源不足。
本篇文章主要对NDIS驱动框架进行探究。
在介绍内容之前，先说明一些概念。
1.面向连接的网络和无连接的网络与面向连接的协议和无连接的协议面向连接的网络是指通过电路交换进行的局域网。
一台机器如果需要给另外一台机器发送信息，就需要先像打电话一样呼叫另外一台机器，另外一台机器可以接受或者拒绝。
一旦接受，就会使用一个专用的线路维持该连接。
该连接的容量是固定的，而且只归该连接所有。
这种局域网最典型的例子是A TM网络。
无连接的网络是指通过分组交换传输信息的局域网。
一台机器如果给另外一台机器发送信息，需要传输的数据组织成一个分组，发送出去。
所有正在通信的计算机共用一个连接。
典型的例子是以太网和FDDI。
(参见《用TCP/IP进行网际互联第四版》第一卷第二章底层网络技术回顾)以上的面向连接和无连接针对的是物理上的网络硬件，属于OSI七层模型中的物理层；而面向连接的协议和无连接的协议则是针对协议的，与硬件是无关的，属于协议层。
常见的面向连接的协议有TCP协议，无连接的协议有UDP协议。
2. 电源状态D0 D1 D2 D3ACPI规定，设备处于四种状态之一，D0到D3。
D0是完全打开，D3是完全关闭。
D1和D2由驱动程序自己定义。
（参见《深入解析windows操作系统第四版》第九章第五小节电源管理器）3.序列化NDIS驱动和非序列化NDIS驱动对NDIS驱动的请求不再是IRP的形式，而是Packet的形式。
其他驱动例如TDI驱动通过NDIS库函数如NdisSend向NDIS驱动发送请求，事实上NDIS库会对Packet进行排队，保证对NDIS驱动的调用是串行的，一个Packet处理完才会发送另一个Packet给NDIS驱动。
这样的NDIS驱动就叫做序列化的NDIS驱动。
而一个非序列化的NDIS驱动则是指，NDIS库不负责对Packet进行排队和串行化，需要NDIS驱动自己处理同时多个Packet请求的情形。
排队和管理多个并发请求的任务落到了NDIS驱动程序的头上。
（参见《深入解析windows操作系统第四版》第十三章第六小节NDIS驱动程序）NDIS驱动本身分为两种，Protocol Driver和Miniport Driver。
至于NDIS中间层驱动，则是由前两种演化而来。
Miniport Driver用来驱动网卡，Protocol Driver是协议驱动，负责将要发送的数据组装成符合特定Protocol的网络封包然后调用Miniport Driver提供的发送功能完成发送。
也就是说，Protocol Driver和Miniport Driver具有实质意义上的堆叠关系。
Protocol Driver负责网络数据的封包，以及封包的解析获得；而Miniport Driver负责提供物理硬件上的驱动，保证数据包能够正常收发，并通知上层的Protocol Driver。
Miniport Driver和Protocol Driver并不是通过普通意义上的IoAttachDevice进行叠加的。
而是通过NDIS库进行粘合的。
NDIS库要求Miniport Driver和Protocol Driver各自提供符合NDIS要求的接口，供NDIS库在运行时调用。
这个过程类似于C++中的虚函数。
NDIS库要求这Protocol Driver和Miniport Driver各自实现自己那个类的虚函数，而NDIS库自己则是直接调用这些虚函数去完成操作。
下面照样是用具体的代码说事儿。
我将使用ReactOS上面的代码来分析NDIS驱动和NDIS 库之间的关系。
当然，主要参考了毛德操老师的《windows内核情景分析》和ReactOS 0.3.1的代码。
下面如无特殊说明，windows内核均指ReactOS的代码，代码均摘自ReactOS 0.3.1。
必须先声明的是，我不会试图去分析NDIS驱动框架的各个方面。
我将只针对NDIS驱动的初始化和NDIS驱动接收包发送包的流程来说明NDIS库和NDIS驱动的关系。
NDIS驱动初始化过程探究1、miniport driver初始化过程以下代码来自ReactOS提供的NE2000网卡驱动模块。
这是一个典型的实际的miniport 驱动。
为何没有使用先前分析的NDISWDM那个miniport驱动进行框架分析，是因为那是一个虚拟网卡的驱动。
这里采用实际的物理NIC驱动进行分析。
(ReactOS -0.3.1\\Drivers\\Network\\DD\\Ne2000\\Main.c DriverEntry函数）这是我们常见的minport驱动的开头。
把CHARACTERSISTICS中的各个函数指针赋值，然后Register一下。
从ddk中我们很容易就知道MiniportInitialize作为初始化函数会被调用，但事实上，你知道，即使到DriverEntry的末尾，也没有调用CHARA TERISTICS中的任意一个函数。
那问题就是，Miniport的初始化函数到底是何时在哪儿被调用的？好了，面对这个暂时无解的问题，我们唯一的解决方案就是弄清楚NDIS库到底在背后做了些啥我们不知道的事情。
第一反应阅读NDIS库的NdisMRegisterMiniport函数。
刚才我们看到的是一个别人写的miniport驱动的代码，下面我们就会切换到windows 内核当中，查看它里面的NDIS库到底做了啥。
Drivers\\network\\ndis\\ndis\\Miniport.c 函数NdisMRegisterMiniport可以看到，这里先是从传入的NdisWrapperHandle中获得PNDIS_M_DRIVER_BLOCK 然后给该BLOCK的CHARACTERISTICS赋值。
这些都比较简单。
最重要的是，设置了该BLOCK 中的DriverObject的MajorFunction的IRP_MJ_PNP和AddDevice函数。
现在我们来看看，这个唯一支持的IRP_MJ_PNP干啥了。
在该函数中，调用了十分可疑的NdisIPnpStartDevice。
继续跟踪该函数。
我相信你已经看到了那个指针的调用。
这里情况就很明白了，操作系统调用完DriverEntry 后，发送了一个IRP_MJ_PNP的请求，启动miniport设备并调用了miniport的InitializeHandler。
NDIS库所做的就是在注册时默默的为miniport驱动提供了一个IRP_MJ_PNP的操作函数，并默默地调用注册的Characteristics的InitializeHandler。
2、protocol driver初始化过程这里使用ReactOS中提供的协议驱动局域网lan的代码。
drivers\\network\\lan\\lan\\Lan.cDriverEntry中调用了LANRegisterProtocol，下面直接看LANRegisterProtocol同样，也是准备一个Charateristics，然后注册，也是没有看到其中哪个函数的调用。
这回你应该清楚了，我们需要看看NDIS库的NdisRegisterProtocol到底干啥了。
drivers\\network\\ndis\\ndis\\Protocol.c 函数NdisRegisterProtocol该函数中有个For循环，针对从注册表读到的值调用该循环，你仔细看看该循环就会懂得。
该循环中，有个地方你没看错，那就是BindHandler的调用。
在NdisRegisterProtocol中，针对已经存在的每个miniport，调用了注册的BindHandler。
这就是NDIS库为我们做的。
现在，我想你应该已经明白，如果要看Miniport Driver的初始化过程，你应该先读了DriverEntry，然后去读InitializeHandler函数；而如果你要看Protocol Driver的初始化过程，你应该先读了DriverEntry，然后去读BindHandler函数。
这才是完整的初始化过程。
NDIS驱动收包过程探究收包的触发过程，想想也知道首先是网卡收到包后产生一个中断，然后触发上层读取该包。
下面我们将联系刚才的那个miniport driver来看整个过程是怎样在miniport driver和protocol driver中流动的。
在以上miniport driver的初始化过程中一节看到的DriverEntry函数指定了该NIC的中断延迟处理函数为MiniportHandleInterrupt。
下面读该函数。
该函数中根据中断的类型，调用了HandleReceive函数。
HandleRecevie中调用了NICReadPacket，而NICReadPacket又调用了NICIndicatePacket，NICIndicatePacket中又调用了NdisMEthIndicateReceive。
到此为止，我们先分清一下虚实。
这个NdisMEthIndicateReceive是由NDIS库提供的函数。
表示一个以太网封包到了。
显然，我们写的以太网网卡的miniport driver的任务已经完成了。
它在自己的中断延迟处理函数中读取了该Packet，并调用了NdisMEthIndicateReceive通知上层说收到网络封包了。
问题就变成了，当miniport driver调用了NdisMEthIndicateReceive进行通知时，NDIS库到底做了啥，让上层读取该封包的？现在看NdisMEthIndicateReceive。
这是一个宏，指向的是PNDIS_MINIPORT_BLOCK中的EthRxIndicateHandler指针。
该函数指针到底指向哪个函数呢？前面其实我们已经在NdisIPNPStartDevice中见到过。
好吧，你别晕，虽然我也有点晕。
返回去看看，其实指向的是EthFilterDprIndicateReceive()。
再看看该函数干嘛了。
其实也就是调用MiniIndicateData。
