Another Article about NDIS Hook Driver

[The article was copied from http://www.dbgger.com/?id=707]

创建时间:2009-04-25
文章类别:内核研究
文章大小:14628 Bytes

网络防火墙开发二三事
– haoxg –

花了近一个月的时间研究 Windows 平台下的网络防火墙相关技术,并实现了一个简单的防火墙。在独自摸索的过程中,由于以往的开发经历从未涉及此领域,所以碰到了不少困难,也走了些弯路。现此项目暂告一段,遂将相关心得整理成文。文章以归纳总结为主,没有创新性技术,高手免看。

◎ 防火墙的数据包拦截方式小结

网络防火墙都是基于数据包的拦截技术之上的。在 Windows 下,数据包的拦截方式有很多种,其原理和实现方式也千差万别。总的来说,可分为“用户级”和“内核级”数据包拦截两大类。

用户级下的数据包拦截方式有:

* Winsock Layered Service Provider (LSP)。
* Win2K 包过滤接口 (Win2K Packet Filtering Interface)。
* 替换 Winsock 动态链接库 (Winsock Replacement DLL)。

内核级下的数据包拦截方式有:

* TDI过滤驱动程序 (TDI-Filter Driver)。
* NDIS中间层驱动程序 (NDIS Intermediate Driver)。
* Win2K Filter-Hook Driver。
* Win2K Firewall-Hook Driver。
* NDIS-Hook Driver。

在这么多种方式面前,我们该如何决定采用哪一种作为自己项目的实现技术?这需要对每一种方式都有一个大致的了解,并清楚它们各自的优缺点。技术方案的盲目选用往往会带来一些技术风险。以自己为例,我需要在截包的同时得到当前进程文件名,也就是说,需向用户报告当前是哪个应用程序要访问网络。在选用 Win2K Filter-Hook Driver 这一方案之后(很多小型开源项目都采用这一方案),便开始编码。但之后发现 Win2K Filter-Hook Driver 的截包上下文处于内核进程中,即 IRQL >= DISPATCH_LEVEL,根本无法知道当前应用程序的名字。相比之下,TDI-Filter Driver 和 NDIS-Hook Driver 则可以得知这些信息。其中 TDI-Filter Driver比 NDIS-Hook Driver 更能准确地获知当前应用程序文件名,后者的接收数据包和少数发送数据包的场景仍然处于内核进程中。

下面列出了各种截包方式的特点:

* Winsock Layered Service Provider (LSP)
  该方式也称为 SPI (Service Provider Interface) 截包技术。SPI是由 Winsock2 提供的一个
  接口,它需要用户机上安装有 Winsock 2.0。Winsock2 SPI 工作在 API 之下的 Driver 之上,可以截获所有基于 Socket 的网络数据包。
  优点:
  * 以DLL形式存在,编程方便,调试简单。
  * 数据封包比较完整,未做切片,便于做内容过滤。
  缺点:
  * 拦截不够严密,对于不用 Socket 的网络通讯则无法拦截 (如 ICMP),木马病毒很容易绕过。

* Win2K Packet Filtering Interface
  这是 Win2K 中一组 API 提供的功能 (PfCreateInterface, PfAddFiltersToInterface, …)。
  优点:
  * 接口简单,实现起来没什么难度。
  缺点:
  * 功能过于简单,只能提供IP和端口的过滤,可能无法满足防火墙的复杂需求。
  * 处于 API 层,木马病毒容易绕过。
  * 只能在 Win2K 以上(含)系统中使用。

* Winsock Replacement DLL
  这种方法通过替换系统 Winsock 库的部分导出函数,实现数据报的监听和拦截。
  缺点:
  * 由于工作在 Winsock 层,所以木马病毒容易绕过。

* TDI-Filter Driver
  TDI 的全称是 Transport Driver Interface。传输层过滤驱动程序通过创建一个或多个设备对象  直接挂接到一个现有的驱动程序之上。当有应用程序或其它驱动程序调用这个设备对象时,会首先映射到过滤驱动程序上,然后由过滤驱动程序再传递给原来的设备对象。
  优点:
  * 能获取到当前进程的详细信息,这对开发防火墙尤其有用。
  缺点:
  * 该驱动位于 tcpip.sys 之上,所以没有机会得到那些由 tcpip.sys 直接处理的包,比如ICMP。
  * TDI驱动需要重启系统方能生效。

* NDIS Intermediate Driver
  也称之为 IM Driver。它位于协议层驱动和小端口驱动之间,它主要是在网络层和链路层之间对所有的数据包进行检查,因而具有强大的过滤功能。它能截获所有的数据包。可参考DDK中附带的例子 Passthru。
  优点:
  * 功能非常强大,应用面广泛,不仅仅是防火墙,还可以用来实现VPN,NAT 和 VLan 等。
  缺点:
  * 编程复杂,难度较大。
  * 中间层驱动的概念是在 WinNT SP4 之后才有的,因此 Win9X 无法使用。
  * 不容易安装,自动化安装太困难。

* Win2K Filter-Hook Driver
  这是从 Win2K 开始提供的一种机制,该机制主要利用 ipfiltdrv.sys 所提供的功能来拦截网络数据包。Filter-Hook Driver 的结构非常简单,易于实现。但是正因为其结构过于简单,并且依赖于 ipfiltdrv.sys,微软并不推荐使用。可参考 CodeProject 上的例子:http://www.codeproject.com/KB/IP/drvfltip.aspx
  优点:
  * 结构简单,易于实现。
  * 能截获所有的IP包(包括ICMP包)。
  缺点:
  * 工作于内核进程中,无法取得当前应用程序进程的信息。
  * 虽能截获所有IP包,但无法取得数据包的以太帧(Ethernet Frame)。
  * 只能在 Win2K 以上(含)系统中使用。

* Win2K Firewall-Hook Driver
  这是一种和 Win2k Filter-Hook Driver 差不多的机制,所不同的是,Firewall-Hook Driver
  能在 IP Driver 上挂接多个回调函数,所以和前者相比,它引起冲突的可能性更小一些。
  可参考 CodeProject 上的例子:http://www.codeproject.com/KB/IP/FwHookDrv.aspx
  这种方式的优缺点和 Win2K Filter-Hook Driver 基本相同。

* NDIS-Hook Driver
  这是一种要重点讲述的截包方式。它是目前大多数网络防火墙所使用的方法。这种方式的做法是安装钩子到 ndis.sys 中,替换其中的某些关键函数,从而达到截包的目的。在下一节中我们将详细地介绍它的实现方法。
  优点:
  * 安装简单,可即时安装和卸载驱动,无需重启系统。
  * 能截获所有的IP包,同时能取得数据包的以太帧(Ethernet Frame)。
  * 安全性高,木马病毒不容易穿透。
  * 在大多数情况下,能获取到当前应用程序的进程信息。
  * 能在 Win98 以上(含)系统中使用。
  缺点:
  * 接收数据包、或偶尔发送数据包时,驱动工作在内核进程中,无法获得应用程序进程信息。

◎ NDIS-Hook 技术

微软和 3COM 公司在1989年制定了一套开发 Windows 下网络驱动程序的标准,称为 NDIS。NDIS 的全称是 Network Driver Interface Specification。NDIS为网络驱动的开发提供了一套标准的接口,使得网络驱动程序的跨平台性更好。

NDIS提供以下几个层次的接口:
1. NDIS 小端口驱动 (NDIS Miniport Driver)。这也就是我们常说的网卡驱动。
2. NDIS 协议驱动 (NDIS Protocol Driver)。用来实现某个具体的协议栈,如 TCP/IP 协议栈,并向上层导出 TDI 接口。
3. NDIS 中间层驱动 (NDIS Intermediate Driver)。这是位于小端口驱动和协议驱动之间的驱动。

NDIS为了给出上述三种接口,提供了一个系统的、完整的 Wrapper。这个 Wrapper 即 ndis.sys。上面提到的 Miniport Driver、Protocol Driver、Intermediate Driver 均属于插入到这个Wrapper 中的“模块”,它们调用 Wrapper 提供的函数,同时也向 Wrapper 注册回调函数。

在简单了解了NDIS的机制之后,不难得知,网络防火墙只需要将自己的函数挂钩(Hook)到 ndis.sys中即可截获网络数据包。NDIS-Hook 技术有两种实现方案:

1. 修改 ndis.sys 的 Export Table。

在 Win32 下,可执行文件(EXE/DLL/SYS)都遵从PE格式。所有提供接口的驱动都有 Export Table,因此只要修改 ndis.sys 的 Export Table,就可实现对关键函数的挂接。在实现步骤中,首先需要得到 ndis.sys 的内存基址,再根据PE格式得到DOS头部结构(IMAGE_DOS_HEADER),进一步得到NT头部结构(IMAGE_NT_HEADER),最后从头部结构中查得 Export Table 的地址。

由于协议驱动程序(NDIS Protocol Driver)在系统启动时会调用 NdisRegisterProtocol() 来向系统注册协议,因此这种方法关键在于修改 ndis.sys 所提供的 NdisRegisterProtocol、
NdisDeRegisterProtocol、NdisOpenAdapter、NdisCloseAdapter、NdisSend 这几个函数的地址。对于处于系统核心的 ndis.sys 而言,要修改它的内存区域,只有驱动程序才能做到,所以我们必须编写驱动程序来达到这个目的。

该方案的缺点是加载或卸载驱动后无法立即生效,必须重启系统。且挂钩方法较为复杂。早期凡使用 NDIS-Hook 的防火墙都采用这一方法,包括著名的费尔防火墙的早期版本(v2.1)。直到 2004 年,www.rootkit.com 上一名黑客公布了一种全新的 NDIS-Hook 技术(即下文即将提到的第2种方法),诸多防火墙产品才都悄悄对自己的核心技术进行了升级。由于新的挂钩技术更好,故本文不打算详述修改 Export Table 这一方法的具体细节。

2. 向系统注册假协议(Bogus Protocol)。

NDIS提供了一个API: NdisRegisterProtocol(),这个API的职责是向系统注册一个协议(如TCPIP),并将该协议作为一个链表节点插入到“协议链表”的头部,最后返回该链表头节点(即新节点)的地址。正常情况下,只有NDIS协议驱动程序(NDIS Protocol Driver)才会调用这个API。

既然如此,如果我们也调用 NdisRegisterProtocol() 向系统注册一个新的协议,我们也就能轻易地得到“协议链表”的首地址,通过走访这个链表,就能修改其中的某些关键信息,比如关键函数的地址。修改完毕后,再调用 NdisDeRegisterProtocol() 注销掉新协议。这看似一切都没发生,但事实上目的已经达到了。这个新协议我们称之为假协议(Bogus Protocol)。

通过这种方法,我们可以不用重启系统就能轻松挂接截包函数。当今大多数网络防火墙都采用了这一方法。近来网上又有人提出了获取协议链表首地址的新的怪异途径,比如获取 tcpip.sys 中全局变量 _ARPHandle 值的方法。不管怎样,相比之下,注册假协议仍不失为一种经典且简单的方法。

本文将详细叙述第2种方案的内部原理和实现细节,即通过注册假协议获取协议链表首地址,遍历链表并修改其中的函数地址,挂钩自己的函数,从而实现网络截包。在这么做之前,需要先对NDIS内部维护的几个结构有清楚的认识。另外,由于历史原因,NDIS存在诸多并不完全向下兼容的版本,不同的版本中关键数据域的偏移地址也不尽相同。微软并没有以文档形式提供这些变化的列表。本文稍后给出这些变化。

* NDIS_PROTOCOL_BLOCK 和 NDIS_OPEN_BLOCK

在NDIS中,所有已注册的协议是通过一个单向的协议链表来维护的。这个单向链表保存了所有已注册的协议,每个协议对应一个节点。链表节点由 NDIS_PROTOCOL_BLOCK 结构来描述,在这个结构中保存了注册协议驱动时所指定的各种信息,如支持协议即插即用的回调函数地址等。同时,每个协议驱动还对应一个 NDIS_OPEN_BLOCK 节点结构的单向链表来维护其所绑定的网卡信息,协议驱动发送和接收数据包的回调函数地址就保存在这个结构中,是我们要重点修改的对象。

协议与网卡绑定的示意图如下:

              ┌───┐
              │ Head │
              └─┬─┘
                      ↓
    ┌──────────────┐      ┌───────────┐
    │ TCPIP Protocol Block                 ├→│ RTL8168 Open Block      │
    └──────┬───────┘      └─────┬─────┘
                              ↓                                                           ↓
    ┌──────────────┐      ┌───────────┐
    │ TCPIP_WANARP Protocol Block│      │ Wireless Open Block       │
    └──────┬───────┘      └─────┬─────┘
                              ↓                                                           ↓         
                     ┌───┐                                           ┌───┐
                     │ NULL │                                           │ NULL │
                     └───┘                                            └───┘

* 得到 NDIS_PROTOCOL_BLOCK 链表的首地址

上文已提到,通过向系统注册假协议,我们即可得到协议链表的首地址。从DDK中可查到 NdisRegisterProtocol() 的原型:

EXPORT
    VOID
    NdisRegisterProtocol(
        OUT PNDIS_STATUS   Status,
        OUT PNDIS_HANDLE   NdisProtocolHandle,
        IN  PNDIS_PROTOCOL_CHARACTERISTICS ProtocolCharacteristics,
        IN  UINT           CharacteristicsLength
        );

可以看出,我们在调用它时需要传入一个结构 NDIS_PROTOCOL_CHARACTERISTICS,这个结构是我们在注册协议时必须填写的一张表格,这个表格描述了协议的相关信息。不过既然我们注册的是一个假协议,所以可以尽量简单地填写它。

NDIS_STATUS
    DummyNdisProtocolReceive(
        IN NDIS_HANDLE ProtocolBindingContext,
        IN NDIS_HANDLE MacReceiveContext,
        IN PVOID HeaderBuffer,
        IN UINT HeaderBufferSize,
        IN PVOID LookAheadBuffer,
        IN UINT LookAheadBufferSize,
        IN UINT PacketSize
        )
    {
        return NDIS_STATUS_NOT_ACCEPTED;
    }

NDIS_HANDLE
    RegisterBogusNdisProtocol(void)
    {
        NTSTATUS Status = STATUS_SUCCESS;
        NDIS_HANDLE hBogusProtocol = NULL;
        NDIS_PROTOCOL_CHARACTERISTICS BogusProtocol;
        NDIS_STRING ProtocolName;

NdisZeroMemory(&BogusProtocol, sizeof(NDIS_PROTOCOL_CHARACTERISTICS));
        BogusProtocol.MajorNdisVersion = 0x04;
        BogusProtocol.MinorNdisVersion = 0x0;

NdisInitUnicodeString(&ProtocolName, L”BogusProtocol”);
        BogusProtocol.Name = ProtocolName;
        BogusProtocol.ReceiveHandler = DummyNdisProtocolReceive;

NdisRegisterProtocol(&Status, &hBogusProtocol, &BogusProtocol,
            sizeof(NDIS_PROTOCOL_CHARACTERISTICS));

if (Status == STATUS_SUCCESS) return hBogusProtocol;
        else return NULL;
    }

函数 RegisterBogusNDISProtocol() 的返回值即是我们想要的协议链表首地址。不过须注意的是,在函数挂钩完成后,应调用 NdisDeregisterProtocol() 将假协议注销。另外,在遍历协议链表进行函数挂钩时,应从首节点的下一个节点开始,因为首节点是我们的假协议节点。

* 修改原有函数地址值实现函数挂钩

上文已提到了和NDIS相关的三个结构:
NDIS_PROTOCOL_BLOCK,
NDIS_OPEN_BLOCK,
NDIS_PROTOCOL_CHARACTERISTICS。

那么我们要替换的函数在哪儿呢?答案是在 NDIS_OPEN_BLOCK 和 NDIS_PROTOCOL_CHARACTERISTICS 这两个结构中,而且重点是前者,因为前者是协议驱动和网卡绑定的纽带。现在的主流网卡都只调用 NDIS_OPEN_BLOCK 中的收发函数进行发送和接收数据包。但据试验,虚拟机 VMware 有时会调用NDIS_PROTOCOL_CHARACTERISTICS 中的函数进行数据包收发。所以为了严谨,我们应该对两个结构中的函数进行替换。关于这两个结构的定义,读者可以自行查阅DDK文档和头文件。下面给出示意性代码。简单起见,下列代码均假设当前NDIS的版本为5.0。

BOOLEAN
    InstallHook(void)
    {
        NDIS_STATUS nStatus;
        NDIS_HANDLE hBogusProtocol = NULL;
        BYTE *pProtocolChain;

        // Get the address of the first NDIS_PROTOCOL_BLOCK node.
        hBogusProtocol = RegisterBogusNDISProtocol();
        if (hBogusProtocol == NULL) return FALSE;

        pProtocolChain = (BYTE*)hBogusProtocol;
        while (TRUE)
        {
            // Get the address of the next node.
            DWORD dwOffset = 0x10;  // for NDIS 5.0
            pProtocolChain = ((BYTE **)(pProtocolChain + dwOffset))[0];
            if (!pProtocolChain) break;

            HookNdisProtocolBlock(pProtocolChain);
        }

        NdisDeregisterProtocol(&nStatus, hBogusProtocol);
        return TRUE;
    }

void
    HookNdisProtocolBlock(
        IN  BYTE *pProtocolBlock
        )
    {
        PNDIS_PROTOCOL_CHARACTERISTICS pProtoChar;
        PNDIS_OPEN_BLOCK pOpenBlock;

        pProtoChar = (PNDIS_PROTOCOL_CHARACTERISTICS)(pProtocolBlock + 0x14);

        HookNdisProc(MyReceive, (PVOID *)&pProtoChar->ReceiveHandler);
        HookNdisProc(MyReceivePacket, (PVOID *)&pProtoChar->ReceivePacketHandler);
        HookNdisProc(MyBindAdapter, (PVOID *)&pProtoChar->BindAdapterHandler);

        pOpenBlock = ((PNDIS_OPEN_BLOCK *)pProtocolBlock)[0];
        while (pOpenBlock)
        {
            HookNdisProc(MySend, (PVOID *)&pOpenBlock->SendHandler);
            HookNdisProc(MyReceive, (PVOID *)&pOpenBlock->ReceiveHandler);
            HookNdisProc(MyReceivePacket, (PVOID *)&pOpenBlock->ReceivePacketHandler);
            HookNdisProc(MySendPackets, (PVOID *)&pOpenBlock->SendPacketsHandler);

            pOpenBlock = pOpenBlock->ProtocolNextOpen;
        }
    }

void
    HookNdisProc(
        IN  PVOID pMyProc,
        IN  PVOID *ppOrgProc
        )
    {
        // TODO: Save the address of the original proc.

        *ppOrgProc = pMyProc;
    }

InstallHook() 首先得到协议链表的首地址,接着遍历链表,针对系统中的每个(第一个除外)
NDIS_PROTOCOL_BLOCK 调用 HookNdisProtocolBlock() 函数。HookNdisProtocolBlock() 对 NDIS_PROTOCOL_BLOCK 中 NDIS_PROTOCOL_CHARACTERISTICS 和NDIS_OPEN_BLOCK 链表的每个节点进行函数挂接。HookNdisProc() 用于替换函数地址。给出的代码中它只是简单地替换函数地址,在实际应用中,它还应当保存原始函数的地址值,以供新的函数调用。

* 关键数据域在不同NDIS版本中的差异

由于 NDIS-Hook 并非受微软官方支持的技术,所以相关文档非常缺乏。不仅如此,操作系统的每次升级,都会同时升级NDIS,而NDIS中的某些数据结构并没有保持向下兼容。最需要注意的是 NDIS_PROTOCOL_BLOCK。

在 Win9x/Me/NT 的DDK中,NDIS_PROTOCOL_BLOCK 都有明确的定义,但在Win2K/XP 的DDK中,并没有该结构的详细定义,也就是说该结构在 Win2K 以后(含)的系统中是非公开的。因此开发人员只能利用各种调试工具来发掘该结构的详细定义。也正是因为如此,NDIS-Hook 方法对平台的依赖性比较大,需要在程序中判断不同的操作系统版本而使用不同的结构定义。

NDIS_PROTOCOL_BLOCK 的定义可大致认为是这个样子:

typedef struct _NDIS_PROTOCOL_BLOCK
    {
        PNDIS_OPEN_BLOCK              OpenQueue;
        REFERENCE                     Ref;
        UINT                          Length;
        NDIS_PROTOCOL_CHARACTERISTICS ProtocolChars;

struct _NDIS_PROTOCOL_BLOCK*  NextProtocol;
        ULONG                         MaxPatternSize;

        // …
    } NDIS_PROTOCOL_BLOCK, *PNDIS_PROTOCOL_BLOCK;

其中 OpenQueue 为 PNDIS_OPEN_BLOCK 链表的首节点地址,NextProtocol 指向下一个
NDIS_PROTOCOL_BLOCK 节点。在不同的NDIS版本中,该结构中的某些域的偏移地址是不同的,现列于下:

┌───────┬───────────┬───────────┐
  │ NDIS Version │ ProtocolChars offset │ NextProtocol offset  │
  ├───────┼───────────┼───────────┤
  │   3.XX       │        0x14          │        0x04          │
  │   4.XX       │        0x14          │        0x60          │
  │   4.01       │        0x14          │        0x8C          │
  │   5.XX       │        0x14          │        0x10          │
  └───────┴───────────┴───────────┘

* 如何在驱动中得到当前NDIS版本?

有两种方法可得到当前NDIS版本。一种是先取得当前操作系统的版本信息,在根据操作系统的版本得到NDIS的版本。操作系统版本和NDIS版本有一个映射关系,读者可在DDK帮助中查到。

┌───────┬───────┐
  │ OS Version   │ NDIS Version │
  ├───────┼───────┤
  │ Win95        │     3.1      │
  │ Win95 OSR2   │     4.0      │
  │ Win98        │     4.1      │
  │ Win98 SE     │     5.0      │
  │ WinMe        │     5.0      │
  │ WinNT 3.5    │     3.0      │
  │ WinNT 4.0    │     4.0      │
  │ WinNT 4.0 SP3│     4.1      │
  │ Win2K        │     5.0      │
  │ WinXP        │     5.1      │
  │ WinVista     │     6.0      │
  └───────┴───────┘

还有一种方法,通过调用 NdisReadConfiguration() 直接获取NDIS版本。代码如下:

BOOLEAN
    GetNdisVersion(
        OUT DWORD *pMajorVersion,
        OUT DWORD *pMinorVersion
        )
    {
        NDIS_STATUS nStatus;
        NDIS_STRING VersionStr = NDIS_STRING_CONST(“NdisVersion”);
        PNDIS_CONFIGURATION_PARAMETER ReturnedValue;
        BOOLEAN bResult;

        NdisReadConfiguration(
            &nStatus,
            &ReturnedValue,
            NULL,
            &VersionStr,
            NdisParameterInteger);

        bResult = ((nStatus == NDIS_STATUS_SUCCESS)? TRUE : FALSE);
        if (bResult)
        {
            //
            // The returned value has the NDIS version of the form
            // 0xMMMMmmmm, where MMMM is major version and mmmm is minor
            // version so 0x00050000 is 5.0
            //
            DWORD dwVersion = ReturnedValue->ParameterData.IntegerData;
            if (pMajorVersion)
                *pMajorVersion = dwVersion >> 16;
            if (pMinorVersion)
                *pMinorVersion = dwVersion & 0xFFFF;
        }

        return bResult;
    }

须注意的是,GetNdisVersion() 必须在 PASSIVE_LEVEL 下运行。所以此函数适合于在
驱动的 DriverEntry() 中调用,因为 DriverEntry() 一定是处于 PASSIVE_LEVEL 的。

Advertisements

Posted on August 31, 2010, in Uncategorized. Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: