C++博客-Good Good code,Day Day up-文章分类-windows kernel

API Hook基本原理和实现[图文]

pear_li — Fri, 14 Aug 2009 10:28:00 GMT

hook是什么？
windows系统下的编程，消息message的传递是贯穿其始终的。这个消息我们可以简单理解为一个有特定意义的整数，正如我们看过的老故事片中的“长江长江，我是黄河”一个含义。windows中定义的消息给初学者的印象似乎是“不计其数”的，常见的一部分消息在winuser.h头文件中定义。hook与消息有着非常密切的联系，它的中文含义是“钩子”，这样理解起来我们不难得出“hook是消息处理中的一个环节，用于监控消息在系统中的传递，并在这些消息到达最终的消息处理过程前，处理某些特定的消息”。这也是hook分为不同种类的原因。
hook的这个本领，使它能够将自身的代码“融入”被hook住的程序的进程中，成为目标进程的一个部分。我们也知道，在windows2000以后的系统中，普通用户程序的进程空间都是独立的，程序的运行彼此间都不受干扰。这就使我们希望通过一个程序改变其他程序的某些行为的想法不能直接实现，但是hook的出现给我们开拓了解决此类问题的道路。

api hook是什么？
在windows系统下编程，应该会接触到api函数的使用，常用的api函数大概有2000个左右。今天随着控件，stl等高效编程技术的出现，api的使用概率在普通的用户程序上就变得越来越小了。当诸如控件这些现成的手段不能实现的功能时，我们还需要借助api。最初有些人对某些api函数的功能不太满意，就产生了如何修改这些api，使之更好的服务于程序的想法，这样api hook就自然而然的出现了。我们可以通过api hook，改变一个系统api的原有功能。基本的方法就是通过hook“接触”到需要修改的api函数入口点，改变它的地址指向新的自定义的函数。api hook并不属于msdn上介绍的13类hook中的任何一种。所以说，api hook并不是什么特别不同的hook，它也需要通过基本的hook提高自己的权限，跨越不同进程间访问的限制，达到修改api函数地址的目的。对于自身进程空间下使用到的api函数地址的修改，是不需要用到api hook技术就可以实现的。

api hook和pe格式的关系
api hook技术的难点，并不在于hook技术，初学者借助于资料“照葫芦画瓢”能够很容易就掌握hook的基本使用技术。但是如何修改api函数的入口地址？这就需要学习pe可执行文件（.exe，.dll等）如何被系统映射到进程空间中，这就需要学习pe格式的基本知识。windows已经提供了很多数据结构struct帮助我们访问pe格式，借助它们，我们就不要自己计算格式的具体字节位置这些繁琐的细节。但是从api hook的实现来看，pe格式的访问部分仍然是整个编程实现中最复杂的一部分，对于经常crack的朋友不在此列。
假设我们已经了解了pe格式，那么我们在哪里修改api的函数入口点比较合适呢？这个就是输入符号表imported symbols table（间接）指向的输入符号地址。
下面对于pe格式的介绍这一部分，对于没有接触过pe格式学习的朋友应该是看不太明白的，但我已经把精华部分提取出来了，学习了pe格式后再看这些就很容易了。

pe格式的基本组成
+-------------------+
| DOS-stub    | --DOS-头
+-------------------+
| file-header | --文件头
+-------------------+
| optional header | --可选头
|- - - - - - - - - -|
|       |
| data directories | --（可选头尾的）数据目录
|       |
+-------------------+
|       |
| section headers | --节头
|       |
+-------------------+
|       |
| section 1 | --节1
|       |
+-------------------+
|       |
| section 2 | --节2
|       |
+-------------------+
|       |
| ...    |
|       |
+-------------------+
|       |
| section n | --节n
|       |
+-------------------+
在上图中，我们需要从“可选头”尾的“数据目录”数组中的第二个元素——输入符号表的位置，它是一个IMAGE_DATA_DIRECTORY结构，从它中的VirtualAddress地址，“顺藤摸瓜”找到api函数的入口地点。
下图的简单说明如下：
OriginalFirstThunk 指向IMAGE_THUNK_DATA结构数组，为方便只画了数组的一个元素，AddressOfData 指向IMAGE_IMPORT_BY_NAME结构。
IMAGE_IMPORT_DESCRIPTOR数组：每个引入的dll文件都对应数组中的一个元素，以全0的元素（20个bytes的0）表示数组的结束
IMAGE_THUNK_DATA32数组：同一组的以全0的元素（4个bytes的0）表示数组的结束，每个元素对应一个IMAGE_IMPORT_BY_NAME结构
IMAGE_IMPORT_BY_NAME：如..@Consts@initialization$qqrv. 表示
Unmangled Borland C++ Function: qualified function __fastcall Consts::initialization()

为了减少这个图的大小，不得已将汇编和c++的结构都用上了。这个图是输入符号表初始化的情形，此时两个IMAGE_THUNK_DATA结构数组的对应元素都指向同一个IMAGE_IMPORT_BY_NAME结构。
程序加载到进程空间后，两个IMAGE_THUNK_DATA结构数组指向有所不同了。看下图：

// 本文转自 C++Builder研究 - http://www.ccrun.com/article.asp?i=1036&d=cf6de2
始化的，“两个结构都指向同一个IMAGE_IMPORT_BY_NAME”，此时还没有api函数地址

当PE文件准备执行时，前图已转换成上图。一个结构指向不变，另一个出现api函数地址

如果PE文件从kernel32.dll中引入10个函数，那么IMAGE_IMPORT_DESCRIPTOR 结构的 Name1域包含指向字符串"kernel32.dll"的RVA，同时每个IMAGE_THUNK_DATA 数组有10个元素。(RVA是指相对地址，每一个可执行文件在加载到内存空间前，都以一个基址作为起点，其他地址以基址为准，均以相对地址表示。这样系统加载程序到不同的内存空间时，都可以方便的算出地址)
上述这些结构可以在winnt.h头文件里查到。

具体编程实现
我将手上的vc示例代码进行了适当修正，修改了一些资源泄漏的小问题，移植到c++builder6 & update4上，经过测试已经可以完成基本的api hook功能。有几个知识点说明一下：
1、 dll中共享内存变量的实现
正常编译下的dll，它的变量使用到的内存是独立的。比如你同时运行两个调用了某个dll的用户程序，试图对某一个在dll中定义的全局变量修改赋值的时候，两个程序里的变量值仍然是不同的。
共享的方法为：在.cpp文件（.h文件里如此设置会提示编译错误）的头部写上如上两行：
#pragma option -zRSHSEG    // 改变缺省数据段名
#pragma option -zTSHCLASS // 改变缺省数据类名

HINSTANCE hdll = NULL;       // 用来保存该动态连接库的句柄
HHOOK hApiHook = NULL;       // 钩子句柄
HHOOK hWndProc = NULL;       // 窗口过程钩子用来拦截SendMessage
int threadId = 0;

另外建立一个与dll同名，不同后缀的def文件，如HookDll.def文件，写上：
LIBRARY HookDll.dll
EXPORTS
;...
SEGMENTS
SHSEG CLASS 'SHCLASS' SHARED
;end

这样设置后在.cpp文件中定义的变量，如果进行了初始化，将进入“SHCLASS”共享内存段（如果不初始化，将不改变其默认段属性）。

上述的共享对于本示例代码并不是必须的，只是稍微演示了一下。

2、 api hook修改api函数入口点地址的时机
很显然，我们必须通过hook进入目标进程的地址空间后，再在位于该地址空间里的hook消息处理过程里修改输入符号表“指向”的api函数入口点地址，退出hook前也必须在这个消息处理过程里恢复原来的地址。只要我们牢记修改的过程发生在目标进程的地址空间中，就不会发生访问违例的错误了。
示例代码使用了WH_GETMESSAGE、WH_CALLWNDPROC两中hook来演示如何hook api，但WH_GETMESSAGE实际上并没有完成具体的功能。
为了让初学者尽快的掌握重点，我将代码进行了简化，是一个不健壮、不灵活的演示示例。

3、函数的内外部表现形式
例如api函数MessageBox，这个形式是我们通常用到的，但到了dll里，它的名字很可能出现了两个形式，一个是MessageBoxA，另一个是MessageBoxW，这是因为系统需要适应Ansi和Unicode编码的两种形式，我们不在函数尾端添加“A”或“W”，是不能hook到需要的函数的。

4、辅助pe格式查看工具
PE Explorer是一个非常好的查看pe资源的工具，通过它可以验证自己手工计算的pe地址，可以更快的掌握pe格式。
调试器ollydbg也是非常好的辅助工具，例如查看输入符号表中的api函数。

5、程序文件列表
dll基本文件：Hook.h，Hook.cpp，HookDll.def
client验证方基本文件：HookTest.h，HookTest.cpp，ApiHookTest.cpp

6、实现的功能
对记事本的MessageBoxW函数进行了hook，先执行自定义的
int WINAPI MyMessageBoxW(HWND hWnd, LPCWSTR M1, LPCWSTR M2, UINT M3)
{
return oldMessageBoxW(hWnd, M1, L"my api hook", M3);
}
从这里可以看到，由于目标进程空间中的执行线程并不知道你已经改变了api函数的实际入口地址，它在调用时仍旧将参数一成不变的压入堆栈（这个说法是汇编代码时看到的等价情形），事实上你已经提前接收到了函数调用的所有参数。这里就是篇首帖子的回复了。

hook之前

hook以后

示例代码
1、client验证方的代码非常简单。建立一个Application工程，在窗体上放一个memo（提示信息），两个button（一个SetHook，另一个RemoveHook）。
void __fastcall TForm1::Button1Click(TObject *Sender)
{
DWORD dwProcessId, dwThreadID;

HWND hWnd = FindWindow("Notepad", NULL);
if (!hWnd)
{
Memo1->Lines->Add("Nodepad is not found");
}
else
{
dwThreadID = GetWindowThreadProcessId(hWnd, &dwProcessId);
Memo1->Lines->Add(dwThreadID);
SetHook(dwThreadID);
}
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button2Click(TObject *Sender)
{
RemoveHook();
}
//---------------------------------------------------------------------------

2、api hook dll稍微复杂些，建立一个dll工程之后，修改之。代码中有一些函数并未用上，ReplaceApiAddress是核心函数，完整代码提供下载：
ApiHook.rar

参考文献
1、《iczelion汇编程序设计教程》pe专题部分
2、《WINDOWS核心编程》第22章
3、《PE文件格式 1.9版》汉译版，原著B. Luevelsmeyer
4、《跨进程API Hook》，出自http://blog.csdn.net/detrox/archive/2004/01/29/17511.aspx，作者detrox
5、《DLL木马注入程序》，出自http://www.mydown.com/code/245/245731.html
6、另有两vc6下的源代码包，APIHOOK与pw，因时间久远，出处不明。在此对原作者的辛勤工作表示真挚的谢意。

pear_li 2009-08-14 18:28 发表评论

Sessions, Desktops and Windows Stations

pear_li — Thu, 16 Jul 2009 13:17:00 GMT

Sessions, Desktops and Windows Stations

Today we are going to briefly go over the basics of some concepts that can be pretty confusing even at the best of times - Sessions, Desktops and Windows Stations. So let's dive right in ...

A session consists of all of the processes and other system objects that represent a single user’s logon session. These objects include all windows, desktops and windows stations. A desktop is a session-specific paged pool area and loads in the kernel memory space. This area is where session-private GUI objects are allocated from. A windows station is basically a security boundary to contain desktops and processes. So, a session may contain more than one Windows Station and each windows station can have multiple desktops.

Only one windows station is permitted to interact with the user at the console; this is called Winsta0. Under Winsta0 there are three desktops loaded: Winlogon (the logon screen), Default (the user desktop) and Disconnect. All three of these have separate logical displays, which is why your main desktop disappears if you lock the workstation. When you lock the workstation, the display switches from Default to Winlogon and there is no user interaction between the two. In Windows Vista this is even a bit more extreme. When you get a UAC prompt for instance, it takes a screenshot of your Default desktop and then displays it dimmed out behind the UAC window in the foreground. The UAC window is part of the Secure Desktop (new for Vista and similar to the logon desktop) and will not allow you to interact with the Default desktop until you provide input.

Other windows stations exist that do not interact with the user. For example, services load under the ‘Service-0x0-3e7$’ non-interactive windows station. The exceptions to this are services that need to interact with the console user, so these load into Winsta0 instead.

All pages mapped to a specific user use the same memory pages, but each user has their own session space mapped in virtual memory. Session space is divided into four different areas:

Session Structure – Memory management control structures including session Working Set List.
Session Image Space – holds a private copy of Win32k.sys modified data, a single copy of Win32k.sys code and unmodified data and various session drivers.
Session View Space – session mapped views including desktop heap
Session Paged Pool – paged pool memory used for this session

As mentioned above, a desktop is an object under which a logical display surface loads. This contains windows, menus and hooks. Session 0 is the base session where services run and is typically also the console session. In Windows Vista this has been changed to exclusively run services, and the console session is typically Session 1. The diagrams below show the relationships between sessions, windows stations, desktops and services in Windows Vista as compared to earlier operating systems (this is from our earlier post on Session 0 Application Compatibility Issues)

Session 0 in Windows XP / Windows Server 2003

Session 0 / Session 1 in Windows Vista

So now let's dig a little deeper using an example. In the diagram below, we are looking at Session 0 with a user logged in named Bob. As you can see, Winsta0 contains both processes from the user console session as well as any service that is marked as Interactive. In this case, that includes Winlogon.exe, Explorer.exe and others that need to interact with the user. The Service-0x0-3e7$ windows station owns any service that loads under Local System and is non-interactive. In this case I have shown Services.exe. As you can see by the connecting bars, it is possible for processes from different virtual sessions to load into a single windows station. The SQL process loads under its own windows station and credentials, so it is not included in either of the other windows stations.

So, to reiterate what is going on in the diagram above:

The whole diagram is Session 0.
Processes that start under the Bob account all load in Winsta0.
Interactive processes that start under Local System load in Winsta0
Non-interactive processes that start under Local System load in the Service-0x0-3e7% windows station
Processes that start under their own credentials start in their own windows station (like SQL)

A single desktop object will have a single desktop heap set aside for it. This heap stores various user interface objects, such as the windows, menus and hooks. When an application needs to draw a user interface object, it calls User32.dll to allocate this object. As I am sure you can guess, each of these interface elements requires resources out of desktop heap. If the desktop heap becomes depleted, you will get symptoms such as a corrupt display or other anomalies. Also, if the Session View Space becomes depleted, it will not be able to create more desktop heaps. Either of these of course is very bad. This is partially why you can still get Out Of Memory errors even on a machine with a lot of free RAM.

When this occurs, you may get initialization errors in addition to visual corruption. A typical error you may see is 0xc0000142, which means STATUS_DLL_INIT_FAILED. You can tell if the problem is with a single desktop heap or the entire session based on the symptom; if the desktop heap is depleted, you will only see the problem with processes that are out of heap. If the Session View Space is depleted, you will have a problem with that entire session.

Win32k.sys has a fixed kernel address space of 48MB set aside for desktop heaps. With Terminal Services, this space is shared with per-session storage, so that leaves 20MB for desktop heaps. So, as you can see, it is possible to run out of desktop heap resources easier on a terminal server than a standard machine. This is true for pre-Vista operating systems. In Windows Vista and Windows Server 2008 desktop heap is allocated dynamically and the 48MB constraint is not there.

There is a registry setting that allows limited modification of how this memory is handled: In the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems key, look for the

Windows value. There's a long string for this value that will look similar to this: %SystemRoot%system32csrss.exe ObjectDirectory=Windows SharedSection=1024,3072,512 Windows …

The portion of interest is "SharedSection=1024,3072,512". The three values under Shared Section determines how much memory in kilobytes (KB) is allocated to each component of the desktop heap. At this point, there is a major caveat here: Please do not modify these values on a whim. Changing the second or third value too high can put you in a no-boot situation due to the kernel not being able to allocate memory properly to even get Session 0 set up. Values up to about 8mb are generally safe, but may be pushing it, and frankly settings that high are not usually needed unless an installed program is misbehaving in the first place. We recommend raising these values in 512kb increments and only enough to alleviate whatever problem you are experiencing.

The first value is the shared heap size, common to all desktops. It's used to store the global handle table and shared system settings. By default, it's set to 1024KB. You generally do not need to modify this value. The second value is the desktop heap size for each desktop associated with the "interactive" window station. It is used to store user objects like hooks, menus, strings and windows. By default, it's set to 3072KB. The more users that log into the system, the more desktops are created. Consequently, the total "interactive" desktop heap size will increase to reflect the number of desktops created. However, each desktop will only have an "interactive" desktop heap of 3072KB. The third value is the desktop heap size for each desktop associated with the "non-interactive" window station. By default, it's set to 512KB. But if this value is not present, the size of the "non-interactive" window station will be the same as that of the "interactive" window station.

Every service process created under a user account will be given a new desktop in a "non-interactive" window station created by the Service Control Manager (SCM). Therefore, each of these services will consume the amount of desktop heap, as specified in the third SharedSection value. The total desktop heap used in both interactive and non-interactive window stations must fit into the 48MB system-wide buffer. Consequently, decreasing the second or third SharedSection values will increase the number of desktops that can be created. However, it will reduce the number of hooks, menus, strings and windows that can be created within each desktop. Conversely, increasing the second of third SharedSection values will reduce the number of desktops that can be created and increases the number of hooks, menus, strings and windows that can be created within each desktop. Also, increasing the third SharedSection value will reduce the number of user account services that can run successfully on the system.

So, hopefully this has shed at least a little light on how Sessions, Windows Stations and Desktops interact with each other. The following MS articles all talk about various aspects of this subject. There's also an in-depth blog post on the NT Debugging blog on Desktop Heap.

Additional Resources:

pear_li 2009-07-16 21:17 发表评论

创建一块命名的进程共享存储空间

pear_li — Thu, 27 Nov 2008 14:51:00 GMT

多个进程可以通过在系统页面文件中存储的内存映射文件来实现多个进程共享数据。

第一个进程

The first process creates the file mapping object by calling the CreateFileMapping function with INVALID_HANDLE_VALUE and a name for the object. By using the PAGE_READWRITE flag, the process has read/write permission to the memory through any file views that are created.

Then the process uses the file mapping object handle that CreateFileMapping returns in a call to MapViewOfFile to create a view of the file in the process address space. The MapViewOfFile function returns a pointer to the file view, pBuf. The process then uses the CopyMemory function to write a string to the view that can be accessed by other processes.

When the process no longer needs access to the file mapping object, it should call the CloseHandle function. When all handles are closed, the system can free the section of the paging file that the object uses.

第一个进程通过调用以INVALID_HANDLE_VALUE 为参数的CreateFileMapping方法创建一个命名的内存映射文件对象。通过使用PAGE_READWRITE 标识，进程可通过任何以创建文件视图获得文件读写权限。
然后进程使用CreateFileMapping 返回的对象句柄作为参数调用MapViewOfFile 方法在进程地址空间内创建一个文件视图。MapViewOfFile 返回一个文件视图的指针。进程可以调用CopyMemory 方法写一段字串到文件视图，而该视图可以被其他进程访问。
当进程不在需要访文件映射对象是，应该调用CloseHandle 方法。当所有的进程都关闭后，系统会释放对象所使用的页面文件。

1#include <windows.h>
2#include <stdio.h>
3#include <conio.h>
4
5#define BUF_SIZE 256
6TCHAR szName[]=TEXT("Global\\MyFileMappingObject");
7TCHAR szMsg[]=TEXT("Message from first process");
8
9int main()
10{
11   HANDLE hMapFile;
12   LPCTSTR pBuf;
13
14   hMapFile = CreateFileMapping(
15                 INVALID_HANDLE_VALUE,    // use paging file使用系统页面文件
16                 NULL,                    // default security
17                 PAGE_READWRITE,          // read/write access
18                 0,                       // max. object size
19                 BUF_SIZE,                // buffer size
20                 szName);                 // name of mapping object
21
22   if (hMapFile == NULL)
23   {
24      printf("Could not create file mapping object (%d).\n",
25             GetLastError());
26      return 1;
27   }
28   pBuf = (LPTSTR) MapViewOfFile(hMapFile,   // handle to map object
29                        FILE_MAP_ALL_ACCESS, // read/write permission
30                        0,
31                        0,
32                        BUF_SIZE);
33
34   if (pBuf == NULL)
35   {
36      printf("Could not map view of file (%d).\n",
37             GetLastError());
38      return 2;
39   }
40
41
42   CopyMemory((PVOID)pBuf, szMsg, strlen(szMsg));
43   _getch();
44
45   UnmapViewOfFile(pBuf);
46
47   CloseHandle(hMapFile);
48
49   return 0;
50}
51

第二个进程

A second process can access the string written to the shared memory by the first process by calling the OpenFileMapping function specifying the same name for the mapping object as the first process. Then it can use the MapViewOfFile function to obtain a pointer to the file view, pBuf. The process can display this string as it would any other string. In this example, the message box displayed contains the message "Message from first process" that was written by the first process.
第二个进程可以通过OpenFileMapping 方法并且指定与第一个进程中相同的内存映射文件对象名称来访问共享内存中的字串。然后可通过MapViewOfFile 方法得到文件视图的指针pBuf

1#include <windows.h>
2#include <stdio.h>
3#include <conio.h>
4
5#define BUF_SIZE 256
6TCHAR szName[]=TEXT("Global\\MyFileMappingObject");
7
8int main()
9{
10   HANDLE hMapFile;
11   LPCTSTR pBuf;
12
13   hMapFile = OpenFileMapping(
14                   FILE_MAP_ALL_ACCESS,   // read/write access
15                   FALSE,                 // do not inherit the name
16                   szName);               // name of mapping object
17
18   if (hMapFile == NULL)
19   {
20      printf("Could not open file mapping object (%d).\n",
21             GetLastError());
22      return 1;
23   }
24
25   pBuf = (LPTSTR) MapViewOfFile(hMapFile, // handle to map object
26               FILE_MAP_ALL_ACCESS,  // read/write permission
27               0,
28               0,
29               BUF_SIZE);
30
31   if (pBuf == NULL)
32   {
33      printf("Could not map view of file (%d).\n",
34             GetLastError());
35      return 2;
36   }
37
38   MessageBox(NULL, pBuf, TEXT("Process2"), MB_OK);
39
40   UnmapViewOfFile(pBuf);
41
42   CloseHandle(hMapFile);
43
44   return 0;
45}
46

更多内容参照http://baike.baidu.com/view/394293.htm

pear_li 2008-11-27 22:51 发表评论

使用线程局部存储TLS

pear_li — Thu, 27 Nov 2008 13:46:00 GMT

Thread local storage (TLS)统一进程的多个线程可以通过由TlsAlloc方法返回的索引值在线程自身的空间内存储和取回一个值。在以下这个例子里，索引值在进程开始时创建，当各个线程启动时，会各自申请一块动态内存并且将内存指针通过TlsSetValue方法存储到各自的TLS空间中（由先前的索引值标定）。CommonFunc方法使用TlsGetValue方法通过索引取得数据指针。在各个线程结束前，释放动态内存块。在进程结束见，调用TlsFree方法释放索引。

1#include <windows.h>
2#include <stdio.h>
3
4#define THREADCOUNT 4
5DWORD dwTlsIndex;
6
7VOID ErrorExit(LPSTR);
8
9VOID CommonFunc(VOID)
10{
11   LPVOID lpvData;
12
13// Retrieve a data pointer for the current thread.
14
15   lpvData = TlsGetValue(dwTlsIndex);
16   if ((lpvData == 0) && (GetLastError() != ERROR_SUCCESS))
17      ErrorExit("TlsGetValue error");
18
19// Use the data stored for the current thread.
20
21   printf("common: thread %d: lpvData=%lx\n",
22      GetCurrentThreadId(), lpvData);
23
24   Sleep(5000);
25}
26
27DWORD WINAPI ThreadFunc(VOID)
28{
29   LPVOID lpvData;
30
31// Initialize the TLS index for this thread.
32
33   lpvData = (LPVOID) LocalAlloc(LPTR, 256);
34   if (! TlsSetValue(dwTlsIndex, lpvData))
35      ErrorExit("TlsSetValue error");
36
37   printf("thread %d: lpvData=%lx\n", GetCurrentThreadId(), lpvData);
38
39   CommonFunc();
40
41// Release the dynamic memory before the thread returns.
42
43   lpvData = TlsGetValue(dwTlsIndex);
44   if (lpvData != 0)
45      LocalFree((HLOCAL) lpvData);
46
47   return 0;
48}
49
50int main(VOID)
51{
52   DWORD IDThread;
53   HANDLE hThread[THREADCOUNT];
54   int i;
55
56// Allocate a TLS index.
57
58   if ((dwTlsIndex = TlsAlloc()) == TLS_OUT_OF_INDEXES)
59      ErrorExit("TlsAlloc failed");
60
61// Create multiple threads.
62
63   for (i = 0; i < THREADCOUNT; i++)
64   {
65      hThread[i] = CreateThread(NULL, // default security attributes
66         0,                           // use default stack size
67         (LPTHREAD_START_ROUTINE) ThreadFunc, // thread function
68         NULL,                    // no thread function argument
69         0,                       // use default creation flags
70         &IDThread);              // returns thread identifier
71
72   // Check the return value for success.
73      if (hThread[i] == NULL)
74         ErrorExit("CreateThread error\n");
75   }
76
77   for (i = 0; i < THREADCOUNT; i++)
78      WaitForSingleObject(hThread[i], INFINITE);
79
80   TlsFree(dwTlsIndex);
81
82   return 0;
83}
84
85VOID ErrorExit (LPSTR lpszMessage)
86{
87   fprintf(stderr, "%s\n", lpszMessage);
88   ExitProcess(0);
89}
90

常用情景：
各个线程所处理的对象有所不同，但是所需要的处理却可能类似，例如多个线程同时处理多个文件，就可以将文件句柄存在在相应的Tls中，在使用相同的接口进行处理
背景知识：
每个线程除了共享进程的资源外还拥有各自的私有资源：一个寄存器组（或者说是线程上下文）；一个专属的堆栈；一个专属的消息队列；一个专属的Thread Local Storage（TLS）；一个专属的结构化异常处理串链。
TLS 是一个良好的Win32 特质，让多线程程序设计更容易一些。TLS 是一个机制，经由它，程序可以拥有全域变量，但在不同的线程里有不同的值。也就是说，进程中的所有线程都可以拥有全域变量，但这些变量其实是特定对某个线程才有意义。例如，你可能有一个多线程程序，每一个线程都对不同的文件写文件（也因此它们使用不同的文件handle）。这种情况下，把每一个线程所使用的文件handle 储存在TLS 中，将会十分方便。当线程需要知道所使用的handle，它可以从TLS 获得。重点在于：线程用来取得文件handle 的那一段码在任何情况下都是相同的，而从TLS中取出的文件handle 却各不相同。非常灵巧，不是吗？有全域变数的便利，却又分属各线程。

　虽然TLS 很方便，它并不是毫无限制。在Windows NT 和Windows 95 之中，有64 个DWORD slots 供每一个线程使用。这意思是一个进程最多可以有64 个「对各线程有不同意义」的DWORDs。虽然TLS 可以存放单一数值如文件handle，更常的用途是放置指针，指向线程的私有资料。有许多情况，多线程程序需要储存一堆数据，而它们又都是与各线程相关。许多程序员对此的作法是把这些变量包装为C 结构，然后把结构指针储存在TLS 中。当新的线程诞生，程序就配置一些内存给该结构使用，并且把指针储存在为线程保留下来的TLS 中。一旦线程结束，程序代码就释放所有配置来的区块。既然每一个线程都有64 个slots 用来储存线程自己的数据，那么这些空间到底打哪儿来？在线程的学习中我们可以从结构TDB中看到，每一个thread database 都有64 个DWORDs 给TLS 使用。当你以TLS 函式设定或取出数据，事实上你真正面对的就是那64 DWORDs。好，现在我们知道了原来那些“对各线程有不同意义的全局变量”是存放在线程各自的TDB中阿。

接下来你也许会问：我怎么存取这64个DWORDS呢？我又怎么知道哪个DWORDS被占用了，哪个没有被占用呢？首先我们要理解这样一个事实：系统之所以给我们提供TLS这一功能，就是为了方便的实现“对各线程有不同意义的全局变量”这一功能；既然要达到“全局变量”的效果，那么也就是说每个线程都要用到这个变量，既然这样那么我们就不需要对每个线程的那64个DWORDS的占用情况分别标记了，因为那64个DWORDS中的某一个一旦占用，是所有线程的那个DWORD都被占用了，于是KERNEL32 使用两个DWORDs（总共64 个位）来记录哪一个slot 是可用的、哪一个slot 已经被用。这两个DWORDs 可想象成为一个64 位数组，如果某个位设立，就表示它对应的TLS slot 已被使用。这64 位TLS slot 数组存放在process database 中（在进程一节中的PDB结构中我们列出了那两个DWORDs）。

下面的四个函数就是对TLS进行操作的：

（1）TlsAlloc

上面我们说过了KERNEL32 使用两个DWORDs（总共64 个位）来记录哪一个slot 是可用的、哪一个slot 已经被用。当你需要使用一个TLS slot 的时候，你就可以用这个函数将相应的TLS slot位置１。

（2）TlsSetValue

TlsSetValue 可以把数据放入先前配置到的TLS slot 中。两个参数分别是TLS slot 索引值以及欲写入的数据内容。TlsSetValue 就把你指定的数据放入64 DWORDs 所组成的数组（位于目前的thread database）的适当位置中。

（3）TlsGetValue

这个函数几乎是TlsSetValue 的一面镜子，最大的差异是它取出数据而非设定数据。和TlsSetValue 一样，这个函数也是先检查TLS 索引值合法与否。如果是，TlsGetValue 就使用这个索引值找到64 DWORDs 数组（位于thread database 中）的对应数据项，并将其内容传回。

（4）TlsFree

这个函数将TlsAlloc 和TlsSetValue 的努力全部抹消掉。TlsFree 先检验你交给它的索引值是否的确被配置过。如果是，它将对应的64 位TLS slots 位关闭。然后，为了避免那个已经不再合法的内容被使用，TlsFree 巡访进程中的每一个线程，把0 放到刚刚被释放的那个TLS slot 上头。于是呢，如果有某个TLS 索引后来又被重新配置，所有用到该索引的线程就保证会取回一个0 值，除非它们再调用TlsSetValue。

pear_li 2008-11-27 21:46 发表评论