Comments

• 2010年05月12日, 玄风残翼 writes: 我是来顶你的。
• 2010年08月6日, pk8995 writes: 我X，我也碰到这事了。 必须用同步的才行，原来是个BUG……
• 2011年01月18日, kkmylove writes: 留个名 顶

Related posts:

• About Handling Nmi

随机日志

• 2009年12月27日 -- Symbian_S60_3rd_Application_Cracking_With_IDA_Remote_Debugger_Tutorial
• 2010年01月12日 -- MS07-014调试手记
• 2008年09月30日 -- [国庆礼]Exploiting Windows Device Drivers译文版
• 2009年05月1日 -- 暴风影音2009(Config.dll)ActiveX远程栈溢出漏洞
• 2010年02月21日 -- Step deeply into NDIS6 LightWeight Filter, part 1
• 2008年10月22日 -- 构造无人之境: Exploiting Realtek RTL8139单芯片以太网控制器
• 2008年11月16日 -- [转载]在英特尔软件网络博客上看到的
• 2011年04月8日 -- Microsoft Windows xp AFD.sys Local Kernel DoS Vulnerability
• 2008年10月19日 -- [POC]基于IO Packet隐藏文件和注册表，过磁盘解析和总线解析
• 2009年05月1日 -- 暴风影音2009(mps.dll)ActiveX远程栈溢出漏洞

[NOTE]: 本文基于WIN7，基于一个NDIS LWF Monitor项目。 

  我们从NDIS的驱动栈开始，系统在启动的时候(IoInitSystem…)会加载系统驱动，典型的比如卷过滤驱动Volsnap是从IopInitializeBootDrivers的IopInitializeBuiltinDriver中启动的，一般的Filter Driver则是在IopInitializeSystemDrivers的时候加载的，而各层的DriverEntry的顺序不一定按栈自底向上走(比如TCPIP调用NdisRegisterProtocolDriver，比Miniport的注册早)，但是各自初始化完了，NDIS会接管开始调整栈结构，依次调用Miniport的MiniportInitializeEx，LightWeight Filter的FilterAttach，到最后的Protocol的ProtocolBindAdapterEx。

  {DriverEntry}

  挑我们感兴趣的，LWF的DriverEntry，略过初始化全局变量，读注册表等等，剩下关键点有两个：

  1) NdisFRegisterFilterDriver

       NdisFRegisterFilterDriver函数本身到底做了什么？

        1) 填充一个NDIS_FILTER_DRIVER_BLOCK；
        2) 调用SetOptionsHandler，返回成功则继续把填充的结构链接进ndisFilterDriverList；
        3) 检查下层Miniport是否可以把Filter Attach上去，如果Filter都加载了，那么Queue一个BindWorkitem，让Protocol有机会进行绑定。

       [NOTE1]: SetOptionsHandler先于FilterAttach，是第一个被调用的入口函数。但是实际上SetOptionsHandler在目前的WIN版本中只是STUB，能做什么大家自己发掘。
       [NOTE2]: NdisFRegisterFilterDriver的第四个参数是个OUT宏修饰的类型，它返回的实际上就是填充的PNDIS_FILTER_DRIVER_BLOCK。

  2) NdisRegisterDeviceEx

        一般情况下，驱动开发人员会在DriverEntry里创建Device方便与应用层通讯。
        而在LWF的DriverEntry里，你可以使用NdisRegisterDeviceEx创建一个Root Device以供通信，典型的用途是IRP_MJ_DEVICE_CONTROL枚举所有的网络接口。

        值得大书一笔的是，NdisRegisterDeviceEx创建的Device，要获取DeviceExtension(开发人员定义的那部分)必须使用NdisGetDeviceReservedExtension。原因在于，NdisRegisterDeviceEx在申请Extension的空间后，会自己预先创建一个类似DeviceExtension Header的结构加在你定义的DeviceExtension前面。

        具体NdisRegisterDeviceEx会做什么？略过其他情况，我们只关心Filter Driver里调用这个函数。

        首先，它从第一个参数NdisObjectHandle(记得刚才我们说过，这个参数实际上就是一个PNDIS_FILTER_DRIVER_BLOCK)里获取DriverObject；
        然后，IoCreateDevice，IoCreateSymbolicLink，之后拿到DeviceObject->DeviceExtension，填充它的开头的0xA0部分，0xA0之后是用户自己定义的部分，在偏移0×14的存放着一个指针，指向0xA0之后，而NdisGetDeviceReservedExtension正是获取DeviceObject->DeviceExtension + 0×14这个指针。
        另外，0×0偏移是个Type，被赋值为9(我不太清楚到底是什么，应该是和CDO关联的)，而传入的参数DeviceAttribute.MajorFunctions将被拷贝到偏移0×18处。
        在这个函数内部有个地方是要值得注意的，如果是Filter Driver调用的这个函数，那么会有这么一句：
          memset(DriverObject->MajorFunction, ndisDummyIrpHandler, sizeof(DriverObject->MajorFunction));
        作用显而易见，而在ndisDummyIrpHandler函数里会判断Type，是17的放过，是9的则调用DeviceExtension + 0×18处的MajorFunction。

        之后在FilterAttach里我们会再解释上面没提到的其他偏移值，这里先Mark。

  /////////////////////////////////

  对于NDIS6 Filter来说，NDIS_FILTER_DRIVER_CHARACTERISTICS是整个Filter的主体。

  [NOTE]: 关于Filter状态的入口函数是必须提供的，包括：FilterAttach，FilterDetach，FilterRestart，FilterPause。

  {FilterAttach}

  Q1: FilterAttach函数的调用过程?

   撇开问题，我们先回过头去看NDIS驱动栈的构造初期，有几个函数，我们看看他们都具体做了什么：

     NdisRegisterProtocolDriver(NDIS6)，NdisFRegisterFilterDriver(NDIS6)，NdisMRegisterMiniportDriver(NDIS6)，NdisMRegisterMiniport，NdisIMRegisterLayeredMiniport，NdisRegisterProtocol等

   首先看Miniport，我们以NdisMRegisterMiniportDriver为例，NDIS5或者之前的NdisMRegisterMiniport等会调用ndisRegisterMiniportDriver，但是函数内部过程都是类似的。

    1) 调用IoAllocateDriverObjectExtension创建一个NDIS_M_DRIVER_BLOCK结构，填充之；
    2) 填充DriverObject->MajorFunction，将ndisPnPAddDevice赋值给DriverObject->DriverExtension->AddDevice；
    3) 调用SetOptionsHandler，将NDIS_M_DRIVER_BLOCK链接进ndisMiniDriverList。

    [NOTE]: 同样的，NdisMRegisterMiniportDriver的第四个参数NdisMiniportDriverHandle其实就是PNDIS_M_DRIVER_BLOCK*类型。

    而在系统启动的过程中，将由PNP Mgr负责遍历并调用各PNP驱动的AddDevice，如：

      nt!KiThreadStartup+0×19
      nt!PspSystemThreadStartup+0x9e
      nt!ExpWorkerThread+0x10d
      nt!PnpDeviceActionWorker+0×241
      nt!PiProcessStartSystemDevices+0x6d
      nt!PipProcessDevNodeTree+0x15d
      nt!PipCallDriverAddDevice+0×565
      nt!PnpCallAddDevice+0xb9
      nt!PpvUtilCallAddDevice+0×19
      ndis!ndisPnPAddDevice+0x5db
      ndis!ndisAddDevice+0x6e4

    我们跟进ndisAddDevice，它做的事很多很繁琐：

     1) IoGetDriverObjectExtension获取Driver Extension，实际上就是之前的NDIS_M_DRIVER_BLOCK结构；
     2) IoCreateDevice创建设备，然后IoAttachDeviceToDeviceStack，再IoCreateSymbolicLink；
     3) 获取DeviceObject->DeviceExtension，按照NDIS_MINIPORT_BLOCK结构填充之，注意这里Type被赋值为17；
     4) 调用ndisInitializeConfiguration进行配置信息的填充，其内部再调用ndisReadMiniportFilterList填充LWFilterList；
     5) IoRegisterDeviceInterface注册一个设备接口；
     6) 将填充完的NDIS_MINIPORT_BLOCK链接进ndisMiniportList。

   然后我们看NdisRegisterProtocolDriver：

    1) 分配一个NDIS_PROTOCOL_BLOCK结构，填充之；
    2) 调用SetOptionsHandler，将填充完的NDIS_PROTOCOL_BLOCK链接进ndisProtocolList；
    3) 调用ndisQueueWorkItem，入队一个工作者例程ndisCheckProtocolBindings。

   现在我们回到问题，FilterAttach是什么时候被调用的？  

    nt!KiThreadStartup+0×19
    nt!PspSystemThreadStartup+0x9e
    ndis!ndisWorkerThread+0xa4
    ndis!ndisCheckProtocolBindings+0x11b
    ndis!ndisCheckMiniportFilters+0×105
    ndis!ndisAttachFilterToMiniport+0xa9b
     ndisFindFilterPosition
     xxx!xxxFilterAttach

    我们看ndisAttachFilterToMiniport，它被调用的时候是这样的：
      ndisAttachFilterToMiniport(CurFilterDriver, NULL, MiniBlock);
    其中，MiniBlock来自ndisMiniDriverList里的MiniportQueue，CurFilterDriver来自ndisFilterDriverList。

    ndisFindFilterPosition原型如下：
     BOOLEAN ndisFindFilterPosition(
         IN PNDIS_MINIPORT_BLOCK NdisMiniBlock,
         IN PUNICODE_STRING LowerFilterName,
         IN PUNICODE_STRING UniqueName,
         IN UCHAR FilterFlag,
         OUT PUNICODE_STRING *RetName,        
         OUT PNDIS_FILTER_BLOCK *LowerFilter,
         OUT PNDIS_FILTER_BLOCK *HigherFilter
         );
-
其中RetName依次经历MiniBlock->LWFilterList -> FilterInstanceName -> FilterModuleGuidName。

    ndisAttachFilterToMiniport会创建一个NDIS_FILTER_BLOCK结构，填充之后链接进ndisGlobalFilterList。
    接下来是填充FilterAttach所需要的第三个参数NDIS_FILTER_ATTACH_PARAMETERS，基本上都是来自于MiniBlock，有兴趣的可以自己跟一下。
    然后调用CurFilterDriver->DefaultFilterCharacteristics.AttachHandler，第一个参数就是创建的NDIS_FILTER_BLOCK，第二个参数是CurFilterDriver->FilterDriverContext，也就是NdisFRegisterFilterDriver的第二个参数返回值。

  Q2: FilterAttach函数该怎么写?

   代码只为演示，请勿直接使用。

-
    NDIS_STATUS
    NetmonFilterAttach(
        IN NDIS_HANDLE NdisFilterHandle,
        IN NDIS_HANDLE FilterDriverContext,
        IN PNDIS_FILTER_ATTACH_PARAMETERS AttachParameters
        )
    /*++

    Routine Description:

    Arguments:

    Return Value:

    –*/

    {
        PMS_FILTER pFilter = NULL;
        NDIS_STATUS Status = NDIS_STATUS_FAILURE;
        NDIS_FILTER_ATTRIBUTES FilterAttributes;
        WCHAR FilterLevel = L’0′;

        KdDebugIn(2);

        do
        {
            if (AttachParameters->FilterModuleGuidName->Length)
            {
                FilterLevel = AttachParameters->FilterModuleGuidName->Buffer[\
                    ((AttachParameters->FilterModuleGuidName->Length - 1) >> 1)];
            }

            if (FilterDriverContext != (NDIS_HANDLE)g_FilterDriverObject)
            {
                Status = NDIS_STATUS_INVALID_PARAMETER;
                break;
            }

            if (!g_AttachUpperLayers && FilterLevel != L’0′)
            {
                if (g_NmDebug)
                {
                    DbgPrintEx(
                        DPFLTR_IHVNETWORK_ID,
                        0,
                        “Discarding:%ws”,
                        AttachParameters->FilterModuleGuidName->Buffer
                        );
                }

                Status = NDIS_STATUS_INVALID_PARAMETER;
                break;
            }

            if (AttachParameters->MiniportMediaType == NdisMediumWan)
            {
                if ((AttachParameters->BaseMiniportName->MaximumLength != 0×24) ||
                    (RtlCompareMemory(
                    L”\\DEVICE\\NDISWANBH”,
                    AttachParameters->BaseMiniportName->Buffer,
                    0×24) != 0×24))
                {
                    break;
                }
            }
            else
            {
                if (AttachParameters->MiniportMediaType == NdisMediumNative802_11 &&
                    (FilterLevel != L’0′))
                {
                    Status = NDIS_STATUS_FAILURE;
                    break;
                }
            }

            // Let’s Create Filter Modules..
            //
            {
                if (NmCreateFilterModule(NdisFilterHandle, AttachParameters, &pFilter)
                    != NDIS_STATUS_SUCCESS)
                {
                    Status = NDIS_STATUS_RESOURCES;
                    break;
                }
                else
                {
                    NdisZeroMemory(&FilterAttributes, sizeof(NDIS_FILTER_ATTRIBUTES));

                    FilterAttributes.Header.Revision = NDIS_FILTER_ATTRIBUTES_REVISION_1;
                    FilterAttributes.Header.Size = sizeof(NDIS_FILTER_ATTRIBUTES);
                    FilterAttributes.Header.Type = NDIS_OBJECT_TYPE_FILTER_ATTRIBUTES;
                    FilterAttributes.Flags = 0; 

                    Status = NdisFSetAttributes(
                        NdisFilterHandle,
                        pFilter,
                        &FilterAttributes
                        );
                    if (Status != NDIS_STATUS_SUCCESS)
                    {
                        break;
                    }

                    NmInitializeMinipInfo(AttachParameters->MiniportMediaType, pFilter);

                    pFilter->State = FilterPaused;
                    NmInitializeTimerSystem(pFilter);

                    FILTER_ACQUIRE_LOCK(&g_FilterListLock, FALSE);
                    InsertHeadList(&g_FilterModuleList, &pFilter->FilterModuleLink);
                    FILTER_RELEASE_LOCK(&g_FilterListLock, FALSE);
                }
            }

        } while (FALSE);

        return Status;
    }
———————–

    1) FilterLevel是什么意思？

       FilterLevel取的是FilterModuleGuidName(形如{xxx-xxxx}-0001)的最后一个字符，它代表的是Filter所在的位置，或者粗略地理解成Filter的第几个实例。
       在LWF的INF安装文件里一般要设置一个注册表值，如 HKR, Ndi,FilterClass,,XXX，FilterClass决定了LWF在整个栈里的位置，具体含义大家可以参考WDK。而在WIN7上默认有另外两个LWF存在，WfpLwf是最高层的ms_firewall_upper，另一个Psched是第二层的scheduler。当再一个LWF加入的时候，可能会插在整个栈的各层，比如某LWF Monitor就可能产生如下的布局：
         {701D0081-81F3-494C-BEBB-B944C752E841}-{6E022F38-AB31-44C5-8206-2EB023EFF145}-0000
         {701D0081-81F3-494C-BEBB-B944C752E841}-{B5F4D659-7DAA-4565-8E41-BE220ED60542}-0000 // Psched
         {701D0081-81F3-494C-BEBB-B944C752E841}-{6E022F38-AB31-44C5-8206-2EB023EFF145}-0001
         {701D0081-81F3-494C-BEBB-B944C752E841}-{B70D6460-3635-4D42-B866-B8AB1A24454C}-0000 // WfpLwf
         {701D0081-81F3-494C-BEBB-B944C752E841}-{6E022F38-AB31-44C5-8206-2EB023EFF145}-0002

这个可以在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\XXX\Linkage\FilterList下看到。

        从上到下对应的是驱动栈的自底向上。{6E022F38-…}对应的是某LWF Monitor，{701D0081-…}是物理网卡。

       这样，FilterLevel对应的就是最后的那个字符，0、1或者2。

    2) FilterDriverContext之前已经解释过了，就是NdisFRegisterFilterDriver的第二个参数值，可具体灵活运用。

    3) g_AttachUpperLayers是在DriverEntry里初始化全局变量时从注册表读取的值，由用户设置，它标志着是不是启用类似{xxx}-0001的LWF实例。一般情况下，{xxx}-0000最贴近Miniport，如果只是监视或者嗅探Miniport上的数据，那么不要上层的那些Filter也是可以的。当然，如果您的Filter不只是Monitor，那就另当别论了。

    4) 接下来是两个判断，如果MiniportMediaType是NdisMediumWan，我们只Attach到NDISWANBH上，其他的不关心；
       而另外一种情况，NdisMediumNative802_11，无线设备没有UpperLayer，如果FilterLevel不是0，那么我们返回。

    5) 排除上面的几种，剩下的Miniport都是我们关心的了，我们对每个都创建一个Filter Device，Attach上去。
       创建成功之后，将DeviceExtension返回，也就是pFilter。然后必须调用NdisFSetAttributes，通知Lwf Miniport，这样pFilter才能被传给其他FilterXXX入口函数。

    6) InitializeMinipInfo会发OID向各个Miniport查询信息，保存到pFilter，并且向Miniport发OID设置Packet Filter以捕获数据；InitializeTimerSystem设置Timer，及时报告数据接收发送的状态信息以及其他的一些定时信息。

    7) g_FilterModuleList链表保存着每个Filter Device的上下文信息pFilter，也就是DeviceExtension。它可以用来给Root Device的IRP_MJ_DEVICE_CONTROL派发例程提供比如枚举所有网络接口的时候需要的相关信息。

   至于CreateFilterModule创建Filter Device，有几点想说明的：

    1) Filter Device的名字可以采用”前缀+[FilterModuleGuidName]“的形式，这样方便以后区分和处理；
    2) 对AttachParameters->MiniportMediaType是NdisMediumNative802_11的情况，可以在这里处理，为无线设备创建专门的结构体记录；
    3) Create Device的时候，你可以使用NdisRegisterDeviceEx，这样步骤会简单很多，但是以后访问内部成员会很费力；

       如果想自己IoCreateDevice，那就要注意仿造NdisRegisterDeviceEx的实现，注意DeviceExtensionSize的大小。

       在{DriverEntry}里，已经提到几个重点，DeviceExtension Header类似下面：

/*0×000*/NDIS_OBJECT_HEADER Header;
/*0×004*/LIST_ENTRY FilterModuleLink;
/*0x00C*/NDIS_HANDLE FilterHandle;
/*0×010*/PDEVICE_OBJECT FilterDeviceObject;
/*0×014*/PVOID UserDeviceExtention;

/*0×018*/PDRIVER_DISPATCH DispatchTable[IRP_MJ_MAXIMUM_FUNCTION + 1];

/*0×088*/NDIS_STRING DeviceName;
/*0×090*/NDIS_STRING SymbolicLinkName;
/*0×098*/NDIS_STRING GuidName;
 

       (1) Header.Type 必须是 9，而且DispatchTable必须在DeviceExtension + 0×18处，否则派发例程将得不到执行；
       (2) pFilter必须包含以上除0×14外的内容，UserExtention的就具体问题具体设计了；
       (3) 什么时候DestroyFilterModule，这个可以使用引用数。

   当然，由于本驱动的特殊性，只是个Monitor而不是Modifier，所以比如NetBufferLists、NetBuffers pool的分配管理，读取Configuration等等，都没有涉及到，可以参考WDK的内容：Attaching a Filter Module。

下篇继续补完其他的FilterXXX入口函数，以及接受发送数据包时候的处理。

———

Comments

• 2010年02月24日, Lewis writes: 膜拜
• 2010年02月27日, Luke writes: 可以做一些Modifier这方面的讨论与研究，比如IpDir，或者虚拟网关。

Related posts:

• 基于NDIS Filter 抓包

随机日志

• 2009年02月1日 -- SoftRCE的Mail Server开通了！
• 2010年08月3日 -- SoftRCE官方T恤开始订购了~
• 2008年09月29日 -- 文章预告：Exploiting Windows Device Drivers
• 2008年11月16日 -- [转载]在英特尔软件网络博客上看到的
• 2008年11月16日 -- 今天又地震～～
• 2010年05月7日 -- IoRegisterDriverReinitialization 和IoRegisterBootDriverReinitialization
• 2008年09月30日 -- [国庆礼]Exploiting Windows Device Drivers译文版
• 2008年10月9日 -- About the SMM rootkit
• 2010年05月12日 -- RdpDr.sys Bug Check 0X7E{0xC0000005}
• 2010年01月12日 -- MS07-014调试手记

===============

PACCESS_ALLOWED_ACE
GetAceFromAcl(
    IN PACL Dacl,
    IN ULONG AceIndex
    )
/*++

Routine Description:

Arguments:

Return Value:

--*/

{
    USHORT i = 0;
    PACCESS_ALLOWED_ACE Ace = NULL;

    if (Dacl && AceIndex < Dacl->AceCount)
    {
        for (Ace = FirstAce(Dacl); i < AceIndex; Ace = NextAce(Ace))
        {
            if (Ace >= (PACCESS_ALLOWED_ACE)((PUCHAR)Dacl + Dacl->AclSize))
            {
                break;
            }

            ++ i;   
        }

        if (i == AceIndex)
        {
            return Ace;
        }
    }

    return NULL;
}

BOOLEAN
NmCheckDaclForGroupSid(
    IN PACL Dacl
    )
/*++

Routine Description:

Arguments:

Return Value:

--*/

{ 
    USHORT i = 0;
    USHORT gSidOffset, cSidOffset;
    BOOLEAN result = FALSE;
    PACCESS_ALLOWED_ACE pACE = NULL;
    SIZE_T retLong;

    if (g_GroupAce->Header.AceSize >= (USHORT)(sizeof(ACCESS_ALLOWED_ACE)))
    {
        gSidOffset = g_GroupAce->Header.AceSize -
              (USHORT)(sizeof(ACCESS_ALLOWED_ACE));  

        if (Dacl->AceCount)
        {
            do
            {
                pACE = GetAceFromAcl(Dacl, i);

                if (pACE)
                {
                    cSidOffset = pACE->Header.AceSize -
                          (USHORT)(sizeof(ACCESS_ALLOWED_ACE));

                    if (gSidOffset == cSidOffset)
                    {
                        retLong = RtlCompareMemory(
                            &(pACE->SidStart),
                            &(g_GroupAce->SidStart),
                            cSidOffset
                            );

                        result = (cSidOffset == retLong);

                        if (result == TRUE)
                        {
                            return result;
                        }
                    }
                 }

                 ++ i;

            } while (i < Dacl->AceCount);
        }
    }

    return result;
}

BOOLEAN
AddAceToAcl(
    IN PACL NewAcl,
    IN PACCESS_ALLOWED_ACE toAddAce
    )
/*++

Routine Description:

Arguments:

Return Value:

--*/

{ 
    USHORT i = 0;
    PACCESS_ALLOWED_ACE Ace = FirstAce(NewAcl);

    if (NewAcl && toAddAce)
    {
        if (NewAcl->AceCount)
        {
            for (NOTHING; i < NewAcl->AceCount; Ace = NextAce(Ace))
            {
                if (Ace >= (PACCESS_ALLOWED_ACE)((PUCHAR)NewAcl + NewAcl->AclSize))
                {
                    break;
                }

                ++ i;
            }
         }

         if ((PACCESS_ALLOWED_ACE)((PUCHAR)Ace + toAddAce->Header.AceSize) >
                        (PACCESS_ALLOWED_ACE)((PUCHAR)NewAcl + NewAcl->AclSize))
         {
             return FALSE;
         }
         else
         {
             NdisMoveMemory(
                 Ace,
                 toAddAce,
                 toAddAce->Header.AceSize
                 );

             NewAcl->AceCount = i + 1;
         }
    }

    return TRUE;
}

NDIS_STATUS
NmModifyDacl(
    IN PACL oldDacl,
    OUT PACL* NewDacl
    )
/*++

Routine Description:

Arguments:

Return Value:

--*/

{
    NDIS_STATUS result = NDIS_STATUS_SUCCESS;
    USHORT tSize;
    PACL tmpDacl = NULL;
    USHORT i = 0;
    PACCESS_DENIED_ACE pdACE = NULL;
    PACCESS_ALLOWED_ACE paACE = NULL;

    if (oldDacl)
    {
        tSize = oldDacl->AclSize + g_GroupAce->Header.AceSize;

        tmpDacl = (PACL)ExAllocatePoolWithTag(
            NonPagedPool,
            tSize,
            'dnTF'
            );
        if (tmpDacl)
        {
            tmpDacl->AclRevision = oldDacl->AclRevision;   
            tmpDacl->Sbz1 = oldDacl->Sbz1;
            tmpDacl->AceCount = 0;
            tmpDacl->AclSize = tSize;   
            tmpDacl->Sbz2 = oldDacl->Sbz2;

            if (oldDacl->AceCount)
            {
                do
                {
                    pdACE = (PACCESS_DENIED_ACE)GetAceFromAcl(
                        oldDacl,
                        i
                        );
                    if (pdACE->Header.AceType != ACCESS_DENIED_ACE_TYPE)
                    {
                        break;
                    }

                    AddAceToAcl(tmpDacl, (PACCESS_ALLOWED_ACE)pdACE);

                    ++ i;

                } while (i < oldDacl->AceCount);    
             }

             AddAceToAcl(tmpDacl, g_GroupAce);

             while(i < oldDacl->AceCount)
             {
                 paACE = GetAceFromAcl(oldDacl, i);

                 AddAceToAcl(tmpDacl, (PACCESS_ALLOWED_ACE)paACE);

                 ++ i;
             }

             *NewDacl= tmpDacl;
        }
    }   

    return result;
}

NDIS_STATUS
NmAddGroupAccessAce(
    IN PDEVICE_OBJECT DeviceObject
    )
/*++

Routine Description:

Arguments:

Return Value:

--*/

{
    NDIS_STATUS Status = NDIS_STATUS_SUCCESS;
    PSECURITY_DESCRIPTOR SecurityDescriptor = NULL;
    PSECURITY_DESCRIPTOR NewSecurityDescriptor = NULL;

    ULONG csize = sizeof(SECURITY_DESCRIPTOR);
    PACL NewDdcl = NULL;
    HANDLE Handle = NULL;
    BOOLEAN DaclPresent, DaclDefaulted;
    PACL Dacl = NULL;

    if (DeviceObject && g_GroupAce)
    {
        Status = ObOpenObjectByPointer(
            DeviceObject,
            OBJ_KERNEL_HANDLE,
            NULL,
            WRITE_DAC,
            0,
            0,
            &Handle
            );
        if (Status == NDIS_STATUS_SUCCESS)
        {
            SecurityDescriptor = DeviceObject->SecurityDescriptor;

            Status = RtlGetDaclSecurityDescriptor(
                SecurityDescriptor,
                &DaclPresent,
                &Dacl,
                &DaclDefaulted
                );
            if (Status == NDIS_STATUS_SUCCESS)
            {
                ASSERT(DaclPresent);
                ASSERT(Dacl != NULL);

                if (NmCheckDaclForGroupSid(Dacl) != TRUE)
                {
                    csize = RtlLengthSecurityDescriptor(SecurityDescriptor);

                    NewSecurityDescriptor = ExAllocatePoolWithTag(
                        NonPagedPool,
                        g_GroupAce->Header.AceSize + csize,
                        'dnTF'
                        );
                    if (NewSecurityDescriptor)
                    {
                        RtlCreateSecurityDescriptor(
                            NewSecurityDescriptor,
                            SECURITY_DESCRIPTOR_REVISION
                            );

                        Status = NmModifyDacl(
                            Dacl,
                            &NewDdcl
                            );
                        if (Status == NDIS_STATUS_SUCCESS)
                        {
                            Status = RtlSetDaclSecurityDescriptor(
                                NewSecurityDescriptor,
                                TRUE,
                                NewDdcl,
                                FALSE
                                );
                            if (Status == NDIS_STATUS_SUCCESS)
                            {
                                Status = ZwSetSecurityObject(
                                    Handle,
                                    DACL_SECURITY_INFORMATION,
                                    NewSecurityDescriptor
                                    );
                            }
                        }
                    }
                }
            }
        }

        if (Handle)
        {
            ZwClose(Handle);
        }

        if (NewSecurityDescriptor)
        {
            ExFreePoolWithTag(NewSecurityDescriptor, 'dnTF');
        }

        if (NewDdcl)
        {
            ExFreePoolWithTag(NewDdcl, 'dnTF');
        }
    }

    return Status;
}

===============

在RegisterDevice之后加上即可，对于g_GroupAce，这个查询注册表或者自己获取，这些都是因时而异。
我这里是需要从注册表读过来的，然后加上去的：

===============

PACCESS_ALLOWED_ACE g_GroupAce = NULL;

//...省略...

       InitializeObjectAttributes(
           &ObjectAttributes,
           RegistryPath,
           OBJ_CASE_INSENSITIVE,
           NULL,
           NULL
           );

       Status = ZwOpenKey(
           &hHandle,
           KEY_READ,
           &ObjectAttributes
           );
       if (Status == STATUS_SUCCESS)
       {
           RtlInitUnicodeString(&DestinationString, L"GroupSid");

           Status = ZwQueryValueKey(
               hHandle,
               &DestinationString,
               KeyValueFullInformation,
               0,
               0,
               &ResultLength
               );
           if (Status == STATUS_BUFFER_OVERFLOW ||
               Status == STATUS_BUFFER_TOO_SMALL)
           {
               pBuffer = (PKEY_VALUE_FULL_INFORMATION)ExAllocatePoolWithTag(
                   NonPagedPool,
                   ResultLength,
                   'dnTF'
                   );  
               if (pBuffer)
               {
                   Status = ZwQueryValueKey(
                       hHandle,
                       &DestinationString,
                       KeyValueFullInformation,
                       pBuffer,
                       ResultLength,
                       &ResultLength
                       );
                   if (Status == STATUS_SUCCESS)
                   {
                         g_GroupAce = (PACCESS_ALLOWED_ACE)ExAllocatePoolWithTag(
                              NonPagedPool,
                              pBuffer->DataLength + sizeof(ACCESS_ALLOWED_ACE),
                              'gamn'
                              );
                         if (g_GroupAce)
                         {
                              NdisZeroMemory(
                                  g_GroupAce,
                                  pBuffer->DataLength + sizeof(ACCESS_ALLOWED_ACE)
                                  );

                              g_GroupAce->Header.AceType = ACCESS_ALLOWED_ACE_TYPE;
                              g_GroupAce->Header.AceFlags = 0;
                              g_GroupAce->Header.AceSize =
                                   (USHORT)(pBuffer->DataLength +
                                   sizeof(ACCESS_ALLOWED_ACE));

                              g_GroupAce->Mask = SYNCHRONIZE |
                                   READ_CONTROL | FILE_READ_ATTRIBUTES |
                                   FILE_READ_DATA | FILE_READ_EA;

                              NdisMoveMemory(
                                  (PVOID)&(g_GroupAce->SidStart),
                                  (PVOID)((PUCHAR)pBuffer + pBuffer->DataOffset),
                                  pBuffer->DataLength
                                  );

//...省略...

===============

PS: 排版很麻烦，我改了半天。下篇把这个工程的真正精华部分放上来大家探讨。

Comments

• 2010年10月11日, Lewis writes: 你丫的，没下文了！

Related posts:

• [国庆礼]Exploiting Windows Device Drivers译文版
• 文章预告：Exploiting Windows Device Drivers
• Vista Bootmgr/Winload使用的大部分选项ID

随机日志

• 2009年05月16日 -- 静态分析驱动的一点技巧
• 2009年05月5日 -- [玩笑]某人不是会坐在被告席上吧？
• 2010年04月21日 -- WinMount mou文件格式溢出漏洞分析
• 2008年10月15日 -- About Handling Nmi
• 2011年04月8日 -- Microsoft Windows xp AFD.sys Local Kernel DoS Vulnerability
• 2009年05月1日 -- 暴风影音2009(mps.dll)ActiveX远程栈溢出漏洞
• 2009年05月1日 -- 暴风影音2009(Config.dll)ActiveX远程栈溢出漏洞
• 2010年02月21日 -- Step deeply into NDIS6 LightWeight Filter, part 1
• 2008年10月22日 -- 构造无人之境: Exploiting Realtek RTL8139单芯片以太网控制器
• 2008年10月9日 -- About the SMM rootkit

作者：Azy
日期：2009-5-31

    如果说Audio Mixer劫持（AMH, http://hi.baidu.com/azy0922/blog/item/fc4fc91e5c2d2617403417a8.html）是一种较为被动的穿越，那么BEIH/F则是主动的攻击。通过BEIH/F可以穿越地上HIPS/主动防御产品加载驱动。
    该方法原理与amh是相同的，最后驱动的加载也是走ExpWorkerThread->PipDeviceActionWorker->IopLoadDriver这条路径，从而绕过了HIPS/主防产品的拦截。但触发攻击的方式完全不同。
    OS中存在一些音频驱动，它们的Start=3，并且Enum键下的值均为0。这些驱动是在系统需要的时候动态枚举并安装总线接口，然后加载相应的驱动文件。
    那么如何触发动态枚举安装接口并加载这些驱动呢？答案就是给swenum驱动发送一个特别的I/O Control Code来触发。在InputBuffer中填入欲加载驱动所在接口的GUID值，然后发I/O control Irp到swenum驱动，便可完成一次触发。内核在接到上述Irp后会扫描总线并动态进行接口安装，然后调用IoInvalidateDeviceRelations来触发最后的驱动安装。
    由于这一过程完全是人为可控，并且总线枚举的GUID信息全部存储在注册表中，因此我们可以事先篡改仿造HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SW键及HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses下面对应的GUID值及其它接口信息。这样一来，便可成功完成一次BEIH/F攻击。

Comments

• 2009年06月8日, dge writes: 膜拜

随机日志

• 2010年02月21日 -- Step deeply into NDIS6 LightWeight Filter, part 1
• 2011年09月13日 -- Microsoft Windows NDISTAPI本地权限提升漏洞（MS11-062)
• 2009年05月1日 -- 暴风影音2009(Config.dll)ActiveX远程栈溢出漏洞
• 2010年03月11日 -- Think Different
• 2010年01月12日 -- MS07-014调试手记
• 2008年10月9日 -- About the SMM rootkit
• 2008年10月15日 -- About Handling Nmi
• 2009年04月30日 -- Native Application之键盘处理
• 2010年09月13日 -- 金山毒霸2011内核溢出漏洞
• 2009年05月1日 -- Symbian S60 3rd Reverse CrAcKiNg Tutorial

如下图所示：

Filter Driver 框架介绍
WDK中\src\network\ndis\filter中Filter的主要框架，在MSDN文档里面有对这个框架的详细解释，这里我们只简单说几个函数。

DriverEntry
// NDIS调用这个函数为一些数据结构分配内存和作初始化工作
// 主要的结构体有:
//NDIS_FILTER_DRIVER_CHARACTERISTICS 指定一些Filter驱动的特性，并把这些参数传给NDIS。
// 主要的函数：
// NdisFRegisterFilterDriver 把Filter驱动注册给NDIS

FilterAttach
// NDIS调用这个函数为一些数据结构分配内存和作初始化工作
// 主要的结构体有:
// NDIS_FILTER_ATTACH_PARAMETERS 初始化参数
// NDIS_FILTER_ATTRIBUTES Filter模块的属性

FilterRegisterDevice
// 填充分派函数，初始化设备属性。并注册。
// 主要的结构体有:
// NDIS_FILTER_ATTACH_PARAMETERS 初始化参数
// NDIS_FILTER_ATTRIBUTES Filter模块的属性

FilterSendNetBufferLists
// 用这个函数去过滤一个NET_BUFFER_LIST的发送
// 主要的结构体有:
// NET_BUFFER_LIST NET_BUFFER的链表

FilterReceiveNetBufferLists
// 用这个函数去过滤一个NET_BUFFER_LIST的接收
// 主要的结构体有:
// NET_BUFFER_LIST NET_BUFFER的链表

如果要读取数据包，那么有两个结构体就相当重要了。它们是NET_BUFFER_LIST和 NET_BUFFER。定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

	typedef	struct	_NET_BUFFER_LIST{
		NET_BUFFER_LIST_HEADER			NetBufferListHeader;
		PNET_BUFFER_LIST_CONTEXT		Context;
		PNET_BUFFER_LIST				ParentNetBufferList;
		NDIS_HANDLE						NdisPoolHandle;
		DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT)PVOID		NdisReserved[2];
		DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT)PVOID		ProtocolReserved[4];
		DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT)PVOID		MiniportReserved[2];
		PVOID							Scratch;
		NDIS_HANDLE						SourceHandle;
		ULONG							NblFlags;
		LONG							ChildRefCount;
		ULONG							Flags;
		NDIS_STATUS						Status;
		PVOID							NetBufferListInfo[MaxNetBufferListInfo];
	}NET_BUFFER_LIST,*PNET_BUFFER_LIST;
 
	typedef	struct	_NET_BUFFER	{
		NET_BUFFER_HEADER	NetBufferHeader;
		USHORT		ChecksumBias;
		USHORT		Reserved;
		NDIS_HANDLE	NdisPoolHandle;
		DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT)PVOID	NdisReserved[2];
		DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT)PVOID	ProtocolReserved[6];
		DECLSPEC_ALIGN(MEMORY_ALLOCATION_ALIGNMENT)PVOID MiniportReserved[4];
		NDIS_PHYSICAL_ADDRESS	DataPhysicalAddress;	// was NdisReserved1;
	} NET_BUFFER,	*PNET_BUFFER;

另外，还有一些宏定义。
NET_BUFFER_LIST_FIRST_NB 从NET_BUFFER_LIST结构中获得第一个NDIS_BUFFER
NET_BUFFER_DATA_OFFSET 从NDIS_BUFFER中获得DATA的偏移
NET_BUFFER_FIRST_MDL 从NDIS_BUFFER中获得第一个MDL
NET_BUFFER_DATA_LENGTH 取得DATA的长度
更具体的自己去看MSDN了。

我根据MSDN和GOOGLE的指点大概写了一段代码了读取数据包。读出数据包的地址和长度。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

void  ReadNetBuffer( PNET_BUFFER_LIST NetBufferLists )
{
	PUCHAR				data,info;
	ULONG				len,i,offset=0;
	PNET_BUFFER_LIST	CurrNbl;
	PNET_BUFFER			Currbuff;
	PMDL				mdl;
	int					DataLen;
 
	CurrNbl = NetBufferLists;
 
	while (CurrNbl)
	{
		Currbuff = NET_BUFFER_LIST_FIRST_NB(CurrNbl);
 
		while(Currbuff)
		{
			offset =	NET_BUFFER_DATA_OFFSET(Currbuff);
			mdl =		NET_BUFFER_FIRST_MDL(Currbuff);
			DataLen	=	NET_BUFFER_DATA_LENGTH(Currbuff);
 
			if ( mdl && DataLen )
			{
				data = (UCHAR*)MmGetSystemAddressForMdlSafe( mdl,NormalPagePriority );
				if(data)
				{
					info = data + offset;
					KdPrint((" PacketData : %p , PacketSize : %d ",info,DataLen));
				}
 
			}
			Currbuff = NET_BUFFER_NEXT_NB(Currbuff);
		}
		CurrNbl = NET_BUFFER_LIST_NEXT_NBL(CurrNbl);
	}
}

小弟水平很菜，写出来的文章也很戳，欢迎拍砖！热爱丢脸！学习… … 再贴个图，凑篇幅

Comments

• 2009年06月8日, dge writes: 学习
• 2009年10月28日, daisy writes: 谢谢博主，通俗易懂，很适合像我一样的初学者，谢谢啦~
• 2009年11月17日, archangel writes: 容易是容易，怎么编译安装得，说一下啊。wdk
• 2010年01月16日, daisy writes: 博主，谢谢你给的小例子，在filter sample里边加入你的代码运行成功后让我长了不少自信。之前一直研究如何通过filter drive修改NET_BUFFER_LIST，对NetBufferList的架构一直难以理解，看你例子的简单读取NetBuffer的数据，比看那一大堆文档明了很多。现在想请教博主一个问题，博士是否了解一些filter driver如何修改NetBuffer的相关技术，msdn里边说只有其创建者才可修改其内容，我试着用NdisAllocateCloneNetBufferList()等函数去复制原NetBufferList，然后修改都不成功。如果博主有了解相关方便的知识，麻烦你可以从百忙中抽出一点时间，给我一些指点或者提示，我的email：hellodaisy@139.com,先谢了~
• 2010年01月30日, gz1x writes: 我以前有个项目是LWF的，等有时间写篇文章抛抛砖。

Related posts:

• Step deeply into NDIS6 LightWeight Filter, part 1

随机日志

• 2009年05月16日 -- 静态分析驱动的一点技巧
• 2009年04月26日 -- SoftRCE再次回归上线
• 2011年04月8日 -- Microsoft Windows xp AFD.sys Local Kernel DoS Vulnerability
• 2009年04月30日 -- 中国游戏中心游戏大厅ActiveX远程栈溢出漏洞
• 2008年09月29日 -- 文章预告：Exploiting Windows Device Drivers
• 2009年05月1日 -- Symbian S60 3rd Reverse CrAcKiNg Tutorial
• 2008年10月19日 -- [POC]基于IO Packet隐藏文件和注册表，过磁盘解析和总线解析
• 2008年10月15日 -- About Handling Nmi
• 2010年01月12日 -- MS07-014调试手记
• 2008年10月9日 -- About the SMM rootkit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161

#define MAX_KEYBOARD_COUNT 10
HANDLE hKbdTable[MAX_KEYBOARD_COUNT];
HANDLE hReadKbdEvt[MAX_KEYBOARD_COUNT];
USHORT KbdInputBuffer[16] = {0};
 
 
UCHAR ScancodeTable[] =
{
0,
0, //ESC
'1','2','3','4','5','6','7','8','9','0',
0,0,0,0,
'Q','W','E','R','T','Y','U','I','O','P',
0,0,
0, //ENTER
0,
'A','S','D','F','G','H','J','K','L',
0,0,0,0,0,
'Z','X','C','V','B','N','M'
};
 
BOOLEAN KeyboardHandler(PULONG pulResult)
{
	HANDLE hKbdDevice = NULL;
	ULONG i = 0;
	ULONG ulKbdNum = 0;
	PWCHAR szwKbdDeviceName = NULL;
	OBJECT_ATTRIBUTES ObjectAttributes;
	NTSTATUS ntStatus = STATUS_UNSUCCESSFUL;
	UNICODE_STRING usDeviceName;
	PIO_STATUS_BLOCK pIoStatusBlocks = NULL;
	LARGE_INTEGER TimeOut;
	LARGE_INTEGER ByteOffset;
	ULONG ulCharCount = 0;
	BOOLEAN bIsEsc = FALSE; //是否输入了ESC
	BOOLEAN bIsEnter = FALSE; //是否输入了回车
	BOOLEAN bIsScanAllDrive = FALSE; //扫描全盘标志位
	WCHAR szwPrintMsg[16] = {0};
	KEYBOARD_INPUT_DATA KeyboardInputData = {0};
 
	ASSERT(pulResult != NULL);
 
	__asm int 3
	szwKbdDeviceName = (PWCHAR)RtlAllocateHeap(Heap, 0, 128);
 
	if (NULL == szwKbdDeviceName)
	{
		return FALSE;
	}
 
	pIoStatusBlocks = (PIO_STATUS_BLOCK)RtlAllocateHeap(Heap, 0, sizeof(IO_STATUS_BLOCK)*MAX_KEYBOARD_COUNT);
 
	if (NULL == pIoStatusBlocks)
	{
		return FALSE;
	}
 
	//
	// 尝试打开系统中所有的键盘设备
	//
	for (; i < MAX_KEYBOARD_COUNT; i++)
	{
		RtlZeroMemory(szwKbdDeviceName, 128);
 
		swprintf(szwKbdDeviceName, L"\\Device\\KeyboardClass%d", i);
 
		RtlInitUnicodeString(&usDeviceName,szwKbdDeviceName);
 
		InitializeObjectAttributes(&ObjectAttributes,&usDeviceName,OBJ_CASE_INSENSITIVE ,NULL,NULL);
 
		ntStatus = NtCreateFile(&hKbdDevice, \
				0x80100080,
				&ObjectAttributes, &pIoStatusBlocks[i], NULL, FILE_ATTRIBUTE_NORMAL, 0, 1, 1, NULL ,0);
 
		if (NT_SUCCESS(ntStatus))
		{
			hKbdTable[ulKbdNum] = hKbdDevice;
			InitializeObjectAttributes(&ObjectAttributes, NULL, 0, NULL, NULL);
			ntStatus = NtCreateEvent(&hReadKbdEvt[ulKbdNum], 0x1F01FF, NULL, SynchronizationEvent, FALSE);
 
			ulKbdNum++;
		}
 
	}
 
	TimeOut.QuadPart = -10 * 1000 * 1000;
	TimeOut.QuadPart *= 10;
 
	ByteOffset.QuadPart = 0;
 
	while(TRUE)
	{
		for (i = 0; i < ulKbdNum; i++)
		{
			ntStatus = NtReadFile(hKbdTable[i], hReadKbdEvt[i], NULL, NULL, &pIoStatusBlocks[i], &KeyboardInputData, sizeof(KEYBOARD_INPUT_DATA), &ByteOffset, NULL);
 
			if (ntStatus == STATUS_PENDING)
			{
				ntStatus = NtWaitForSingleObject(hReadKbdEvt[i], FALSE, &TimeOut);
 
				if (ntStatus == STATUS_TIMEOUT)
				{
					NtCancelIoFile(hKbdTable[i], &pIoStatusBlocks[i]);
				}
				else
				{
					//保存数据
					if (KeyboardInputData.MakeCode == 0x1C) //如果是回车
					{
					    bIsEnter = TRUE;
					    break;
					}
					else if (KeyboardInputData.MakeCode == 0x01) //如果是ESC
					{
					    bIsEsc = TRUE;
					    break;
					}
					else if (KeyboardInputData.MakeCode == 0x3B) //如果是F1键 则扫描全盘
					{
					    bIsScanAllDrive = TRUE;
					    break;
					}
 
					if (KeyboardInputData.Flags == 0)
					{
					    if (KeyboardInputData.MakeCode<sizeof(ScancodeTable))
                        {
                            //则不做任何处理
                            swprintf(szwPrintMsg, L"%c", ScancodeTable[KeyboardInputData.MakeCode]);
					        DisplayString(szwPrintMsg);
 
					        if (ulCharCount &lt;16)
					            KbdInputBuffer[ulCharCount++] = ScancodeTable[KeyboardInputData.MakeCode];
                        }
					}
				}
			}
 
		}
 
		//如果输入了回车或者ESC键则停止记录键盘
 
	    if (bIsEnter)
	    {
	        *pulResult = 1;
	        break;
	    }
	    else if (bIsEsc)
	    {
	        *pulResult = 2;
	        break;
	    }
	    else if (bIsScanAllDrive)
	    {
	        *pulResult = 3;
	        break;
	    }
	}
 
	return TRUE;
}

效果：

Comments

• 2009年04月30日, gz1x writes: 挺好玩的。
• 2009年04月30日, gz1x writes: 好像代码贴的有问题。
• 2009年04月30日, robinh00d writes: 我少贴了几个全局变量~ 一会加上 还有 代码高亮功能还没弄好，等晚上ayarei下课后再弄~
• 2009年04月30日, ayarei writes: 其实贴完整代码没什么意思呀~还是有点悬念自己改改的好~
• 2009年04月30日, Rinrin writes: TinyKRNL里有个NCLI,不过只能处理一个键盘
• 2009年05月1日, Azy writes: 不错。。。
• 2009年05月3日, mengxp writes: 那行字没空格 -.-
• 2009年05月3日, robinh00d writes: 没支持空格～
• 2009年06月1日, 0x4 writes: 怎么tab跟空格混用的，真难看 全部替换成空格多好。
• 2009年07月31日, 49513524 writes: 郁闷,对于大菜鸟来说代码贴不全很郁闷的.

随机日志

• 2010年05月12日 -- RdpDr.sys Bug Check 0X7E{0xC0000005}
• 2010年08月3日 -- SoftRCE官方T恤开始订购了~
• 2009年01月10日 -- 容易被忽略的IDA快捷键
• 2011年05月18日 -- Microsoft Windows Vista/Server 2008 “nsiproxy.sys” Local Kernel DoS Vulnerability
• 2009年04月30日 -- 中国游戏中心游戏大厅ActiveX远程栈溢出漏洞
• 2009年05月16日 -- 静态分析驱动的一点技巧
• 2009年04月26日 -- SoftRCE再次回归上线
• 2010年02月10日 -- How to adjust the Ace of device object
• 2009年05月1日 -- 暴风影音2009(mps.dll)ActiveX远程栈溢出漏洞
• 2008年11月16日 -- 今天又地震～～

一、浅“藏”
一直以来隐蔽战线采取着一种策略，即：藏得了就藏，藏不了就“装”。靠在ring3层隐藏自己端口的rk如今肯定是回天乏术了，而像ring3级别的Hacker Defender以及Byshell则是通过挂接网络native api来实现端口复用从而达到不开端口隐蔽通信的伪装效果。尽管作者们使用的技术与技巧十分之精湛，但面对如今这个内核代码满天飞的局面，ring3对抗ring0还是显得势单力薄了一些。ring3级别的挂钩很容易被检测，端口复用同样会在ring0层的连接枚举下无可遁形，同时又受到基于主机的防火墙的封杀。与此同时或是更早，PCC（Passive Convert Channels）进入到某些人的视线之中。这种将后门或者rk通信数据嵌入到正常的数据包之中的方法的确很有创意（例如通过TCP报头中的ISN来传递数据的NUSHU），但却无法逃脱本身缺陷导致的局限性以及被检测的厄运。

二、深藏不露？
伴随着rk面向内核层的全线出击，隐蔽通信方面也催生出了新技术。而这些新技术的答案也往往可以在NDIS_PROTOCOL_BLOCK之中找到。为什么？因为协议驱动，中间层驱动和微端口驱动在NDIS体系中按照自顶向下的顺序排列。所以位于最上层的协议驱动首当其冲地成为了宰割对象。并且NDIS_PROTOCOL_BLOCK这个结构可以用很强大来形容，它下面的各个成员链接到的结构可以说是五花八门、不尽其数，这里面当然就包括NDIS_OPEN_BLOCK，NDIS_PROTOCOL_CHARACTERISTICS等结构。这些结构之中包含有N多函数指针，于是很容易联想到对它们进行暗箱操作。
协议驱动在DriverEntry()中会调用NdisRegisterProtocol()向NDIS库注册自己的协议，获取到一个指向NDIS_PROTOCOL_BLOCK的指针。NDIS做的则是把这个结构放到协议块链表的最前面，链表头由ndisProtocolList指定。事实上，每个协议的NDIS_PROTOCOL_BLOCK通过一个单向链表链在了一起。
Uay通过挂接NDIS_PROTOCOL_CHARACTERISTICS结构中的发送和接收例程实现自己的隐蔽通信；Deepdoor则是挂接了TCP/IP协议的NDIS_OPEN_BLOCK块中的发送和接受处理例程达到目的。Uay和Deepdoor有些类似，都是在协议层上进行挂接，因此它们要自己实现封包解包等一些功能。其实可以做手脚的地方还有很多，比如DKOM NDIS_MINIPORT_BLOCK。
另一方面，检测与防护战线也不甘示弱。中间层驱动，设备过滤，MajorFunction hooking，NDIS.SYS导出表挂接，NDIS代码补丁…战火一度在内核层引爆。随着基于主机的网络嗅探器与防火墙在内核位置的下移，上述原本深藏不露的隐蔽通信方法也因为疲于应付而变得捉襟见肘。其中某些手段在协议链遍历和NDIS_OPEN_BLOCK函数指针完整性检测的排挤下也开始逐渐失效。更严重的是，它们的通信数据包在Iris等网络嗅探工具下可以马上现形。因此，这就需要我们开辟新的方法。

三、无人之境？
那么究竟如何才能绕过现有一切检测技术，并且在通信数据包不被基于主机的嗅探器截获的情况下实现隐蔽的通信呢？答案即：回归原始，直接和网卡芯片控制器交互。下面的文字将围绕这一主题展开：以PCI总线类型的Realtek RTL8139高速以太网卡为例，具体阐述rk同网卡芯片控制器实施交互的过程，探讨打造出一个如入无人之境的隐蔽rk的可能。由于某些原因，所以仅仅描述原理，感兴趣的朋友自己动手也完全没有问题。
同控制器直接交互的优点在于通过直接I/O芯片上的一些端口寄存器避免了一切NDIS层面上的挂接，嗅探器完全不能抓到任何我们的数据包，因为它在我们的上面！还有，这种方法根本不受操作系统环境下对网卡状态的影响：将网络连接关闭，网卡停止等都是徒劳，因为生杀大权牢牢被我们掌控。只要网卡连在总线上，供电，网路畅通即可实现数据传输。
作为目前应用范围较广的RTL8139芯片控制器提供了众多特性。比如高度集成的以太网MAC，物理芯片同收发器的集成，支持远程唤醒，最大可支持128K EPROM和Flash Memory。与此同时，RTL8139提供了为数众多的端口寄存器供映射到I/O空间，下面仅结合网卡初始化、数据包的发送与接收讲解常用的几个，其它的参考datasheet即可。

1. 8139初始化
网卡在初始化时涉及到的寄存器有：CR（Command Register），TCR（Tx Configuration Register），RCR（Rx Configuration Register），IMR（Interrupt Mask Register），RBSTART（Rx Buffer Start Address）。它们很多可以顾名思义。初始化过程大致为：
(1) 设置CR：将CR中的RE和TE标志位置1并写入CR，即启用8139网卡芯片的收发器。这两个标志位置1后，接收状态机和发送状态机将由空闲变为活动状态
(2) 设置RCR：
a 将RCR中的RBLEN（BIT12-11）相应位置1并写回RCR：即指定接收环形缓冲区（Rx Ring Buffer）的大小（通常设为16K+16bytes）；
b 将MXDMA（BIT10-8）标志中的相应位置1，写回RCR：即指定接收的DMA传输数据最大值（通常为1024bytes）；
c 将RXFTH（BIT15-13）标志中的相应位置1并写回RCR：即指定Rx FIFO的接收数据阀值（通常为64bytes），这个下面会讲到
d 将AB，AM，APM位置1写回，即指明接受广播、组播以及匹配网卡地址的数据包

(3) 设置TCR：
a 将TCR中的IFG（BIT25-24）标志位置为全1并写回TCR，指定帧间隔时间；
b 将MXDMA（BIT10-8）相应位置1（视不同情况而定），指明每次DMA发送数据的最大字节数（推荐值为1024bytes）
(4) 设置RBSTART：将事先分配的物理地址写入Receive Buffer Start Address，8139芯片会将Rx FIFO中的数据移动到这块物理内存
(5) 设置IMR：开启除系统错误外的所有中断，并写入IMR。这个寄存器指明了在什么条件下会致使芯片的中断控制逻辑产生一个中断并调用ISR

2. 发送数据包
其实在我们的rk中完全没必要再对网卡进行初始化，因为网卡驱动已经帮助我们做了这项工作。如果需要，rk可以读出这些端口寄存器的值进行修改（比如直接让网卡halt掉）。让我们把注意力放在8139芯片的收发数据包上。根据RTL8139 datasheet中的规定，其在进行数据发送时要用一对描述符用以描述待发送的数据。这对描述符分别是TSD（Transmit Status Descriptor）和TSAD（Transmit Start Address Descriptor）。而8139共提供了4对这样的描述符用于数据的发送，即TSD0-3，TSAD0-3。它们分别位于I/O空间的0×10偏移和0×20偏移处，每个描述符4字节大小。这四个描述符是轮流使用的。
从硬件层讲，当对一对transmit描述符I/O完毕之后，8139芯片就会在指
令的控制下通过PCI接口将数据包从物理内存以总线主控的DMA传输模式搬运到网卡芯片的发送FIFO（Tx FIFO）。而这个数据包的物理地址和大小恰好是对TSD和TSAD进行I/O写时指定过的，所以它可以很轻松地得到该数据包。8139芯片内置了两个大容量（2K）的收发FIFO用于暂存即将送上电缆及从电缆上接收的报文。如果FIFO中包含了一个完整的数据包抑或包大小到达了在TSD中指定的阀值，芯片便开始继续向下传输。接下来数据包将会经由FIFO控制逻辑部件，到达收发逻辑接口，然后再经MII接口出去离开MAC到达物理芯片。物理芯片中经过编码后再通过发送器部件送至RJ-45端口。
当然，软件层没必要关心太多FIFO之后的事情，rk只需要按照规矩做就行了。发送包的流程大概如下：
(1) 分配好一块物理内存，将待发送数据包拷贝到这片内存
(2) I/O写transmit描述符，将数据包的内存地址和大小填入
当整个数据包被送上电缆时，TSD中的TOK（Transmit OK）标志位被置为1，如果之前在IMR中开启了TOK中断，此时中断就会触发。

3. 接收数据包
接收模块相对就要复杂一些。因为transmit是一个主动行为，而receive是被动的。rk毕竟不是硬件，没有一个机制触发它使其能比网卡更早的得到数据包到达的中断信号。因此我们不得不对网卡驱动的ISR做些处理。
之前提到了所谓的Tx FIFO，那么自然就会有一个Rx FIFO。从电缆上接收的数据包首先被放置在芯片的Rx FIFO中。当Rx FIFO到达了RCR中预先设定的数据量阀值时，芯片就会发信号申请占用PCI总线，以总线主控模式通过DMA将数据传送到接收缓冲区。
而这个接收缓冲区是以一个环形的方式组织而成的，其实质还是一片连续的物理内存。这里面涉及到一个CAPR（Current Address of Packet Read），其中包含了当前读到的数据包的地址。综上，那么网卡处理一个包的整个过程为：
(1) 线路上接收到的数据存储在芯片的Rx FIFO中
(2) 当到达接收阀值时，数据被移动到Rx Buffer（RBSTART指定的物理内存）
(3) 当整个包移动完毕时，接收包头信息被写入包的起始。
(4) CR中的BUFE标志位被置为1，ISR中的TOK标志位置为1
(5) 网卡的ISR例程被调用，由ISR来清TOK位并更新CAPR
讲到这里，原理已经很明显了。rk能做的就是替换掉网卡驱动的ISR，当接收中断产生时自己同芯片控制器交互，读包并判断是否是自己的包，如是做特殊处理，否则交由原始ISR处理，当然，也可以邪恶地对包任意进行涂改让Sniffer去嗅去吧。

不得不提地是，这种方法明显存在严重依赖网卡芯片型号，通用性不好的弊端，但鱼和熊掌不可兼得，我们毕竟迈出了一步，但要走的路还很远。

PS：由于条件受限，测试用bin会在适当的时候放出

四、参考资源
[1] Realtek RTL8139C(L) datasheet Rev1.4, 2002
[2] Sean. Programming guide and sample code for RTL8139 family. 1999
[3] Alex Tereshkin. Rootkits: Attacking Personal Firewalls. BH Vegas 2006
[4] Joanna Rutkowska. Fighting Stealth Malware-Towards Verifiable OSes. CCC 2006
[5] uty. Uay Rootkit source code
[6] Azy. AK922 Rootkit (http://hi.baidu.com/azy0922)

随机日志

• 2010年05月7日 -- IoRegisterDriverReinitialization 和IoRegisterBootDriverReinitialization
• 2008年10月19日 -- Vista Bootmgr/Winload使用的大部分选项ID
• 2008年11月16日 -- [转载]在英特尔软件网络博客上看到的
• 2008年10月9日 -- About the SMM rootkit
• 2010年08月3日 -- SoftRCE官方T恤开始订购了~
• 2009年05月16日 -- 静态分析驱动的一点技巧
• 2008年10月22日 -- 绕过主动防御的代码注入方法一点思考
• 2010年03月1日 -- Steve Jobs在斯坦福大学毕业典礼上的演讲
• 2009年04月26日 -- SoftRCE再次回归上线
• 2009年02月1日 -- SoftRCE的Mail Server开通了！

Related posts:

• 构造无人之境: Exploiting Realtek RTL8139单芯片以太网控制器

随机日志

• 2009年04月26日 -- SoftRCE再次回归上线
• 2010年05月12日 -- RdpDr.sys Bug Check 0X7E{0xC0000005}
• 2010年02月10日 -- How to adjust the Ace of device object
• 2009年05月15日 -- ActiveX 控件组件的Fuzz和利用
• 2010年03月11日 -- Think Different
• 2008年10月9日 -- About the SMM rootkit
• 2010年05月7日 -- IoRegisterDriverReinitialization 和IoRegisterBootDriverReinitialization
• 2009年02月1日 -- SoftRCE的Mail Server开通了！
• 2008年09月30日 -- [国庆礼]Exploiting Windows Device Drivers译文版
• 2008年11月16日 -- [转载]在英特尔软件网络博客上看到的

kd> !idt -a

Dumping IDT:
00: 8082409e nt!KiTrap00
01: 8082421a nt!KiTrap01
02: Task Selector = 0×0058
03: 8082462a nt!KiTrap03
04: 808247a6 nt!KiTrap04
05: 80824904 nt!KiTrap05
06: 80824a86 nt!KiTrap06
07: 808250e6 nt!KiTrap07
08: Task Selector = 0×0050
09: 80825518 nt!KiTrap09
0a: 80825632 nt!KiTrap0A
//…
ff: 808231b0 nt!KiUnexpectedInterrupt207

相关的中断可以查阅详细资料_[1]，我们只关心下面两个：
IDTEntry _KiTrap02, D_INT032 ; 2: NMI/NPX Error
IDTEntry _KiTrap08, D_INT032 ; 8: Double Exception
即Windbg中显示的：
02: Task Selector = 0×0058
08: Task Selector = 0×0050
表示的是系统为处理这两个int而设置的任务门，KGDT_DF_TSS(50h)和KGDT_NMI_TSS(58h)。那么是系统什么时候设置的呢？ntoskrnl加载的时候，KERNEL_ENTRY_POINT是KiSystemStartup()函数，反汇编不难看出它的流程，你也可以参考WangYu的一篇文章_[2]，或者可以参考ReactOs的代码，不过我们简单地反汇编一些：

0) 这里涉及一些结构，用Windbg可以清晰地看到：
kd> !pcr 0
kd> dt -r1 nt!_KPCR
kd> dt nt!_KIDTENTRY (_KGDTENTRY)
kd> dt -r1 nt!_KTHREAD
kd> dt -r1 nt!_KPROCESS

typedef struct _IDTENTRY{
unsigned short   OffsetLow;    //中断执行代码偏移量的底16位
unsigned short   Selector;       //选择器，也就是寄存器
unsigned char     Reserved;    //保留位，始终为零
unsigned char     Type:4;         //中断门，陷阱门和任务门_[5]
unsigned char     SegmentFlag:1;   //段标识位  1:CS\DS段描述符  0:门\系统描述符
unsigned char     DPL:2;         //权级，0:内核级，3:用户级
unsigned char     Present:1;   //呈现标志位
unsigned short    OffsetHigh;  //中断执行代码偏移量的高16位
}IDTENTRY,*PIDTENTRY;_[4]

typedef struct _KGDTENTRY {
USHORT  LimitLow;
USHORT  BaseLow;
union {
struct {
UCHAR   BaseMid;
UCHAR   Flags1;
UCHAR   Flags2;
UCHAR   BaseHi;
} Bytes;
struct {
ULONG   BaseMid : 8;
ULONG   Type : 5;
ULONG   Dpl : 2;
ULONG   Pres : 1;
ULONG   LimitHi : 4;
ULONG   Sys : 1;
ULONG   Reserved_0 : 1;
ULONG   Default_Big : 1;
ULONG   Granularity : 1;
ULONG   BaseHi : 8;
} Bits;
} HighWord;
} KGDTENTRY, *PKGDTENTRY;

1) 首先是为NMI建立任务门，这样我们就能捕捉到NMI了：
INIT:006053CE mov eax, [ebp+var_10]                    ; 之前由GetMachineBootPointers得到的Idt
INIT:006053D1 lea ecx, [eax+10h]                             ; 16/8 -> 2号中断描述符
INIT:006053D4 mov byte ptr [ecx+5], 85h                 ; 10000101 -> dpl=0, present, taskgate
INIT:006053D8 mov word ptr [ecx+2], 58h                ; KGDT_NMI_TSS(58h)
INIT:006053DE lea ecx, [edi+58h]
INIT:006053E1 mov byte ptr [ecx+5], 89h                  ; 10001001 -> 32bit, dpl=0, present, TSS32, not busy
INIT:006053E5 mov edx, offset _KiNMITSS
INIT:006053EA mov eax, edx
INIT:006053EC mov [ecx+2], ax                                  ; KgdtBaseLow(2h)
INIT:006053F0 shr eax, 10h
INIT:006053F3 mov [ecx+7], ah                                   ; KgdtBaseHi(7h)
INIT:006053F6 mov [ecx+4], al           &nbs
p;                        ; KgdtBaseMid(4h)
INIT:006053F9 mov eax, 68h                                       ; MINIMUM_TSS_SIZE(68h)
INIT:006053FE mov [ecx], ax                                        ; KgdtLimitLow(0h)
INIT:00605401 push edx
INIT:00605402 push edx
INIT:00605403 call KiInitializeTSS(x)

2) 然后是建立堆栈(32位)：
INIT:00605408 pop edx
INIT:00605409 mov eax, cr3
INIT:0060540C mov [edx+1Ch], eax                                            ; TssCr3(1ch)
INIT:0060540F mov eax, offset P0BootStack
INIT:00605414 mov eax, [eax+38h]
INIT:00605417 mov [edx+4], eax                                                  ; TssEsp0(4h) , NMI stack
INIT:0060541A mov [edx+38h], eax
INIT:0060541D mov dword ptr [edx+20h], offset _KiTrap02           ; 处理例程
INIT:00605424 mov dword ptr [edx+24h], 0                                  ; eflags
INIT:0060542B mov word ptr [edx+4Ch], 8                                   ; KGDT_R0_CODE(8h) -> CS
INIT:00605431 mov word ptr [edx+58h], 30h                                ; KGDT_R0_PCR(30h) -> FS
INIT:00605437 mov word ptr [edx+50h], ss
INIT:0060543A mov word ptr [edx+48h], 23h                                ; KGDT_R3_DATA(20h) + RPL_MASK(3h)
INIT:00605440 mov word ptr [edx+54h], 23h                                ; 初始化ES，DS
INIT:00605446 push offset _KiDoubleFaultStack                         ; 使用int 8号的Double Fault堆栈
//…
INIT:0060545D call KiInitializePcr(x,x,x,x,x,x,x)

—————————————————————————————————————————
如果想在XP里设置Handler处理NMI，那么也该仿造以上过程，设置处理例程KiTrap02，把NMI-TSS里的EIP指向你的处理代码，然后建立堆栈,最后还要在iret后面添加jmp回到你的处理代码.原因简单地说,就是每当接受一个NMI中断，处理器会在内部屏蔽再次响应NMI，这一屏蔽过程直到执行中断返回指令IRET后才结束。还是直接看反汇编的KiTrap02代码吧:

.text:00484748 ; =============== S U B R O U T I N E =====================
.text:00484748
.text:00484748 _KiTrap02 proc near
.text:00484748
.text:00484748 var_8 = dword ptr -8
.text:00484748 var_4 = dword ptr -4
.text:00484748
.text:00484748 cli
.text:00484749 mov eax, ds:0FFDFF040h                                  ; nt!_KPCR + 40 == _KTSS
.text:0048474E mov ecx, ds:0FFDFF124h                                  ; nt!_KTHREAD
.text:00484754 mov edi, [ecx+38h]                                               ; Edi= _KPROCESS
.text:00484757 mov ecx, [edi+18h]                                               ; ULONG_PTR DirectoryTableBase[2]
.text:00484757                                                                          ; DirectoryTableBase[1]-> hyperspace
.text:00484757                                                                          ; DirectoryTableBase[0]-> CR3
.text:0048475A mov [eax+1Ch], ecx                                              ; TSS.Edx= DirectoryTableBase[0]
.text:0048475D mov cx, [edi+30h]
.text:00484761 mov [eax+66h], cx                                           ; TSS.IoMapBase= KPROCESS.IopmOffset
.text:00484765 mov ecx, [edi+20h]              &
nbsp;                                ; LdtDescriptor:_KGDTENTRY
.text:00484768 test ecx, ecx
.text:0048476A jz short loc_484770
.text:0048476A
.text:0048476C mov cx, 48h                                                          ;KGDT_LDT(0×48)
.text:0048476C
.text:00484770 loc_484770:
.text:00484770 mov [eax+60h], cx                                                  ; set TSS.LDT
.text:00484774 push dword ptr ds:0FFDFF040h                        ; PcTss
.text:0048477A mov eax, ds:0FFDFF03Ch                                   ; PcGdt(3c)
.text:0048477F mov ch, [eax+5Fh]                                               ; KGDT_NMI_TSS(58)+KgdtBaseHi(7)
.text:00484782 mov cl, [eax+5Ch]                                                ; KGDT_NMI_TSS(58)+KgdtBaseMid(4)
.text:00484785 shl ecx, 16
.text:00484788 mov cx, [eax+5Ah]                                               ; KGDT_NMI_TSS(58)+KgdtBaseLow(2)
.text:0048478C mov ds:0FFDFF040h, ecx                                    ; PcTss
.text:0048478C                                                                        ;// PCR.TSS points to the NMI TSS
.text:0048478C
.text:00484792 pushf
.text:00484793 and [esp+8+var_8], 11111111111111111011111111111111b
.text:0048479A popf                                  ;// Clear Nested Task bit in EFLAGS, no more NMI handler
.text:0048479A
.text:0048479B mov ecx, ds:0FFDFF03Ch                                   ; PcGdt
.text:004847A1 lea eax, [ecx+58h]                                                  ; lea eax, [ecx] +KGDT_NMI_TSS
.text:004847A4 mov byte ptr [eax+5], 10001001b
; 32bit,dpl=0, present, TSS32, not busy
.text:004847A4                                                                              ; // Clear the busy bit in the TSS selector
.text:004847A4
.text:004847A8 mov eax, [esp+4+var_4]                                        ; var_4 = KiSaveProcessorState(…)
.text:004847AB push 0
//… …
.text:0048480B push ebp
.text:0048480C call KiSaveProcessorState(x,x)
.text:0048480C
.text:00484811 call KiHandleNmi() ; <—————- Our CallBack Routines here..
.text:00484811
.text:00484816 or al, al                                                              ; if any CallBackRoutine handled nmi trap..
.text:00484818 jnz short Nmi_Magic_Handled                              ; Jump to restore and wait..
.text:00484818
.text:0048481A cmp ds:NmiUnknowFlag, 0                          &n
bsp;       ;  Nmi counts (Can anybody tell?)
.text:00484821 jnz short loc_484825                                               ; Setup Kernel debugger…
.text:00484821
.text:00484823 jmp short loc_484849                                             ; Pass nmi to Hal.dll,actually crash..
.text:00484823
.text:00484825 ; —————————————————————————
.text:00484825 loc_484825:
.text:00484825 cmp ds:NmiUnknowFlag, 8                                   ; 0 No more Nmi, just pass to HAL
.text:00484825                                                             ; 1-7 Nested Nmi, just pass to HAL and do crash
.text:00484825                                                                                    ; 8 Get into KdDebugger
.text:00484825                                                                                    ; >8 Dead Lock
.text:0048482C jb short loc_484849
.text:0048482C
.text:0048482E jnz short loc_484847

.text:00484830 cmp ds:_KdDebuggerNotPresent, 0               ; if ( !_KdDebuggerNotPresent )
.text:00484837 jnz short loc_484847
.text:00484839 cmp ds:_KdDebuggerEnabled, 0                    ; if ( _KdDebuggerEnabled )
.text:00484840 jz short loc_484847
.text:00484842 call KeEnterKernelDebugger() ; KeEnterKernelDebugger();
.text:00484847 loc_484847:                                                         ; else
.text:00484847 jmp short loc_484847                                       ;  while(1);
.text:00484849 loc_484849:
.text:00484849 inc ds:NmiUnknowFlag
.text:0048484F push 0
.text:00484851 call ds:HalHandleNMI(x) ; <—————- Default Nmihandler in Hal
.text:00484851
.text:00484857 dec ds:NmiUnknowFlag
.text:0048485D jnz short _Nmi_DoCrash                                       ; But can we reach here? hmm..
.text:0048485D
.text:0048485F Nmi_Magic_Handled:
.text:0048485F mov eax, ds:0FFDFF040h                                         ; eax= _KTSS
.text:00484864 cmp word ptr [eax], 58h                                 ; if KGDT_NMI_TSS(58h)
.text:00484868 jz short _Nmi_DoCrash                          ;In another Nmi,we can’t handle it,just crash
.text:00484868
.text:0048486A add esp, 8Ch                                                           ; Nmi handled,so let’s restore
.text:0048486A
.text:00484870 pop dword ptr ds:0FFDFF040h                                ; restore PcTss
.text:00484876 mov ecx, ds:0FFDFF03Ch                                          ; PcGdt
.text:0048487C lea eax, [ecx+28h]                                                       ; lea eax, [ecx] +KGDT_TSS
.text:0048487F mov byte ptr [eax+5], 8Bh                                       ; 32bit, dpl=0, present,TSS32, *busy*
.text:00484883 pushf
.text:00484884 or [esp+4+var_4], 4000h                                        ; Set Nested Task bit in EFLAGS
.text:0048488B popf                                                                            ; then iretd will start a tast switch
.text:0048488C iret
.text:0048488D jmp _KiTrap02 ; <——–!!!!!!!!!!!!!!!!!!!!!
.text:00484892
.text:00484892 _Nmi_DoCrash:
.text:00484892 mov eax, 2
.text:00484897 jmp _KiSystemFatalException        ; Crash!! UNEXPECTED_KERNEL_MODE_TRAP
.text:00484897
.text:00484897 _KiTrap02 endp

大致的流程是设置返回后中断门需要的信息,更新TSS,保存CPU状态,调用用户注册的NMI处理例程;如果不能处理,则交给默认的Nmi Handler,也就是HalHandleNMI(x),但是它并不能做什么实质性的解决工作,只是准备BugCheck…上面还有一些需要详细解释的:

1) KiSaveProcessorState对多核系统是必须的,因为NMI一次只能由一个CPU来处理,如果不保存,会在Bugcheck的时候出现dump出来的信息不准确的情况。
2) NmiUnknowFlag按我的理解是NMI的触发次数,一种情况是iret进BIOS int 10触发另一个NMI，或者由NMI激发进入SMM(查考我之前的一篇文章),而SMM下设置了SMI Handler，那么就会可能再出现NMI，而在SMM RSM切换出来的时候，由于SMM的state save map里并不保存NMI的状态信息，所以RSM必然触发NMI，这样的话我们很有可能面对处理两次或者更多NMI(Nested Nmi)。所以我们必须判断当前是不是nested Nmi，是的话尝试处理。
3) 处理嵌套的Nmi有几种情况，一是调试器触发导致nested Nmi，这个不用担心；对于SMM触发的，那就必须在SMM内部解决掉NMI，这就是我上篇文章里提到的一些内容_[6]，还是那句老话，想接收并处理(unmask)中断，简单的iret是不行的（或者可行，只是我用的测试方法不对:)，如果可以，麻烦指点一二)，得想其他办法，参考我的文章；
4) .text:00484825 cmp ds:NmiUnknowFlag, 8 这个我在一年多前刚看到的时候也很迷惑，但是之后的一个显卡驱动项目让我明白了意思：由于BIOS里的显卡部分会处理int 10，如果处理例程里修改了KGDT_TSS，就可能引发Nmi，而且这是个恶性循环，由于TSS的错位，会产生更多错误的NMI来弥补错误。而这句就是判断是不是超过8个NMI了，是的话神也处理不了了，但是又不能直接Bugcheck，因为这样又会”自作多情”地又调用显卡处理，所以只能死锁掉(while..)。

5) 关于刷新BIOS…这个和我上篇_[6]里也是有关联的.Map BIOS那部分内存简单,你可以translate address,但是想真正修改却是个麻烦事.这个先放着,等有机会好好和大家交流.

言归正传,在XP下,NMI一旦触发,都是交给HalHandleNMI,然后直接crash掉系统.Win2003下提供了一个很好的机制KeRegisterNmiCallback, 你可以注册Nmi的处理例程,这样发生Nmi中断的时候,你可以进行一些收尾工作,但是注意在回调函数里有很多的限制,不能有系统函数调用,不能去获取SpinLock,必须使用Interlocked系列进行数据操作等等..

函数原型:
PVOID
KeRegisterNmiCallback(
PNMI_CALLBACK CallbackRoutine,
PVOID Context
);

还原出来的源代码如下:

static PVOID gKiNmiCallbackListHead= NULL;
KSPIN_LOCK KiNmiCallbackListLock;

typedef struct _KNMI_CALLBACK_RECORD
{
struct _KNMI_CALLBACK_RECORD *PreCallBackRecord;
PNMI_CALLBACK CallbackRoutine;
PVOID Context;
_KNMI_CALLBACK_RECORD *CurCallBackRecord;
} KNMI_CALLBACK_RECORD, *PKNMI_CALLBACK_RECORD;
// 以上是全局变量和结构体的声明.

PVOID _KeRegisterNmiCallback( IN PNMI_CALLBACK CallbackRoutine,
IN OPTIONAL PVOID Context )
{
PVOID result;
PKNMI_CALLBACK_RECORD pKNmiCallbackRecord;
KIRQL OldIrql;
result = ExAllocatePoolWithTag(NonPagedPool, sizeof(KNMI_CALLBACK_RECORD), ‘IMNK’);
pKNmiCallbackRecord = (PKNMI_CALLBACK_RECORD)result;
if ( result )
{
pKNmiCallbackRecord->CallbackRoutine = CallbackRoutine;
pKNmiCallbackRecord->Context = Context;
pKNmiCallbackRecord->CurCallBackRecord = result;
OldIrql = KfAcquireSpinLock(&KiNmiCallbackListLock);
pKNmiCallbackRecord->PreCallBackRecord = gKiNmiCallbackListHead;
InterlockedCompareExchange( (PLONG)&gKiNmiCallbackListHead, (LONG)pKNmiCallbackRecord,(LONG)

gKiNmiCallbackListHead );
KfReleaseSpinLock(&KiNmiCallbackListLock, OldIrql);
result = pKNmiCallbackRecord->CurCallBackRecord;
}
return result;
}

NTSTATUS _KeDeregisterNmiCallback(PVOID Handle)
{
KIRQL OldIrql;
PKNMI_CALLBACK_RECORD *tmpCallBackRecord;
PKNMI_CALLBACK_RECORD CurCa
llBackRecord;
NTSTATUS result;

CurCallBackRecord = (PKNMI_CALLBACK_RECORD)gKiNmiCallbackListHead;
OldIrql = KfAcquireSpinLock(&KiNmiCallbackListLock);
tmpCallBackRecord = &(PKNMI_CALLBACK_RECORD)gKiNmiCallbackListHead;

if ( !gKiNmiCallbackListHead )
{
KfReleaseSpinLock(&KiNmiCallbackListLock, OldIrql);
result = STATUS_INVALID_HANDLE;

return result;
}
do
{
if ( (ULONG)(CurCallBackRecord->CurCallBackRecord) == (ULONG)Handle )
break;
tmpCallBackRecord = (PKNMI_CALLBACK_RECORD*)CurCallBackRecord;
CurCallBackRecord = *(PKNMI_CALLBACK_RECORD*)CurCallBackRecord;
}
while ( CurCallBackRecord );
if ( CurCallBackRecord && (ULONG)(CurCallBackRecord->CurCallBackRecord) == (ULONG)Handle )
{
*tmpCallBackRecord = *(PKNMI_CALLBACK_RECORD*)CurCallBackRecord;
KfReleaseSpinLock(&KiNmiCallbackListLock, OldIrql);
ExFreePoolWithTag(CurCallBackRecord, ‘IMNK’); result = 0;
}
else
{
KfReleaseSpinLock(&KiNmiCallbackListLock, OldIrql);
result = STATUS_INVALID_HANDLE;

}
return result;
}
其中,gKiNmiCallbackListHead是系统的一个全局变量,它指向最后注册的CallBackRecord,以反向的链表把所有的CallBack连接起来.正如MSDN中描述的:
When a nonmaskable interrupt occurs, the system calls each registered callback in reverse order from the orderin which they were registered.
For the first callback, the system passes FALSE as the Handled parameter. For each subsequent callback, if anyprevious callback returned TRUE, the system passes TRUE as the Handled parameter, otherwise it passes FALSE. If any callback returns a value of TRUE, the system considers the interrupt to have been handled.Otherwise, thesystem calls the HAL’s default handler for the interrupt, which normally causes the system to bug check.

正如前面的反汇编代码,NMI处理的流程大致为KiSystemStartup -> _KiTrap02 -> KiHandleNmi -> HalHandleNMI.把其他两个函数的代码也还原如下:

BOOLEAN _KiHandleNmi()
{
PKNMI_CALLBACK_RECORD CurCallBackRecord;
BOOLEAN nmiHandled;
CurCallBackRecord = gKiNmiCallbackListHead;
nmiHandled = FALSE;
while ( CurCallBackRecord )
{
nmiHandled |= (CurCallBackRecord->CallbackRoutine)(CurCallBackRecord->Context, nmiHandled) ;
CurCallBackRecord = CurCallBackRecord->PreCallBackRecord;
}
return nmiHandled;
}

// HalHandleNMI比较长,加了点注释:
void _HalHandleNMI(PVOID NmiInfo)
{
UCHAR EISAExNmiStatus;
UCHAR PortNmiStatus;
UCHAR EisaPort;
PUCHAR Port;
UCHAR EisaNMIMsgBuff[28];
ULONG i;

HalpNMIInProgress = 1;
HalpDoingCrashDump = 1;
EisaPort = READ_PORT_UCHAR((PUCHAR)0×61); // 0×61 -> SYSTEM_CONTROL_PORT_B

if ( InbvIsBootDriverInstalled() )
{
InbvAcquireDisplayOwnership();
InbvResetDisplay();
InbvSolidColorFill(0, 0, 639, 479, 4);
InbvSetTextColor(15); InbvInstallDisplayStringFilter(0);
InbvEnableDisplayString(1); InbvSetScrollRegion(0, 0, 639, 479);
}

HalDisplayString(“\n*** Hardware Malfunction\n\n”);
HalDisplayString(“Call your hardware vendor for support\n\n”);
if ( EisaPort & 0×80 )
HalDisplayString(“NMI: Parity Check / Memory Parity Error\n”);

if ( EisaPort & 0×40 )
HalDisplayString(“NMI: Channel Check / IOCHK\n”);

if ( HalpBusType == 1 ) // #define MACHINE_TYPE_EISA 1
{
EISAExNmiStatus = READ_PORT_UCHAR((PUCHAR)0×461); // 0×461 -> EISA_EXTENDED_NMI_STATUS
EisaPort = EISAExNmiStatus;
if ( (char)EISAExNmiStatus < 0 )
HalDisplayString(“NMI: Fail-safe timer\n”);
if ( EisaPort & 0×40 )
HalDisplayString(“NMI: Bus Timeout\n”);
if ( EisaPort & 0×20 )
HalDisplayString(“NMI: Software NMI generated\n”);
EisaPort = 1;
port = (EisaPort << 12) + 0xC80;
do {
WRITE_PORT_UCHAR(Port, 0xFF);
if ( (char)READ_PORT_UCHAR(Port) >= 0 )
{
PortNmiStatus = READ_PORT_UCHAR(Port + 4);
if ( PortNmiStatus & 0×2 )
{
if ( PortNmiStatus != 0xFFFFFFFF )
{ // EisaNMIMsg[]: “NMI: Eisa IOCHKERR board %\n”
memcpy(EisaNMIMsgBuff, &EisaNMIMsg, sizeof(EisaNMIMsgBuff));
&nbs
p;       i = 0;
if ( EisaNMIMsgBuff )
{
while ( EisaNMIMsgBuff[i] != ‘%’ )
{
++i;
if ( !EisaNMIMsgBuff[i] )
goto DisplayMsg;
}
EisaNMIMsgBuff[i] = (EisaPort > 9 ? ‘A’-10 : ’0′) + EisaPort;
}
DisplayMsg: HalDisplayString(EisaNMIMsgBuff);
}
}
}
++EisaPort; Port += 0×1000;
} while ( EisaPort <= 0xF );
}
HalDisplayString(“\n*** The system has halted ***\n”);
if ( HalpNMIDumpFlag ) //Registry\Machine\System\CurrentControlSet\Control\CrashControl
KeBugCheckEx(0×80, ‘ODT’, 0, 0, 0);
if ( !KdDebuggerNotPresent )
{
if ( KdDebuggerEnabled )
KeEnterKernelDebugger();
} while ( 1 );
}

有意思的是HalpNMIDumpFlag这个全局标志(HalpGetNMICrashFlag),它决定了NMI触发而且要Crash系统的时候是否生成dump_[3].其实就是注册表的这个位置:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control \CrashControl,CrashDumpEnabled设置为2,NMICrashDump设置为1.这个可以为服务器生成dump以调试,比如DELL PE2850,设置好BISO允许使用NMI Button后,你只要按下机器上的NMI按钮就可以了.

todo…

Related posts:

• 中国游戏中心游戏大厅ActiveX远程栈溢出漏洞
• 暴风影音2009(mps.dll)ActiveX远程栈溢出漏洞
• MS07-014调试手记

随机日志

• 2008年09月29日 -- 文章预告：Exploiting Windows Device Drivers
• 2009年05月16日 -- 静态分析驱动的一点技巧
• 2010年08月3日 -- SoftRCE官方T恤开始订购了~
• 2009年06月1日 -- BEIH/F：总线枚举接口劫持/伪造
• 2009年02月1日 -- SoftRCE的Mail Server开通了！
• 2010年02月10日 -- How to adjust the Ace of device object
• 2010年03月11日 -- Think Different
• 2008年11月16日 -- [转载]在英特尔软件网络博客上看到的
• 2008年10月19日 -- [POC]基于IO Packet隐藏文件和注册表，过磁盘解析和总线解析
• 2009年05月30日 -- 基于NDIS Filter 抓包

其实SMM是早在97年就有的东西,我跟这个东西也算是有点渊源,之前在实验室做过一些关于这个的研究，但是远没有到rootkit的方向.之后在逛网站的时候发现一篇5.12时候的新闻:Researchers dig into x86 chips for stealthier rootkits,然后才重新回头去看了这个东西,也隔天就写了篇分析.不过功力尚浅,很多东西在Win32平台到现在我实验着还是有问题的.

SMM类似ICE,ICE是一种硬件调试机制,也是深入到CPU级别的最根本的调试,但是ICE在Intel公司对CPU的改革过程中变成了现在的Branch Trace(tr12)_[1],而SMM也继承ICE的实现方式(但并不是直接的”复制”)独立成为新的机制,主要处理ACPI,详细的介绍看后面的[注]_[2].AMD稍微显得逊色一些,之前的CPU版本可以利用XX软指令去改DR7,也就是说基本是ICE的直接复制.Intel也显示出优越性,一来Intel的SMM是不支持调试触发的,因为Intel把SMM和ICE分开了,再者Intel的SMM也不支持微处理器的指令触发,只能由硬件中断(CPU,ACPI)来引发.我也提到过一个很好的物理方法,就是用信号发生器和频率源去接芯片引脚…

由于太过于依赖硬件,CPU的支持很大程度上决定了SMM的实现方式,而且不同的主板公司(主要是BIOS)也可以实现不同的SMI处理例程,在之前(2008.5.12)我个人觉得要做成rootkit还是有不少问题的.由于SMM的特殊性:CPU不管是怎么切换,由SMI进入SMM或者由RSM切回保护模式,都是悄然无声的,OS是”不知道”的.SMI handler是在POST的时候安装到SMRAM里的.要想rootkit,肯定要想办法遛进SMM.当时也很怀疑Sparks是不是要在类BSD系统上演示,因为相对来说,WIN32更加的困难,有很多的限制,一方面和硬件关联太多,一方面又要PIO操作权限又要内存操作权限,不好处理.

要在正常模式下做成rootkit,首先就要保证控制寄存器位的置位(D_OPEN),因为如果D_CLK位打上去的话,只读了,就失效了.想办法进SMRAM?HSEG(正常系统模式下,0xa0000-0xbffff这段内存是给某些显卡的)看起来remap也不那么简单,位被限制的很死,而且一旦到了Above段,更是一碰就挂…那就是想办法更改SMI Handler了,不过这个比较好检测,AV只要定时检查就能知道是不是有handler被修改了.要不然就是通过BIOS,那就更是多此一举,那么多驱动要BIOS CALL,可以修改BISO直接就搞了[思路上就是动比如bus0-dev1-func0-0x30/33这几个寄存器,PCI配置头它们指示的是expansion rom,会被map到比如0xC0000，刷进去，然后想办法hook int,10号或者其他号,10号想必大家都清楚,VGA小端口会调用比如Ke386CallBios交回控制权.这里还涉及一些VM86的东西,公开的未公开的.推荐一下VBEMP x86 Project 做为副产品,你可以从里面得到关于以上东西的一些灵感.至于Re-flash,这个就不多说了,IO方法很多],但是通过BIOS也可以给SMM-RK做个引子.

不过既然Sparks要在BH上演示,也只好要拭目以待,可惜的是,她在BH上的演讲并没有什么让我觉得为之一亮的地方.因为在BH之前PHRACK爆出的一篇文章里把基本的内容都含盖了:System Management Mode Hack .

Paper里提到触发SMI是通过存取PCI配置寄存器(其实可以衍生出不少方法,比如APM.),类BSD系统上的.PIO 0xCF8-0xCFF,如果是新的PCI-Express MMIO更简单.Paper里只是简单提了下Code relocation,其实这个特性很强大.你可以修改state save map里的SMMBASE值,完成一些隐蔽工作.但是这里可能会有点问题,因为我在这里挂起了很多次.就是如果你需要装进DS,需要在SMM handler里自己从state save map里读出descriptor cache结构体的里CS段的地址值,shr 4后给DS,这样才是指向了重定位后的SMMBASE.其他的值也是一样,你可以修改CRx,CS,EIP,EFLAGS以及CPL(SS.DPL),来实现模式切换(这个很有价值). 关于中断,SMM处理中断并不像Intel手册说的.先看看paper里的2.4.2 – SMM Details这一小节,其实中断确实会被屏蔽,但是paper里的”To enable that is needed to issue the IRET/IRETD instructions” 是不对的, 至少我没成功,我的方法是设置硬件中断例程[timer kick]. 后面又提到code relocation后会出现很多莫名其妙的问题,其实这个和前里提到的一样, CS:IP也需要你手动修改,取SMRAM里的SS,CS值,shr 4然后push入栈,取esp,retf就可以了.

todo… (原文在: http://hi.baidu.com/gz1x)

[1] http://bbs.pediy.com/showthread.php?t=66975

[2] http://en.wikipedia.org/wiki/System_Management_Mode

http://www.biosren.com/thread-29-1-1.html

[3] Nice Links:

[如何跟踪ACPI代码] http://advdbg.com/blogs/advdbg_system/articles/14.aspx

Related posts:

• 构造无人之境: Exploiting Realtek RTL8139单芯片以太网控制器
• About Handling Nmi

随机日志

• 2009年05月1日 -- 暴风影音2009(mps.dll)ActiveX远程栈溢出漏洞
• 2011年04月8日 -- Microsoft Windows xp AFD.sys Local Kernel DoS Vulnerability
• 2009年06月1日 -- BEIH/F：总线枚举接口劫持/伪造
• 2009年04月30日 -- 中国游戏中心游戏大厅ActiveX远程栈溢出漏洞
• 2009年05月16日 -- 静态分析驱动的一点技巧
• 2008年10月19日 -- Vista Bootmgr/Winload使用的大部分选项ID
• 2010年02月10日 -- How to adjust the Ace of device object
• 2011年03月21日 -- QQplayer Memory Corruption Vulnerability
• 2010年03月1日 -- Steve Jobs在斯坦福大学毕业典礼上的演讲
• 2009年05月1日 -- Symbian S60 3rd Reverse CrAcKiNg Tutorial