博客园_Zachary.XiaoZhen - 梦想的家园

C/C++ SQLite 之基础篇

2012-03-31T02:24:00Z

文章目录：

1. 下载 SQLite3 源码：

2. 下载 SQLite3.dll 文件：

3. 生成 SQLite3.lib 文件：

4. 生成或者下载 SQLite3 Shell 文件：

5. 创建数据库以及数据表：

6. 总结：

1. 下载 SQLite3 源码：

虽然说摆弄 c/c++ 有很长时间了，但是说到用 c/c++ 来摆弄数据库倒还真是没有弄过，

一直有关数据库的项目似乎都用 .Net 给去 OK 了，就好比 SQLite，

现在的项目就是用的 SQLite.Net，有什么东西都是用 c# 直接操作 SQLite.Net 了，

而相对底层的东西则使用 c/c++ 完成且封装成 DLL 供 c# 调用就 OK 了。

不过有的时候自己在写一些小东西的时候，可能也会有些数据需要本地存储的，

以前为了图个简单，就直接存文件咯，不过要是相对隐私点的东西的话，

我想还是有个数据库比较好，这不是就有 SQLite3 了嘛，注意一下哈，

SQLite3 是供 c/c++ 代码来使用的，如果是 .Net 的话那就得用 SQLite.Net 了，

废话少说，进入正题了，首先我们需要下载好 SQLite3 的相关文件，

官网地址：http://www.sqlite.org/download.html

我们先下载的是 SQLite3 的源码，下载好后，你可以解压缩出来，然后你就会看到 4 个 C/C++ 文件了。

而我们每次在 C/C++ 中使用 SQLite3 时总是需要其中的头文件 sqlite3.h

2. 下载 SQLite3.dll：

然后需要下载的是 SQLite3 的 DLL 文件以及导出库，

下载完后你可以解压出来，你会发现只有 SQLite3.dll 和 SQLite3.def 两个文件，

3. 生成 SQLite3.lib 文件：

做过 c/c++ DLL 的都知道，.def 文件可以用来定义一个 DLL 中 API 的导出，

所以我们可以打开 SQLite3.def 看看，里面定义的 API 名称就是 SQLite3.dll 所导出的 API，

而在 C/C++ 中如果你要链接到其他的 DLL 上，你必须要有那个 DLL 的导出库，也就是 .lib 文件，

而我们这里没有导出文件(Lib)怎么办呢?没有那就根据 DLL 和.def 文件来生成一个 .lib 文件不就 OK 了 ~

首先将 SQLite3.dll 和 SQLite3.def 文件拷贝到 VS 安装目录下的 Bin 文件夹，

比如我安装的是 VS2010，且默认安装在 C:\Program Files\ 目录下面，

那么你就需要将上面的两个文件拷贝到以下目录：

C:\Program Files\Microsoft Visual Studio 10.0\VC\bin

然后打开 Visual Studio 命令提示符，且定位到上面的这个目录，

然后输入命令:lib /def:sqlite3.def /machine:ix86，

然后你就会在 Bin 目录下发现已经生成了 SQLite3.lib 文件。

4. 生成或下载 SQLite3 Shell 文件：

关于这 SQLite3 的 Shell 文件呢，就是用来创建 SQLite3 数据库啊，创建表啊之类的东西，

说白了就是个 SQLite Admin 的控制台界面，当然咯，控制台这个东西并不怎么好用，

所以你可以考虑换个其他的带 GUI 的工具来管理你的 SQLite3 数据库。

有个工具不错，叫 DataBase.Net，什么乱七八糟的数据库它都可以连接上去，不过要 .Net Framework 的支持。

对于这个 SQLite3 的 Shell 文件你可以直接在 SQLite 的官方网站上下载到，

而后，除了下载 SQLite3 的 Shell 工具外，我们还可以自己编译 SQLite 源代码来生成这个工具，

前面我们已经下载好了 SQLite3 的源代码，并且源代码里面还有一个叫做 shell.c 的文件，

其实这个文件就可以用来处理 SQLite3 Shell 命令的，

所以我们可以直接在 VS2010 下新建一个 Console 项目，

然后将源代码里面的 4 个 C\C++ 文件拷贝到项目中，然后直接编译，

你也可以得到 SQLite3 的 Shell 工具 SQLite3.exe。

5. 创建数据库以及数据表：

这里使用麻烦点的方式，即使用 SQLite3 的 Shell 工具，

下面的例子呢就是很简单的方式，即使用 SQLite3 的 Shell 工具来创建个 DataBase，

然后再创建个 Table，再插入几条记录，查询一下就 OK 了。

具体命令就看下面的截图就好了：

首先在命令行下定位到你的 SQLite3.exe 也就是 Shell 程序所在的目录：

比如我的 SQLite3.exe 所在目录为：

E:\Code\SQLite\sqlite-shell-win32-x86-3071000

然后输入命令 sqlite3 testDB.db 从而创建 SQLite 数据库，

然后输入命令 create table testDB_ID(ID int, Number int) 来创建数据表 testDB_ID

然后输入命令 ; 从而执行上面的创建表的命令。

执行完这些命令后，在你的 Shell 程序也就是 SQLite3.exe 所在的位置中发现你创建的 testDB.db 数据库了。

其实上面的这种创建数据库的方式太麻烦了，还不如直接用 Database.Net 来做，方便很多，

比如我用 DataBase.Net 打开我们上面创建的这个 testDB.db 数据库，用这个工具来管理数据库很方便。

6. 小结：

好，这篇博文到这里就完了，话说回来上面的文章还真没有讲到什么有用的东西，

仅仅是一些关于 SQLite 的环境啊之类的流水账记录。

仅仅是对于那些没有操作过 SQLite3 的小白可能还有点作用，

当然咯，我也还是个小白，所以才做这个文章做个记录。

下面的篇章就要来写写在 C\C++ 下面对 SQLite 的一些具体的操作了。

本文链接

进程与端口映射

2012-02-20T05:12:00Z

文章目录：

1. Demo 效果展示：

2. 进程和端口乱扯淡：

3. 查询进程和端口的 API 的介绍：

4. 根据进程 ID 获得该进程所打开的 TCP 和 UDP 端口：

5. 根据端口号来获得打开该端口号的进程：

6. 小结：

1. Demo 效果展示：

下面的这个 Demo 我只是用最简单的方式做了个 CUI 界面来演示一下而已，

支持 Windows XP，Windows Server 2003，Vista，Windows 7 ~

并且使用 C++ 来完成的，所以对于博客园里面这么多的 .Net 开发者来说不太友好，

但是有兴趣的可以将 Demo 改写成 DLL，然后 .Net 程序也就可以进行平台调用了，

里面所有的封装都很工整，所有改写 DLL 以及平台调用的声明也会很简单，有过平台调用经验的都可以改写的。

本文的后面我将会把这个 Demo 提供链接下载；

本篇博文 Demo 效果演示：

(关于端口的查询操作，你可以使用 netstat 命令行进行查询，

也可以使用 TCPView 这个工具来查询，当然还可以使用 360 的流量防火墙里面的网络连接来进行查询)

查询指定进程所打开的所有的 TCP 端口：

查询指定进程所打开的所有的 UDP 端口：

查询指定 TCP 端口所属的进程 ID：

查询指定 UDP 端口所属的进程 ID：

2. 进程和端口乱扯淡：

很久没写博文了，以前跟自己说的，每个月要写那么一两篇还看得下去的博文，

可是去年春节家里出了些事情给耽搁了 1 个多月，而后人又懒了 1 个多月，所以算下来有 2 个多月没有写博文了。

而后今年过来帮一小哥做了个小东西，主要是用来实现伪造端口、伪造远程地址以及进程内存的保护啊之类的动作。

而后呢就是上面提到的这个小东西中中涉及到了端口的知识，

一开始嘛，我也是放狗一搜索，然后发现关于端口这一块的东西，

在 2000、XP、Server 2003 下的资料很多，但惟独到了 Vista 和 7 上面就没什么资料了，

似乎一下子端口就完了似的，就好比端口的隐藏吧，在 XP 上无数端口隐藏工具，

应用层的，内核层的都有，但是在 Vista 和 7 上呢就都死绝了(主要是指内核层)，

没办法，只能够自己去研究了，研究的成果呢，主要分为内核层和应用层的成果，

当然咯，今天我的这篇博文并不会去介绍内核里面关于端口的什么东西，

而是介绍如何在应用层里面完成端口和进程之间的映射。

所谓的进程与端口映射在我来理解，

简单点就是假如我知道一个进程，那我就要知道这个进程所打开的所有的端口，

又假如我知道一个端口，那我就应该知道是哪一个进程打开了这个端口。

所以要完成端口和进程的映射其实归根结底是一个根据进程查询端口和根据端口查询进程的问题。

然后我稍微解释一下为何到了 Vista 和 7 以后，狗上面的关于端口的资源就锐减了，

其实原因是这样的，在 Vista 之前，我这里摘抄一点在别人博客上的东西出来：

Windows Vista 的网络模块较从前发生了很大变化,从而导致很多旧的端口隐藏工具无法使用.

事实上在 Vista 下 netstat.exe 调用 Iphlpapi.dll 导出的 InternalGetTcpTable2 函数实现对所有打开端口的列举.

InternalGetTcpTable2 随后调用由 nsi.dll 导出的 NsiAllocateAndGetTable 函数,

nsi.dll 则调用 NsiEnumerateObjectsAllParametersEx 向 nsiproxy.sys 发送 Irp 最终转入内核.

而nsiproxy.sys 又只是对 netio.sy s的简单封装,它最终调用了 netio.sys 导出的内核服务例程.

上面的这些文字多说无益，大体的意思就是从 Vista 开始，Windows 的网络模块发生了大的变化，

不过话说回来，上面的这种变化在应用层体会的不多，不过如果做到内核的话，

你就能够体会到网络层确实变化很大 ~

安全焦点上的一篇关于在 Vista 之前的系统上的进程和端口的很古老的文章

《再谈进程与端口的映射》：http://www.xfocus.net/articles/200202/344.html

3. 查询进程和端口的 API 介绍：

好，上面说的有点离题了，这篇博文的目的在应用层而不在内核层，

所以我们无须去体会 Windows 网络层的这种变化。

一般来说，要完成进程和端口的映射，我们使用的是由 IPHlpapi.dll 中导出的 API 来完成的，

在 Vista 之前的操作系统中，要查询进程和端口的信息，容易很多，

你可以通过调用 IPHlpapi.dll 中导出的下面两个 API 来完成查询 TCP 和 UDP 端口的信息，

下面的两个 API 分别用来查询 TCP 和 UDP 端口信息，

(下面的两个 API 仅适用于 XP 和 Server 2003，在 Vista 以及 7 中，这两个 API 被移除)

          1: DWORD WINAPI AllocateAndGetTcpExTableFromStack(         2:   __out         PVOID* ppTcpTable,         3:   __in          BOOL bOrder,         4:   __in          HANDLE hHeap,         5:   __in          DWORD dwFlags,         6:   __in          DWORD dwFamily         7: );         8:           9: DWORD WINAPI AllocateAndGetUdpExTableFromStack(        10:   __out         PVOID* ppUDPTable,        11:   __in          BOOL bOrder,        12:   __in          HANDLE hHeap,        13:   __in          DWORD dwFlags,        14:   __in          DWORD dwFamily        15: );        16:  

参数说明：

第一个参数：很显然，为输出参数，带回我们查询到的 TCP 或者 UDP 信息；

第二个参数：也很显然，判断输出结果是否排序；

第三个参数：指定在哪个 Heap 上分配内存；

第四个参数：指定用来控制 Heap 的标识；

第四个参数：指定 IP_V4 还是 IP_V6，具体看下面的截图：

不过要完成进程和端口的映射在 Vista 和 7 下确实也没那么容易，至于原因呢，

就是 IPHlpapi.dll 中关于查询进程和端口信息的 API 没有公开，即为 UnDocument API，

不过我们还是可以通过 UnDocument API 来完成这个查询的工作，具体涉及到下面的两个 API，

当然，下面的这两个 API 由于是 UnDocumnet API，自然你查什么 MSDN 啊之类都找不到这个 API 的声明的，

下面的两个 API 分别用来查询 TCP 和 UDP 端口信息，

       1: //=====================================================================================//       2: //Name: DWORD InternalGetTcpTable2()                                                   //       3: //                                                                                     //       4: //Descripion: 该函数在 Windows Vista 以及 Windows 7 下面效                                    //       5: //                                                                                     //       6: //=====================================================================================//       7: typedef DWORD (WINAPI *PFNInternalGetTcpTable2)(       8:     PMIB_TCPEXTABLE_VISTA *pTcpTable_Vista,       9:     HANDLE heap,      10:     DWORD flags      11:     );      12:        13: //=====================================================================================//      14: //Name: DWORD InternalGetUdpTableWithOwnerPid()                                        //      15: //                                                                                     //      16: //Descripion: 该函数在 Windows Vista 以及 Windows 7 下面效                                    //      17: //                                                                                     //      18: //=====================================================================================//      19: typedef DWORD (WINAPI *PFNInternalGetUdpTableWithOwnerPid)(      20:     PMIB_UDPEXTABLE *pUdpTable,      21:     HANDLE heap,      22:     DWORD flags      23:     );

参数说明：

第一个参数：pTcpTable_Vista 或者 pUdpTable 则不需要多说，其为输出参数，带回查询到的值；

第二个参数：heap 也不需要多说，其指示要从哪个 Heap 上面分配内存；

第三个参数：flags 则未知，一般都设置为 1，不过貌似设置为 2 啊之类的好像又多影响不大；

4. 根据进程 ID 获得该进程所打开的所有的 TCP 和 UDP 端口：

废话不多少的，直接上代码来得更加容易，注意下面函数中的 HeapFree 函数的调用，

因为从函数里面分配了内存，并且函数返回指针带出了这片内存，所以必须在外部释放，否则会造成内存泄露。

       1: //=======================================================================================//       2: //Name: DWORD GetAllPortByProcessId()                                                    //       3: //                                                                                       //       4: //Descripion: 根据进程 ID 来求出该进程所打开的所有的端口号，并且在 dwAllPort 数组中返回所有端口号 //       5: //              其中 dwMaxLen 为数组的长度，函数的返回值为进程所打开的端口的数目                  //       6: //              (支持 XP，Server 2003，Vista，Win7)                                       //       7: //                                                                                       //       8: //=======================================================================================//       9: DWORD GetAllPortByProcessId(TcpOrUdp type, DWORD dwProcessId, DWORD * dwAllPort, DWORD dwMaxLen)      10: {      11:     DWORD dwPortCount = 0;      12:     HMODULE hModule = LoadLibraryW(L"iphlpapi.dll");      13:     if (hModule == NULL)      14:     {      15:         return dwPortCount;      16:     }      17:        18:     if(type == TcpType)      19:     {      20:         // 表明查询的是 UDP 信息      21:         PFNAllocateAndGetTcpExTableFromStack pAllocateAndGetTcpExTableFromStack;      22:         pAllocateAndGetTcpExTableFromStack =       23:             (PFNAllocateAndGetTcpExTableFromStack)GetProcAddress(hModule, "AllocateAndGetTcpExTableFromStack");      24:         if (pAllocateAndGetTcpExTableFromStack != NULL)      25:         {      26:             // 表明为 XP 或者 Server 2003 操作系统      27:             PMIB_TCPEXTABLE pTcpExTable = NULL;      28:             if (pAllocateAndGetTcpExTableFromStack(&pTcpExTable, TRUE, GetProcessHeap(), 0, AF_INET) != 0)      29:             {      30:                 if (pTcpExTable)      31:                 {      32:                     HeapFree(GetProcessHeap(), 0, pTcpExTable);      33:                 }      34:        35:                 FreeLibrary(hModule);      36:                 hModule = NULL;      37:        38:                 return dwPortCount;      39:             }      40:        41:             for (UINT i = 0; i < pTcpExTable->dwNumEntries; i++)      42:             {      43:                 // 过滤掉数据，只获取我们要查询的进程的 Port 信息      44:                 if(dwProcessId == pTcpExTable->table[i].dwProcessId)      45:                 {      46:                     if(dwPortCount < dwMaxLen)      47:                     {      48:                         dwAllPort[dwPortCount] = ntohs(0x0000FFFF & pTcpExTable->table[i].dwLocalPort);      49:                         dwPortCount++;      50:                     }      51:                 }      52:             }      53:        54:             if (pTcpExTable)      55:             {      56:                 HeapFree(GetProcessHeap(), 0, pTcpExTable);      57:             }      58:        59:             FreeLibrary(hModule);      60:             hModule = NULL;      61:        62:             return dwPortCount;      63:         }      64:         else      65:         {      66:             // 表明为 Vista 或者 7 操作系统      67:             PMIB_TCPEXTABLE_VISTA pTcpExTable = NULL;      68:             PFNInternalGetTcpTable2 pInternalGetTcpTable2 =       69:                 (PFNInternalGetTcpTable2)GetProcAddress(hModule, "InternalGetTcpTable2");      70:             if (pInternalGetTcpTable2 == NULL)      71:             {      72:                 if (pTcpExTable)      73:                 {      74:                     HeapFree(GetProcessHeap(), 0, pTcpExTable);      75:                 }      76:        77:                 FreeLibrary(hModule);      78:                 hModule = NULL;      79:        80:                 return dwPortCount;      81:             }      82:        83:             if (pInternalGetTcpTable2(&pTcpExTable, GetProcessHeap(), 1))      84:             {      85:                 if (pTcpExTable)      86:                 {      87:                     HeapFree(GetProcessHeap(), 0, pTcpExTable);      88:                 }      89:        90:                 FreeLibrary(hModule);      91:                 hModule = NULL;      92:        93:                 return dwPortCount;      94:             }      95:        96:             for (UINT i = 0;i < pTcpExTable->dwNumEntries; i++)      97:             {      98:                 // 过滤掉数据，只获取我们要查询的进程的 TCP Port 信息      99:                 if(dwProcessId == pTcpExTable->table[i].dwProcessId)     100:                 {     101:                     if(dwPortCount < dwMaxLen)     102:                     {     103:                         dwAllPort[dwPortCount] = ntohs(0x0000FFFF & pTcpExTable->table[i].dwLocalPort);     104:                         dwPortCount++;     105:                     }     106:                 }     107:             }     108:       109:             if (pTcpExTable)     110:             {     111:                 HeapFree(GetProcessHeap(), 0, pTcpExTable);     112:             }     113:       114:             FreeLibrary(hModule);     115:             hModule = NULL;     116:       117:             return dwPortCount;     118:         }     119:     }     120:     else if(type == UdpType)     121:     {     122:         // 表明查询的是 UDP 信息     123:         PMIB_UDPEXTABLE pUdpExTable = NULL;     124:         PFNAllocateAndGetUdpExTableFromStack pAllocateAndGetUdpExTableFromStack;     125:         pAllocateAndGetUdpExTableFromStack =      126:             (PFNAllocateAndGetUdpExTableFromStack)GetProcAddress(hModule,"AllocateAndGetUdpExTableFromStack");     127:         if (pAllocateAndGetUdpExTableFromStack != NULL)     128:         {     129:             // 表明为 XP 或者 Server 2003 操作系统     130:             if (pAllocateAndGetUdpExTableFromStack(&pUdpExTable, TRUE, GetProcessHeap(), 0, AF_INET) != 0)     131:             {     132:                 if (pUdpExTable)     133:                 {     134:                     HeapFree(GetProcessHeap(), 0, pUdpExTable);     135:                 }     136:       137:                 FreeLibrary(hModule);     138:                 hModule = NULL;     139:       140:                 return dwPortCount;     141:             }     142:       143:             for (UINT i = 0; i < pUdpExTable->dwNumEntries; i++)     144:             {     145:                 // 过滤掉数据，只获取我们要查询的进程的 UDP Port信息     146:                 if(dwProcessId == pUdpExTable->table[i].dwProcessId)     147:                 {     148:                     if(dwPortCount < dwMaxLen)     149:                     {     150:                         dwAllPort[dwPortCount] = ntohs(0x0000FFFF & pUdpExTable->table[i].dwLocalPort);     151:                         dwPortCount++;     152:                     }     153:                 }     154:             }     155:       156:             if (pUdpExTable)     157:             {     158:                 HeapFree(GetProcessHeap(), 0, pUdpExTable);     159:             }     160:       161:             FreeLibrary(hModule);     162:             hModule = NULL;     163:       164:             return dwPortCount;     165:         }     166:         else     167:         {     168:             // 表明为 Vista 或者 7 操作系统     169:             PFNInternalGetUdpTableWithOwnerPid pInternalGetUdpTableWithOwnerPid;     170:             pInternalGetUdpTableWithOwnerPid =      171:                 (PFNInternalGetUdpTableWithOwnerPid)GetProcAddress(hModule, "InternalGetUdpTableWithOwnerPid");     172:             if (pInternalGetUdpTableWithOwnerPid != NULL)     173:             {     174:                 if (pInternalGetUdpTableWithOwnerPid(&pUdpExTable, GetProcessHeap(), 1))     175:                 {     176:                     if (pUdpExTable)     177:                     {     178:                         HeapFree(GetProcessHeap(), 0, pUdpExTable);     179:                     }     180:       181:                     FreeLibrary(hModule);     182:                     hModule = NULL;     183:       184:                     return dwPortCount;     185:                 }     186:       187:                 for (UINT i = 0; i < pUdpExTable->dwNumEntries; i++)     188:                 {     189:                     // 过滤掉数据，只获取我们要查询的进程的 UDP Port信息     190:                     if(dwProcessId == pUdpExTable->table[i].dwProcessId)     191:                     {     192:                         if(dwPortCount < dwMaxLen)     193:                         {     194:                             dwAllPort[dwPortCount] = ntohs(0x0000FFFF & pUdpExTable->table[i].dwLocalPort);     195:                             dwPortCount++;     196:                         }     197:                     }     198:                 }     199:             }     200:       201:             if (pUdpExTable)     202:             {     203:                 HeapFree(GetProcessHeap(), 0, pUdpExTable);     204:             }     205:       206:             FreeLibrary(hModule);     207:             hModule = NULL;     208:       209:             return dwPortCount;     210:         }     211:     }     212:     else     213:     {     214:         FreeLibrary(hModule);     215:         hModule = NULL;     216:       217:         return dwPortCount;     218:     }     219: }

5. 根据端口号来获得打开该端口的进程：

同样是直接上代码，同样需要注意下面函数中的 HeapFree 函数的调用，

因为从函数里面分配了内存，并且函数返回指针带出了这片内存，所以必须在外部释放，否则会造成内存泄露。

       1: //=====================================================================================//       2: //Name: DWORD GetProcessIdByPort()                                                     //       3: //                                                                                     //       4: //Descripion: 根据端口号求出打开该端口号的进程 ID(支持 XP，Server 2003，Vista，Win7)        //       5: //                                                                                     //       6: //=====================================================================================//       7: DWORD GetProcessIdByPort(TcpOrUdp type, DWORD dwPort)       8: {       9:     HMODULE hModule = LoadLibraryW(L"iphlpapi.dll");      10:     if (hModule == NULL)      11:     {      12:         return 0;      13:     }      14:        15:     if(type == TcpType)      16:     {      17:         // 表明查询的是 TCP 信息      18:         PFNAllocateAndGetTcpExTableFromStack pAllocateAndGetTcpExTableFromStack;      19:         pAllocateAndGetTcpExTableFromStack =       20:             (PFNAllocateAndGetTcpExTableFromStack)GetProcAddress(hModule, "AllocateAndGetTcpExTableFromStack");      21:         if (pAllocateAndGetTcpExTableFromStack != NULL)      22:         {      23:             // 表明为 XP 或者 Server 2003 操作系统      24:             PMIB_TCPEXTABLE pTcpExTable = NULL;      25:             if (pAllocateAndGetTcpExTableFromStack(&pTcpExTable, TRUE, GetProcessHeap(), 0, AF_INET) != 0)      26:             {      27:                 if (pTcpExTable)      28:                 {      29:                     HeapFree(GetProcessHeap(), 0, pTcpExTable);      30:                 }      31:        32:                 FreeLibrary(hModule);      33:                 hModule = NULL;      34:        35:                 return 0;      36:             }      37:        38:             for (UINT i = 0; i < pTcpExTable->dwNumEntries; i++)      39:             {      40:                 // 过滤掉数据，只查询我们需要的进程数据      41:                 if(dwPort == ntohs(0x0000FFFF & pTcpExTable->table[i].dwLocalPort))      42:                 {      43:                     DWORD dwProcessId = pTcpExTable->table[i].dwProcessId;      44:                     if (pTcpExTable)      45:                     {      46:                         HeapFree(GetProcessHeap(), 0, pTcpExTable);      47:                     }      48:        49:                     FreeLibrary(hModule);      50:                     hModule = NULL;      51:        52:                     return dwProcessId;      53:                 }      54:             }      55:        56:             if (pTcpExTable)      57:             {      58:                 HeapFree(GetProcessHeap(), 0, pTcpExTable);      59:             }      60:        61:             FreeLibrary(hModule);      62:             hModule = NULL;      63:        64:             return 0;      65:         }      66:         else      67:         {      68:             // 表明为 Vista 或者 7 操作系统      69:             PMIB_TCPEXTABLE_VISTA pTcpExTable = NULL;      70:             PFNInternalGetTcpTable2 pInternalGetTcpTable2 =       71:                 (PFNInternalGetTcpTable2)GetProcAddress(hModule, "InternalGetTcpTable2");      72:             if (pInternalGetTcpTable2 == NULL)      73:             {      74:                 if (pTcpExTable)      75:                 {      76:                     HeapFree(GetProcessHeap(), 0, pTcpExTable);      77:                 }      78:        79:                 FreeLibrary(hModule);      80:                 hModule = NULL;      81:        82:                 return 0;      83:             }      84:        85:             if (pInternalGetTcpTable2(&pTcpExTable, GetProcessHeap(), 1))      86:             {      87:                 if (pTcpExTable)      88:                 {      89:                     HeapFree(GetProcessHeap(), 0, pTcpExTable);      90:                 }      91:        92:                 FreeLibrary(hModule);      93:                 hModule = NULL;      94:        95:                 return 0;      96:             }      97:        98:             for (UINT i = 0;i < pTcpExTable->dwNumEntries; i++)      99:             {     100:                 // 过滤掉数据，只查询我们需要的进程数据     101:                 if(dwPort == ntohs(0x0000FFFF & pTcpExTable->table[i].dwLocalPort))     102:                 {     103:                     DWORD dwProcessId = pTcpExTable->table[i].dwProcessId;     104:                     if (pTcpExTable)     105:                     {     106:                         HeapFree(GetProcessHeap(), 0, pTcpExTable);     107:                     }     108:       109:                     FreeLibrary(hModule);     110:                     hModule = NULL;     111:       112:                     return dwProcessId;     113:                 }     114:             }     115:       116:             if (pTcpExTable)     117:             {     118:                 HeapFree(GetProcessHeap(), 0, pTcpExTable);     119:             }     120:       121:             FreeLibrary(hModule);     122:             hModule = NULL;     123:       124:             return 0;     125:         }     126:     }     127:     else if(type == UdpType)     128:     {     129:         // 表明查询的是 UDP 信息     130:         PMIB_UDPEXTABLE pUdpExTable = NULL;     131:         PFNAllocateAndGetUdpExTableFromStack pAllocateAndGetUdpExTableFromStack;     132:         pAllocateAndGetUdpExTableFromStack =      133:             (PFNAllocateAndGetUdpExTableFromStack)GetProcAddress(hModule,"AllocateAndGetUdpExTableFromStack");     134:         if (pAllocateAndGetUdpExTableFromStack != NULL)     135:         {     136:             // 表明为 XP 或者 Server 2003 操作系统     137:             if (pAllocateAndGetUdpExTableFromStack(&pUdpExTable, TRUE, GetProcessHeap(), 0, AF_INET) != 0)     138:             {     139:                 if (pUdpExTable)     140:                 {     141:                     HeapFree(GetProcessHeap(), 0, pUdpExTable);     142:                 }     143:       144:                 FreeLibrary(hModule);     145:                 hModule = NULL;     146:       147:                 return 0;     148:             }     149:       150:             for (UINT i = 0; i < pUdpExTable->dwNumEntries; i++)     151:             {     152:                 // 过滤掉数据，只查询我们需要的进程数据     153:                 if (dwPort == ntohs(0x0000FFFF & pUdpExTable->table[i].dwLocalPort))     154:                 {     155:                     DWORD dwProcessId = pUdpExTable->table[i].dwProcessId;     156:                     if (pUdpExTable)     157:                     {     158:                         HeapFree(GetProcessHeap(), 0, pUdpExTable);     159:                     }     160:       161:                     FreeLibrary(hModule);     162:                     hModule = NULL;     163:       164:                     return dwProcessId;     165:                 }     166:             }     167:       168:             if (pUdpExTable)     169:             {     170:                 HeapFree(GetProcessHeap(), 0, pUdpExTable);     171:             }     172:       173:             FreeLibrary(hModule);     174:             hModule = NULL;     175:       176:             return 0;     177:         }     178:         else     179:         {     180:             // 表明为 Vista 或者 7 操作系统     181:             PFNInternalGetUdpTableWithOwnerPid pInternalGetUdpTableWithOwnerPid;     182:             pInternalGetUdpTableWithOwnerPid =      183:                 (PFNInternalGetUdpTableWithOwnerPid)GetProcAddress(hModule, "InternalGetUdpTableWithOwnerPid");     184:             if (pInternalGetUdpTableWithOwnerPid != NULL)     185:             {     186:                 if (pInternalGetUdpTableWithOwnerPid(&pUdpExTable, GetProcessHeap(), 1))     187:                 {     188:                     if (pUdpExTable)     189:                     {     190:                         HeapFree(GetProcessHeap(), 0, pUdpExTable);     191:                     }     192:       193:                     FreeLibrary(hModule);     194:                     hModule = NULL;     195:       196:                     return 0;     197:                 }     198:       199:                 for (UINT i = 0; i < pUdpExTable->dwNumEntries; i++)     200:                 {     201:                     // 过滤掉数据，只查询我们需要的进程数据     202:                     if (dwPort == ntohs(0x0000FFFF & pUdpExTable->table[i].dwLocalPort))     203:                     {     204:                         DWORD dwProcessId = pUdpExTable->table[i].dwProcessId;     205:                         if (pUdpExTable)     206:                         {     207:                             HeapFree(GetProcessHeap(), 0, pUdpExTable);     208:                         }     209:       210:                         FreeLibrary(hModule);     211:                         hModule = NULL;     212:       213:                         return dwProcessId;     214:                     }     215:                 }     216:             }     217:       218:             if (pUdpExTable)     219:             {     220:                 HeapFree(GetProcessHeap(), 0, pUdpExTable);     221:             }     222:       223:             FreeLibrary(hModule);     224:             hModule = NULL;     225:       226:             return 0;     227:         }     228:     }     229:     else     230:     {     231:         FreeLibrary(hModule);     232:         hModule = NULL;     233:       234:         return -1;     235:     }     236: }

6. 小结：

好了，文章就写到这里了，对于那些对端口有兴趣的童鞋，我想这篇文章还是很有帮助的，

因为在网络上关于这一块的资料真的不多的，不过到最后了还是要提一下，

就是上面的文章介绍的是在应用层，也就是 Ring3 下的端口的查询以及使用，

我做过在 Ring0 下的端口隐藏，是通过 Hook NtDeviceIoControlFile 来实现的，

在 Vista 之前的操作系统中都容易搞定，但是在 Vista 后的操作系统中，

由于网络模块和之前完全不同了，而且公开的资料又太少，

所以在 Vista 后的操作系统中的端口隐藏以及端口伪造实现效果很不好，

不知有同仁是否研究过这一块的东西，有的话，我们可以讨论讨论的 ~

Demo 下载地址： http://files.cnblogs.com/BoyXiao/TestPort.zip

本文链接

约定 - 王菲

2011-11-01T15:44:00Z

还记得当天旅馆的门牌
还留住笑著离开的神态
当天整个城市那样轻快
沿路一起走半哩长街
还记得街灯照出一脸黄
还燃亮那份微温的便档
剪影的你轮廓太好看
凝住眼泪才敢细看

忘掉天地彷佛也想不起自己
仍未忘相约看漫天黄叶远飞
就算会与你分离凄绝的戏
要决心忘记我便记不起
明日天地只恐怕认不出自己
仍未忘跟你约定假如没有死
就算你壮阔胸膛不敌天气
两鬓斑白都可认得你

还记得当天吉他的和弦
还明白每段旋律的伏线
当天街角流过你声线
沿路旅程如歌褪变

就算你壮阔胸膛不敌天气
两鬓斑白都可认得你

本文链接

【转】理解 RESTful 架构

2011-10-26T06:14:00Z

越来越多的人开始意识到，网站即软件，而且是一种新型的软件。

这种"互联网软件"采用客户端/服务器模式，建立在分布式体系上，

通过互联网通信，具有高延时（high latency）、高并发等特点。

网站开发，完全可以采用软件开发的模式。但是传统上，软件和网络是两个不同的领域，很少有交集；

软件开发主要针对单机环境，网络则主要研究系统之间的通信。互联网的兴起，使得这两个领域开始融合,

现在我们必须考虑，如何开发在互联网环境中使用的软件。

RESTful架构，就是目前最流行的一种互联网软件架构。

它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。

但是，到底什么是RESTful架构，并不是一个容易说清楚的问题。

下面，我就谈谈我理解的RESTful架构。

一、起源

REST这个词，是Roy Thomas Fielding在他2000年的博士论文中提出的。

Fielding是一个非常重要的人，他是HTTP协议（1.0版和1.1版）的主要设计者、

Apache服务器软件的作者之一、Apache基金会的第一任主席。

所以，他的这篇论文一经发表，就引起了关注，并且立即对互联网开发产生了深远的影响。

他这样介绍论文的写作目的：

"本文研究计算机科学两大前沿----软件和网络----的交叉点。

长期以来，软件研究主要关注软件设计的分类、设计方法的演化，很少客观地评估不同的设计选择对系统行为的影响。

而相反地，网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现，常常忽视了一个事实，

那就是改变应用程序的互动风格比改变互动协议，对整体表现有更大的影响。

我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，

得到一个功能强、性能好、适宜通信的架构。"

(This dissertation explores a junction on the frontiers of two research disciplines

in computer science: software and networking. Software research has long been concerned

with the categorization of software designs and the development of design methodologies,

but has rarely been able to objectively evaluate the impact of various design choices

on system behavior. Networking research, in contrast, is focused on the details of

generic communication behavior between systems and improving the performance of

particular communication techniques, often ignoring the fact that changing the

interaction style of an application can have more impact on performance than the

communication protocols used for that interaction. My work is motivated by the desire

to understand and evaluate the architectural design of network-based application software

through principled use of architectural constraints, thereby obtaining the functional,

performance, and social properties desired of an architecture. )

二、名称

Fielding 将他对互联网软件的架构原则，定名为 REST，即 Representational State Transfer 的缩写。

我对这个词组的翻译是"表现层状态转化"。如果一个架构符合 REST 原则，就称它为 RESTful 架构。

要理解 RESTful 架构，最好的方法就是去理解 Representational State Transfer 这个词组到底是什么意思，

它的每一个词代表了什么涵义。如果你把这个名称搞懂了，也就不难体会REST是一种什么样的设计。

三、资源（Resources）

REST 的名称"表现层状态转化"中，省略了主语。

"表现层"其实指的是"资源"（Resources）的"表现层"。

所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。

它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。

你可以用一个 URI（统一资源定位符）指向它，每种资源对应一个特定的 URI。

要获取这个资源，访问它的URI就可以，因此 URI 就成了每一个资源的地址或独一无二的识别符。

所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的 URI。

四、表现层（Representation）

"资源"是一种信息实体，它可以有多种外在表现形式。

我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。

比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；

图片可以用JPG格式表现，也可以用PNG格式表现。URI 只代表资源的实体，不代表它的形式。

严格地说，有些网址最后的".html"后缀名是不必要的，

因为这个后缀名表示格式，属于"表现层"范畴，而 URI 应该只代表"资源"的位置。

它的具体表现形式，应该在 HTTP 请求的头信息中用 Accept 和 Content-Type 字段指定，

这两个字段才是对"表现层"的描述。

五、状态转化（State Transfer）

访问一个网站，就代表了客户端和服务器的一个互动过程。

在这个过程中，势必涉及到数据和状态的变化。互联网通信协议HTTP协议，是一个无状态协议。

这意味着，所有的状态都保存在服务器端。

因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。

而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。客户端用到的手段，只能是HTTP协议。

具体来说，就是 HTTP 协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。

GET 用来获取资源；

POST 用来新建资源（也可以用于更新资源）；

PUT 用来更新资源；

DELETE 用来删除资源；

六、综述

综合上面的解释，我们总结一下什么是RESTful架构：

（1）每一个URI代表一种资源；

（2）客户端和服务器之间，传递这种资源的某种表现层；

（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

七、误区

RESTful 架构有一些典型的设计误区。

最常见的一种设计错误，就是 URI 包含动词。

因为"资源"表示一种实体，所以应该是名词，URI 不应该有动词，动词应该放在 HTTP 协议中。

举例来说，某个 URI 是 /posts/show/1，其中 show 是动词，这个 URI 就设计错了，

正确的写法应该是 /posts/1，然后用 GET 方法表示 show。

如果某些动作是 HTTP 动词表示不了的，你就应该把动作做成一种资源。

比如网上汇款，从账户 1 向账户 2 汇款 500 元，错误的 URI 是：

POST /accounts/1/transfer/500/to/2

正确的写法是把动词 transfer 改成名词 transaction，资源不能是动词，但是可以是一种服务：

POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00

另一个设计误区，就是在URI中加入版本号：

http://www.example.com/app/1.0/foo

http://www.example.com/app/1.1/foo

http://www.example.com/app/2.0/foo

因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个 URI。

版本号可以在 HTTP 请求头信息的 Accept 字段中进行区分（参见 Versioning REST Services）：

Accept: vnd.example-com.foo+json; version=1.0

Accept: vnd.example-com.foo+json; version=1.1

Accept: vnd.example-com.foo+json; version=2.0

（完）

文档信息

版权声明：自由转载-非商用-非衍生-保持署名 | Creative Commons BY-NC-ND 3.0
原文网址：http://www.ruanyifeng.com/blog/2011/09/restful.html
最后修改时间：2011年10月25日 14:53

本博文转载自：阮一峰的网络日志 - 《理解 RESTful 架构》

本文链接

棋子 - 王菲

2011-10-20T08:16:00Z

想走出你控制的领域 却走近你安排的战局我没有坚强的防备 也没有后路可以退 想逃离你布下的陷阱 却陷入了另一个困境我没有决定输赢的勇气 也没有逃脱的幸运 我像是一颗棋 进退任由你决定我不是你眼中唯一将领 却是不起眼的小兵 我像是一颗棋子 来去全不由自己举手无回你从不曾犹豫 我却受控在你手里 想走出你控制的领域 却走近你安排的战局我没有坚强的防备 也没有后路可以退 想逃离你布下的陷阱 却陷入了另一个困境我没有决定输赢的勇气 也没有逃脱的幸运 我像是一颗棋 进退任由你决定我不是你眼中唯一将领 却是不起眼的小兵 我像是一颗棋子 来去全不由自己举手无回你从不曾犹豫 我却受控在你手里 我像是一颗棋子 来去全不由自己举手无回你从不曾犹豫 我却受控在你手里我却受控在你手里我却受控在你手里

本文链接

七友 - 梁汉文

2011-10-12T14:03:00Z

为了她又再勉强去谈天论爱

又再振作去慰解他人

如难复合便尽早放开凡事看开

又再讲没有情人时还可自爱

忘掉或是为自己感慨

笑住说沉沦那些苦海会有害

因为我坚强到利用自己的痛心转换成爱心

抵我对她操心已记不起我也有权利爱人

谁人曾照顾过我的感受待我温柔

吻过我伤口

能得到的安慰是失恋者得救后很感激忠诚的狗

谁人曾介意我也不好受

为我出头碰过我的手

重生者走得的都走

谁人又为天使忧愁

甜言蜜语没有但却有我这个好友

直到她又再告诉我重新被爱

又再看透了我的将来

完成任务后大可喝采无谓搭台

别怪她就怪我永远难得被爱

然后自虐地赞她可爱

往日最徬徨那刻好彩有我在

因为我坚强到利用自己的痛心转换成爱心

抵我对她操心已记不起我也有权利爱人

谁人曾照顾过我的感受待我温柔

吻过我伤口

能得到的安慰是失恋者得救后很感激忠诚的狗

谁人曾介意我也不好受

为我出头碰过我的手

重生者走得的都走

谁人又为天使忧愁

甜言蜜语没有但却有我这个好友

白雪公主不多

认命扮矮人的有太多个早有六个

多我这个不多我太好心还是太傻

未问过她有没有理我的感受

待我温柔吻过我伤口

能得到的安慰是失恋者得救后很感激忠诚的狗

谁人曾介意我也不好受

为我出头碰过我的手

重生者走得的都走

谁人又为天使忧愁

甜言蜜语没有但却有我这个好友

本文链接

Native Application 开发详解

2011-09-21T00:56:00Z

文章目录：

1. 引子：

2. Native Application Demo 展示：

3. Native Application 简介：

4. Native Application 有何妙用：

5. MJ0011 关于 Native Application 的文章整理：

6. 互联网上其他关于 Native Application 的文章整理：

7. 小结：

1. 引子：

其实在好久以前就看了 MJ0011 翻译的那个《Native 应用程序详细》系列的文章，

(PS: MJ0011 为 360 的首席技术执行官，技术是没的说，不过貌似有点狂妄之说 ~ )

而且看完后对这一系列文章也很感兴趣的，所以又去 Google 上找了几个小资料学习了一下，

而这篇文章呢，则是将我前阵子的所谓的学习给总结出来也顺道给大伙分享一下。

虽然这里是说的总结 Native Application，但最早出现 Native Application 应该是 06 年的事了，

(当然，Native Application 这个技术是一直存在的，只是在 06 年后有了下面这篇文章后就稍微火了点)

其是 Sysinternals 上的一篇由 Mark Russinovich 发表的文章《Inside Native Applications》，

文章地址如下：http://technet.microsoft.com/en-us/sysinternals/bb897447

而我却在 2011 年才得以来总结这个技术，所以我确是属于研究这些东西的落后者啊 ~

下面我给出一副截图来看一下 Windows 操作系统下的程序的类型：

在 Windows 最初设计的时候考虑到了兼容各种系统的应用程序，所以有了环境子系统之说，

其中一开始的时候考虑到了子系统，POSIX 子系统和 OS/2 子系统，

但是随着历史的发展，现在也就剩下个 Windows 子系统了，

我们日常使用的 Windows 操作系统的上层其实也就是指的这个 Windows 子系统了，

至于这里为何要扯到 Windows 子系统的话，就看下文介绍了。

很多朋友都知道有 Windows 应用程序和 Windows 内核驱动程序之说，

却很少有知道在 Windows 中还有 Native Application 一说了，

但是这类程序确实是存在的 ~只不过这类程序应用比较窄，也没有被很好的推广开来，

当然还有一点就是 Microsoft 自然不希望你随随便便的使用 Native API。

2. Native Application Demo 展示：

首先你需要将下载(博文的最后面附上 Demo 的下载地址)的 EXE 文件拷贝一份到 system32 目录下，

(博文的 Demo 只是拿了网上的代码然后自行使用 DDK 编译了而已，Demo 并非笔者原创)

然后再在注册表以下路径中修改 BootExecute，

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

在其中添加 NativeApp_01 Hello World ! 这个字符串，

重启电脑，然后就可以看到下面的效果图了(仅在 XP SP3 上进行了测试)

3. Native Application 简介：

何为 Native API ?

Native API 就是你 system32 目录下的那个 ntdll.dll 中所公开的 API(大部分为 Undocument)~

如果读者看过我前面的《进程隐藏与进程保护(SSDT Hook 实现)》系列文章的话，

相信肯定会知道在 Windows 中 kernel32.dll 中的 API 的调用都会经过转换，

也就是跳转到 ntdll.dll 中，并且在 ntdll.dll 中也有与之相对于的 API 调用，

(比如 Kernel32.dll 中的 CreateProcess 在 ntdll.dll 中有 NtCreateProcess 与之对应)

那么什么称之为 Native 应用程序呢 ?

下面给出一副截图：

从上面的截图可以看出，在一开始的 Windows NT 内核中是支持三个环境子系统的，

即 POSIX,WINDOWS,OS/2，这些子系统属于同一层，它们共用了 Windows NT 所提供的 API，

即每一个子系统中的 API 的调用都会转换到下一层的相同调用上，

在 Windows 环境子系统(有 Windows,Posix,OS/2)中的程序，

都会调用其相对于的子系统下的 API，比如 Windows 子系统中的程序有可能会调用 Win32 API CreateProcess，

而 Posix 子系统中的程序也有可能会调用 Posix API CreateProcess(当然有可能在 POSIX 下创建进程不是这个名称)，

但是终归来说，这两个 CreateProcess 的调用都会转换到 Ntdll.dll 中的 NtCreateProcess 中，

也就是上面的三个子系统最后的调用都会回归到 ntdll.dll 上，

而我们的 Native Application 则是绕过 Windows 子系统，

直接自己调用 Native API，比如创建进程的话，我就不再通过子系统中的神马 CreateProcess 来完成了，

而是直接在程序中调用 ntdll.dll 中的 Native API NtCreateProcess 来完成，

而这类程序即称之为 Native Application !

Native Application 的运行环境：

上面也说了，Native Application 是只能够访问 ntdll.dll 中的内容的，

而如果是在子系统下运行一个程序的话，必然会加载其他的 DLL，

比如在 Windows 子系统下一个 kernel32.dll 是必不可少的吧，

如果 Native Application 能够运行在 Windows 子系统下的话，必然也会加载到 Kernel32.dll，

这样不就和上面相违背了嘛 ~

总之：Native Application 是不能够运行在任何子系统下的 !

比如在 Windows 子系统下运行 Native Application 会弹出如下错误对话框：

Native Application 的启动时机：

对于 Windows 操作系统的引导过程，这里需要带一笔的，Windows 操作系统启动时，

当 Windows 内核的引导完成以后，就会启动会话管理器 smss.exe 进程了，

smss.exe 进程虽然是一个用户模式的进程，但是这个进程相对于其他用户模式进程是具有一定特殊性的，

首先 smss.exe 进程是直接建立在 Windows NT 内核上的，其不依赖于任何一个环境子系统，

至于不依赖于任何一个环境子系统这一说的话，还是可以很好的解释的，

因为当环境子系统进程(Windows 子系统进程为 csrss.exe)就是由 smss.exe 进程启动的，

然后 smss.exe 是 Windows 操作系统启动的第一个用户态进程，

而 Native Application 也属于用户态程序，自然 Native Application 的启动是在 smss.exe 之后，

而后前面也说过，Native Application 运行时，子系统进程还尚未启动，

所以 Native Application 的启动则是在 csrss.exe 之前的，

而话又说回来，csrss.exe 就是由会话管理器(smss.exe)启动的，

所以 Native Application 的启动时机也就只有一种可能了，

即 smss.exe 先启动 Native Application，然后 Native Application 开始执行，

等到 Native Application 都给执行完了后 smss.exe 再启动 csrss.exe 进程。

（事实上，Win32 应用程序环境子系统 csrss.exe 本质上也是一个 Native Application ~）

下面给出一副截图以说明 SMSS.EXE 的在启动过程中所完成的工作：

运行启动时执行的程序即是执行 Native Application

4. Native Application 有何妙用：

前面也提到过，Native Application 的应用范围比较窄，这主要受以下几点约束：

首先，Native Application 是直接调用 Native API 来完成任务的，

而在 Windows 中，Native API 绝大部分都是 Undocument 的，这样开发起来自然难度会大很多了。

然后，由于 Native Application 是调用的 Undocument API，

说不准那一天 Microsoft 就在下一代 Windows 中修改了这个 API，这样的话，你程序的可移植性也就完全没了。

最后的话，Native Application 的执行环境并非是在 Windows 子系统中，

事实上，当 Native Application 开始执行的时候，Windows 子系统进程(csrss.exe)进程都还没有启动的 ~

所以 Native Application 的执行是受限制的，其不能够执行子系统中的任何东西，

说白一点的话就是 Native Application 只能够调用 ntdll.dll 中的 API，

其他 DLL 中的 API 一律不得调用，这样也就注定 Native Application 的应用范围不会很广泛了。

应用范围比较窄并不等于说没有应用价值，

也还是有蛮多的软件，包括一些商业软件也都是用了 Native Application，

下面来看一些 Native Application 的应用(我也只是从网上道听途说，不过有些也确实是自己也用过的)：

最典型的应用自然是属于 Windows 操作系统自带的磁盘自检程序了;

然后比较典型的商业应用是瑞星的开机杀毒，即实现让病毒在你还没有完全开机之前死掉;

然后就是可以通过 Native Application 来实现接管 Windows 的开机启动界面和密码输入界;

还可以通过 Native Application 来实现开机前的磁盘修复(Windows 自带了这款工具也是这样实现的);

5. MJ0011 关于 Native Application 的文章整理：

这一小节里面主要是整理一下关于 MJ0011 的 Native Application 的博文，

也就是说我这里纯粹是将他的东西给贴出来瞧瞧，关于 MJ0011 博文的原地址为：

《NATIVE应用程序详细之一》：

http://hi.baidu.com/mj0011/blog/item/7ee496d67a4d4d2f07088bc7.html

《NATIVE应用程序详细之2 NATIVE应用程序的优势和劣势》

http://hi.baidu.com/mj0011/blog/item/f8108f2f5890fb381e30896d.html

《native应用程序详细之三构建native应用程序》：

http://hi.baidu.com/mj0011/blog/item/725b4882042b03a20df4d269.html

《深入Native应用程序》(该文翻译自《Inside Native Application》)：

http://hi.baidu.com/mj0011/blog/item/85c0b50f80b1baedab6457de.html

《native app GUI界面的实现》：

http://hi.baidu.com/mj0011/blog/item/6e5a22fa214c8116a9d3115b.html

Native 应用程序简介：

NT 系统被设计成为支持子系统（封装），它可以执行在不同平台上的代码。包括但不限于：POSIX、OS/2和Win32，

为了管理这些子系统，NT内核输出了大量名为 Native API的API函数，子系统服务将这些函数包装为他们自己的函数。

例如:CreateFile和fopen都被映射到NtCreateFile.那么子系统管理程序运行在哪个子系统中？

为了避免先有鸡还是先有蛋的问题，NT系统同样支持原生的Native应用程序。

这些Native应用程序是独立于子系统的。现在，所有的子系统应用程序都需要注册它们自己的子系统服务，

显然，Kernel32是一个Win32应用程序，csrss注册WIN32子系统，然后通知子系统管理器SMSS，

因此，一个Native应用程序是无法调用其中数千种API的，

同时它也无法使用一些基本的DLL中的函数例如kernel32、user32、gdi32等，

其它任何调用了这三者的DLL中的函数的DLL也无法被使用。

事实上，加载者在其入口点没有被加载前，并不允许加载决大多数的Win32 DLL。

因此，native应用程序被限制只许使用一个DLL：ntdll.dll，这个DLL供应所有Native和运行函数。

但是想想，既然所有Win32函数最后都是去调用Ntdll.dll中的函数来实现的（除了GUI部分），

这些函数就已经足够了，不是吗?

Native应用程序优势：

(一) 内存使用和大小：因为Native应用程序并不需要加载90多个DLL到内存中去，因此其使用的内存是很小的。

(二) 速度：Native API比Win32对应的函数要更快（通常会快很多），

尽管实际上很多时间都被消耗在Win32 API的封装上，这些包括修改、兼容性选项，和其他的代码部分，

这些都会在执行真正的Native调用前执行。如果你知道如何去做而且希望它运行得更快，Native是一个很好的方法。

因为不需要加载那90多个DLL，kernel32不需要到csrss和smss做lpc注册，因此启动也是非常快速和直接的。

(三) 熟悉程度和特性：Native应用程序并没有古怪的入口点或者奇怪的Hack，就象读命令行一样简单使用，

而事实上将在后面介绍，Native应用程序和Console程序一样启动与_main函数，

通过一组简单的char*[]队列来接受命令行参数和环境变量，就象一个典型的Win32 Console程序一样，

一些特性例如缓冲区溢出保护(/GS)、Safe SEH(/SAFESEH）、hotpathing(/HOTPATCH)，

以及其他的特性都被支持。

(四) 丰富：Native API非常丰富，它们提供的特性和功能性要远远超越Win32函数所能达到的程度。

这并不是说Win32无法做到Native API那样的更困难和更复杂的工作，而是Win32太过简单而已，

比如Win32函数中，无法远程注入一个Section到一个进程中，因为MapViewOfFileEx不提供进程句柄接口，

而Native API则可以实现这个功能。

(五) 安全：但是Native应用程序有这样一个特点:人们对于Native API不是十分熟悉，

他们需要花费更多的时间才能理解你的代码，而更重要的是，无法使用一个用户模式的debugger来调试Native应用程序，

只有SoftIce和使用内核模式远程连接的WinDbg才可以对其进行调试，这足以让那些废物脚本小子去死了，

再说一遍，这并不意味着Native 应用程序是“不可调试的，安全的”，只是它更模糊更难被破解。

(六) 同内核模式的连接:因为Native应用程序只使用Native API，这些函数在内核模式仍然可用，

这样，一个Native程序只需少量修改就可修改为内核驱动，而Win32程序则需要几乎重写所有代码。

(七) 运行在独立于子系统的环境中：因为Native应用程序并不依赖与任何子系统，

它运行于一个正常应用永远无法再次得到的环境中，比如autochk.exe，它运行与任何子系统加载之前，

并负责显示'press any key to scan your hard disk"信息，并扫描你的硬盘是否有错误。

在这个模式运行允许你显示信息到启动屏幕上，以及很多增强特性。

(八) 标准性：不象Win32函数有一个正常版本，一个"Ex"版本，以及经常有一个"扩展其他功能"的版本，

以及经常返回0,1,-1或一些随机的数值来表示成功，并且要使用SetLastError来设置返回错误，

在Native应用程序中，这些垃圾都是不存在的，所有的Native API都有统一的标准，

所有都返回NTSTAUS(除非明确表示会返回一个特定的值），NTSTAUS是一个标准的错误码定义，

而且使用它们时你也不需要考虑该死的Ex版本。

Native 应用程序劣势：

(一) 和Win32开发的差异较大：如果你以前从来没有进行过Native API或内核驱动的相关开发，

你可能需要学习所有的API相关知识，当然，他们的名字是相似的，但是他们的标志经常是完全不同的，

而且他们的返回值，很可能使你感到迷惑。

(二) 缺少文档：虽然所有的Rtl*函数都是有文档的，数百个其他的Native API仍是无文档的。

(三) 缺少商业价值：虽然Native程序如此美好，但是建议你不要在商业产品中使用 Native API 或着使用Native应用程序，

Native API是可能改变的，虽然它们通常没有改变，但是他们很可能变得不再有用，不要拿你的客户的钱冒险。

(四) 没有GUI、及输入/输出接口:没有"Native控制台程序"，你无法简单地从用户那里接受到输入或显示些什么到屏幕上，

因为那些接口都无法再使用（控制台API都是Win32 API)。

Native 应用程序构建：

你需要这两者或两者之一来创建你的 native 应用程序:

(1)Visual C++ 2005 Express(or higher)

(2)Windows Driver Kit

我们将从基础开始，首先你需要创建你的应用程序的头文件，precomp.h，ntddk.h

1: #include "ntddk.h"

Now that that's done, create your main initialization file,

which we will call init.c. In this file, add precomp.h like this:

1: #include "precomp.h"

And define your entrypoint:

1: NTSTATUS __cdeclmain( 2: 3: INT argc, 4: 5: PCHAR argv[], 6: 7: PCHAR envp[], 8: 9: ULONG DebugFlag OPTIONAL) 10: 11: { 12: 13: // Entry code here 14: 15: }

Hopefully you are familiar with this entrypoint, it's the typical one used by C programs,

except with an addon: the "DebugFlag". Right now, we don't need to care about this.

We'll keep this entry simple, and turn this into a "Hello World":

1: NTSTATUS __cdecl main( 2: 3: INT argc, 4: 5: PCHAR argv[], 6: 7: PCHAR envp[], 8: 9: ULONG DebugFlag OPTIONAL) 10: 11: { 12: 13: UNICODE_STRING HelloMsg = RTL_CONSTANT_STRING(L"Hello World!\n"); 14: 15: //Say hello 16: 17: NtDisplayString(&HelloMsg); 18: 19: } 20:

Now, if you're wondering what NTSTATUS is,

what NtDisplayString is or what

RTL_CONSTANT_STRING and UNICODE_STRINGs are,

then you'll need to read all the DDK documentation you can swallow,

as well as Nebett's Undocumented Native API book.

Although it's outdated, the information about the APIs is still pretty valid.

I also plan to possibly give a fully-fledged lesson on this if lots of

people are interested.So now that we have our simple program, we need to build it.

I prefer using the WDK myself,

because it's much simpler and doesn't require changing 100 of MSVC's default settings.

Assuming you've properly installed the WDK and entered the Windows build environment for

your OS (from the Start Menu),

you'll need to create two files in the directory where init.c and precomp.h are:

sources and makefile.

Sources should look something like this:

1: TARGETNAME=native 2: 3: TARGETTYPE=PROGRAM 4: 5: UMTYPE=nt 6: 7: INCLUDES=\ 8: 9: $(DDK_INC_PATH); \ 10: 11: $(NDK_INC_PATH); 12: 13: SOURCES=init.c 14: 15: PRECOMPILED_INCLUDE=precomp.h 16:

that you'll have to set NDK_INC_PATH as an environment variable yourself,

to where the NDK is installed (DDK_INC_PATH is already setup by the WDK).

Finally, you'll need a makefile:

1: INCLUDE $(NTMAKEENV)\makefile.def

That's all you really need for our purposes.

So now you should have init.c, precomp.h, sources and makefile.

The only thing left is to write "build",

and the WDK should do the magic and create your first native application.

Unforunately, you can't really test it for now,

unless you do the following:Open registry editor and browse to

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

Edit the "BootExecute" key and write "native" instead of what's currently in it,

then copy native.exe to your system32 directory and restart the computer.

You should see the message appear on the screen for a little while.

Make sure that you do NOT boot with /NOGUIBOOT, or else you will never see it.

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

/////////////////MJ0011 翻译《Inside Native Application》//////////////////////

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

导言

如果你对Windows Nt结构有一定的了解，你可能会知道，Win32 应用程序所使用的API，

并非是"真正"的NT API，POSIX、OS/2和Win32这些Windows NT 操作系统环境，

使用他们自己的 API 同他们的客户应用程序进行交流，但却使用Windows NT的"Native" API同Windows NT交流，

这些Native API大都是未公开UnDocumented 的。

大约只有25个API（包含250种功能）在Windows NT设备驱动开发工具包(DDK)里有所描述。

尽管绝大多数人都不知道，但"Native"应用程序的确存在与Windows NT上，他们在操作环境上没有任何客户程序，

这些程序交流着Native NT API并且不能使用任何操作环境API比如 Win32，为什么这样一种程序是必须的呢?

因为在Win32子系统启动之前(大约在登陆对话框出现时)只可以运行Native应用程序，

最常见的Native应用程序的例子是"autochk"程序，他在初始化蓝色登陆屏幕前运行chkdsk(程序在屏幕上打印一串".")。

当然，Win32应用程序环境服务程序:CSRSS.exe(客户-服务运行时间子系统)，也是一个Native应用程序。

在这篇文章里，我将会讲述如何构造一个Native应用程序以及它们是如何工作的，

同时我也会提供一个Native应用程序的示例源代码。

这个示例很容易安装，它会在启动时的蓝色屏幕打印一段你指定的字符串。

Autochk是如何被执行的

Autochk在当内存分页被打开，Windows启动和系统开始驱动被载入之间的时间内运行，

在这个时间点会启动会话管理器(smss.exe)进入Windows NT用户模式，并且没有任何程序被启动。

注册表中:HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute

一个MULTI_SZ类型的键值，这里存放着将被会话管理器所执行的程序名称和参数，通常是Autochk后加*号作为其参数

Autocheck Autochk *
;名称程序名参数

会话管理器在<winnt>\system32目录下查找该值列出的可执行程序，当Autochk运行时，没有任何文件被打开，

所以Autochk可以用raw模式打开任何一个驱动器卷(包括根驱动器)，并操作其磁盘数据结构，

之后的任何时间点都无法进行类似这样的操作。

编译Native应用程序

1. 微软没有提供相应的文档，但是NT DDK构建器知道如何去生成一个Native应用程序，

而且它可以被用来编译autochk程序，和编写设备驱动程序一样，你必须指定SOURCE文件中的信息来定义应用程序，

然而和编写驱动不同的时，你在SOURCE文件中要求生成一个Native应用程序需要这样定义:

TARGETTYPE=PROGRAM

2. 构建器使用一个标准的makefile来进行向导:\ddk\inc\makefile.def 在编译Native应用程序时，

会查找名为nt.lib的运行库。不幸的是，微软并没在DDK上装载这个文件(在Windows Server 2003 DDK里包括了这个文件，

但是我怀疑你用这个版本来连接你的Native应用程序是无法运行在Windows XP或Windows 2000上的）不管怎样，

你可以忽略这个错误，方法是加入一行不考虑nt.lib，而指定Visual C++ 的运行库msvcrt.lib到makefile.lib中。

3. 如果你在DDK的"Checked Build"环境下进行编译，

将会在%BASEDIR%\lib\%CPU%\ Checked(例如c:\ddk\lib\i386\checked\ native.exe)

产生一个包含了全部调试信息的Native应用程序。

4. 如果在"Free Build"环境中编译，你会在%BASEDIR%\lib\%CPU%\Free得到一个释出版本的程序，

这些和构造设备驱动程序放置的位置是一样的。

5. Native应用程序有着".exe"的扩展名，但是你不能像 Win32的.exe文件那样去运行它，

如果你在Win32环境下运行下，将会得到如下提示:"<应用程序名> 应用程序无法在Win32模式中运行。"

深入学习Native应用程序

1. Native应用程序的入口点是NtProcessStartup，类似WinMain或Main，不同于其他的 Win32入口点的是，

Native应用程序提供一个数据结构来存放它的唯一的参数来定位命令行参数。

2. 大多数的Native应用程序的运行环境是由Windows Nt的Native API输出库 - NTDLL.DLL提供的。

3. Native应用程序必须使用RtlCreateHeap(一个ntdll函数)来创建他们自己的堆来分配存储，

使用RtlAllocateHeap来分配内存以及用RtlFreeHeap来释放内存。

4. Native应用程序需要使用NtDisplayString 函数才可以打印想要的内容到屏幕上(将被输出到初始化时的蓝色屏幕上)。

5. Native应用程序不像Win32程序那样简单地从他们的启动函数返回，你需要调用NtProcessTerminate函数来结束它的进程。

6. NTDLL运行包含了数百个函数允许Native应用程序执行文件I/O，与设备驱动进行相连，并执行进程间通讯。

不幸的是，他们大部分都是未公开的。

Native应用程序实例

1. 我创建一个Native应用程序用来演示Native应用程序是如何构建的以及他们是如何工作的。

运行install.bat来安装Native程序。

2. 批处理程序复制Native.exe到你的<winnt>\system32目录，

并在注册表中增加一个BootExecute的入口点: native Hello World!

3. 当你重新启动时，会话管理器运行完autochk后就会执行Native，Native分配一些堆，

定位它的命令行参数并打印参数("Hello world!")到蓝色屏幕上，它所使用的函数上面已说过了。

如果你想要打印其他的简单内容，可以编辑BootExecute值使用regedit或regedit32，

修改"Hello world"为你想要的信息。

4. 运行uinstall.bat可以卸载这个Native执行程序。它从<winnt>\system32 目录删除 Native.exe，

并修改BootExecute值为通常的值。

5. 如果你想要构建native程序你必须要用Windows设备驱动工具包(DDK)，

复制makefile.def到 \ddk\inc然后你可以运行构建。

Native.H

1: //Environment information, which includes command line and image file name 2: typedef struct 3: { 4: ULONG Unknown[21]; 5: UNICODE_STRING CommandLine; 6: UNICODE_STRING ImageFile; 7: } ENVIRONMENT_INFORMATION, *PENVIRONMENT_INFORMATION; 8: 9: // This structure is passed as NtProcessStartup's parameter 10: typedef struct 11: { 12: ULONG Unknown[3]; 13: PENVIRONMENT_INFORMATION Environment; 14: } STARTUP_ARGUMENT, *PSTARTUP_ARGUMENT; 15: 16: // Data structure for heap definition. 17: // This includes various sizing parameters and callback routines, 18: // which, if left NULL, result in default behavior 19: typedef struct 20: { 21: ULONG Length; 22: ULONG Unknown[11]; 23: } RTL_HEAP_DEFINITION, *PRTL_HEAP_DEFINITION; 24: 25: // Native NT api function to write something to the boot-time 26: // blue screen 27: NTSTATUS NTAPI NtDisplayString( 28: PUNICODE_STRING String 29: ); 30: 31: // Native applications must kill themselves when done - 32: // the job of this native API 33: NTSTATUS NTAPI NtTerminateProcess( 34: HANDLE ProcessHandle, 35: LONG ExitStatus 36: ); 37: 38: // Definition to represent current process 39: #define NtCurrentProcess() ( (HANDLE) -1 ) 40: 41: // Heap creation routine 42: HANDLE NTAPI RtlCreateHeap( 43: ULONG Flags, 44: PVOID BaseAddress, 45: ULONG SizeToReserve, 46: ULONG SizeToCommit, 47: PVOID Unknown, 48: PRTL_HEAP_DEFINITION Definition 49: ); 50: 51: // Heap allocation function (ala "malloc") 52: PVOID NTAPI RtlAllocateHeap( 53: HANDLE Heap, 54: ULONG Flags, 55: ULONG Size 56: ); 57: 58: // Heap free function (ala "free") 59: BOOLEAN NTAPI RtlFreeHeap( 60: HANDLE Heap, 61: ULONG Flags, 62: PVOID Address 63: );

Native.C

1: //====================================================================== 2: // 3: // This is a demonstration of a Native NT program. These programs 4: // run outside of the Win32 environment and must rely on the raw 5: // services provided by NTDLL.DLL. AUTOCHK (the program that executes 6: // a chkdsk activity during the system boot) is an example of a 7: // native NT application. 8: // 9: // This example is a native 'hello world' program. When installed with 10: // the regedit file associated with it, you will see it print 11: // "hello world" on the initialization blue screen during the system 12: // boot. This program cannot be run from inside the Win32 environment. 13: // 14: //====================================================================== 15: #include "ntddk.h" 16: #include "stdio.h" 17: #include "native.h" 18: 19: // Our heap 20: HANDLE Heap; 21: //---------------------------------------------------------------------- 22: // NtProcessStartup 23: // Instead of a 'main', NT applications are entered via this entry point. 24: //---------------------------------------------------------------------- 25: void NtProcessStartup( PSTARTUP_ARGUMENT Argument ) 26: { 27: PUNICODE_STRING commandLine; 28: PWCHAR stringBuffer; 29: PWCHAR argPtr; 30: UNICODE_STRING helloWorld; 31: RTL_HEAP_DEFINITION heapParams; 32: 33: // Initialize some heap 34: memset( &heapParams, 0, sizeof( RTL_HEAP_DEFINITION )); 35: heapParams.Length = sizeof( RTL_HEAP_DEFINITION ); 36: Heap = RtlCreateHeap( 2, 0, 0x100000, 0x1000, 0, &heapParams ); 37: 38: // Point at command line 39: commandLine = &Argument->Environment->CommandLine; 40: // Locate the argument 41: argPtr = commandLine->Buffer; 42: while( *argPtr != L' ' ) 43: { 44: argPtr++; 45: } 46: argPtr++; 47: 48: // Print out the argument 49: stringBuffer = RtlAllocateHeap( Heap, 0, 256 ); 50: swprintf( stringBuffer, L"\n%s", argPtr ); 51: 52: helloWorld.Buffer = stringBuffer; 53: helloWorld.Length = wcslen( stringBuffer ) * sizeof(WCHAR); 54: helloWorld.MaximumLength = helloWorld.Length + sizeof(WCHAR); 55: 56: NtDisplayString( &helloWorld ); 57: 58: // Free heap 59: RtlFreeHeap( Heap, 0, stringBuffer ); 60: 61: // Terminate 62: NtTerminateProcess( NtCurrentProcess(), 0 ); 63: }

Install.bat：

1: @echo off 2: copy native.exe %systemroot%\system32\. 3: regedit /s add.reg 4: echo Native Example Installed

UnInstall.bat：

1: @echo off 2: del %systemroot%\system32\native.exe 3: regedit /s remove.reg 4: echo Native Example Uninstalled

6. 互联网上其他关于 Native Application 的文章整理：

下面给出的则是我在互联网上其他地方找到的关于 Native Application 的比较好的资料，

这里也只是将这些资料进行一个整理。

《native app 开发小结（一）》：

http://hi.baidu.com/316526334/blog/item/32823e8a83d87b1fc9fc7a0f.html

《native app 开发小结（二）》：

http://hi.baidu.com/316526334/blog/item/43a21061ad619cd28cb10d08.html

《Native Application 应用之开机杀毒》：

http://www.cublog.cn/u/8754/showart_447592.html

程序类型

关于程序级别的分类，大概可以分为三层：应用层程序，即普通的APP程序；Native App程序，如常见的chkdsk工具，PQ分区工具等，都属于这类，它是在win子系统未启动起来就执行的程序，执行环境比较纯净，只能调用ntdll.dll导出的函数；

Driver 内核驱动程序，因功能不同也分为若干类，如设备驱动程序，内核扩展程序，文件系统驱动，过滤驱动等，

同属于内核态程序；其中，native app在项目开发中用的较少，所用的函数接口MS也均未公开，

开发难度和驱动相当，所以很少有人问津。但是，事实上，在某些应用场景下，用native app来实现是非常完美的，

比如：接管winodws的开机启动界面和密码输入界面，需要native app；

在开机前，执行磁盘修复，需要native app；开机前，执行杀毒，或者磁盘整理，

因为此时环境比较纯净，需要native app。诸如此类~ 最近，开发一个Native App项目，其规模和复杂度也不一般。

期间遇到很多问题，在逐一解决的时候也收获了很多东西。现在略作整理，以备将来查用，二来与大家分享之~

Native app 基本工作原理

这里，只想简单的描述下。

Windows的设计是基于分层模型的，在设计之初，内核NT支持三个子系统，OS/2,posix,win32,

这些子系统同属于一个层面上，它们公用windows nt提供的系统API和例程。其中，在某一个子系统上的API调用，

都会经过NT”native”API同windowsNT进行通信。这些native API就是ntdll.dll导出的函数，

因为它导出的大部分函数都只是起一个从子系统到NT内核的转发传递作用，所以也成为stub函数，

这些函数的原型大多是未公开的，在早期的DDK里会有相关的描述，但是现在没了，

取而代之的是内核实现的zw*,nt*开头的驱动函数。这里表明了MS的一个态度，

不希望第三方在native app上干涉windows的太多工作，比如，接管了开机启动系统，接管了登录密码界面:D.

后来，因为种种历史原因，对OS/2和posix子系统的支持逐渐被淡忘。但是这种分层模型仍然存在，

native app就是工作在子系统未启动之前，此时的系统环境很纯净，权限也相对较高；

另外，对操作系统来说，支持native app也是一种必须，因为在子系统启动之前，

很多功能的程序只能以native app来呈现，比如登录界面，CSRSS~

具体的启动时机：

Native app由启动会话管理器(smss.exe)来启动，如果想通知smss来执行一个native app程序，

只需要修改一个注册表项，smss在每次启动的时候会去检查该项，确保该项下面的每个native app程序依次执行。

注册表项为：HKLM\System\CurrentControlSet\Control\Session Manager\BootExecute ，

其类型为MULTI_SZ, 又是MS玩的一种字符串类型—多字符串类型，也就是说，

这个MULTI_SZ字符串包含多个以\0结尾的子字符串，而整个字符串以\0\0结尾。

在该注册表项后面添加要注册的native 程序名和参数就可以了。

关于native app的更多详细介绍，可以参考Mark Russinovich的一篇关于native的文章。

Native app程序结构

Native app程序结构很简单，就好像我们写hello world，需要写一个main函数入口一样，

native app的入口函数是NtProcessStartup，形如：

1: void NtProcessStartup( PSTARTUP_ARGUMENT Argument )

其中，参数PSTARTUP_ARGUMENT是一个结构体，用来存放传入参数。

程序退出时，主动调用函数NtProcessTerminate退出，它不会像普通应用程序一样一个返回return就退出了。

基本的结构就是这样了：

1: void NtProcessStartup( PSTARTUP_ARGUMENT Argument ) 2: 3: { 4: 5: // do something else 6: 7: NtProcessTerminate( NtCurrentProcess(), 0 ); 8: 9: } 10:

当然现在还没有包含头文件之类的。

开发语言及第三方的库

Native app支持的开发语言有C/ASM/C++,并且完美的支持C++的类特性,不过要像编写驱动一样，

需要重载new,delete等内存分配函数。在内存使用上，可以使用两套接口：堆函数接口，以及虚拟内存函数接口，

但是根据我的经验，使用堆函数接口，更高效并且内存bug出现的频率会大大降低。

举个例子：我在调试native app的时候，一切正常，且全部通过，但是双机调试的时候，

功能代码都运行完了，在子系统起来的时候，提示memory_corruption错误，

这个问题整整找了好几天都没有找到，到最后，无意间屏蔽掉了系统的DbgPrint函数，memory错误才解决。

其原因是，native gui图形模块的debug消息打印的太快太频繁，导致调试缓冲被溢出，

当屏蔽了系统DbgPrint的时候，也就是在windbg 下bp DbgPrint,然后a eip,ret后，就正常了。

虽然这个现象和程序无关，但是，用了虚拟内存的话，这个问题会更加容易重现。关于这个问题的重现很容易，

就是在native 环境下双机调试，target机器一直打印消息，当打印到10W条以上时，调试缓冲就“爆”了。

这真不知道是ms的bug，还是自己~~

关于 new, delete 的重载。

使用堆函数过程如下：首先创建一个全局堆，然后在这个全局堆上分配和释放局部堆。

1: HANDLE hGlobalHeap = NULL; // for globle call 2: 3: void* __cdecl operator new(size_t size) 4: 5: { 6: if(hGlobalHeap == NULL) 7: return NULL; 8: return RtlAllocateHeap(hGlobalHeap,0/*HEAP_ZERO_MEMORY*/,size); 9: } 10: 11: void __cdecl operator delete(void* addr) 12: 13: { 14: if(hGlobalHeap && addr) (void)RtlFreeHeap(hGlobalHeap,0,addr); 15: } 16:

关于 NDK：前面说到，native app用的是ntdll.dll的导出函数，而这些函数MS并没有公开接口声明，

那么我们使用的时候，首先必须要自己定义函数声明。

NDK就是这样的一个类库，它几乎定义了ntdll.dll导出的全部函数的声明以及一些常用的数据结构的定义，

我们只需要包含相应的头文件，导入ntdll.lib库，就可以像使用普通的API函数一样开发native app了。

关于DLL：native app可以调用同一级别的DLL，使大型的项目开发更加容易，更加容易划分模块。

注意，DLL的编译环境要和native app一致。

关于native app的编译：可以选择用vs环境，也可以用DDK/WDK，但是推荐使用WDK。

用VS环境的话，需要简单的设置下，随意创建一个类型的工程，然后修改Linker->system->Native，

就可以了。如果用WDK编译，需要写一个SOURCE模板，如：

1: TARGETNAME=defrag 2: 3: TARGETPATH=obj 4: 5: TARGETTYPE=PROGRAM 6: 7: INCLUDES=$(PUBLIC_ROOT)\inc\ddk 8: 9: SOURCES=defrag.cpp 10:

注意：上面说的DLL的编译环境和native app的编译环境要一致，

指的是不要用WDK编译的native去尝试链接VS编译的DLL,反之亦然。

1: //NTSTATUS NTAPI NtDisplayString( PUNICODE_STRING String);

Native GUI

在native app执行环境下画界面是不可行的，但是不是说做不到。

前面说了，可以写一个native app来接管windows的启动界面和密码输入界面，那么这个界面是如何画的呢？

也有从驱动里实现的。但是，事实上，MS提供了一个native级别的动态库，名为:Bootvid.dll，

用来实现GUI启动屏幕的引导视频驱动，这个dll导出了一些函数，可以实现画图，贴图功能，

当然，这些函数接口仍然是未公开的。呵呵~

另外，在native app程序，可以利用一个函数向屏幕打印输出字符串，名为：

但是，事实上，这个函数已经不推荐使用了，

在用WDK编译native app的时候，会提示一个警告信息，deprecated~~

Native app的灵活性

native app由于受到调用函数接口未公开，以及开发难度和调试难度不小的原因，很少有项目问津，

但是，事实上，它仍然是一种工作于ring3的用户态程序，只是在子系统启动之前运行，

所以，native app程序一般不会引起系统蓝屏的问题。

也正是如此，native 程序工作在一个相对纯净的环境下，可以访问任何文件，甚至搬移MFT，系统元文件等。

Ntdll.dll为native app导出的函数虽少，但是可以完成很多的功能。

这些导出函数，基本上和内核的系统例程都是一一对应的。结合其他的模块，driver,应用程app,

在加之native独特的运行环境和执行能力，往往会达到一个良好的效果。在这里，仅仅是一个普及~

具体应用及实例

在开发native app之前，我想，最好有开发驱动的基础。因为native app程序的编写规范基本上和驱动一样，

除了入口函数，调试方法也一样，必须要双机调试。当然，只是说编写规则一样，驱动特有的函数例程以及工作原理，

二者是毫不相干的。举个例子，操作注册表，文件IO，线程创建，内存使用，二者基本上是一致的，具体的在使用中自己体会吧。

作为入门例子

作为入门我想还是用Mark Russinovich的例子吧，就好像Hello World的作用一样，

让你真切的感受下native app程序。该程序在系统启动时，蓝屏界面上输出一行字符串信息。

程序在附件，没什么过多的需要解释的。

实际开发

实际开发中，有不少的应用例子。比如，影子系统的启动界面，PQ分区工具，

win系统自带的chkdsk工具，都属于这类程序。下面说下自己的一些经历吧：

项目中有个需要，对特定文件进行磁盘整理。我们知道，文件系统导出了一组函数接口，

用于对磁盘上的文件进行搬移操作，使文件内碎片和外碎片减少，提高IO吞吐率和磁盘访问率。

唯一的限制是，pagefile.sys和日志文件不能整理，其他的文件，如MFT,系统元文件都可以整理。

对于文件整理，更重要的是算法和稳定法，当然，这是另外一个话题了。

根据prefreth原理，一个应用程序的工作集页面在运行时基本上是趋于稳定的，

那么这些稳定的页面如果位于不同的文件（可能是链接库之类），且这些文件在磁盘上比较分散，

那么就会影响程序的启动时间了，虽然prefretch做了改善，会自动的激发系统的磁盘整理来对“相关”的文件紧密排放，

但仍然是不够的。所以，关于这种性能的改善看起来微乎其微，但是做好了，价值是不可估量的。

这仅仅是一个方面，当然，项目中的主要目的并不是这个，虽然也是为了提高性能。

在native app下操作文件，考虑的情况是比较单一的，不会担心文件或目录被锁，

从而出现不能访问的情况，也不会考虑过多的并发问题。

所以，功能会更加集中，运行效率会更高，操作的空间和权限也更大。

仅限于此，就到这吧 ~

7. 小结：

上面的文字呢就大体的把 Native Application 给介绍的差不多了，

主要是总结了一下自己关于 Native Application 的理解，

然后再将 MJ0011 和互联网上的几位博主的文章给整理了一下(原博文排版不怎么好)，

这里对 MJ0011 以及所整理的文章的博主表示感谢 ~

博文中的 Demo 我是采用的 DDK 2600.1106 编译的，至于 WDK 7 的话，我没有去试哦 ~

有兴趣的可以直接下载了 Demo 进行测试的，代码什么的都在里面，

source 和 makefile 我也都整理好了放在 Demo 中 ~

最后还是和以往一样，给出些我近来的一些疑问:

我曾经从一台电脑 A 上下载了卡巴斯基的试用版，然后我将这个试用版的安装文件拷贝到了电脑 B 上，

这时我发现卡巴斯基的这个安装文件在电脑 B 上是无法运行的 ~ 直接报错，

当然，这个安装文件在电脑 A 上是可以运行安装的，

我想应该是卡巴斯基的这个安装文件在拷贝的过程中还是下载的过程中记录下了我的电脑 A，

然后在安装的时候，其自动判断是否是在电脑 A 上安装运行，

如果是的话，则可以成功安装，如果不是，则直接报错 ~

我想知道上面是怎么来实现的呢 ? 我只是下载和拷贝了一下哦 ~

还有就是貌似要考个微软的 MCTS 证书，

应该是 Windows 方向的 71-511 或者 Web 方向的 71-515 这两门考试，

不晓得大伙有什么好建议或者好的资料没有哦 ~ 可否提供一些呢 ~ 谢谢咯 ~

然后再问一下哦，有没有湖南娄底的啊 ? 国庆组队回去否 ?(我在深圳 ~)

下载 Demo Source Code

本文链接

进程隐藏与进程保护（SSDT Hook 实现）（三）

2011-09-05T15:03:00Z

文章目录：

1. 引子：

2. 获取当前系统下所有进程：

3. 服务管理（安装，启动，停止，卸载）：

4. 应用程序和内核程序通信：

5. 小结：

1. 引子：

关于这个 SSDT Hook 实现进程隐藏和进程保护呢，这是最后一篇博文了，

在文章的结尾处呢你可以下载到整个项目的实例程序以及代码，

程序可以在 XP、Server、Win7 上运行的，当然我是说的 32 位操作系统。

《进程隐藏与进程保护(SSDT Hook 实现)(一)》呢把 SSDT Hook 的原理说得差不多了，

博文地址：http://www.cnblogs.com/BoyXiao/archive/2011/09/03/2164574.html

《进程隐藏与进程保护(SSDT Hook 实现)(二)》则把 SSDT Hook 的实现说得差不多了，

博文地址：http://www.cnblogs.com/BoyXiao/archive/2011/09/04/2166596.html

这一篇博文介绍的则是在 Ring3 下编写 MFC 应用程序，并且让应用程序与内核程序通信，

即由应用程序将需要隐藏的进程或者是需要保护的进程的 PID 传递给内核程序，

然后在内核程序中就会将传递进来的这个 PID 进行隐藏或者保护 ~

在这里再给出这个应用程序的一张截图：

2. 获取当前系统下所有进程：

前面提到过，要想获取到系统下的所有进程，有三种方法，

第一种即是使用 ToolHelp 来获取，

第二种则是使用 PSAPI 来获取，

第三种则是使用 ntdll.dll 中的未文档化的 NtQuerySystemInformation 之类的 API 来获取(比较麻烦)。

而在这里我使用最简单的方式，即通过 PSAPI 中的 EnumProcesses 这个 API 来获取，

EnumProcesses API 可以获取到当前系统下所有进程的 PID，并且将 PID 存放在作为输出参数的数组当中，

其原型如下（可以看 MSDN）：

1: BOOL WINAPI EnumProcesses( 2: __out DWORD* pProcessIds, 3: __in DWORD cb, 4: __out DWORD* pBytesReturned 5: ); 6:

代码中使用(将获取到所有的 PID，然后将 PID 保存到 vector 容器中)：

1: //遍历当前所有的进程，并且将进程 ID 填充到容器 vectorPID 中 2: void CSSDTProcessDlg::FillPIDVector() 3: { 4: DWORD dwPIDArray[MAX_PROCESS_COUNT]; 5: DWORD dwNeededBytes; 6: DWORD dwProcCount; 7: 8: dwNeededBytes = 0; 9: dwProcCount = 0; 10: memset(dwPIDArray, 0, sizeof(DWORD) * MAX_PROCESS_COUNT); 11: if(NULL != EnumProcesses(dwPIDArray, sizeof(dwPIDArray), &dwNeededBytes)) 12: { 13: dwProcCount = dwNeededBytes / sizeof(DWORD); 14: } 15: 16: BubbleSort(dwPIDArray, dwProcCount); 17: 18: ClearVector(); 19: for(int i=0; i<dwProcCount; i++) 20: { 21: PROCESS_BIND procBind; 22: procBind.dwPID = dwPIDArray[i]; 23: if(dwPIDArray[i] == 0) 24: { 25: procBind.state = ProcessStateUnknown; 26: } 27: else 28: { 29: procBind.state = ProcessStateGeneral; 30: } 31: this->m_vctAllProcess.push_back(procBind); 32: } 33: }

3. 服务管理（安装，启动，停止，卸载）：

在 Windows 内核程序中，现在大体可以分为三类了，

第一类是 NT 式驱动程序；

第二类为 WDM 驱动程序；

第三类为 WDF 驱动程序；

其中，对于 NT 式驱动程序，其安装方式是很简单的，因为你可以将 NT 式驱动程序看做一个服务，

既然是服务的话，自然在 Windows 中可以通过 SCM API 来完成其安装，启动，停止和卸载等功能 ~

而至于 WDM 和 WDF 的话，如果其中涉及到了设备的话，还必须使用 INF 文件来实现安装 ~

而我们前面的那个 SSDT 内核程序就是基于 NT 式的驱动程序，所以可以通过 SCM API 来实现上面的这些功能，

至于如何使用 SCM API 来完成服务的安装、启动、停止和卸载功能的话，

可以参见笔者的另外一篇博文《Windows 服务(附服务开发辅助工具)》，

博文地址为：http://www.cnblogs.com/BoyXiao/archive/2011/08/07/2130208.html

下面就只是将服务的安装 API、启动 API、停止 API 和卸载 API 贴出来了 ~

至于这些代码的细细道来的话，可以参加上面给出的那篇博文的 ~

1: //=====================================================================================// 2: //Name: bool InstallSvc() // 3: // // 4: //Descripion: 安装服务 // 5: // lpszSvcName 为服务名称， // 6: // lpszDisplay 为显示在服务控制管理器中的名称， // 7: // lpszSvcBinaryPath 为服务映像文件所在路径， // 8: // dwSvcType 为服务类型 // 9: // dwStartType 为服务启动类型 // 10: //=====================================================================================// 11: bool CSSDTProcessDlg::InstallSvc(LPTSTR lpszSvcName, LPTSTR lpszDisplayName, 12: LPTSTR lpszSvcBinaryPath, DWORD dwSvcType, DWORD dwStartType) 13: { 14: SC_HANDLE hSCM = NULL; 15: SC_HANDLE hSvc = NULL; 16: 17: AdjustProcessTokenPrivilege(); 18: 19: hSCM = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS); 20: if(NULL == hSCM) 21: { 22: OutputErrorMessage(TEXT("InstallSvc - OpenSCManager Failed , Error Code Is %d , Error Message Is %s !")); 23: 24: return FALSE; 25: } 26: 27: for(int i = 0; i < 3 && (NULL == hSvc); i++) 28: { 29: //SERVICE_WIN32_OWN_PROCESS | SERVICE_INTERACTIVE_PROCESS 30: hSvc = CreateService(hSCM, lpszSvcName, lpszDisplayName, SERVICE_ALL_ACCESS, 31: dwSvcType, dwStartType, SERVICE_ERROR_NORMAL, 32: lpszSvcBinaryPath, NULL, NULL, NULL, NULL, NULL); 33: if(NULL != hSvc) 34: { 35: if(NULL != hSvc) 36: { 37: CloseServiceHandle(hSvc); 38: } 39: CloseServiceHandle(hSCM); 40: return TRUE; 41: } 42: } 43: 44: OutputErrorMessage(TEXT("InstallSvc - CreateService Failed , Error Code Is %d , Error Message Is %s !")); 45: 46: CloseServiceHandle(hSCM); 47: 48: return FALSE; 49: } 50: 51: 52: //=====================================================================================// 53: //Name: bool UnInstallSvc() // 54: // // 55: //Descripion: 实现卸载服务 // 56: //=====================================================================================// 57: bool CSSDTProcessDlg::UnInstallSvc(LPTSTR lpszSvcName) 58: { 59: SC_HANDLE hSCM = NULL; 60: SC_HANDLE hSvc = NULL; 61: bool rtResult = FALSE; 62: 63: AdjustProcessTokenPrivilege(); 64: 65: hSCM = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS); 66: if(NULL == hSCM) 67: { 68: OutputErrorMessage(TEXT("UnInstallSvc - OpenSCManager Failed , Error Code Is %d , Error Message Is %s !")); 69: 70: return FALSE; 71: } 72: 73: hSvc = OpenService(hSCM, lpszSvcName, SERVICE_ALL_ACCESS); 74: if(NULL == hSvc) 75: { 76: OutputErrorMessage(TEXT("UnInstallSvc - OpenService Failed , Error Code Is %d , Error Message Is %s !")); 77: 78: CloseServiceHandle(hSCM); 79: 80: return FALSE; 81: } 82: 83: rtResult = DeleteService(hSvc); 84: 85: CloseServiceHandle(hSvc); 86: CloseServiceHandle(hSCM); 87: 88: return rtResult; 89: } 90: 91: 92: //=====================================================================================// 93: //Name: bool StartSvc() // 94: // // 95: //Descripion: 实现启动服务 // 96: //=====================================================================================// 97: bool CSSDTProcessDlg::StartSvc(LPTSTR lpszSvcName) 98: { 99: SC_HANDLE hSCM = NULL; 100: SC_HANDLE hSvc = NULL; 101: bool rtResult = FALSE; 102: 103: AdjustProcessTokenPrivilege(); 104: 105: hSCM = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS); 106: if(NULL == hSCM) 107: { 108: OutputErrorMessage(TEXT("StartSvc - OpenSCManager Failed , Error Code Is %d , Error Message Is %s !")); 109: 110: return FALSE; 111: } 112: 113: hSvc = OpenService(hSCM, lpszSvcName, SERVICE_ALL_ACCESS); 114: if(NULL == hSvc) 115: { 116: OutputErrorMessage(TEXT("StartSvc - OpenService Failed , Error Code Is %d , Error Message Is %s !")); 117: 118: CloseServiceHandle(hSCM); 119: 120: return FALSE; 121: } 122: 123: rtResult = StartService(hSvc, NULL, NULL); 124: 125: CloseServiceHandle(hSvc); 126: CloseServiceHandle(hSCM); 127: 128: if(FALSE == rtResult) 129: { 130: if(ERROR_SERVICE_ALREADY_RUNNING == GetLastError()) 131: { 132: return TRUE; 133: } 134: else 135: { 136: OutputErrorMessage(TEXT("StartSvc - StartService Failed , Error Code Is %d , Error Message Is %s !")); 137: 138: return FALSE; 139: } 140: } 141: else 142: { 143: return TRUE; 144: } 145: } 146: 147: 148: //=====================================================================================// 149: //Name: bool StopSvc() // 150: // // 151: //Descripion: 实现停止服务 // 152: //=====================================================================================// 153: bool CSSDTProcessDlg::StopSvc(LPTSTR lpszSvcName) 154: { 155: SC_HANDLE hSCM = NULL; 156: SC_HANDLE hSvc = NULL; 157: bool rtResult = FALSE; 158: 159: SERVICE_STATUS svcStatus; 160: 161: AdjustProcessTokenPrivilege(); 162: 163: hSCM = OpenSCManager(NULL, NULL, SC_MANAGER_ALL_ACCESS); 164: if(NULL == hSCM) 165: { 166: OutputErrorMessage(TEXT("StopSvc - OpenSCManager Failed , Error Code Is %d , Error Message Is %s !")); 167: 168: return FALSE; 169: } 170: 171: hSvc = OpenService(hSCM, lpszSvcName, SERVICE_ALL_ACCESS); 172: if(NULL == hSvc) 173: { 174: OutputErrorMessage(TEXT("StopSvc - OpenService Failed , Error Code Is %d , Error Message Is %s !")); 175: 176: CloseServiceHandle(hSCM); 177: 178: return FALSE; 179: } 180: 181: rtResult = ControlService(hSvc, SERVICE_CONTROL_STOP, &svcStatus); 182: if(rtResult == FALSE) 183: { 184: OutputErrorMessage(TEXT("StopSvc - ControlService Failed , Error Code Is %d , Error Message Is %s !")); 185: } 186: CloseServiceHandle(hSvc); 187: CloseServiceHandle(hSCM); 188: 189: return rtResult; 190: }

那么服务的安装和启动放在那里比较合适，而服务的关闭和卸载又放在那里比较合适呢 ?

由于这个应用程序采用 MFC 开发，自然可以在 OnInitDialog()中安装和启动服务比较合适，

而后可以在对话框类的析构函数中关闭和卸载掉服务 ~

安装和启动服务：

1: wstring wStrSysPath = GetSysFilePath(); 2: BOOL bResult = InstallSvc(((LPTSTR)(LPCTSTR)SSDT01_SERVICE_NAME), 3: ((LPTSTR)(LPCTSTR)SSDT01_SERVICE_NAME), 4: ((LPTSTR)(LPCTSTR)wStrSysPath.c_str()), 5: SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START); 6: if(FALSE == bResult) 7: { 8: MessageBox(_TEXT(" Install SSDT Service Failed , Application Auto Exit ! "), 9: _TEXT("Application Error"), MB_OK | MB_ICONSTOP); 10: CDialogEx::OnCancel(); 11: return FALSE; 12: } 13: else 14: { 15: bResult = StartSvc(SSDT01_SERVICE_NAME); 16: if(FALSE == bResult) 17: { 18: MessageBox(_TEXT(" Start SSDT Service Failed , Application Auto Exit ! "), 19: _TEXT("Application Error"), MB_OK | MB_ICONSTOP); 20: CDialogEx::OnCancel(); 21: return FALSE; 22: } 23: }

停止并且将服务卸载掉：

1: ~CSSDTProcessDlg() 2: { 3: //在析构函数中关闭 SSDT 设备句柄 4: if(this->m_hDevice) 5: { 6: CloseHandle(this->m_hDevice); 7: } 8: 9: //当发生析构函数时，停止服务并且卸载服务 10: StopSvc(SSDT01_SERVICE_NAME); 11: UnInstallSvc(SSDT01_SERVICE_NAME); 12: }

4. 应用程序和内核程序通信：

由前面的第二篇博文，可以知道，应用程序和内核程序的通信我是通过 DeviceIoControl 来完成的，

开发过内核程序的都清楚，应用程序和内核程序的通信最普遍的也就通过三个 API 来实现，

一个 ReadFile，一个 WriteFile，一个 DeviceIoContrl，

当然其中属 DeviceIoControl 功能最为强大，完全可以用其替换掉 ReadFile 和 WriteFile，

DeviceIoControl 原型(详细信息可以参考 MSDN)：

1: BOOL WINAPI DeviceIoControl( 2: __in HANDLE hDevice, 3: __in DWORD dwIoControlCode, 4: __in LPVOID lpInBuffer, 5: __in DWORD nInBufferSize, 6: __out LPVOID lpOutBuffer, 7: __in DWORD nOutBufferSize, 8: __out LPDWORD lpBytesReturned, 9: __in LPOVERLAPPED lpOverlapped 10: ); 11:

至于如何实现应用程序和内核程序的通信的话，在我的 Demo 中是这样做处理的，

首先在 OnInitDialog 事件中通过 CreateFile 打开我们所安装的服务中创建的设备，

(在 NT 式驱动程序中我创建了一个设备，这个设备用来实现应用程序和内核程序的通信)，

然后在对话框类中保存有一个全局变量，这个全局变量即代表所打开的这个设备的句柄，

既然这个全局变量是保存的我们的设备的句柄，自然我们需要来获取到设备的句柄，并且将句柄赋值给该全局变量，

而这个呢，又是在 OnInitDialog 中完成的 ~

1: this->m_hDevice = CreateFile(SSDT01_DEVICE_NAME, GENERIC_READ | GENERIC_WRITE, 0, 2: NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); 3: if(INVALID_HANDLE_VALUE == this->m_hDevice) 4: { 5: MessageBox(_TEXT(" Open SSDT Device Failed , Application Auto Exit ! "), 6: _TEXT("Application Error"), MB_OK | MB_ICONSTOP); 7: 8: CDialogEx::OnCancel(); 9: return FALSE; 10: }

有了这个设备句柄，我们就可以通过其来实现和内核程序的通信了，

因为通过在应用程序中调用 DeviceIoControl 可以产生 IRP_MJ_DEVICE_CONTROL 的 IRP，

然后该 IRP 可以被驱动程序中的 DeviceIoControl 分发函数所处理 ~

我们的应用程序只需要将我们所要隐藏或者是需要保护的进程的 PID 通过 DeviceIoControl 传递给内核程序即可 !!!

所以我们在应用程序中只需要调用 DeviceIoContrl 即可 ~

下面给出的代码比较凌乱(重点请看 DeviceIoControl 的调用)

1: //隐藏进程或者取消对进程的隐藏 2: void CSSDTProcessDlg::OnBnClickedBtnHideorunhide() 3: { 4: int nIndex; 5: DWORD dwPID; 6: CString cStrText; 7: CString cStrState; 8: 9: DWORD dwOutput; 10: BOOL bRet; 11: CHAR inBuffer[10]; 12: CHAR outBuffer[10]; 13: memset(inBuffer, 0, 10); 14: memset(outBuffer, 0, 10); 15: 16: dwPID = this->GetDlgItemInt(IDC_STATIC_SELECTED_PID); 17: this->GetDlgItemText(ID_BTN_HIDEORUNHIDE, cStrText); 18: 19: ultoa(dwPID, inBuffer, 10); 20: 21: nIndex = QueryItemIndexByPID(dwPID); 22: cStrState = this->m_ListCtrlProcess.GetItemText(nIndex, 4); 23: 24: if(cStrText.CompareNoCase(_TEXT("Hide")) == 0) 25: { 26: //隐藏 dwPID 27: bRet = DeviceIoControl(this->m_hDevice, IO_INSERT_HIDE_PROCESS, inBuffer, 10, 28: &outBuffer, 10, &dwOutput, NULL); 29: if(bRet) 30: { 31: this->SetDlgItemText(ID_BTN_HIDEORUNHIDE, _TEXT("UnHide")); 32: if(cStrState.CompareNoCase(_TEXT("Protect")) == 0) 33: { 34: this->m_ListCtrlProcess.SetItemText(nIndex, 4, _TEXT("HideAndProtect")); 35: } 36: else 37: { 38: this->m_ListCtrlProcess.SetItemText(nIndex, 4, _TEXT("Hide")); 39: } 40: MessageBox(_TEXT(" Hide Process Sucess ! "), _TEXT("Information"), MB_OK | 41: MB_ICONINFORMATION); 42: } 43: else 44: { 45: MessageBox(_TEXT(" Hide Process Failed ! "), _TEXT("Warning"), MB_OK | MB_ICONERROR); 46: } 47: } 48: else 49: { 50: //解除 dwPID 隐藏 51: bRet = DeviceIoControl(this->m_hDevice, IO_REMOVE_HIDE_PROCESS, inBuffer, 10, 52: &outBuffer, 10, &dwOutput, NULL); 53: if(bRet) 54: { 55: this->SetDlgItemText(ID_BTN_HIDEORUNHIDE, _TEXT("Hide")); 56: if(cStrState.CompareNoCase(_TEXT("Protect")) == 0 || 57: cStrState.CompareNoCase(_TEXT("HideAndProtect"))== 0) 58: { 59: this->m_ListCtrlProcess.SetItemText(nIndex, 4, _TEXT("Protect")); 60: } 61: else 62: { 63: this->m_ListCtrlProcess.SetItemText(nIndex, 4, _TEXT("General")); 64: } 65: MessageBox(_TEXT(" UnHide Process Sucess ! "), _TEXT("Information"), MB_OK | 66: MB_ICONINFORMATION); 67: } 68: else 69: { 70: MessageBox(_TEXT(" UnHide Process Failed ! "), _TEXT("Warning"), MB_OK | MB_ICONERROR); 71: } 72: } 73: } 74: 75: 76: //保护进程或者取消对进程的保护操作 77: void CSSDTProcessDlg::OnBnClickedBtnProtectorunprotect() 78: { 79: int nIndex; 80: DWORD dwPID; 81: CString cStrText; 82: CString cStrState; 83: 84: DWORD dwOutput; 85: BOOL bRet; 86: CHAR inBuffer[10]; 87: CHAR outBuffer[10]; 88: memset(inBuffer, 0, 10); 89: memset(outBuffer, 0, 10); 90: 91: dwPID = this->GetDlgItemInt(IDC_STATIC_SELECTED_PID); 92: this->GetDlgItemText(ID_BTN_PROTECTORUNPROTECT, cStrText); 93: 94: ultoa(dwPID, inBuffer, 10); 95: 96: nIndex = QueryItemIndexByPID(dwPID); 97: cStrState = this->m_ListCtrlProcess.GetItemText(nIndex, 4); 98: 99: if(cStrText.CompareNoCase(_TEXT("Protect")) == 0) 100: { 101: //保护 dwPID 保护 102: bRet = DeviceIoControl(this->m_hDevice, IO_INSERT_PROTECT_PROCESS, inBuffer, 10, 103: &outBuffer, 10, &dwOutput, NULL); 104: if(bRet) 105: { 106: this->SetDlgItemText(ID_BTN_PROTECTORUNPROTECT, _TEXT("UnProtect")); 107: if(cStrState.CompareNoCase(_TEXT("Hide"))== 0) 108: { 109: this->m_ListCtrlProcess.SetItemText(nIndex, 4, _TEXT("HideAndProtect")); 110: } 111: else 112: { 113: this->m_ListCtrlProcess.SetItemText(nIndex, 4, _TEXT("Protect")); 114: } 115: MessageBox(_TEXT(" Protect Process Sucess ! "), _TEXT("Information"), MB_OK | 116: MB_ICONINFORMATION); 117: } 118: else 119: { 120: MessageBox(_TEXT(" Protect Process Failed ! "), _TEXT("Warning"), MB_OK | MB_ICONERROR); 121: } 122: } 123: else 124: { 125: //解除 dwPID 保护 126: bRet = DeviceIoControl(this->m_hDevice, IO_REMOVE_PROTECT_PROCESS, inBuffer, 10, 127: &outBuffer, 10, &dwOutput, NULL); 128: if(bRet) 129: { 130: this->SetDlgItemText(ID_BTN_PROTECTORUNPROTECT, _TEXT("Protect")); 131: if(cStrState.CompareNoCase(_TEXT("Hide")) == 0 || 132: cStrState.CompareNoCase(_TEXT("HideAndProtect")) == 0) 133: { 134: this->m_ListCtrlProcess.SetItemText(nIndex, 4, _TEXT("Hide")); 135: } 136: else 137: { 138: this->m_ListCtrlProcess.SetItemText(nIndex, 4, _TEXT("General")); 139: } 140: MessageBox(_TEXT(" UnProtect Process Sucess ! "), _TEXT("Information"), MB_OK | 141: MB_ICONINFORMATION); 142: } 143: else 144: { 145: MessageBox(_TEXT(" UnProtect Process Failed ! "), _TEXT("Warning"), MB_OK | MB_ICONERROR); 146: } 147: } 148: }

5. 小结：

介绍这个应用程序呢，还真是不好写，因为感觉整个 Demo 里面却是没有什么好介绍的，

无非就是获取到所有的进程，然后通过一个 ListCtrl 来显示这些数据，

然后用户选择一个进程，单击一下隐藏呢，我就在这个按钮的消息处理函数中和内核程序通过 DeviceIoControl 通信一下，

将这个进程的 PID 传递给内核程序，其他的就都不需要理会了 ~ 所以转来转去的，也没什么好些的，干脆就写到这里得了，

等下将整个 Demo 打个包，直接提供下载，我这里说得口干舌燥也没什么用，感兴趣的自己下载了源码去慢慢玩得了 ~

最后再总结一个 SSDT Hook 的优点，那就是 SSDT Hook 无论你是 Windows XP 还是 Server 或者 Vista 或者 Win7，

你都是可以很好的运行程序的，所以你下载的 Demo 你可以放心的在上面的这些操作系统上运行，当然 64 位的除外，

64 位的操作系统虽然我没有做过测试，但是我估摸着会蓝屏的 ~ 有兴趣的可以去蓝一次 ~

下载 Demo Source Code

本文链接

进程隐藏与进程保护（SSDT Hook 实现）（二）

2011-09-04T10:10:00Z

文章目录：

1. 引子 – Demo 实现效果：

2. 进程隐藏与进程保护概念：

3. SSDT Hook 框架搭建：

4. Ring0 实现进程隐藏：

5. Ring0 实现进程保护：

6. 隐藏进程列表和保护进程列表的维护：

7. 小结：

1. 引子 – Demo 实现效果：

上一篇《进程隐藏与进程保护(SSDT Hook 实现)(一)》呢把 SSDT 说得差不多了，

博文地址：

http://www.cnblogs.com/BoyXiao/archive/2011/09/03/2164574.html

不过呢，那也只是些理论的东西，看不到什么实物，估计说来说去把人说晕了后，也没什么感觉，

而这一篇博文的话，给出点新意的，让人头脑清醒点的 ~ 所以先给个 Demo 出来吧 ~

(不好意思，本着不喝倒怎出得了好文章这个理由，所以今天又喝多了点，文章有疏忽之处还请见谅 ~

顺便在这里跟朋友们分享一下哈，晚上于这个时间点，比如 2 点的时候啊，喝点小酒，

听点曲子，你会精神振奋，头脑更加清醒，思路也会很清晰，尤其是写起程序来那是唰唰的来の ~ )

进程隐藏效果：

应用程序主界面：

隐藏进程 taskmgr.exe：

取消进程隐藏 taskmgr.exe：

进程保护效果：

进程保护(保护自身进程 SSDTProcess.exe)：

取消进程保护(这里还是以 SSDTProcess.exe 为例)：

下面的截图表示 SSDTProcess.exe 已经被取消了保护，

此时再到任务管理器中结束 SSDTProcess.exe 时，你可以发现是可以正常结束这个进程的 ~

2. 进程隐藏与进程保护概念：

在 Ring3 下获取到当前 Windows 操作系统下的所有的进程无外乎以下的几种方法：

第一种：使用 ToolHelp 遍历获取到所有进程，关于这种方式的话，笔者以前写过一篇博文的，

《列举 Windows 所有进程(ToolHelp)》博文地址如下：

http://www.cnblogs.com/BoyXiao/archive/2011/02/27/1966383.html

第二种：使用 PSAPI 下的 EnumProcesses 获取到所有进程的 PID，然后提升进程权限为 SE_DEBUG 权限，

再调用 OpenProcess 即可打开进程，从而获取到进程的基本信息(可以查看 MSDN 的 PSAPI 专题)。

第三种：使用未公开的本地 API 即位于 Ntdll.dll 中的未文档化的 API – NtQuerySystemInformation，

而 Windows 任务管理器就是通过这种方式来获取到所有的进程信息的 ~

而事实上的是，ToolHelp 和 PSAPI 只不过是对 Ntdll.dll 中 NtQuerySystemInformation API 的一个封装，

所以在 Ring3 下获取系统中所有进程信息最终都会回到 Ndll.dll 中 NtQuerySystemInformation API 的调用上。

如果要实现在 Ring3 中对进程进行隐藏的话，只需要 Hook 掉 NtQuerySystemInformation API 即可。

而至于进程保护的话，我们需要考虑到两种情况，第一种则是该进程自行终止，第二种情况则是该进程被其他进程给杀掉，

第一种情况基本上对于窗口应用程序来说，一般都是用户点击了右上角的 x 按钮，然后产生 WM_CLOSE 消息，

最后由窗口过程退出进程，这种情况下，我们应该是需要允许退出的，也就是进程是可以正常退出的。

而第二种情况的话，就是进程被别的进程杀掉，比如在任务管理器中就可以杀掉绝大部分的应用程序进程，

而这里的进程保护就是要实现进程不能够被任务管理器或者其他的进程管理工具杀掉。

在 Ring3 中，由一个进程结束其他进程，调用的 API 为 Kernel32.dll 中的 TerminateProcess，

如果追溯这个 TerminateProcess，可以发现，其调用了 Ntdll.dll 中的 NtTerminateProcess API，

然后再追溯下去就可以到 ntoskrnl.exe 中的 ZwTerminateProcess 和系统服务 NtTerminateProcess 了。

而这和我的上一篇博文中介绍 NtQuerySystemInformation 就是一致的了，

所以如果我们要实现进程保护，需要 Hook 的系统服务就是 NtTerminateProcess ~

3. SSDT Hook 框架搭建：

从上面的介绍中，我们可以知道，要想实现进程隐藏和进程保护，我们需要在 SSDT 中 Hook 两个系统服务，

即 Ring0 下的 NtQuerySystemInformation 和 Ring0 下的 NtTerminateProcess，

既然要实现两个 Hook 的话，我干嘛不将 SSDT Hook 写成一个框架呢，

这样的话，以后我无论是需要 Hook 哪个 SSDT 中的系统服务，我直接调用这个 SSDT 框架不就 OK 了，

免得再去重复造轮子不，所以这里就来简单介绍一下这个 SSDT 框架 ~

当然这里谈得 SSDT Hook 框架可不是大伙眼里的什么 .Net 框架啊，MVC 框架啊之类的，

没那么复杂，算到底也就是一个 .cpp 和一个 .h 的文件而已，然后再在其中对外公开几个 API 即 OK 了 ~

这里既是使用了 SSDT 的话，而在前一篇博文中也谈到了在 ntoskrnl.exe 中导出了 KeServiceDescriptorTable，

但是内核中导出归导出，它导出有个屁用啊，别个类型啊什么的都没给你，看你怎么在你代码中使用它 ~

所以我们首先要做的就是如何使用这个 ntoskrnl.exe 中导出的 KeServiceDescriptorTable 了，

不过好在还有 WRK(当然在反汇编，逆向工程里面那些牛的作用也是相当的给力)的帮助，

我们可以定义下面的代码来完成在自己的代码中使用 KeServiceDescriptorTable 这个任务：

1: //=====================================================================================// 2: //Name: KSYSTEM_SERVICE_TABLE 和 KSERVICE_TABLE_DESCRIPTOR // 4: //Descripion: 用来定义 SSDT 结构 // 6: //=====================================================================================// 7: typedef struct _KSYSTEM_SERVICE_TABLE 8: { 9: PULONG ServiceTableBase; // SSDT (System Service Dispatch Table)的基地址 10: PULONG ServiceCounterTableBase; // 包含 SSDT 中每个服务被调用的次数 11: ULONG NumberOfService; // 服务函数的个数, NumberOfService * 4 就是整个地址表的大小 12: ULONG ParamTableBase; // SSPT(System Service Parameter Table)的基地址 13: 14: } KSYSTEM_SERVICE_TABLE, *PKSYSTEM_SERVICE_TABLE; 15: 16: 17: typedef struct _KSERVICE_TABLE_DESCRIPTOR 18: { 19: KSYSTEM_SERVICE_TABLE ntoskrnl; // ntoskrnl.exe 的服务函数 20: KSYSTEM_SERVICE_TABLE win32k; // win32k.sys 的服务函数(GDI32.dll/User32.dll 的内核支持) 21: KSYSTEM_SERVICE_TABLE notUsed1; 22: KSYSTEM_SERVICE_TABLE notUsed2; 23: 24: } KSERVICE_TABLE_DESCRIPTOR, *PKSERVICE_TABLE_DESCRIPTOR; 25: 26: 27: //导出由 ntoskrnl.exe 所导出的 SSDT 28: extern PKSERVICE_TABLE_DESCRIPTOR KeServiceDescriptorTable;

既然是个 SSDT Hook 框架的话，自然需要能够安装 Hook，当然也需要能够解除 Hook，

而我们拿什么来解除 Hook 呢，经过前面的介绍，我们可以知道的是，

SSDT Hook 其实就是拿我们自己的 Hook 函数的地址去替换掉原来 SSDT 中保存的系统服务的地址，

如果 Hook 了某个 API，那就意味着在 SSDT 中指定索引处所保存的系统服务的地址被修改为了 Hook 函数的地址，

而如果要解除这个 API 的 Hook，自然就需要将原来系统中原有的系统服务的地址写回 SSDT 指定索引处，

但是我们拿什么来保存 SSDT Hook 之前的系统服务的地址呢 ?

由于在 32 位机器上，一个入口地址可以用 32 位来表示，也就可以使用一个 ULONG 类型来保存，

而由于我们这个是 SSDT 框架，也就是能够随意的 Hook SSDT 中的任意系统服务，

自然为了能成功实现 Hook 的解除，就需要将 SSDT 中在 Hook 之前的每一个系统服务的地址保存下来，

根据上面的总结，这可以通过一个 ULONG 数组来保存就可以了 ~

然后再在 Hook 任意的系统服务之前，将 SSDT 中的所有系统服务的地址保存或者说是备份到 ULONG 数组中即可 ~

而后在解除 Hook 时，我们就可以从这个 ULONG 数组中取出原有系统服务的地址，

然后将地址写入到 SSDT 中即可实现 Hook 解除 ~

1: //定义 SSDT(系统服务描述表) 中服务个数的最大数目 2: //这里定义为 1024 个，实际上在 XP SP3 是 0x0128 个 3: #define MAX_SYSTEM_SERVICE_NUMBER 1024 4: 5: //用来保存 SSDT 中所有的旧的服务函数的地址 6: ULONG oldSysServiceAddr[MAX_SYSTEM_SERVICE_NUMBER];

同时由于要实现安装 Hook，解除 Hook，所以自然也要公开两个 API，一个用来安装 Hook，一个用来解除 Hook，

根据上面的这些呢，我们大致可以确定至少需要三个 API：

1: //备份 SSDT 中所有系统服务的地址 2: VOID BackupSysServicesTable(); 3: 4: //安装 Hook 5: NTSTATUS InstallSysServiceHook(ULONG oldService, ULONG newService); 6: 7: //解除 Hook 8: NTSTATUS UnInstallSysServiceHook(ULONG oldService);

然后还需要注意的是，SSDT 中保存的地址不是说你想写就可以写的，

SSDT 在内存中是具有只读属性保护的，如果你想修改 SSDT 中的内容，你必须先要解除只读属性，

也就是要赋予 SSDT 所在的这块内存具有可写属性才行，不然回馈你的将是一个无情的蓝屏(内存写入错误) ~

你给了这块内存可写属性后，你他妈的写完后总的把可写属性去掉，把别个恢复到只读属性吧 ~

不然也太不厚道了，用完就不管了 ~ 所以还需要一个恢复只读属性的 API，

综述，在 SSDT Hook 框架中又有了两个 API：

1: //禁止写入保护，也就是恢复到只读 2: VOID DisableWriteProtect(ULONG oldAttr); 3: 4: //允许写入保护，也就是设置为可写 5: VOID EnableWriteProtect(PULONG pOldAttr);

然后呢下面就将上面的这些个 API 的实现代码给贴出来，个人觉得自己的代码风格还算比较好的，

应该还是看得下去吧(当然这只是我现在的观点，说不准再过段时间回头来看这些代码就会感慨这代码是给人看的嘛) ~

1: #include "SSDTHook.h" 2: 4: //=====================================================================================// 5: //Name: VOID DisableWriteProtect() // 6: // // 7: //Descripion: 用来去掉内存的可写属性，从而实现内存只读 // 8: // // 9: //=====================================================================================// 10: VOID DisableWriteProtect(ULONG oldAttr) 11: { 12: _asm 13: { 14: mov eax, oldAttr 15: mov cr0, eax 16: sti; 17: } 18: } 19: 20: 21: //=====================================================================================// 22: //Name: VOID EnableWriteProtect() // 23: // // 24: //Descripion: 用来去掉内存的只读保护，从而实现可以写内存 // 25: // // 26: //=====================================================================================// 27: VOID EnableWriteProtect(PULONG pOldAttr) 28: { 29: ULONG uAttr; 30: 31: _asm 32: { 33: cli; 34: mov eax, cr0; 35: mov uAttr, eax; 36: and eax, 0FFFEFFFFh; // CR0 16 BIT = 0 37: mov cr0, eax; 38: }; 39: 40: //保存原有的 CRO 属性 41: *pOldAttr = uAttr; 42: } 43: 44: 45: //=====================================================================================// 46: //Name: VOID BackupSysServicesTable() // 47: // // 48: //Descripion: 备份 SSDT 中原有服务的地址，因为在解除 Hook 时需要还原 SSDT 中原有地址 // 49: // // 50: //=====================================================================================// 51: VOID BackupSysServicesTable() 52: { 53: ULONG i; 54: 55: for(i = 0; (i < KeServiceDescriptorTable->ntoskrnl.NumberOfService) && (i < MAX_SYSTEM_SERVICE_NUMBER); i++) 56: { 57: oldSysServiceAddr[i] = KeServiceDescriptorTable->ntoskrnl.ServiceTableBase[i]; 58: //oldSysServiceAddr[i] = *(PULONG)((ULONG)KeServiceDescriptorTable->ntoskrnl.ServiceTableBase + 4 * i); 59: 60: KdPrint(("\Function Information { Number: 0x%04X , Address: %08X}", i, oldSysServiceAddr[i])); 61: } 62: } 63: 64: 65: //=====================================================================================// 66: //Name: NTSTATUS InstallSysServiceHook() // 67: // // 68: //Descripion: 实现 Hook 的安装，主要是在 SSDT 中用 newService 来替换掉 oldService // 69: // // 70: //=====================================================================================// 71: NTSTATUS InstallSysServiceHook(ULONG oldService, ULONG newService) 72: { 73: ULONG uOldAttr = 0; 74: 75: EnableWriteProtect(&uOldAttr); 76: 77: SYSCALL_FUNCTION(oldService) = newService; 78: //KeServiceDescriptorTable->ntoskrnl.ServiceTableBase[SYSCALL_INDEX(oldService)] = newService; 79: 80: DisableWriteProtect(uOldAttr); 81: 82: return STATUS_SUCCESS; 83: } 84: 85: 86: //=====================================================================================// 87: //Name: NTSTATUS UnInstallSysServiceHook() // 88: // // 89: //Descripion: 实现 Hook 的解除，主要是在 SSDT 中用备份下的服务地址来替换掉 oldService // 90: // // 91: //=====================================================================================// 92: NTSTATUS UnInstallSysServiceHook(ULONG oldService) 93: { 94: ULONG uOldAttr = 0; 95: 96: EnableWriteProtect(&uOldAttr); 97: 98: SYSCALL_FUNCTION(oldService) = oldSysServiceAddr[SYSCALL_INDEX(oldService)]; 100: 101: DisableWriteProtect(uOldAttr); 102: 103: return STATUS_SUCCESS; 104: }

可以注意到上面有两个很重要的宏，即 SYSCALL_FUNCTION 和 SYSCALL_INDEX 宏，

关于这两个宏的具体作用，可以看注释的 ~

1: //根据 Zw_ServiceFunction 获取 Zw_ServiceFunction 在 SSDT 中所对应的服务的索引号 2: #define SYSCALL_INDEX(ServiceFunction) (*(PULONG)((PUCHAR)ServiceFunction + 1)) 3: 4: 5: //根据 Zw_ServiceFunction 来获得服务在 SSDT 中的索引号， 6: //然后再通过该索引号来获取 Nt_ServiceFunction的地址 7: #define SYSCALL_FUNCTION(ServiceFunction) 8: KeServiceDescriptorTable->ntoskrnl.ServiceTableBase[SYSCALL_INDEX(ServiceFunction)]

4. Ring0 实现进程隐藏：

有了 SSDT Hook 框架后，其实要实现进程的隐藏是很简单的了，

根据前面的介绍，要想实现进程隐藏，你可以通过 Hook NtQuerySystemInformation 来实现，

所以剩下的任务就只需要在我们自己的 Hook 处理函数中来将进程隐藏掉就 OK 了 ~

由于 NtQuerySystemInformation 这个系统服务在 ntddk.h 中并没有被声明，

虽然这个系统服务在 ntoskrnl.exe 中被导出了，但是没有它的声明，我们仍然是无法使用的，

所以我们就需要手动的声明一下这个函数 ~

还有需要注意的是，我们在前面知道，在 ntoskrnl.exe 中实质上是存在 ZwQuerySystemInformation

以及 NtQuerySystemInformation 这两个 API 的，

而在 SSDT Hook 中我们是根据 ZwQuerySystemInformation

来推算出在 SSDT 中保存有 NtQuerySystemInformation 的地址所在的索引号的 ~

关于这个，你可以查看 SYSCALL_INDEX 这个宏来再次确认一下 ~

然后有了这个索引号，我们才可以进行对 NtQuerySystemInformation 系统服务的 Hook，

所以在声明时，我们需要声明两个 API，当然如果这些 API 在 ntddk.h 中声明了就不需要了，

但是由于 ZwQuerySystemInformation 和 NtQuerySystemInformation 在 ntddk.h 中都没有声明，

所以需要在我们自己的代码中手动声明 ~

1: NTSYSAPI NTSTATUS NTAPI ZwQuerySystemInformation ( 2: __in SYSTEM_INFORMATION_CLASS SystemInformationClass, 3: __out_bcount_opt(SystemInformationLength) PVOID SystemInformation, 4: __in ULONG SystemInformationLength, 5: __out_opt PULONG ReturnLength 6: ); 7: 8: typedef NTSTATUS (* NTQUERYSYSTEMINFORMATION)( 9: __in SYSTEM_INFORMATION_CLASS SystemInformationClass, 10: __out_bcount_opt(SystemInformationLength) PVOID SystemInformation, 11: __in ULONG SystemInformationLength, 12: __out_opt PULONG ReturnLength 13: );

(暂停一下，肚子饿了 ~ 吃饭去 ~ )

(好，饭给吃了，酒也喝了，精神亢奋中，现在咱继续哈 ~ 嘿嘿 ~)

完成了这些声明后，我们就可以来实现自己的 NtQuerySystemInformation Hook 函数了，

在这个 Hook 函数中，我们需要对我们感兴趣的进程进行隐藏 ~

然后这里需要注意的是，我是如何来实现对进程隐藏的，

首先我是判断这个进程的 ID 是否是需要隐藏的进程 ID，

这是通过 ValidateProcessNeedHide 函数来判断的 ~ 这个函数会在后面给出 ~

注意结合代码中的注释来看(虽然注释比较少 ~ 嘿嘿 ~ )

1: NTSTATUS HookNtQuerySystemInformation ( 2: __in SYSTEM_INFORMATION_CLASS SystemInformationClass, 3: __out_bcount_opt(SystemInformationLength) PVOID SystemInformation, 4: __in ULONG SystemInformationLength, 5: __out_opt PULONG ReturnLength 6: );

1: //=====================================================================================// 2: //Name: NTSTATUS HookNtQuerySystemInformation() // 3: // // 4: //Descripion: 自定义的 NtQuerySystemInformation，用来实现 Hook Kernel API // 5: // // 6: //=====================================================================================// 7: NTSTATUS HookNtQuerySystemInformation ( 8: __in SYSTEM_INFORMATION_CLASS SystemInformationClass, 9: __out_bcount_opt(SystemInformationLength) PVOID SystemInformation, 10: __in ULONG SystemInformationLength, 11: __out_opt PULONG ReturnLength 12: ) 13: { 14: NTSTATUS rtStatus; 15: 16: pOldNtQuerySystemInformation = (NTQUERYSYSTEMINFORMATION) 17: oldSysServiceAddr[SYSCALL_INDEX(ZwQuerySystemInformation)]; 18: 19: rtStatus = pOldNtQuerySystemInformation(SystemInformationClass, SystemInformation, 20: SystemInformationLength, ReturnLength); 21: if(NT_SUCCESS(rtStatus)) 22: { 23: if(SystemProcessInformation == SystemInformationClass) 24: { 25: PSYSTEM_PROCESS_INFORMATION pPrevProcessInfo = NULL; 26: PSYSTEM_PROCESS_INFORMATION pCurrProcessInfo = 27: (PSYSTEM_PROCESS_INFORMATION)SystemInformation; 28: 29: while(pCurrProcessInfo != NULL) 30: { 31: //获取当前遍历的 SYSTEM_PROCESS_INFORMATION 节点的进程名称和进程 ID 32: ULONG uPID = (ULONG)pCurrProcessInfo->UniqueProcessId; 33: UNICODE_STRING strTmpProcessName = pCurrProcessInfo->ImageName; 34: 35: //判断当前遍历的这个进程是否为需要隐藏的进程 36: if(ValidateProcessNeedHide(uPID) != -1) 37: { 38: if(pPrevProcessInfo) 39: { 40: if(pCurrProcessInfo->NextEntryOffset) 41: { 42: //将当前这个进程(即要隐藏的进程)从 SystemInformation 中摘除(更改链表偏移指针实现) 43: pPrevProcessInfo->NextEntryOffset += pCurrProcessInfo->NextEntryOffset; 44: } 45: else 46: { 47: //说明当前要隐藏的这个进程是进程链表中的最后一个 48: pPrevProcessInfo->NextEntryOffset = 0; 49: } 50: } 51: else 52: { 53: //第一个遍历到得进程就是需要隐藏的进程 54: if(pCurrProcessInfo->NextEntryOffset) 55: { 56: (PCHAR)SystemInformation += pCurrProcessInfo->NextEntryOffset; 57: } 58: else 59: { 60: SystemInformation = NULL; 61: } 62: } 63: } 64: 65: //遍历下一个 SYSTEM_PROCESS_INFORMATION 节点 66: pPrevProcessInfo = pCurrProcessInfo; 67: 68: //遍历结束 69: if(pCurrProcessInfo->NextEntryOffset) 70: { 71: pCurrProcessInfo = (PSYSTEM_PROCESS_INFORMATION) 72: (((PCHAR)pCurrProcessInfo) + pCurrProcessInfo->NextEntryOffset); 73: } 74: else 75: { 76: pCurrProcessInfo = NULL; 77: } 78: } 79: } 80: } 81: return rtStatus; 82: }

既然有了自己的 Hook NtQuerySystemInformation 了，自然我们就可以通过利用 SSDT 框架来实现 Hook 了，

这部分的代码其实是最简单的，因为我只需要在 DriverEntry 中 Hook 掉 NtQuerySystemInformation 即可，

这里需要注意的是，在执行 Hook 之前需要备份一次 SSDT，即在 DriverEntry 中最先需要备份 SSDT ~

当然为了保证系统的安全以及其他诸多方面，我们在 DriverUnload 中会将 Hook 解除掉 ~

从下面的代码中，我们看到在安装 Hook 和解除 Hook 时参数传递进去的是 ZwQuerySystemInformation，

这样很有可能会让很多朋友认为我们在 Ring0 下的 Hook 的是 ZwQuerySystemInformation，

如果你这样认为的话，那就大错特错了，确实在 Google 上搜索出的一大堆关于 SSDT Hook 中，

很多文章都说是 Hook 的 ZwQuerySystemInformation，而事实上这是大错特错的，

我们这里传入 ZwQuerySystemInformation ，是因为我们需要调用 SYS_INDEX(ZwQuerySystemInformation)

来获得 NtQuerySystemInformation 在 SSDT 中的地址所在的索引号，

然后我们根据这个索引号来 Hook NtQuerySystemInformation，

认识到这一点是非常重要的，因为我一开始也认为是 Hook 的 ZwQuerySystemInformation，

从而导致蓝屏了 n 次，在这里非常鄙视那些把文章从别处拷贝过来也不加验证就乱发表的 ~ 害死人 ~ 当然也要怪自己懒 ~

5. Ring0 实现进程保护：

有了上面实现进程隐藏的基础，要再来实现进程保护，其实也就是过过场子了 ~

进程保护呢，上面也说了，是要 Hook NtTermianteProcess 这个系统服务 ~

由于 ZwTerminateProcess 呢，在 ntddk.h 中已经声明了，

所以在我们自己的代码中就不需要声明 ZwTermianteProcess 了，

而只需要声明 NtTerminateProcess 以及 Hook 函数就 OK 了 ~

1: typedef NTSTATUS (* NTTERMINATEPROCESS)( 2: __in_opt HANDLE ProcessHandle, 3: __in NTSTATUS ExitStatus 4: ); 5: 6: NTSTATUS HookNtTerminateProcess( 7: __in_opt HANDLE ProcessHandle, 8: __in NTSTATUS ExitStatus 9: ); 10: 11: NTTERMINATEPROCESS pOldNtTerminateProcess;

至于安装 Hook 以及卸载 Hook ，都可以根据进程隐藏中的代码来完成，因为有了 SSDT Hook 框架，

这一切也就变得很简单了，只要在 DriverEntry 中 InstallHook ，然后再在 DriverUnload 中 UnInstallHook 即 OK ~

下面我们重点来看一看我们自己的 Hook NtTerminateProcess 中是如何实现进程保护的 ~

进程保护呢其实也是比较简单的，因为从上面一层的调用会传递一个进程句柄下来，

而后我们可以根据这个进程句柄来获得进程的 EPROCESS 对象(进程位于执行体层得对象)，

通过这个 EPROCESS 对象，我们就可以获得这个请求被结束的进程的 PID，

我们再判断这个 PID 是否是我们已经保护了的 PID，如果是的话，直接返回一个请求被拒绝即可，

而如果这个 PID 未被保护，自然我们就交给原来的 NtTerminateProcess 处理即可 ~

1: //=====================================================================================// 2: //Name: NTSTATUS HookNtTerminateProcess() // 3: // // 4: //Descripion: 自定义的 NtTerminateProcess，用来实现 Hook Kernel API // 5: // // 6: //=====================================================================================// 7: NTSTATUS HookNtTerminateProcess( 8: __in_opt HANDLE ProcessHandle, 9: __in NTSTATUS ExitStatus 10: ) 11: { 12: ULONG uPID; 13: NTSTATUS rtStatus; 14: PCHAR pStrProcName; 15: PEPROCESS pEProcess; 16: ANSI_STRING strProcName; 17: 18: //通过进程句柄来获得该进程所对应的 FileObject 对象，由于这里是进程对象，自然获得的是 EPROCESS 对象 19: rtStatus = ObReferenceObjectByHandle(ProcessHandle, 20: FILE_READ_DATA, NULL, KernelMode, &pEProcess, NULL); 21: if(!NT_SUCCESS(rtStatus)) 22: { 23: return rtStatus; 24: } 25: 26: //保存 SSDT 中原来的 NtTerminateProcess 地址 27: pOldNtTerminateProcess = 28: (NTTERMINATEPROCESS)oldSysServiceAddr[SYSCALL_INDEX(ZwTerminateProcess)]; 29: 30: //通过该函数可以获取到进程名称和进程 ID，该函数在内核中实质是导出的(在 WRK 中可以看到) 31: //但是 ntddk.h 中并没有到处，所以需要自己声明才能使用 32: uPID = (ULONG)PsGetProcessId(pEProcess); 33: pStrProcName = (PCHAR)PsGetProcessImageFileName(pEProcess); 34: 35: //通过进程名来初始化一个 ASCII 字符串 36: RtlInitAnsiString(&strProcName, pStrProcName); 37: 38: if(ValidateProcessNeedProtect(uPID) != -1) 39: { 40: //确保调用者进程能够结束(这里主要是指 taskmgr.exe) 41: if(uPID != (ULONG)PsGetProcessId(PsGetCurrentProcess())) 42: { 43: //如果该进程是所保护的的进程的话，则返回权限不够的异常即可 44: return STATUS_ACCESS_DENIED; 45: } 46: } 47: 48: //对于非保护的进程可以直接调用原来 SSDT 中的 NtTerminateProcess 来结束进程 49: rtStatus = pOldNtTerminateProcess(ProcessHandle, ExitStatus); 50: 51: return rtStatus; 52: }

6. 隐藏进程列表和保护进程列表的维护：

由于需要隐藏的进程以及需要被保护的进程都是由应用程序传递进来的，

也就是说这个内核程序是需要和应用程序通信的，自然就需要创建一个 Device，

然后我就采用了简单的 DeviceIoControl 来实现了内核程序和应用程序的通信，

对于需要隐藏的进程或者是需要保护的进程，其由应用程序通过 DeviceIoControl 来将这个进程的 PID 传递给内核程序，

然后在内核程序中呢，维护了两个数组，一个数组用来存放需要隐藏的进程的 PID，

另外一个数组自然就是用来存放需要保护的进程的 PID，

1: ULONG g_PIDHideArray[MAX_PROCESS_ARRARY_LENGTH]; 2: ULONG g_PIDProtectArray[MAX_PROCESS_ARRARY_LENGTH]; 3: 4: ULONG g_currHideArrayLen = 0; 5: ULONG g_currProtectArrayLen = 0;

为了维护上面的这两个数组呢，又衍生出了几个 API，即实现对数组中的 PID 进行增删查 ~

1: //验证 uPID 所代表的进程是否存在于隐藏进程列表中，即判断 uPID 这个进程是否需要隐藏 2: ULONG ValidateProcessNeedHide(ULONG uPID); 3: 4: //验证 uPID 所代表的进程是否存在于保护进程列表中，即判断 uPID 这个进程是否需要保护 5: ULONG ValidateProcessNeedProtect(ULONG uPID); 6: 7: //往隐藏进程列表中插入 uPID 8: ULONG InsertHideProcess(ULONG uPID); 9: 10: //从隐藏进程列表中移除 uPID 11: ULONG RemoveHideProcess(ULONG uPID); 12: 13: //往保护进程列表中插入 uPID 14: ULONG InsertProtectProcess(ULONG uPID); 15: 16: //从隐藏进程列表中移除 uPID 17: ULONG RemoveProtectProcess(ULONG uPID);

对于前面谈及的 HookNtQuerySystemInformation 和 HookNtTerminateProcess 的话，

需要判断一个进程是否是需要被保护或者需要被隐藏的进程就是通过上面的数组来完成的，

即判断一个进程是否需要被隐藏时，只需要判断这个进程在隐藏列表中是否存在即可，

而对于实现进程保护的话，道理也是一样的 ~

上面说过，应用程序和内核程序的通信是通过 DeviceIoControl 来完成的，

下面我们就来看看 DeviceIoControl 的代码：

1: //=====================================================================================// 2: //Name: NTSTATUS SSDT01DeviceIoControlDispatcher() // 3: // // 4: //Descripion: 分发函数 // 5: // // 6: //=====================================================================================// 7: NTSTATUS SSDT01DeviceIoControlDispatcher(IN PDEVICE_OBJECT pDeviceObject, IN PIRP pIrp) 8: { 9: NTSTATUS rtStatus; 10: 11: ULONG uPID; 12: ULONG uInLen; 13: ULONG uOutLen; 14: ULONG uCtrlCode; 15: 16: PCHAR pInBuffer; 17: 18: PIO_STACK_LOCATION pStack; 19: 20: uPID = 0; 21: rtStatus = STATUS_SUCCESS; 22: pStack = IoGetCurrentIrpStackLocation(pIrp); 23: 24: uInLen = pStack->Parameters.DeviceIoControl.InputBufferLength; 25: uOutLen = pStack->Parameters.DeviceIoControl.OutputBufferLength; 26: uCtrlCode = pStack->Parameters.DeviceIoControl.IoControlCode; 27: 28: //使用缓冲区方式与应用程序进行通信 29: pInBuffer = (PCHAR)pIrp->AssociatedIrp.SystemBuffer; 30: 31: if(uInLen >= 4) 32: { 33: //stdlib.h(atol = Array To LONG) 34: uPID = atol(pInBuffer); 35: 36: switch(uCtrlCode) 37: { 38: case IO_INSERT_PROTECT_PROCESS: 39: { 40: if(InsertProtectProcess(uPID) == FALSE) 41: { 42: rtStatus = STATUS_PROCESS_IS_TERMINATING; 43: } 44: break; 45: } 46: case IO_REMOVE_PROTECT_PROCESS: 47: { 48: if(RemoveProtectProcess(uPID) == FALSE) 49: { 50: rtStatus = STATUS_PROCESS_IS_TERMINATING; 51: } 52: break; 53: } 54: case IO_INSERT_HIDE_PROCESS: 55: { 56: if(InsertHideProcess(uPID) == FALSE) 57: { 58: rtStatus = STATUS_PROCESS_IS_TERMINATING; 59: } 60: break; 61: } 62: case IO_REMOVE_HIDE_PROCESS: 63: { 64: if(RemoveHideProcess(uPID) == FALSE) 65: { 66: rtStatus = STATUS_PROCESS_IS_TERMINATING; 67: } 68: break; 69: } 70: default: 71: { 72: rtStatus = STATUS_INVALID_VARIANT; 73: break; 74: } 75: } 76: } 77: else 78: { 79: rtStatus = STATUS_INVALID_PARAMETER; 80: } 81: 82: //输出信息总是为空，即该驱动程序不返回输出信息 83: pIrp->IoStatus.Status = rtStatus; 84: pIrp->IoStatus.Information = 0; 85: IoCompleteRequest(pIrp, IO_NO_INCREMENT); 86: 87: return rtStatus; 88: }

7. 小结：

这篇博文呢，是承接前一篇博文《进程隐藏与进程保护(SSDT Hook 实现)(一)》来的，

前面的博文主要介绍了 SSDT 是个什么东西，以及我们做内核 Hook 的一些基础，

而这篇博文则完整的介绍了 SSDT Hook 的具体实现，其中涉及到了很多底层的知识的，

对于绝大部分的代码呢，大伙是可以参考代码来进行理解的，而后我会将内核部分的代码先公开出来 ~

本来呢是打算将这个 SSDT Hook 做两篇博文就给结束得了，

不过第二篇博文写了这么长了，但是在应用程序中的实现都还没有开始介绍，

而今晚真的又太晚了，再写下去天就亮了，还说要尽量不熬夜的 ~ 唉 ~ 算了，权当周末给自己找个借口吧 ~

下一篇博文将介绍的是如何在应用程序中获取到所有的进程啊，以及应用程序如何和内核程序设备进行通信之类的知识，

知识重点是放在 Ring3 了，其中不会涉及到很多 Ring0 的内容了 ~

开发工具以及环境搭建：

Visual Studio 2010 + VirtualDDK + WDK + VMware + Windows Service 2003 SP1，至于具体环境的搭建，

可以参考我的博文《驱动程序环境搭建(VS2010 + WDK + VirtualDDK + VMware)》，博文地址如下：

http://www.cnblogs.com/BoyXiao/archive/2011/07/31/2122755.html

下载 SSDT Hook Source Code

和前一篇文章一样，我将我近来遇到的一些疑问放到博文的最后面，看是否有看官遇到过，如果有遇到过的，

还请不吝赐教 ~ 在下感激不尽 ~

疑问 1：

在 .Net WinForm 中，我有一个定时器，然后又有一个按钮，

那么对应的就有一个定时器 Tick 处理事件，按钮也会有一个 Click 事件，

考虑在多核处理器上，有没有这样一种可能，按钮的 Click 事件和 Tick 处理事件并发执行 ?

如果有的话，大伙一般都是如何做处理的 ?

疑问 2：

大家都有用过 SVN 的，当我们安装好客户端工具 TortoiseSVN 后，

每次启动 PC ，均会有一个 TSVNCache.exe 的进程随 PC 自动启动，

请教一下大家这个进程是如何启动的 ?

本文链接

进程隐藏与进程保护（SSDT Hook 实现）（一）

2011-09-03T00:17:00Z

文章目录：

1. 引子 – Hook 技术：

2. SSDT 简介：

3. 应用层调用 Win32 API 的完整执行流程：

4. 详解 SSDT：

5. SSDT Hook 原理：

6. 小结：

1. 引子 – Hook 技术：

前面一篇博文呢介绍了代码的注入技术(远程线程实现)，博文地址如下：

http://www.cnblogs.com/BoyXiao/archive/2011/08/11/2134367.html

虽然代码注入是很老的技术了，但是这种技术也还是比较常见，

当然也比较好用的，比如在 Spy++ 中就使用了远程线程注入技术，

同时，如果有兴趣的阅读过 Spy++ 的源码的朋友，当然也可以在其源码中阅读到关于远程线程注入技术了。

（这篇博文虽然我会截断分为两篇博文撰写，但是博文仍然会比较长，内容其实是比较多的，覆盖面也比较广，

需要有一定耐心和基础方可阅读完，有兴趣者请自备茶水以及零食，然后慢慢阅读全文，

PS：这话引用自园子里某位园友）

（然后的话就是漫漫长夜，心情不佳，于是写了篇博文，刚好又喝了点，所以估计会有些许疏漏之处，还请见谅 ~）

在这一篇博文中呢，介绍的是一种 Hook 技术，对于 Hook 技术，可以分为两块，

第一块是在 Ring3 层的 Hook，俗称应用层 Hook 技术，

而另外一块自然是在 Ring0 层得 Hook，俗称为内核层 Hook 技术，

而在 Ring3 层的 Hook 基本上可以分为两种大的类型，

第一类即是 Windows 消息的 Hook，第二类则是 Windows API 的 Hook。

关于 Hook 的几种类型呢，下面给出几个简洁的图示：

关于 Windows 消息的 Hook，相信很多朋友都有接触过的，因为一个 SetWindowsHookEx 即可以完成消息 Hook，

在这里简要介绍一下消息 Hook，消息 Hook 是通过 SetWindowsHookEx 可以实现将自己的钩子插入到钩子链的最前端，

而对于发送给被 Hook 的窗口(也有可能是所有的窗口，即全局 Hook)的消息都会被我们的钩子处理函数所捕获到，

也就是我们可以优先于窗体先捕获到这些消息，Windows 消息 Hook 可以实现为进程内消息 Hook 和全局消息 Hook，

对于进程内消息 Hook，则可以简单的将 Hook 处理函数直接写在这个进程内，即是自己 Hook 自己，

而对于用途更为广泛的全局消息 Hook，则需要将 Hook 处理函数写在一个 DLL 中，

这样才可以让你的处理函数被所有的进程所加载(进程自动加载包含 Hook 消息处理函数的 DLL)。

对于 Windows 消息 Hook 呢，可以有个简单的邪恶应用，就是记录键盘按键消息，

从而达到监视用户输入的键值信息的目的，这样，对于一些简单的用户通过键盘输入的密码就可以被 Hook 获取到，

因为没当用户按下一个键时，Windows 都会产生一个按键消息(当然有按下，弹起等消息的区分)，

然后我们可以 Hook 到这个按键消息，这样就可以在 Hook 的消息处理函数中获取到用户按下的是什么键了。

当然关于消息 Hook 的话，其不是这篇博文的重点，

这篇博文主要介绍的是 SSDT Hook 技术，即内核 Hook 技术的一种，

这种技术呢，也是比较老的技术了，貌似是当年 Rootkit 起火的时候出来的，

但是 SSDT Hook 现在也还比较流行，比如在很多的杀毒软件或者安全软件里面也都会使用到 SSDT Hook 技术。

关于内核 Hook 也有几种类型，下面也给出一副图示：

上面的几种内核级 Hook 技术，在看雪啊，debugman，xfocus 上都有很多的介绍，

而我只不过是落后这些技术很多年的小辈后生，在这里也只是将自己的学习以及一些总结的经验给列出来而已，

如果有兴趣想深入了解这些内容的话，完全可以在看雪上找到资料 ~

2. SSDT 简介：

以下介绍来自百度(PS:被百度文库弄去了很多博文，这里也抄它一下)：

SSDT 的全称是 System Services Descriptor Table，系统服务描述符表。

这个表就是一个把 Ring3 的 Win32 API 和 Ring0 的内核 API 联系起来。

SSDT 并不仅仅只包含一个庞大的地址索引表，它还包含着一些其它有用的信息，诸如地址索引的基地址、服务函数个数等。

通过修改此表的函数地址可以对常用 Windows 函数及 API 进行 Hook，从而实现对一些关心的系统动作进行过滤、监控的目的。

一些 HIPS、防毒软件、系统监控、注册表监控软件往往会采用此接口来实现自己的监控模块。

在 NT 4.0 以上的 Windows 操作系统中，默认就存在两个系统服务描述表，这两个调度表对应了两类不同的系统服务，

这两个调度表为：KeServiceDescriptorTable 和 KeServiceDescriptorTableShadow，

其中 KeServiceDescriptorTable 主要是处理来自 Ring3 层得 Kernel32.dll 中的系统调用，

而 KeServiceDescriptorTableShadow 则主要处理来自 User32.dll 和 GDI32.dll 中的系统调用，

并且 KeServiceDescriptorTable 在 ntoskrnl.exe(Windows 操作系统内核文件，包括内核和执行体层)是导出的，

而 KeServiceDescriptorTableShadow 则是没有被 Windows 操作系统所导出，

而关于 SSDT 的全部内容则都是通过 KeServiceDescriptorTable 来完成的 ~

从下面的截图可以看出 KeServiceDescriptorTable 在 ntoskrnl.exe 中被导出：

然后我们再来看看在 Windows 操作系统的源码 WRK 中，KeServiceDescriptorTable 是怎么被定义的 ~

首先来看 KeServiceDescriptorTable 是如何被 Windows 操作系统源码给导出的：

从下面的截图可以看出，这个系统服务描述表是在 WRK 源码中的某一个模块划分文件(.def)中所导出的。

关于 WRK 是什么东西 ? 则可以参阅我的另一篇博文《Windows 内核(WRK)简介》，博文地址如下：

http://www.cnblogs.com/BoyXiao/archive/2011/01/08/1930904.html

而在 Windows 源码 WRK 中对于系统服务描述符表的代码定义如下(KeServiceDecriptorTable 即由该结构定义)：

上面的这个结构定义在成员变量的名称上还看不出什么名堂，下面给出我们将在自己代码中所使用的结构体：

1: typedef struct _KSYSTEM_SERVICE_TABLE 2: { 3: PULONG ServiceTableBase; // SSDT (System Service Dispatch Table)的基地址 4: PULONG ServiceCounterTableBase; // 用于 checked builds, 包含 SSDT 中每个服务被调用的次数 5: ULONG NumberOfService; // 服务函数的个数, NumberOfService * 4 就是整个地址表的大小 6: ULONG ParamTableBase; // SSPT(System Service Parameter Table)的基地址 7: 8: } KSYSTEM_SERVICE_TABLE, *PKSYSTEM_SERVICE_TABLE; 9: 10: typedef struct _KSERVICE_TABLE_DESCRIPTOR 11: { 12: KSYSTEM_SERVICE_TABLE ntoskrnl; // ntoskrnl.exe 的服务函数 13: KSYSTEM_SERVICE_TABLE win32k; // win32k.sys 的服务函数(GDI32.dll/User32.dll 的内核支持) 14: KSYSTEM_SERVICE_TABLE notUsed1; 15: KSYSTEM_SERVICE_TABLE notUsed2; 16: 17: } KSERVICE_TABLE_DESCRIPTOR, *PKSERVICE_TABLE_DESCRIPTOR; 18: 19: //导出由 ntoskrnl.exe 所导出的 SSDT 20: extern PKSERVICE_TABLE_DESCRIPTOR KeServiceDescriptorTable;

有了上面的介绍后，我们可以简单的将 KeServiceDescriptor 看做是一个数组了(其实质也就是个数组)，

在应用层 ntdll.dll 中的 API 在这个系统服务描述表(SSDT)中都存在一个与之相对应的服务，

当我们的应用程序调用 ntdll.dll 中的 API 时，最终会调用内核中与之相对应的系统服务，

由于有了 SSDT，所以我们只需要告诉内核需要调用的服务所在 SSDT 中的索引就 OK 了，

然后内核根据这个索引值就可以在 SSDT 中找到相对应的服务了，然后再由内核调用服务完成应用程序 API 的调用请求即可。

基本结构可以参考下图：

3. 应用层调用 Win32 API 的完整执行流程：

有了上面的 SSDT 基础后，我们再来看一下在应用层调用 Win32 API(这里主要指的是 ntdll.dll 中的 API)的完整流程，

这里我们主要是分析 ntdll.dll 中的 NtQuerySystemInformation 这个 API 的调用流程，

(PS:Windows 任务管理器即是通过这个 API 来获取到系统的进程等等信息的)。

先给出一副图示(先记住这里有四个类似的 API，但是必须得注意区分开来，弄混淆了就麻烦大了)：

再给出这些个 API 的基本的调用流程(让大伙有个印象，至少不会迷失)：

首先，使用 PE 工具来打开 ntdll.dll 文件，可以看到 NtQuerySystemInformation，

除了 NtQuerySystemInformation 外，同时还可以看到 ZwQuerySystemInformation，

而实质上，在 Windows 操作系统中，

Ntdll.dll 中的ZwQuerySystemInformation 和 NtQuerySystemInformation 是同一函数，

可以通过下面的截图看出，这两个函数的入口地址指向同一区域，他们的函数入口地址都是一样的 ~

很奇怪吧 ~ 其实我也觉得奇怪 ~ 何必多此一举呢 ~

众所周知 Ntdll.dll 中的 API 都只不过是一个简单的包装函数而已，

当 Kernel32.dll 中的 API 通过 Ntdll.dll 时，会完成参数的检查，

再调用一个中断(int 2Eh 或者 SysEnter 指令)，从而实现从 Ring3 进入 Ring0 层，

并且将所要调用的服务号(也就是在 SSDT 数组中的索引值)存放到寄存器 EAX 中，

并且将参数地址放到指定的寄存器(EDX)中，再将参数复制到内核地址空间中，

再根据存放在 EAX 中的索引值来在 SSDT 数组中调用指定的服务 ~

经过上面的步骤后，便由 Ring3 层进入了 Ring0 层，

我们再通过 PE 工具来查看 ntoskrnl.exe 中的 ZwQuerySystemInformation 和 NtQuerySystemInformation

先来看 ntoskrnl.exe 中的 ZwQuerySystemInformation：

在上面的这幅截图中，可以看到在 Ring0 下的 ZwQuerySystemInformation 将 0ADh 放入了寄存器 eax 中，

然后调用了系统服务分发函数 KiSystemService，而这个 KiSystemService 函数则是根据 eax 寄存器中的索引值，

然后再 SSDT 数组中找到索引值为 eax 寄存器中存放的值得那个 SSDT 项，

最后就是根据这个 SSDT 项中所存放的系统服务的地址来调用这个系统服务了 ~

比如在这里就是调用 KeServiceDescriptorTable[0ADh] 处所保存的地址所对应的系统服务了 ~

也就是调用 Ring0 下的 NtQuerySystemInformation 了 ~

至此，在应用层中调用 NtQuerySystemInformation 的全部流程也就结束了 ~

最后，贴出一点在 Ring0 下的 NtQuerySystemInformation 的反汇编代码：

4. 详解 SSDT：

在这一节里面，我们将来看看 SSDT 到底是个什么东西 ~ 这里使用 WinDbg 来调试 XP SP2 系统 ~

首先来看看 KeServiceDescriptorTable 是何物 ?

从下面的截图中可以看到 KeServiceDesciptorTable 的首地址为 804e58a0，

然后查看分析这个地址，可以查看到第一个系统服务的入口地址为 80591bfb ！

我们再来看看 80591bfb 这个地址对应的究竟是何系统服务 ?

从下面的截图中，可以看到 SSDT 中第一个系统服务就是 NtAcceptConnectPort !!!

由于我们知道了 SSDT 的首地址，又知道了 Ring0 下 NtQuerySystemInformation 服务的索引号，

所以可以根据 “SSDT 中系统服务地址所在的 Address = SSDT 首地址 + 4 * 索引号”,

推算出 NtQuerySystemInformation 服务的地址，

因此有 Address = 804e58a0 + 4 * 0adh = 804E5B54；

然后我们再来看 804E5B54 这个地址的信息，信息如下截图：

从截图中，我们可以看到 NtQuerySystemInformation 的起始地址为 80586ff1，

下面就来验证一下地址 80586ff1 到底是不是 NtQuerySystemInformation 的首地址 ~

从下面的截图中可以肯定 80586ff1 确实就是 NtQuerySystemInformation 的首地址，

这和我们上面对 SSDT 中指定索引号的服务的地址的计算公式计算出来的结果是统一的 !!!

从上面的介绍，可以看出，其实 SSDT 就是一个用来保存 Windows 系统服务地址的数组而已 !!!

5. SSDT Hook 原理：

有了上面的这部分基础后，就可以来看 SSDT HOOK 的原理了，

其实 SSDT Hook 的原理是很简单的，从上面的分析中，

我们可以知道在 SSDT 这个数组中呢，保存了系统服务的地址，

比如对于 Ring0 下的 NtQuerySystemInformation 这个系统服务的地址，

就保存在 KeServiceDescriptorTable[0ADh] 中，

既然是 Hook 的话，我们就可以将这个 KeServiceDescriptorTable[0ADh] 下保存的服务地址替换掉，

将我们自己的 Hook 处理函数的地址来替换掉原来的地址，

这样当每次调用 KeServiceDescriptorTable[0ADh]时就会调用我们自己的这个 Hook 处理函数了。

下面用几幅截图来表示：

下面的截图则是 SSDT Hook 之后了，可以看到将 SSDT 中的服务地址修改为 MyHookNtQuerySystemInformation 了，

这样的话，每次系统调用 NtQuerySystemInformation 这个系统服务时，

实质上调用的就是 MyHookNtQuerySystemInformation 了，而我们为了保证系统的稳定性(至少不让其崩溃)，

一般会在 MyHookNtQuerySystemInformation 中调用系统中原来的服务，也就是 NtQuerySystemInformation。

6. 小结：

本篇博文呢尚还只是介绍了 SSDT 到底是个什么东西，而还没有给出具体的 SSDT Hook 的实现，

对于 SSDT Hook 的实现以及 Demo 我都放到(二)中完成，也就是本篇博文未完 , 待续 ……

关于 SSDT 的话，在看雪上有很多的文章，由于我也是前阵子对这东西突然感兴趣了，

所以我也算是初次了解，自然也看过了很多的文章，SSDT 在 Google 一搜索可以出来一大堆，

但是要说介绍 SSDT 最详细的话，我想还是我的这篇文章介绍的比较详细，

因为网上很多介绍 SSDT 的都只是将 SSDT 原理做了简单的介绍，然后在网上 down 一个 Demo，

把代码贴出来就完事了，甚至是代码都还无法完整编译通过的，

所以如果读者想对 SSDT 有所了解的话，可以好好看一看这篇文章的 ~

顺便这里还带出一个问题，是我这阵子脑子里突然冒出来的一个疑问，

但是由于时间或者说是个人状态问题，一直没有去研究 ~ 不晓得园子里有木有对这个有研究的 ~

众所周知，在 Windows 操作系统中，System 进程的进程 PID 为 4，

我想问的就是：System 进程的 PID 为何是 4 ?

欢迎大家对这个问题讨论啊 ~ 在这里先给点思路，

那就是可以通过 Windows 操作系统的启动过程，然后结合 WRK 源码进行研究 ~

本文链接