目前的很多主动防御工具和反XX系统，在对特定进程进行保护的时候，出于兼容性的考虑，都会保留一些白名单。特别是一些系统进程，例如csrss.exe、svchost.exe等等。而针对这些系统进程，判断是否在白名单中的方式，为了简便起见经常采用取系统路径、可执行文件名的方式。

内核中比较明显的能够取到可执行文件路径的方法有下面几个：

1、              通过PEB. ProcessParameters -> ImagePathName取得可执行文件路径，通过PEB. ProcessParameters -> CommandLine取得执行的命令行，以及PEB. ProcessParameters里面其他几个成员取得其他一些相关的路径信息。

2、              通过nt!_EPROCESS的ImageFileName取得。

3、              通过nt!_EPROCESS:: SeAuditProcessCreationInfo:: ImageFileName取得。

4、              通过和_EPROCESS相关的文件对象信息取得。

常见的方式一般只有1、2两种。而上述的前三种方式都可以在运行时被修改掉，用来进行欺骗。特别是PEB里面的信息由于在ring3直接就可以访问，实现上来说非常简单。

下面这段代码通过NtQueryInformationProcess拿到PEB，然后修改路径信息：

HMODULE hMod = GetModuleHandle( _T( "ntdll.dll"));

         pfnNtQueryInformationProcess p = (pfnNtQueryInformationProcess)::GetProcAddress( hMod, "NtQueryInformationProcess");

         PROCESS_BASIC_INFORMATION stInfo = {0};

         DWORD dwRetnLen = 0;

         DWORD dw = p( GetCurrentProcess(), ProcessBasicInformation, &stInfo, sizeof(stInfo), &dwRetnLen);

         PPEB pPeb = stInfo.PebBaseAddress;

         WCHAR wszFullPath[MAX_PATH] = {0};

         WCHAR wszTmp2[MAX_PATH] = {0};

         wcscpy( wszFullPath, wszPath);

         MultiByteToWideChar( CP_THREAD_ACP, 0, szName, -1, wszTmp2, MAX_PATH);

         wcscat( wszFullPath, wszTmp2);

         wcscpy( pPeb->ProcessParameters->ImagePathName.Buffer, wszFullPath);

         pPeb->ProcessParameters->ImagePathName.Length = wcslen( wszFullPath) * sizeof(WCHAR);

         int nParamStart = 0;

         WCHAR *wszTmp = new WCHAR[pPeb->ProcessParameters->CommandLine.MaximumLength];

         ZeroMemory( wszTmp, sizeof(WCHAR) * pPeb->ProcessParameters->CommandLine.MaximumLength);

         wcscpy( wszTmp, pPeb->ProcessParameters->CommandLine.Buffer);

         if ( pPeb->ProcessParameters->CommandLine.Buffer[0] == '"')

         {

                   for ( int i = 1; i < pPeb->ProcessParameters->CommandLine.Length / 2; i++)

                   {

                            if ( pPeb->ProcessParameters->CommandLine.Buffer[i] == '"')

                            {

                                     nParamStart = i;

                            }

                   }

         }

         if ( nParamStart != 0)

         {

                   if ( pPeb->ProcessParameters->CommandLine.Buffer[0] == '"')

                   {

                            pPeb->ProcessParameters->CommandLine.Buffer[0] = NULL;

                            wcscat( pPeb->ProcessParameters->CommandLine.Buffer, L"\"");

                   }

                   else

                   {

                            pPeb->ProcessParameters->CommandLine.Buffer[0] = NULL;

                   }

                   wcscat( pPeb->ProcessParameters->CommandLine.Buffer, wszFullPath);

                   wcscat( pPeb->ProcessParameters->CommandLine.Buffer, wszTmp + nParamStart);

         }

         delete[] wszTmp;

这个方式可以欺骗通过toolhelp函数枚举出来的模块路径，以及直接读取PEB获取进程主模块路径的方式。

另外，通过修改EPROCESS中的主模块名信息，可以欺骗一些在驱动层的程序。基本的代码如下：

首先需要获取EPROCESS里面ImageFileName的偏移。这个函数必须在DriverEntry里面调用。

ULONG GetNameOffsetInEProcss()

{

         PEPROCESS pProcess = NULL;

         ULONG i = 0;

         pProcess = PsGetCurrentProcess();

         for ( i = 0; i < 0x1000; i++)

         {

                   if ( strncmp( "System", (PUCHAR)pProcess + i, strlen("System")) == 0)

                   {

                            return i;

                   }

         }

         return 0;

}

然后可以在IoCtrl里面修改当前进程的名字：

case IOCTL_CHANGE_EXENAME:

                            szName = (char*)Irp->AssociatedIrp.SystemBuffer;

                            if ( !szName)

                            {

                                     ntStatus = STATUS_UNSUCCESSFUL;

                                     break;

                            }

                            pEProcess = PsGetCurrentProcess();

                            strncpy( (PCHAR)pEProcess + g_NameOffsetInEProcess, szName, 16);

                            ntStatus = STATUS_SUCCESS;

                            break;

由于只是示例，所以只实现了良种方式。修改SeAuditProcessCreationInfo里面的信息，考虑到兼容性问题，可能稍微复杂一点。不过也可以比较容易的实现。

这种方式的伪装可以穿过多少主动防御工具没有试过，大家可以去看看，哈哈。

至于对付的方式，可以通过上面说的第四种取进程路径的方法。不过就比较复杂了，呵呵。

流程就是，通过EPROCESS的SectionObject获得文件的FilePointer，通过ObQueryNameString取得这个对象的名字。然后就可以取得主映像模块的路径了。详细的代码可以参考wrk中NtQueryInformationProcess的相关实现。

下面是实现代码:
ImgPathChanger.rar

cc682/NetRoc

http://netroc682.spaces.live.com/

一、             基本原理和基本技术

1、 Rising 2008本身对产品的描述：

瑞星杀毒软件2008中采用的主动防御技术包含三个层次，资源访问规则控制；资源访问扫描；程序活动行为分析引擎，其中尤其以行为分析引擎技术最为关键。

第一层：资源访问控制层（即HIPS）

    它通过对系统资源（注册表、文件、特定系统API的调用、进程启动）等进行规则化控制，阻止病毒、木马等恶意程序对这些资源的使用，从而达到抵御未知病毒、木马攻击的目的。

    第二层：资源访问扫描层（即传统的文件监控、邮件监控等）

    通过监控对一些资源，如文件、引导区、邮件、脚本的访问,并使用拦截的上下文内容（文件内存、引导区内容等）进行威胁扫描识别的方式，来处理已经经过分析的恶意代码。

    第三层：进程活动行为判定层（危险行为判定、DNA识别）

    进程活动行为判定层自动收集从前两层传上来的进程动作及特征信息，并对其进行加工判断。瑞星专家经过对数十万病毒的危险行为进行分析，提炼，设计出全新的主动防御智能恶意行为判定引擎。无需用户参与，该层可以自动识别出具有有害动作的未知病毒、木马、后门等恶意程序。

    目前，市面上的一些主动防御软件只做了三层结构中的部分功能，瑞星认为，只有全面实现三个层级的主动防御，才是真正意义上的“主动防御功能”，如果用户使用不完全的主动防御，将给自己带来严重的安全风险。

帐号保险柜，严密保护您的帐号密码

木马强杀技术，彻底查杀70万木马

2、 分析得到的rising 2008主动防御的体系结构

Rising2008的主动防御体系基本涵盖了它自己描述的几大方面。

l 文件访问控制方面，对关键的系统目录、Rising程序安装目录进行保护，在其他程序进行访问系统目录的时候，弹出用户提示；拒绝对Rising安装目录的修改、删除等操作。

l 进程启动控制方面，通过对注册表相关项的监控实现。很弱智的是，对Start Menu\Programs\Startup的访问没有进行监控。

l 系统动作规则方面，对跨进程访问的一些API调用进行了Hook和控制。包括ntos和少量win32k的操作。在应用程序调用这些API函数时，rising只是给以任务栏的气泡提示，并没有发现可供用户选择策略的方法。这可能也是为了方便大多数普通用户采取的模式。

l 邮件和网页监控由于不在本次分析重点范围内，所以也跳过这部分。不过在驱动内部没有发现和这两个功能相关代码，基本可排除在ring0实现的可能性。

l Rising用于主动防御的文件和基本结构如图：

HookNtos、HookReg、HookSys分别有一个驱动和一个ring3层接口dll构成。HookNtos主要处理对 SSDT中进程保护相关的函数、Win32K的hook和相关逻辑

HookReg主要处理SSDT中注册表相关函数的Hook和逻辑。

HookSys中包含对文件系统驱动的Hook，以及文件扫描、处理等的代码。

上述三个模块，都依赖于一个支持模块HookHelp.sys。HookHelp提供对内核Hook的支持。包括管理Hook所使用的跳板代码的内存等功能。另外，提供对nt!_EPROCESS等内核结构的访问支持，供其它模块获取进程信息使用。

3、 基本技术

Rising主动防御的核心技术只有2个

l SSDT以及SSDT Shadow的Hook

l DriverObject的IRP处理例程Hook

二、             详细实现

1、 HookHelp.sys部分

下图是HookHelp.sys的导出函数

Hook方面Hook的SSDT会跳转到HookHelp中的跳板代码：

f775a571 687caa46f7      push    offset HookNtos+0x1a7c (f746aa7c)

f775a576 c3              ret

通过跳板，实际转到Hook函数中。

ProcessInfo方面，都是从nt!_EPROCESS中获取。

2、 HookReg部分

通过Hook SSDT中以下函数实现：

NtCreateKey

NtDeleteKey

NtDeleteValueKey

NtRenameKey

NtRestoreKey

NtSetSecurityObject

NtSetValueKey

对注册表操作进行监控，向一些关键的注册表主键下面写入或者修改数据，会提示用户并询问操作。主要有以下几处：

3、 HookNtos部分

Hook掉的函数包括SSDT和SSDT Shadow中的一共有以下几个：

这些函数都是对应于瑞星进程保护的各个选项：

另外，对Rising的几个进程，默认都是会进行保护的。

监控了驱动加载和卸载的几个函数，以实现对内核模块加载卸载的控制。

4、 HookSys部分

主要是处理文件操作的Hook。

通过ObReferenceObjectByName获取以下几个设备对象：

\FileSystem\Ntfs

\FileSystem\Fastfat

\FileSystem\fastfat

\FileSystem\MRxSmb

\FileSystem\mrxsmb

\FileSystem\Cdfs

\FileSystem\Rdr

并钩挂DriverObject里面的

IRP_MJ_CLEANUP

IRP_MJ_CLOSE

IRP_MJ_SET_INFORMATION

IRP_MJ_WRITE

IRP_MJ_SET_SECURITY

DRIVER_OBJECT::FastIoDispatch::FastIoWrite

实现对文件监控。

三、             整体评价

Rising的主动防御系统是08年Rising主推的产品特性。总体来看，还是实现得中规中矩。没有什么新东西，但是还是具备基本的一些主动防御产品的特性。例如对系统文件夹访问的控制、对启动项的监控、对驱动加载的监控等等。

不过，和现在市面上绝大多数主动防御系统一样。由于突破关键保护的方法多种多样，并且很多是由系统本身所提供的，主动防御难以面面俱到，将每种方法都进行监控，Rising不可避免的存在一点突破，满盘皆输的毛病。对于普通用户的价值有限。

 http://netroc682.spaces.live.com/

        为了避免自己的某个dll模块被别人检测出来，有时候希望在自己加载一个dll之后，或者将dll注入到他人进程之后避免被检查出来。这就需要想办法抹掉这个dll的模块信息，使得Toolhelp、psapi等枚举模块的API无法枚举它。

        我们可以先简单看看Windows枚举进程内模块的办法吧：

        首先是BOOL EnumProcessModules( HANDLE hProcess, HMODULE* lphModule, DWORD cb, LPDWORD lpcbNeeded);

        EnumProcessModules实际调用EnumProcessModulesInternal进行枚举。下面是vista下psapi的代码片断：

.text:514024B8                 push    ebx

.text:514024B9                 push    18h

.text:514024BB                 lea     eax, [ebp+stProcessBasicInfo]

.text:514024BE                 push    eax

.text:514024BF                 push    ebx      ;ebx=0

.text:514024C0                 push    [ebp+hProcess]

.text:514024C3                 call    ds:__imp__NtQueryInformationProcess@20 ; NtQueryInformationProcess(x,x,x,x,x)

.text:514024C9                 cmp     eax, ebx

.text:514024CB                 jge     short loc_514024E0

        调用NtQueryInformationProcess获得ProcessBasicInformation，在PROCESS_BASIC_INFORMATION结构中取得PEB地址。然后读取指定进程PEB中的数据

text:514024E0 loc_514024E0:                           ; CODE XREF: EnumProcessModulesInternal(x,x,x,x,x)+24j

.text:514024E0                 mov     eax, [ebp+stProcessBasicInfo.PebBaseAddress]

.text:514024E3                 cmp     eax, ebx

.text:514024E5                 jnz     short loc_514024EE

.text:514024E7                 push    8000000Dh

.text:514024EC                 jmp     short loc_514024CE

.text:514024EE ; ---------------------------------------------------------------------------

.text:514024EE

.text:514024EE loc_514024EE:                           ; CODE XREF: EnumProcessModulesInternal(x,x,x,x,x)+3Ej

.text:514024EE                 push    ebx             ; lpNumberOfBytesRead

.text:514024EF                 push    4               ; nSize

.text:514024F1                 lea     ecx, [ebp+Ldr]

.text:514024F4                 push    ecx             ; lpBuffer

.text:514024F5                 add     eax, 0Ch

.text:514024F8                 push    eax             ; lpBaseAddress

.text:514024F9                 push    [ebp+hProcess] ; hProcess

.text:514024FC                 mov     edi, ds:__imp__ReadProcessMemory@20 ; ReadProcessMemory(x,x,x,x,x)

.text:51402502                 call    edi ; ReadProcessMemory(x,x,x,x,x) ; ReadProcessMemory(x,x,x,x,x)

这里读取的是PEB地址+0C处的四个字节。

通过WinDbg我们可以看看nt!_PEB的结构

0: kd> dt nt!_PEB

   +0x000 InheritedAddressSpace : UChar

   +0x001 ReadImageFileExecOptions : UChar

   +0x002 BeingDebugged    : UChar

   +0x003 SpareBool        : UChar

   +0x004 Mutant           : Ptr32 Void

   +0x008 ImageBaseAddress : Ptr32 Void

   +0x00c Ldr              : Ptr32 _PEB_LDR_DATA

  +0x010 ProcessParameters : Ptr32 _RTL_USER_PROCESS_PARAMETERS

……

+0C处是一个_PEB_LDR_DATA结构指针，里面包含了和LDR相关的一些数据，进程的模块链表就保存在Ldr中。下面是_PEB_LDR_DATA的结构：

0: kd> dt nt!_PEB_LDR_DATA

   +0x000 Length           : Uint4B

   +0x004 Initialized      : UChar

   +0x008 SsHandle         : Ptr32 Void

   +0x00c InLoadOrderModuleList : _LIST_ENTRY

   +0x014 InMemoryOrderModuleList : _LIST_ENTRY

   +0x01c InInitializationOrderModuleList : _LIST_ENTRY

   +0x024 EntryInProgress : Ptr32 Void

其中，InLoadOrderModuleList、InMemoryOrderModuleList、InInitializationOrderModuleList就是进程当前已加载模块的链表，只是按照不同的方式排序。EnumProcessModules是通过InMemoryOrderModuleList链表枚举的，而根据Win2k代码，ToolHelp32函数是通过InLoadOrderModuleList枚举。这三个_LIST_ENTRY都是在一个RTL_PROCESS_MODULE_INFORMATION结构中的成员。这个结构在2k代码中有引用，不过没有确切的定义，下面是ReactOS中的定义，不过看起来我的vista PSAPI中使用的结构已经有所变化了，这里只作参考。

//

// Loader Data Table Entry

//

typedef struct _LDR_DATA_TABLE_ENTRY

{

    LIST_ENTRY InLoadOrderLinks;

    LIST_ENTRY InMemoryOrderModuleList;

    LIST_ENTRY InInitializationOrderModuleList;

    PVOID DllBase;

    PVOID EntryPoint;

    ULONG SizeOfImage;

    UNICODE_STRING FullDllName;

    UNICODE_STRING BaseDllName;

    ULONG Flags;

    USHORT LoadCount;

    USHORT TlsIndex;

    union

    {

        LIST_ENTRY HashLinks;

        PVOID SectionPointer;

    };

    ULONG CheckSum;

    union

    {

        ULONG TimeDateStamp;

        PVOID LoadedImports;

    };

    PVOID EntryPointActivationContext;

    PVOID PatchInformation;

} LDR_DATA_TABLE_ENTRY, *PLDR_DATA_TABLE_ENTRY;

到这里，隐藏模块的方法就已经明了了：通过PEB取得Ldr数据，拿到三个模块链表，并将要隐藏的模块断链即可。下面是主要代码实现：

BOOL HideMyself()

{

     HMODULE hMod = GetModuleHandle( _T( "ntdll.dll"));

     HMODULE hModMyself = GetModuleHandle( _T("dll.dll"));

     pfnNtQueryInformationProcess p = (pfnNtQueryInformationProcess)::GetProcAddress( hMod, "NtQueryInformationProcess");

     PROCESS_BASIC_INFORMATION stInfo = {0};

     DWORD dwRetnLen = 0;

     DWORD dw = p( GetCurrentProcess(), 0, &stInfo, sizeof(stInfo), &dwRetnLen);

     PPEB pPeb = stInfo.PebBaseAddress;

     PLIST_ENTRY ListHead, Current;

     PLDR_DATA_TABLE_ENTRY pstEntry = NULL;

     ListHead = &( stInfo.PebBaseAddress->Ldr->InLoadOrderModuleList);

     Current = ListHead->Flink;

     while ( Current != ListHead)

     {

         pstEntry = CONTAINING_RECORD( Current, LDR_DATA_TABLE_ENTRY, InLoadOrderLinks);

         //DebugOutW( L"Module:%s, base:0x%X\r\n", pstEntry->FullDllName.Buffer, pstEntry->EntryPoint);

         if ( pstEntry->DllBase == hModMyself)

         {

              pstEntry->InLoadOrderLinks.Flink->Blink = pstEntry->InLoadOrderLinks.Blink;

              pstEntry->InLoadOrderLinks.Blink->Flink = pstEntry->InLoadOrderLinks.Flink;

              DebugOut( _T( "Hide injected dll."));

              break;

         }

         Current = pstEntry->InLoadOrderLinks.Flink;

     }

     ListHead = &( stInfo.PebBaseAddress->Ldr->InMemoryOrderModuleList);

     Current = ListHead->Flink;

     while ( Current != ListHead)

     {

         pstEntry = CONTAINING_RECORD( Current, LDR_DATA_TABLE_ENTRY, InMemoryOrderModuleList);

         DebugOutW( L"Module:%s, base:0x%X\r\n", pstEntry->FullDllName.Buffer, pstEntry->EntryPoint);

         if ( pstEntry->DllBase == hModMyself)

         {

              pstEntry->InMemoryOrderModuleList.Flink->Blink = pstEntry->InMemoryOrderModuleList.Blink;

              pstEntry->InMemoryOrderModuleList.Blink->Flink = pstEntry->InMemoryOrderModuleList.Flink;

              DebugOut( _T( "Hide injected dll."));

              break;

         }

         Current = pstEntry->InMemoryOrderModuleList.Flink;

     }

     DebugOutW( L"\r\n");

     ListHead = &( stInfo.PebBaseAddress->Ldr->InInitializationOrderModuleList);

     Current = ListHead->Flink;

     while ( Current != ListHead)

     {

         pstEntry = CONTAINING_RECORD( Current, LDR_DATA_TABLE_ENTRY, InInitializationOrderModuleList);

         DebugOutW( L"Module:%s, base:0x%X\r\n", pstEntry->FullDllName.Buffer, pstEntry->EntryPoint);

         if ( pstEntry->DllBase == hModMyself)

         {

              pstEntry->InInitializationOrderModuleList.Flink->Blink = pstEntry->InInitializationOrderModuleList.Blink;

              pstEntry->InInitializationOrderModuleList.Blink->Flink = pstEntry->InInitializationOrderModuleList.Flink;

              DebugOut( _T( "Hide injected dll."));

              break;

         }

         Current = pstEntry->InInitializationOrderModuleList.Flink;

     }

     //DebugOut( _T("Out HideMyself\r\n"));

     return TRUE;

}

        这样处理之后，通过常规的枚举进程方式已经枚举不到隐藏模块，ProcessExplorer也无法枚举。但是，通过枚举进程内存空间等非常规方法，仍然是可以找到的。关于PSAPI和Toolhelp函数枚举模块的原理，可以逆向Windows代码，或者查找网上的代码看看就明白了。

NetRoc

一直想写点技术文章的，但是每次想起这事的时候没时间，有时间的时候又提不起兴致J。

我们有时候需要从系统中某些驱动处理数据的方式，例如作一些过滤、对数据进行一些修改或者监视通过某个设备栈的数据等等。通常情况下是采用Filter Driver的方式实现。但是这样有种种局限性：容易暴露自己的存在、有些情况下可能不能再Detach掉，升级驱动的时候必须重启机器等等。

这里介绍两种通过HOOK方式截取数据的方法。

1、 Hook Dispatch例程。

首先通过ObReferenceObjectByName等函数拿到被Hook设备的DriverObject。有了这个之后，我们就可以用指向自己例程的指针改写MajorFunction数组里面的指针。

NTSTATUS ntStatus = STATUS_SUCCESS;

UNICODE_STRING wszDriverName;

PDRIVER_OBJECT pDriverObject = NULL;

PDRIVER_DISPATCH pOrgDispatch = NULL;

RtlInitUnicodeString( &wszDriverName, DRIVER_NAME);

ntStatus = ObReferenceObjectByName( &wszDriverName,

                  0,

                  NULL,

                  0,

                  *IoDriverObjectType,

                  //NULL,

                  KernelMode,

                  NULL,

                  (PVOID*)&pDriverObject);

if( !NT_SUCCESS(ntStatus))

{

                  DbgPrint( "ObReferenceObjectByName Fail.\r\n");

                  return FALSE;

}

          pOrgDispatch = (PDRIVER_DISPATCH) InterlockedExchange( ( PLONG)&pDriverObject->MajorFunction[IRP_MJ_READ], (LONG)&DispatchMyRead);

          ……

卸载的时候同样这样修改回去即可。

这种方法比较方便，由于只需要改写一个函数指针，避免了inline hook的很多不稳定因素。另外，在调用原来的Dispatch例程的时候也只需要直接call它就行了。

但是，如果有些IRP不能立即完成的，例如键盘鼠标驱动的IRP，用这种方法就拿不到完成时候的数据了。因此我们还需要第二种方式J

2、 Hook Completion Routine。

在Hook掉的Dispatch里面，我们已经拿到了发到下层驱动的IRP。想在完成时再获得控制权，很简单，只需要再Hook掉Completion Routine。

NTSTATUS DispatchMyRead ( IN PDEVICE_OBJECT pDeviceObject, IN PIRP Irp)

{

         PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation( Irp);

         //需要保存一下旧的完成例程信息

              g_RecentIrpInfo.ComplettionRoutine = irpSp->CompletionRoutine;

              g_RecentIrpInfo.Context = irpSp->Context;

              g_RecentIrpInfo.Control = irpSp->Control;

              g_RecentIrpInfo.irpSp = irpSp;

              //安装自己的完成例程

              irpSp->CompletionRoutine = MyIoCompletion;

              irpSp->Context = NULL;

              irpSp->Control = SL_INVOKE_ON_SUCCESS;    

              //OK，call下去。

ntStatus = g_ pOrgDispatch ( pDeviceObject, Irp);

return ntStatus;

}

前段时间和yuewang和一块三毛钱商量着写写Windows分析的文章，我来开个头吧，哈哈。既然是开头，所以就选择了内核入口点开始，我向来不怎么会写文章，也就当流水账记记吧，看能不能引出他们更好的分析出来J

Ntoskrnl的入口点函数名是KiSystemStartup，这是bootloader执行了一些基本的初始化之后跳转到的内核入口函数，用汇编语言实现。

一、KiSystemStartup功能介绍

KiSystemStartup第一次运行于processor 0，主要是初始化一些系统硬件状态，调用一些系统初始化过程，然后就进入调度程序，开始系统调度过程。而对于其他processor，初始化的时候也是进入KiSystemStartup，但是做的工作有所区别而已。

二、Processor 0(以后简称P0)开始执行KiSystemStartup时的系统环境

这个运行环境是由bootloader准备好的：

1、 一个精简版的IDT环境，从0到0x1F号中断已经被准备好

2、 一个完整的GDT被初始化出来并且Load。

3、 完整的TSS被初始化并且Load。

4、 页面映射经过了基本的初始化，并且设置好了初始化所需的最少的页面。虚拟内存的最低4M被直接映射到物理内存中。

5、 ntoskrnl.exe被装载到它内存描述符中的地址。也即编译时确定的基地址。

6、 DS=ES=SS，ESP指向一个可用的栈中。

7、 中断被关闭。

三、其他Processor开始执行KiSystemStartup的环境

IDT, GDT, TSS, stack, selectors, PCR全部初始化完成并可用，页表设置为当前运行的页表(这一点偶也不太明白，可能还需要看看以后的代码才能理解)，具备一个LoaderBlock，作为在该处理器上执行KiSystemStartup的参数。

四、大致流程

1、 KiSystemStartup将参数KissLoaderBlock放到全局变量_KeLoaderBlock中

2、 取出_KeNumberProcessors，并判断是否是0。_KeNumberProcessors保存了系统中的处理器数目，这个变量被初始化为0，所以当Ntoskrnl开始执行时，这个变量还没有被填充。因此判断_KeNumberProcessors是否是0，就可以知道当前是不是第一次执行KiSystemStartup。

3、 如果是P0，会将_KiInitialThread和P0BootStack的地址分别保存 到_KeLoaderBlock中的对应字段中。_KiInitialThread是系统启动之后的初始线程，而P0BootStack应该是初始化时临时使用的内核堆栈，定义为db      KERNEL_STACK_SIZE dup (?)。KERNEL_STACK_SIZE在i386中是0x3000，在AMD64中是0x6000。然后会设置fs为0x30，这是内核_KPCR结构的在GDT中序号。最后，会将处理器序号，也就是0，保存到_KPCR中对应位置，这个位置在i386和AMD64中也是不同的。

4、 下面又是所有处理器都会执行的代码了，设置初始线程的_ETHREAD:: Tcb:: ApcState:: ApcListHead[0]，将_LIST_ENTRY的Flink和Blink都设置为自身。

5、 调用_KiInitializeMachineType过程，会设置一下机器类型。不过这里做得很简单，这个函数可能在未来也会有较大更改。主要的机器类型信息可能包含了总线类型、CPU大致的系列等简单信息。

6、 然后又判断是否是P0，如果不是，会跳过一大段初始化代码。

7、 在P0的情况下，调用GetMachineBootPointers函数，获取由bootloader初始化过的一些信息。从这个函数返回后，edi中保存gdt基地址，esi中保存pcr基地址，edx保存tss基地址，eax保存idt基地址。KiSystemStartup接下来会将这些值保存到自己的局部变量中使用。

8、 Bootloader初始化的TSS是16位的，KiSystemStartup在这里会将它的标志改为32位，然后连续调用_KiInitializeTSS2和_KiInitializeTSS初始化TSS。KiInitializeTSS2初始化了内核TSS结构在GDT中描述符的界限大小，以及初始化IOPM的相关结构。_KiInitializeTSS在TSS中首先设置不使用IOPM，然后设置Tss->Flags = 0，将EFLAGS清空。最后将LDT和ss0都设置为0。设置完成后，重新装载TR寄存器。

9、 接下来设置了double fault task gate。这里会设置IDT中的08号中断，设置成了一个任务门，并填充相应的TSS结构，是用于#DF异常时的。

10、             设置用于NMI fault 的task gate，设置IDT的02号中断。这是用于不可屏蔽中断的中断号。同样也调用_KiInitializeTSS填充了另外一个TSS结构。上面两条详细的原理参考Intel手册关于IDT和task gate的描述。

11、             调用_KiInitializePcr初始化了当前的pcr。

12、             将初始进程的_EPROCESS地址，即_KiInitialProcess的地址设置到了初始线程的_ETHREAD:: Tcb:: ApcState:: Process中。

13、             设置PCR->Teb = 0。

14、             设置PCR->PrcbData.ProcessorState.SpecialRegisters.KernelDr6和PCR->PrcbData.ProcessorState.SpecialRegisters.KernelDr7为0。这里是为了初始化内核调试器相关的东西，具体作用可能只有分析到相关代码才能知道了。

15、             调用_KiSwapIDT转换IDT描述符的格式。IDTENTRY定义如下：

typedef struct tagIDTENTRY

{

        unsigned short OffsetLow;

        unsigned short Selector;

        unsigned char Reserved;

        unsigned char Type:4;

        unsigned char Always0:1;

        unsigned char Dpl:2;

        unsigned char Present:1;

        unsigned short OffsetHigh;

} IDTENTRY, *PIDTENTRY;

这个函数将ntoskrnl定义的IDT表项数组中，选择子的Selector和OffsetHigh字段对换。这里估计是在初始化这些表项的时候，为了方便直接将处理代码的地址填到了&OffsetLow中，所以Selector保存了高位的地址，然后到后面来统一替换。详细的原理参见Intel手册。

16、             将ds和es的值设置为0x23，也就是Ring3下的ds和es值。

17、             将ntoskrnl中_IDT数组的内容复制到当前的IDT表中。前面设置的double fault和 nmi fault的表项不会被覆盖掉，而是使用新设置的内容。

18、             接下来又是所有处理器都会执行的操作了。调用_KiProcessorStart初始化处理器。这个函数会根据KiProcessorStartControl的不同值进行不同的操作，例如获取一些处理器信息、启动或者停止处理器等等。由于P0已经不需要初始化了，所以在P0阶段这个函数直接返回。

19、             获取_KiFreezeExecutionLock这个锁，用于修改一些和处理器相关的全局资源。主要是_KPCR里面的处理器相关的信息。然后调用了_HalInitializeProcessor函数，初始化该处理器的IDT。估计这个函数会继续为每个处理器调用KiSystemStartup函数。不过没能确认。

20、             将IRQL的信息保存下来。这是hal由参数传过来的。

21、             在_KeActiveProcessors中设置初始化完成的处理器MASK。

22、             调用_KiInitializeAbios初始化ABIOS结构。这里的详细原理就不太清楚了，因为没能分析过相关部分。

23、             将_KeNumberProcessors加1，增加已初始化完成的处理器数量。然后就会释放掉_KiFreezeExecutionLock锁了。

24、             接下来调用_KdInitSystem函数。这里应该会初始化内核调试器。只在P0上调用。

25、             后面将会初始化内核了，首先会将IRQL提升到HIGH_LEVEL，并初始化调用内核初始化函数使用的寄存器，包括传递参数的eax,ebx,edx，以及用于堆栈访问的esp和ebp。然后就调用_KiInitializeKernel进行内核初始化。这个函数相当复杂，也够一篇文章，这里就不写了。呵呵

26、             出来之后设置idle thread的优先级为0，开中断，降低IRQL到DISPATCH_LEVEL。然后检查并等待_KiBarrierWait这个锁。对P0来说，由于_KiBarrierWait初始化为0，所以直接就跳到idle线程了，其他处理器会一直等待_KiBarrierWait，直到允许他们运行。

27、             最后通过一个长跳转到KiIdleLoop函数，开始系统的处理和调度，整个系统初始化过程就完成了。

五、后记

唉，真的写起来才发现文章不好写啊。自己再看的时候都感觉不清不楚的，呵呵。不过暂时就这样吧J

Ring3层包括几个dll和一个进程。看里面貌似使用了pipe相关的函数，运行时也起了一个进程。所以XTrap的架构应该和NP很类似，但是实现上就要弱很多了。

1、 现在还没发现有ring3全局注入的dll。

2、 大量工作放到了作为和游戏接口的dll里面。通过dll方式提供游戏使用这点不同于NP的lib库，而更类似HS。这种方式一大弱点就是那个dll容易被模拟，并且比较难发现。

3、 驱动相对来说应该是三个系统里面最弱的了，原因下面会讲到。花了5天时间逆出了整个驱动的源码，好像没有那么多硬编码的东西，呵呵。不过倒是发现了一些编程的BUG什么的。基本的功能点只有三个：HOOK SSDT实现的跨进程访问控制、通过对IoAccessMap的设置关闭对鼠标键盘端口访问权限、通过挂接Int 1中断获得调试信息。

大概的流程如下：

1、 DriverEntry：通过PsGetVersion判断系统版本，并根据不同的版本保存要Hook的在SSDT Shadow表中服务的ID。而SSDT表中的则是由后面IoControl里面Ring3传下来的。目前来看已经支持Vista了。通过KeQuerySystemTime拿了一下系统时间并保存下来，不过后面就没有再使用了，估计以后为了反调试会做时间检查什么的东西吧。申请了0x2000长度的内存，这是用于后面设置IoAccessMap的。然后就是例行的IoCreateDevice和IoCreateSymbolicLink，设置Dispatch例程。XTrap的IRP_MJ_DEVICE_CONTROL、IRP_MJ_CREATE、IRP_MJ_CLOSE、IRP_MJ_CLEANUP是在同一个例程中处理的。最后有一个莫名其妙的调用KfLowerIrql( KeRaiseIrqlToDpcLevel());偶的水平实在是还难以理解高丽棒子为啥要这样做，嘿嘿。

2、 剩下的就是通过DeviceIoControl来控制的了，我这个版本的XTrap一共有17个ControlCode。Dispatch例程的代码如下

NTSTATUS

XDvaDispatchAll( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp)

{

         PIO_STACK_LOCATION pIrpStack;

         PVOID pSystemBuffer;

         PVOID pOutBuffer;

         ULONG ulMajorFunction;

         NTSTATUS ntStatus;

         pIrpStack = IoGetCurrentIrpStackLocation( Irp);

         Irp->IoStatus.Status = STATUS_SUCCESS;

         Irp->IoStatus.Information = 0;

         pSystemBuffer = Irp->AssociatedIrp.SystemBuffer;

         ulMajorFunction = pIrpStack->MajorFunction;

         switch( ulMajorFunction)

         {

         case IRP_MJ_DEVICE_CONTROL:

                  if( (pIrpStack->Parameters.DeviceIoControl.IoControlCode & 0x3) == 0x3)

                  {

                           pOutBuffer = Irp->UserBuffer;

                  }

                  else

                  {

                           pOutBuffer = pSystemBuffer;

                  }

                  return DoDeviceIoControl( Irp, pIrpStack->FileObject, 1, pSystemBuffer,

                           pIrpStack->Parameters.DeviceIoControl.InputBufferLength,

                           pOutBuffer, pIrpStack->Parameters.DeviceIoControl.OutputBufferLength,

                           pIrpStack->Parameters.DeviceIoControl.IoControlCode,

                           &Irp->IoStatus, DeviceObject);

         case IRP_MJ_CLOSE:

                  HookSSDT( g_HookInfo.NtOpenProcessInfo.Id, (ULONG)g_pNtOpenProcess, (ULONG)NewNtOpenProcess);

                  HookSSDT( g_HookInfo.NtDeviceIoControlFileInfo.Id, (ULONG)g_pNtDeviceIoControlFile, (ULONG)NewNtDeviceIoControlFile);

                  HookSSDT( g_HookInfo.NtWriteVirtualMemoryInfo.Id, (ULONG)g_pNtWriteVirtualMemory, (ULONG)NewNtWriteVirtualMemory);

                  HookSSDT( g_HookInfo.NtOpenSectionInfo.Id, (ULONG)g_pNtOpenSection, (ULONG)NewNtOpenSection);

                  HookSSDT( g_HookInfo.NtProtectVirtualMemoryInfo.Id, (ULONG)g_pNtProtectVirtualMemory, (ULONG)NewNtProtectVirtualMemory);

                  HookSSDT( g_HookInfo.NtTerminateProcessInfo.Id, (ULONG)g_pNtTerminateProcess, (ULONG)NewNtTerminateProcess);

                  HookSSDT2( g_dwNtGdiGetPixelId, (ULONG)g_pNtGdiGetPixel, (ULONG)NewNtGdiGetPixel);

                  HookSSDT2( g_dwNtUserSendInputId, (ULONG)g_pNtUserSendInput, (ULONG)NewNtUserSendInput);

                  HookSSDT2( g_dwNtUserCallNextHookExId, (ULONG)g_pNtUserCallNextHookEx, (ULONG)NewNtUserCallNextHookEx);

                  HookSSDT2( g_dwNtUserPostMessageId, (ULONG)g_pNtUserPostMessage, (ULONG)NewNtUserPostMessage);

                  HookSSDT2( g_dwNtUserTranslateMessageId, (ULONG)g_pNtUserTranslateMessage, (ULONG)NewNtUserTranslateMessage);

                  if( g_byIsSuccess)

                  {

                           g_byIsSuccess = FALSE;

                  }

                  if( g_byIsReboot)

                  {

                           _asm cli;

                           WRITE_PORT_UCHAR( (PUCHAR)0x64, (UCHAR)0xFE);

                           _asm hlt;

                  }

                  else

                  {

                           ntStatus = STATUS_SUCCESS;

                  }

                  break;

         case IRP_MJ_CREATE:

                  if( g_arrSomeCode[0] == 0)

                  {

                           memcpy( g_arrSomeCode, MyInt1, 5*sizeof( ULONG));

                  }

                  ntStatus = STATUS_SUCCESS;

                  break;

         case IRP_MJ_CLEANUP:

                  ntStatus = STATUS_SUCCESS;

                  break;

         default:

                  Irp->IoStatus.Status = STATUS_INVALID_DEVICE_REQUEST;

                  ntStatus = STATUS_INVALID_DEVICE_REQUEST;

         }

         IofCompleteRequest( Irp, IO_NO_INCREMENT);

         return ntStatus;

}

IRP_MJ_DEVICE_CONTROL的处理是在另外一个函数里面，由于太复杂，影响blog的美观，就不写出来了，哈哈。这里面可以看到，XTrap采用了和NP一样的办法重起电脑，就是往64端口写0xFE。挺白痴的是居然通过WRITE_PORT_UCHAR，难道以为只有他会Hook~

IRP_MJ_CREATE里面把自己的Int 1 函数的代码复制了一段出来，这个会用于后面再覆盖回去，是用于对付Inline hook的伎俩。

其他就没什么好说的了。

3、 关于SSDT的Hook

SSDT中Hook的函数有以下几个：NtOpenProcess、NtDeviceIoControlFile、NtWriteVirtualMemory、NtOpenSection、NtProtectVirtualMemory、NtTerminateProcess

Shadow Table中Hook的函数有下面几个：NtGdiGetPixel、NtUserSendInput、NtUserCallNextHookEx、NtUserPostMessage、NtUserTranslateMessage。

所有函数Hook的目的都很清楚，没有什么古怪的地方，呵呵。不过相当部分的钩子都只是简单的pass过去，并没有任何实质性的处理。可以看出来XTrap仍然是一个非常不完善的系统，这些部分应该都是留到以后进行功能扩充的。

关于Shadow Table的处理有一些特别的地方。Shadow Table的地址获取采用了硬编码+验证的方式。这一点偶个人觉得还是在KeAddSystemServiceTable中去取比较好，至少说在出现新的系统的时候很大可能并不用修改代码。另外，取到Shadow Table地址之后，除了将KSERVICE_TABLE_DESCRIPTOR地址保存之外，还将Shadow Table的Base保存到了KeServiceDescriptorTable第二项的Base中，以后在Hook或者其他操作的时候就直接到KeAddSystemServiceTable地址+0x10去取了。这一点我也觉得有些奇怪，保存到全局变量什么的不就好了，为什么要去修改系统本身的东西，虽然目前那个位置并没有什么用。大约是为了反调试。

4、 关于Int 1的处理

这里貌似也没什么好说的，记录了一下断点被触发的次数、dr0到dr4的内容什么的，然后IoControl里面Ring3会取走这些信息。不过有个很搞笑的BUG，Hook中断的函数里面的cli没有对应的sti。

5、 关于IoAccessMap的处理

这里没什么好说的，是由Ring3触发，Ring0实现。贴一段DeviceIoContrl里面的代码就明白了。

case 0x85000044:

                  ntStatus = STATUS_INVALID_PARAMETER;

                  if( !pSystemBuffer || ulInputBufferLength != 4)

                  {

                           break;

                  }

                  PsLookupProcessByProcessId( *((ULONG*)pSystemBuffer), pSystemBuffer);

                  ((PUCHAR)g_pIoAccessMap)[0x0C] |= 0xFF;

                  ((PUCHAR)g_pIoAccessMap)[0x0D] |= 0xFF;

                  Ke386IoSetAccessProcess( pSystemBuffer, 1);

                  Ke386SetIoAccessMap( 1, g_pIoAccessMap);

                  ntStatus = STATUS_SUCCESS;

                  break;

         现在模拟键盘的所谓硬件模式，大部分人都是使用了网上一些开源工具，例如WinIo，基本原理就是通过IoAccessMap打开ring0的端口读写权限(啰嗦一句，上次看到某人拿来的一个sys，貌似将整个机器的io都打开了，实在是无比暴力……。寒一个)。所以对应办法就是也通过改写IoAccessMap关闭掉权限。

这也是我现在比较推荐使用的方法，对使用WinIo的按键精灵什么的外挂，都有药到病除的疗效。而且，影响范围比较小，只关闭了有限的端口。对于某些特殊情况下的程序，也可以发现之后再单独处理。不过对于自己写驱动读写端口的一类外挂来说，任何办法都没用了。In~~~out~~~~in~~~~out~~~~~in~~~~~~out~~~~~~J

6、 下面选一些函数贴出来吧J

ULONG __stdcall

NewNtGdiGetPixel( PVOID hDC, LONG XPos, LONG YPos)

{

         BOOLEAN blIsBlock = TRUE;

         if ( g_dwCurrentProcessId == (ULONG)PsGetCurrentProcessId())

         {

                  blIsBlock = FALSE;

         }

         //这里奇怪,不知道为什么这么搞

         if ( XPos == 0)

         {

                  if( YPos != 0)

                  {

                           if( YPos == 0x5A)

                           {

                                     blIsBlock = FALSE;

                           }

                  }

                  else

                  {

                           blIsBlock = FALSE;

                  }

         }

         if( g_byIsSuccess == TRUE && blIsBlock == TRUE)

                  return 0;

         return g_pNtGdiGetPixel( hDC, XPos, YPos);

}

ULONG

__stdcall NewNtUserSendInput(

                                                                  ULONG nInputs,

                                                                  LPINPUT pInput,

                                                                  ULONG cbSize)

{

         if( (g_byIsSuccess != TRUE) || (g_byAllowUserSendInput == TRUE))

         {

                  return g_pNtUserSendInput( nInputs, pInput, cbSize);

         }

         else

         {

                  return 1;

         }

}

NTSTATUS

__stdcall NewNtOpenProcess (

                                                                 PHANDLE ProcessHandle,

                                                                 ACCESS_MASK DesiredAccess,

                                                                 POBJECT_ATTRIBUTES ObjectAttributes,

                                                                 PCLIENT_ID ClientId

                                                                 )

{

         if( g_dwCurrentProcessId != 0)

         {

                  if( (ULONG)ClientId->UniqueProcess == g_dwCurrentProcessId)

                  {

                           if( DesiredAccess != 0x478)

                           {

                                     DesiredAccess &= 0xFFFFFFCF;//清掉PROCESS_VM_READ和PROCESS_VM_WRITE

                           }

                  }

         }

         if( g_dwProtectPid2 != 0)

         {

                  if( g_dwProtectPid2 == (ULONG)ClientId->UniqueProcess)

                  {

                           DesiredAccess &= 0x0FFFFFFFE; //清掉PROCESS_TERMINATE

                  }

         }

         if( g_dwCurrentProcessId == (ULONG)ClientId->UniqueProcess)

         {

                  g_dwIsSomeoneOpenMe = 1;

         }

         return g_pNtOpenProcess( ProcessHandle, DesiredAccess, ObjectAttributes, ClientId);

}

NTSTATUS

__stdcall NewNtWriteVirtualMemory(

                                                                           HANDLE ProcessHandle,

                                                                           PVOID BaseAddress,

                                                                           CONST VOID *Buffer,

                                                                           SIZE_T BufferSize,

                                                                           PSIZE_T NumberOfBytesWritten

                                                                           )

{

         BOOLEAN blIsNeedSkip = FALSE;

         PROCESS_BASIC_INFORMATION stProcessInfo;

         HANDLE Handle;

         HANDLE hCurrentPid;

         RtlZeroMemory( &stProcessInfo, sizeof(stProcessInfo));

         if( STATUS_SUCCESS ==

                  ZwDuplicateObject( (HANDLE)0xFFFFFFFF,

                                                                 ProcessHandle,

                                                                 (HANDLE)0xFFFFFFFF,

                                                                 &Handle,

                                                                 0x400,

                                                                 0,

                                                                 0)

                  )

         {

                  ZwQueryInformationProcess( Handle, 0, &stProcessInfo, 0x18, 0);

                  ZwClose( Handle);

         }

         if( g_dwCurrentProcessId == (ULONG)stProcessInfo.UniqueProcessId)

         {

                  blIsNeedSkip = TRUE;

         }

         hCurrentPid = PsGetCurrentProcessId();

         if( (ULONG)hCurrentPid == g_dwSafePid1 ||

                  (ULONG)hCurrentPid == g_dwSafePid2 ||

                  (ULONG)hCurrentPid == g_dwSafePid3)

         {

                  blIsNeedSkip = FALSE;

         }

         if( (ULONG)hCurrentPid == g_dwCurrentProcessId)

         {

                  if( (g_dwFromUser2 | 0xFFFFF0F) == 0xFFFFF1F)

                  {

                           blIsNeedSkip = FALSE;

                  }

         }

         if ( !g_byIsSuccess || !blIsNeedSkip)

         {

                  return g_pNtWriteVirtualMemory( ProcessHandle, BaseAddress, Buffer, BufferSize, NumberOfBytesWritten);

         }

         return 0;

}

ULONG __stdcall NewNtUserTranslateMessage(PMSG lpMsg, ULONG dwhkl)

{

         CHAR ucScanCode, ucScanCode2;

         UCHAR blNeedSkip = FALSE;

         if( lpMsg->message == 0x100 || lpMsg->message == 0x101)

         {//WM_KEYDOWN,WM_KEYUP

                  ucScanCode2 = IsNeedSkipKeyMsg( lpMsg->wParam);

                  if( ucScanCode2)

                  {

                           ucScanCode = (lpMsg->lParam & 0x00FF0000) >> 16;

                           if( ucScanCode == ucScanCode2)

                           {

                                     blNeedSkip = TRUE;

                           }

                  }

         }

         if( !g_byIsSuccess || !blNeedSkip)

         {

                  return g_pNtUserTranslateMessage( lpMsg, dwhkl);

         }

         return 1;

}

         后记：

不知不觉做反XX工作已经快两年了，再加上做XX工作的时间，突然发现搞这些东西居然这么久了。貌似接触的东西都没什么新意了，万变不离其宗。XX和反XX也就那么几招，倒不如直接找人去砍来得方便快捷。至此三大系统全部告破，呵呵。

众里寻她千百度，蓦然回首，偶还是喜欢.NET。

奇怪，我的MSIME打不出来“蓦”。

关键词：I/O Permission Bit Map、按键精灵、模拟键盘鼠标

今天又被恶心了，上班不想工作。来谈谈IoAccessMap相关的一些东西吧。

我在上一篇XTrap驱动分析的文章里面提到过，现在的一些模拟键盘鼠标输入的程序使用了一种所谓硬件模式的东西，例如按键精灵。其实就是使用了WinIo这样一些打开进程在Ring3访问端口权限的库。这里会详细分析一下他们的实现机制，以及对付这些工具的推荐方法。

首先摘抄一段WinIo驱动里面的代码：

case IOCTL_WINIO_ENABLEDIRECTIO:

          OutputDebugString("IOCTL_WINIO_ENABLEDIRECTIO");

          pIOPM = MmAllocateNonCachedMemory(sizeof(IOPM));

          if (pIOPM)

          {

            RtlZeroMemory(pIOPM, sizeof(IOPM));

            Ke386IoSetAccessProcess(PsGetCurrentProcess(), 1);

            Ke386SetIoAccessMap(1, pIOPM);

          }

          else

            Irp->IoStatus.Status = STATUS_INSUFFICIENT_RESOURCES;

        break;

ok，打开端口权限的所有秘密就在这里了。不过我们要先介绍一下Inter CPU对IoAccessMap的定义。

I386架构下，每个进程拥有的TSS块包含一个I/O Permission Bit Map，其中定义了该进程对各个端口的读写权限。I/O Permission Bit Map的每一位对应一个端口。例如和鼠标键盘相关的端口对应于bit60和bit64。另外，在EFLAGS寄存器中的bit12、bit13指示了IN, INS, OUT, OUTS, CLI, STI这几条指令需要的IOPL。当CPL大于IOPL时，IO访问时就会再查询I/O Permission Bit Map里面对应bit是否为0，如果为0则允许IO访问，否则会触发general-protection exception (#GP)。

所以，如果要打开某个进程的IO权限，只需要修改它的I/O Permission Bit Map就可以了。

Windows为每个进程保存的TSS结构如下：

typedef struct _KTSS {

    USHORT Backlink;

    USHORT Reserved0;

    ULONG   Esp0;

    USHORT Ss0;

    USHORT Reserved1;

    ULONG   NotUsed1[4];

    ULONG   CR3;

    ULONG   Eip;

    ULONG   EFlags;

    ULONG   Eax;

    ULONG   Ecx;

    ULONG   Edx;

    ULONG   Ebx;

    ULONG   Esp;

    ULONG   Ebp;

    ULONG   Esi;

    ULONG   Edi;

    USHORT Es;

    USHORT Reserved2;

    USHORT Cs;

    USHORT Reserved3;

    USHORT Ss;

    USHORT Reserved4;

    USHORT Ds;

    USHORT Reserved5;

    USHORT Fs;

    USHORT Reserved6;

    USHORT Gs;

    USHORT Reserved7;

    USHORT LDT;

    USHORT Reserved8;

    USHORT Flags;

    USHORT IoMapBase;

    KIIO_ACCESS_MAP IoMaps[IOPM_COUNT];

    //

    // This is the Software interrupt direction bitmap associated with

    // IO_ACCESS_MAP_NONE

    //

    KINT_DIRECTION_MAP IntDirectionMap;

} KTSS, *PKTSS;

其中的IOPM_COUNT定义为1。貌似本来Windows想为每个Process保存多个IoAccessMap，默认只保存了一个。在访问相关函数时，如果制定MapNumber为0，则表示不使用IoAccessMap。所以0号map是虚拟出来的，这点在wrk1.2代码中可以确认。

以下三个函数用于访问IoAccessMap：

BOOLEAN Ke386QueryIoAccessMap(ULONG MapNumber, PKIO_ACCESS_MAP IoAccessMap);用于查询IoAccessMap

BOOLEAN Ke386SetIoAccessMap(ULONG MapNumber, PKIO_ACCESS_MAP IoAccessMap);用于设置IoAccessMap

BOOLEAN Ke386IoSetAccessProcess(PKPROCESS Process, ULONG MapNumber);用于设置某个Process使用的IoAccessMap号

下面分别讲一下三个函数的作用。

Ke386QueryIoAccessMap将系统KTSS中的IoMaps复制出来，也就是查询当前的IoAccessMap。MapNumber传入Map号，当为0的时候表示指定IO_ACCESS_MAP_NONE，此时将传入IoAccessMap的所有位置1，当MapNumber为其他值时，复制对应的Map。

Ke386SetIoAccessMap将IoAccessMap中的内容复制到指定MapNumber的内容中，当为0时返回FALSE，当为其他合法值时，Ke386SetIoAccessMap会创建一个DPC，并在DPC中将IoAccessMap的内容复制到进程TSS的IoMaps中。

Ke386IoSetAccessProcess则是设置Process使用的IoAccessMap号。同样，会创建一个DPC，并由DPC修改指定进程的EPROCESS中的IopmOffset。

Ok，回过头来看WinIo的代码就一目了然了

pIOPM = MmAllocateNonCachedMemory(sizeof(IOPM));

          if (pIOPM)

          {

            RtlZeroMemory(pIOPM, sizeof(IOPM));

            Ke386IoSetAccessProcess(PsGetCurrentProcess(), 1);

            Ke386SetIoAccessMap(1, pIOPM);

          }

首先Alloc一块内存，大小总是为0x2000字节，并将所有位置为0，也就是说打开0~0x10000端口的读写权限。

Ke386IoSetAccessProcess的调用是确认使用IoAccessMap，然后通过Ke386SetIoAccessMap将map设置进去。

这样的方式似乎有点暴力了，如果改良一下的话，可以设置为只打开需要的端口。

这种方式其实为系统打开了很大的漏洞，在ring3为一个进程打开了权限，实际上就是为任何人打开了权限。再加上往64端口写东西又可以重起机器什么的，呵呵……不说了。

当然，如果要关掉对应的权限，就可以反其道而行之，将map中对应位设置为1即可。这就是我在上篇文章中提到的方法了。

话说回来，wrk真是好东西，哈哈。