1. 引子：一个反常的现象

在研究 Windows 线程局部存储（Thread Local Storage，TLS）边界情况时，我们编写了一个简单的测试程序。该程序使用 __declspec(thread) 声明了一个线程局部数组，并注册了三个 TLS 回调函数，期望在 main 函数执行前通过回调记录调用顺序。然而，在分别使用 Debug 和 Release 配置编译后，通过 dumpbin /headers 查看生成的 PE 文件，发现了一个有趣的现象：

• Debug 版：存在 .tls 节，TLS 目录（Thread Storage Directory）的 RVA 为 0xADA0，大小为 0x28。
• Release 版：.tls 节消失，但 TLS 目录仍然存在（RVA 0x2400，大小 0x28）。

这引出了几个关键问题：TLS 模板数据被重新定位到了何处？链接器进行了何种优化？这一行为对逆向分析有何启示？本文将以此示例程序为基础，从底层剖析 Windows TLS 的实现机制，并解释这一反常现象背后的原理。

1.1 示例代码

以下是完整的测试程序代码，读者可自行编译验证：

#include <windows.h>
#include <cstdio>

static volatile long g_callback_order = 0;
static int g_callback_values[3] = {0};

extern "C" void NTAPI TlsCallbackA(void*, DWORD reason, void*) {
    if (reason == DLL_PROCESS_ATTACH) 
        g_callback_values[0] = (int)InterlockedIncrement(&g_callback_order);
}

extern "C" void NTAPI TlsCallbackB(void*, DWORD reason, void*) {
    if (reason == DLL_PROCESS_ATTACH) 
        g_callback_values[1] = (int)InterlockedIncrement(&g_callback_order);
}

extern "C" void NTAPI TlsCallbackC(void*, DWORD reason, void*) {
    if (reason == DLL_PROCESS_ATTACH) 
        g_callback_values[2] = (int)InterlockedIncrement(&g_callback_order);
}

#pragma section(".CRT$XLU", long, read)
#pragma section(".CRT$XLV", long, read)
#pragma section(".CRT$XLW", long, read)

__declspec(allocate(".CRT$XLU")) PIMAGE_TLS_CALLBACK xl_a = TlsCallbackA;
__declspec(allocate(".CRT$XLV")) PIMAGE_TLS_CALLBACK xl_b = TlsCallbackB;
__declspec(allocate(".CRT$XLW")) PIMAGE_TLS_CALLBACK xl_c = TlsCallbackC;

__declspec(thread) volatile int g_dummy_tls[1024] = {0};

int main(int argc, char* argv[]) {
    g_dummy_tls[0] = argc;
    if (g_dummy_tls[0] == argc) {
        // 防止优化
    }

    if (g_callback_values[0] == 1 && g_callback_values[1] == 2 && g_callback_values[2] == 3)
        printf("true\n");
    else
        printf("false\n");
    return 0;
}

编译环境为 Visual Studio 2026（预览版），编译器版本 Microsoft (R) C/C++ Optimizing Compiler Version 19.50.35727 for x64。

2. 什么是 TLS？为什么需要它？

2.1 线程局部存储的基本概念

线程局部存储（Thread Local Storage，TLS） 是一种机制，允许程序中的每个线程拥有独立的数据副本。对于声明为 TLS 的变量，每个线程在访问时都会看到自己的私有版本，不同线程之间互不干扰。

例如，在多线程程序中声明一个全局变量 __declspec(thread) int counter;，那么线程 A 对 counter 的修改不会影响线程 B 中的 counter 值。这就像每个线程都有一个同名的“私有保险箱”，钥匙相同，但保险箱各自独立。

2.2 为什么需要 TLS？

在多线程编程中，如果多个线程需要共享数据，通常需要使用同步机制（如锁、原子操作）来避免数据竞争。然而，并非所有数据都需要共享。许多场景下，每个线程需要自己的私有状态：

• 错误码（errno）：C 运行时库中的 errno 必须是线程局部的，否则一个线程的错误码会被另一个线程覆盖。
• 线程标识：每个线程需要存储自己的 ID、栈基址等。
• 性能计数器：性能分析工具常使用 TLS 存储每线程的统计数据，避免全局锁竞争。
• 线程池工作线程的状态：每个线程持有自己的缓存、连接池等。

如果这些数据使用普通的全局变量，就必须加锁保护，这会引入性能开销和复杂的编程逻辑。TLS 提供了零锁、零同步的解决方案，因为每个线程只访问自己的副本，不存在竞争。

从更宏观的角度看，TLS 的复杂性根源于硬件多核时代的必然选择：单核性能遇到物理瓶颈（功耗墙），硬件转向多核并行，从而迫使软件必须处理线程私有数据。这种硬件复杂性的“外溢”最终由操作系统和编译器共同封装，呈现给开发者相对简单的接口。

2.3 Windows 中的 TLS 实现方式

Windows 提供了两种 TLS 使用方式：

• 静态 TLS：使用 __declspec(thread) 关键字声明变量。链接器会在 PE 文件中创建 .tls 节（或合并到其他节），并生成 TLS 目录。静态 TLS 效率最高，但要求程序加载时所有 TLS 变量大小已知，且不能用于动态加载的 DLL（需使用特定模型）。
• 动态 TLS：使用 TlsAlloc、TlsSetValue、TlsGetValue 等 API。这种方式更灵活，允许在运行时动态分配 TLS 槽，适用于无法预先确定数量的场景（如插件系统）。

本文主要探讨静态 TLS 及其在 PE 文件中的表现形式。

2.4 TLS 的硬件与操作系统基础

TLS 的高效实现依赖于底层硬件的支持：

• 段寄存器：x86 架构的 FS 寄存器和 x64 架构的 GS 寄存器，被操作系统设置为指向当前线程的线程环境块（TEB）。通过 FS:[offset] 或 GS:[offset] 可以快速访问线程私有数据。
• 线程环境块（TEB）：每个线程有一个 TEB，其中包含一个指针数组（ThreadLocalStoragePointer），数组的每个元素指向一个模块的 TLS 数据块。

编译器将 __declspec(thread) 变量的访问编译为基于段寄存器的间接寻址，从而实现极低的开销。

3. PE 中的 TLS 结构解剖（逆向视角）

3.1 .tls 节是什么？

.tls 节是 PE 文件中专门用于存放 TLS 变量初始值模板 的区域。它的作用类似于 .data 节的“线程私有版本”：

• 包含已初始化的 TLS 变量。
• 未初始化的部分（相当于 .tbss）在内存中补零。
• 当系统创建新线程时，会根据这个模板初始化该线程的 TLS 数据块。

在 Debug 版中，.tls 节的大小为 0x1800 字节。数组 g_dummy_tls[1024] 占用 0x1000 字节，多出的 0x800 字节可能包含编译器/链接器生成的 TLS 管理数据（如 TLS 索引表、安全 Cookie 等）。具体内容可通过查看 .tls 节的原始数据进一步分析，但并非本文重点。

3.2 TLS 目录（IMAGE_TLS_DIRECTORY）

TLS 目录位于 PE 文件的数据目录（Data Directory）的第 10 项（索引 9）。其结构定义如下（64 位版本）：

typedef struct _IMAGE_TLS_DIRECTORY64 {
    ULONGLONG StartAddressOfRawData;   // TLS 模板的起始地址
    ULONGLONG EndAddressOfRawData;     // TLS 模板的结束地址
    ULONGLONG AddressOfIndex;          // 指向 TLS 索引的指针
    ULONGLONG AddressOfCallBacks;      // 指向 TLS 回调函数数组的指针
    DWORD SizeOfZeroFill;               // 模板后需要补零的大小
    DWORD Characteristics;              // 属性（通常为对齐标志，保留）
} IMAGE_TLS_DIRECTORY64;

各字段的含义和作用：

• StartAddressOfRawData / EndAddressOfRawData：定义了 TLS 模板数据在内存中的范围。线程创建时，系统从该区域复制数据到线程的 TLS 块。
• AddressOfIndex：指向一个 DWORD 值，该值存储当前模块的 TLS 索引。这个索引用于在 TEB 的 TLS 数组中定位本模块的 TLS 块。
• AddressOfCallBacks：指向一个以 NULL 结尾的函数指针数组，数组中的每个指针都是一个 TLS 回调函数。该数组本身通常位于只读节（如 .rdata），其位置可通过此字段确定。
• SizeOfZeroFill：指定在模板数据之后需要补充的零填充字节数（对应未初始化的 TLS 变量）。
• Characteristics：保留字段，通常为 0 或对齐标志。在示例中值为 00500000，可能表示 16 字节对齐。

使用 dumpbin /TLS 可以方便地查看这些字段的值。例如，Debug 版的输出为：

Start of raw data     = 000000014000F000
End of raw data       = 0000000140010543
Address of index      = 000000014000C1FC
Address of callbacks  = 0000000140009778
Size of zero fill     = 0
Characteristics       = 00500000

3.3 TLS 模板数据的使用时机

TLS 模板数据的生命周期如下：

1. 进程启动时：加载器解析 TLS 目录，记录模板数据的位置和大小。
2. 线程创建时：系统为新线程分配 TLS 块，从模板数据中复制初始值。
3. 线程运行时：通过 TEB 和 TLS 索引访问本线程的 TLS 变量副本。
4. 线程退出时：释放 TLS 块（若注册了析构函数，则先调用）。

3.4 如何使用工具观察？

• dumpbin /headers：查看 TLS 目录的 RVA 和大小。
• dumpbin /TLS：直接解析 TLS 目录内容并列出回调函数。
• CFF Explorer：图形化查看 PE 结构，直接解析 IMAGE_TLS_DIRECTORY 的各个字段，并能直观显示节归属。
• IDA Pro：查看节区分配，识别 TLS 相关符号（如 _tls_used），通过节视图可确认模板数据所在节。

4. TLS 回调：隐藏在 main 之前的初始化

理解了 TLS 目录的结构后，我们来看如何利用它注册回调函数。

4.1 回调函数原型与触发时机

TLS 回调函数的原型定义如下：

typedef VOID (NTAPI *PIMAGE_TLS_CALLBACK)(
    PVOID DllHandle,   // 模块句柄
    DWORD Reason,      // 触发原因
    PVOID Reserved     // 保留参数
);

Reason 参数的可选值：

• DLL_PROCESS_ATTACH (1)：进程启动时。
• DLL_THREAD_ATTACH (2)：线程创建时。
• DLL_THREAD_DETACH (3)：线程退出时。
• DLL_PROCESS_DETACH (0)：进程退出时。

4.2 回调数组的注册与合并

MSVC 链接器约定：所有以 .CRT$XL 开头的节会被合并成一个连续的数组，并按 $ 后的字母顺序排序。例如：

• .CRT$XLA、.CRT$XLB、……、.CRT$XLZ 被合并。
• 顺序为 A、B、C、……、Z。

CRT 自身使用了 .CRT$XLA 到 .CRT$XLD 等节，因此开发者若想添加自己的 TLS 回调，应选择靠后的字母（如 .CRT$XLU、.CRT$XLV、.CRT$XLW）以避免与 CRT 的回调混杂。

在示例代码中，三个回调函数指针分别放在 .CRT$XLU、.CRT$XLV、.CRT$XLW 中。链接器将这些节与 CRT 自身的 .CRT$XLA～.CRT$XLD 合并，最终形成一个完整的回调数组。数组顺序为：CRT 回调（若有）、TlsCallbackA、TlsCallbackB、TlsCallbackC、NULL。

重要：回调数组必须以 NULL 结尾，否则系统在遍历时可能越界读取。示例中未显式放置 NULL，但 CRT 通常会在 .CRT$XLZ 中放置一个 NULL 指针，因此数组会自动以 NULL 结束。

4.3 TLS 目录生成的条件

要使 TLS 回调生效，PE 文件中必须存在 TLS 目录。TLS 目录的生成通常依赖于以下条件之一：

1. 至少有一个 __declspec(thread) 变量被实际使用（读写操作）。在示例中，我们声明了 g_dummy_tls 并在 main 中进行了读写，并通过 volatile 限定防止优化，从而满足条件。
2. 使用 #pragma comment(linker, "/INCLUDE:_tls_used") 强制链接器包含 TLS 目录。

4.4 回调执行顺序验证

通过 dumpbin /TLS 查看 Debug 版的可执行文件，得到的回调列表为：

TLS Callbacks
          Address
          ----------------
          00000001400010C3  @ILT+190(TlsCallbackA)
          00000001400011CC  @ILT+455(TlsCallbackB)
          0000000140001127  @ILT+290(TlsCallbackC)
          0000000000000000

说明：Debug 版由于启用了增量链接，回调地址显示为 @ILT+xxx 形式的跳转表项，实际执行时会跳转到真正的函数入口。三个回调的地址顺序为 A、B、C，与段名排序一致。运行程序输出 true，证明三个回调均被调用且按预期顺序执行。

Release 版虽然没有了 .tls 节，但 dumpbin /TLS 仍然列出了三个回调地址：

TLS Callbacks
          Address
          ----------------
          0000000140001000
          0000000140001020
          0000000140001040
          0000000000000000

这些地址没有符号信息，但通过反汇编验证（例如在 IDA 或 x64dbg 中查看 0x140001000 处的代码），可以确认它们分别对应 TlsCallbackA、TlsCallbackB、TlsCallbackC 的入口。这说明 Release 版的 TLS 回调机制依然有效。

5. 深入案例：为什么 Release 版没有 .tls 段？

5.1 Debug 与 Release 的 TLS 目录对比

通过 dumpbin /TLS 获取两个版本的关键数据：

5.2 逆向分析步骤（基于实际数据）

1. 确认 TLS 目录存在：从 dumpbin /headers 已知 Release 版 TLS 目录的 RVA 为 0x2400，且大小非零，说明 TLS 目录确实存在。
2. 解析 TLS 目录内容：使用 dumpbin /TLS 得到 StartAddressOfRawData = 0x1400027E0，对应的 RVA 为 0x27E0（因为 ImageBase 为 0x140000000）。
3. 确定模板数据所在节：根据 Release 版的节表（dumpbin /headers）：
   • .rdata 节：虚拟地址范围 0x2000 ～ 0x3E4F
   • .data 节：虚拟地址范围 0x4000 ～ 0x4147
   • 0x27E0 显然落在 .rdata 节范围内。
4. 结论：Release 版的 TLS 模板数据被合并到了 .rdata 节中，不再保留独立的 .tls 节。

5.3 优化原理

TLS 模板数据在 PE 文件中是只读的（它是每个线程初始值的副本），系统在创建线程时会从模板复制数据到每个线程的私有 TLS 块。模板数据本身在进程内存中通常保持只读属性。链接器为了减少 PE 文件中的节数量，可以将这些只读数据合并到普通的只读数据节（如 .rdata）中。这种优化在满足以下条件时可能发生：

• TLS 变量数量较少。
• 没有特殊的节属性要求（如可写、可执行等）。

值得注意的是，TLS 目录仍然保留，因为系统需要它来定位模板数据的范围和回调函数数组。无论模板数据位于哪个节，只要 StartAddressOfRawData 指向正确的位置，TLS 机制就能正常工作。

5.4 对逆向的启示

这一优化对逆向分析提出了更高的要求：

1. 不能仅凭有无 .tls 节判断程序是否使用 TLS。必须检查 TLS 目录是否存在并解析其字段。
2. TLS 模板数据可能隐藏在 .data、.rdata 甚至其他自定义节中。需要根据 StartAddressOfRawData 和 EndAddressOfRawData 准确定位。
3. TLS 回调数组的位置也需要通过 AddressOfCallBacks 字段定位，不能假设它在特定节中。
4. 在分析恶意软件时，TLS 回调常用于反调试（如检测调试器、修改代码）。识别 TLS 目录并查看回调数组，有助于发现隐藏的初始化代码。可通过修改 PE 头中 AddressOfCallBacks 指针为零来临时绕过回调。

6. 实验验证与工具使用

6.1 静态验证方法

• 使用 CFF Explorer：打开 Release 版可执行文件，在“Data Directories”中双击“Thread Local Storage”，即可看到 StartAddressOfRawData = 0x1400027E0。切换至“Section Headers”视图，可确认该地址落在 .rdata 节。
• 使用 IDA Pro：加载文件后，按 Ctrl+S 查看节区列表，记下 .rdata 的起始和结束地址。然后搜索 _tls_used 符号（该符号指向 TLS 目录），定位到 TLS 目录结构，验证模板地址与节范围的关系。
• 使用 010 Editor：加载 PE 模板，直接解析 IMAGE_TLS_DIRECTORY 并查看原始数据。

6.2 动态验证方法

• 使用 x64dbg：在 ntdll!LdrpCallTlsInitializers 函数下断点。该函数在进程启动时会被调用，遍历 TLS 回调数组并依次执行。断下后，观察回调地址，验证是否与 dumpbin /TLS 列出的地址一致。
• 访问 TLS 变量：在代码中对 g_dummy_tls 取地址，并在 watch 窗口中观察其值。可以创建多个线程，验证每个线程拥有独立的副本。

7. 总结与启示

通过这次探索，我们可以得出以下结论：

1. TLS 的复杂性是硬件多核时代向软件层的自然外溢。多核架构带来的线程私有数据需求，催生了从硬件（FS/GS）、操作系统（TEB）到编译器（__declspec(thread)）的完整解决方案。

2. Windows 通过 TEB、TLS 目录等机制封装了底层细节，使开发者能够以相对简单的方式使用线程局部存储。

3. 编译器/链接器会不断优化 PE 文件结构，导致传统的逆向特征（如独立的 .tls 节）可能消失。Release 版将 TLS 模板数据合并到 .rdata 节正是这种优化的体现。

4. 对逆向工程师而言，必须掌握更本质的定位方法：依赖 PE 结构定义而非节名称。具体来说：

   • 始终检查数据目录中的 TLS 目录项，而非搜索 .tls 节。
   • 解析 IMAGE_TLS_DIRECTORY 的各个字段，准确定位模板数据和回调数组。
   • 理解 TLS 回调的注册机制和执行时机，避免被反调试技巧迷惑。

TLS 机制虽然看似复杂，但其设计遵循了清晰的层次结构。理解这一结构，不仅能帮助我们在逆向分析中准确定位相关数据，也能让我们更深刻地体会系统软件设计的精妙。

附录：工具与典型分析流程

典型分析流程：

1. 使用 dumpbin /headers 快速检查是否存在 TLS 目录。
2. 使用 dumpbin /TLS 获取 StartAddressOfRawData 和回调列表。
3. 使用 CFF Explorer 打开文件，验证模板数据所在节。
4. 若需要动态验证，用 x64dbg 在回调入口下断。
5. 若需批量分析，编写 IDA Python 脚本提取信息。

参考文献

• [1] Microsoft Corporation. PE Format [M]. 2023. (03bK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6D9k6h3q4J5L8W2)9J5k6h3#2A6j5%4u0G2M7$3!0X3N6q4)9J5k6h3y4G2L8g2)9J5c8X3g2F1i4K6u0V1N6i4y4Q4x3V1k6%4K9h3&6V1L8%4N6K6i4K6u0r3N6$3W2F1x3K6u0Q4x3V1k6V1k6h3u0#2k6#2)9J5c8Y4m8W2i4K6u0V1k6X3!0J5L8h3q4@1i4K6t1&6
• [2] Russinovich, M., Solomon, D., Ionescu, A. Windows Internals, Part 1 [M]. 7th ed. Microsoft Press, 2017.
• [3] Richter, J., Nasarre, C. Windows via C/C++ [M]. 5th ed. Microsoft Press, 2007.
• [4] Drepper, U. ELF Handling For Thread-Local Storage [R]. Red Hat, 2005.
• [5] Intel Corporation. Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A [M]. 2023.

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！