线程进入和线程启动之间的确切区别和关系是什么？答案

【问题标题】：What is the exact difference and the relation between thread entry and thread start?线程进入和线程启动之间的确切区别和关系是什么？
【发布时间】：2021-05-01 17:13:16
【问题描述】：

thread entry and thread start 之间的确切区别是什么？和
RIP（在动态分析中执行前端所在的位置）是否总是以相同的可预测顺序到达它们？
线程入口是否动态变化（在动态分析中我想我看到它在寄存器和堆栈中报告）？

到目前为止，我了解thread start 是从某个角度定义的，例如，在Windows 中，它始终是ntdll.RtlUserThreadStart+21（用户），但在程序库级别，它可以是任何函数。但是thread start在创建线程之前不会被调用ntdll.NtCreateThreadEx+14（系统）。

thread entry 是作为thread create 函数的参数的（库，即导出或私有）函数。

使用 x64dbg 制作的带有线程（threadID、Address、to、from、size、comment、party）的调用堆栈示例：

4200                                                                                                 
      00000076EBDFF9A8 00007FFEC900A34E 00007FFECB4EC034 A0  ntdll.NtWaitForSingleObject+14          System
      00000076EBDFFA48 00007FF7987B48A1 00007FFEC900A34E 30  kernelbase.WaitForSingleObjectEx+8E     User
      00000076EBDFFA78 00007FF7988961A0 00007FF7987B48A1 30  mylibrarydll0.00007FF7987B48A1          User
      00000076EBDFFAA8 00007FF7987B13DF 00007FF7988961A0 30  mylibrarydll0.00007FF7988961A0          User
      00000076EBDFFAD8 00007FF798B4A175 00007FF7987B13DF 30  mylibrarydll0.00007FF7987B13DF          User
      00000076EBDFFB08 00007FFECA637034 00007FF798B4A175 30  mylibrarydll0.sub_7FF798B4A0B4+C1       System
      00000076EBDFFB38 00007FFECB49D0D1 00007FFECA637034 80  kernel32.BaseThreadInitThunk+14         System
      00000076EBDFFBB8 0000000000000000 00007FFECB49D0D1     ntdll.RtlUserThreadStart+21             User
2736                                                                                                 
      00000076EB5FF648 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14  System
      00000076EB5FF948 00007FFECA637034 00007FFECB4623D7 30  ntdll.TppWorkerThread+2F7               System
      00000076EB5FF978 00007FFECB49D0D1 00007FFECA637034 80  kernel32.BaseThreadInitThunk+14         System
      00000076EB5FF9F8 0000000000000000 00007FFECB49D0D1     ntdll.RtlUserThreadStart+21             User
2468                                                                                                 
      00000076EBBFFB78 00007FFEC900A34E 00007FFECB4EC034 A0  ntdll.NtWaitForSingleObject+14          System
      00000076EBBFFC18 00007FF7987B48A1 00007FFEC900A34E 30  kernelbase.WaitForSingleObjectEx+8E     User
      00000076EBBFFC48 00007FF7988961A0 00007FF7987B48A1 30  mylibrarydll0.00007FF7987B48A1          User
      00000076EBBFFC78 00007FF7987B13DF 00007FF7988961A0 30  mylibrarydll0.00007FF7988961A0          User
      00000076EBBFFCA8 00007FF798B4A175 00007FF7987B13DF 30  mylibrarydll0.00007FF7987B13DF          User
      00000076EBBFFCD8 00007FFECA637034 00007FF798B4A175 30  mylibrarydll0.sub_7FF798B4A0B4+C1       System
      00000076EBBFFD08 00007FFECB49D0D1 00007FFECA637034 80  kernel32.BaseThreadInitThunk+14         System
      00000076EBBFFD88 0000000000000000 00007FFECB49D0D1     ntdll.RtlUserThreadStart+21             User
3784                                                                                                 
      00000076EB6FFB88 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14  System
      00000076EB6FFE88 00007FFECA637034 00007FFECB4623D7 30  ntdll.TppWorkerThread+2F7               System
      00000076EB6FFEB8 00007FFECB49D0D1 00007FFECA637034 80  kernel32.BaseThreadInitThunk+14         System
      00000076EB6FFF38 0000000000000000 00007FFECB49D0D1     ntdll.RtlUserThreadStart+21             User
1928                                                                                                 
      00000076EB7FFA48 00007FFEC900A34E 00007FFECB4EC034 A0  ntdll.NtWaitForSingleObject+14          System
      00000076EB7FFAE8 00007FF7987B48A1 00007FFEC900A34E 30  kernelbase.WaitForSingleObjectEx+8E     User
      00000076EB7FFB18 00007FF7988961A0 00007FF7987B48A1 30  mylibrarydll0.00007FF7987B48A1          User
      00000076EB7FFB48 00007FF7987B13DF 00007FF7988961A0 30  mylibrarydll0.00007FF7988961A0          User
      00000076EB7FFB78 00007FF798B4A175 00007FF7987B13DF 30  mylibrarydll0.00007FF7987B13DF          User
      00000076EB7FFBA8 00007FFECA637034 00007FF798B4A175 30  mylibrarydll0.sub_7FF798B4A0B4+C1       System
      00000076EB7FFBD8 00007FFECB49D0D1 00007FFECA637034 80  kernel32.BaseThreadInitThunk+14         System
      00000076EB7FFC58 0000000000000000 00007FFECB49D0D1     ntdll.RtlUserThreadStart+21             User
2276                                                                                                 
      00000076EB8FF7C8 00007FFEC900A34E 00007FFECB4EC034 A0  ntdll.NtWaitForSingleObject+14          System
      00000076EB8FF868 00007FF7987B48A1 00007FFEC900A34E 30  kernelbase.WaitForSingleObjectEx+8E     User
      00000076EB8FF898 00007FF7988961A0 00007FF7987B48A1 30  mylibrarydll0.00007FF7987B48A1          User
      00000076EB8FF8C8 00007FF7987B13DF 00007FF7988961A0 30  mylibrarydll0.00007FF7988961A0          User
      00000076EB8FF8F8 00007FF798B4A175 00007FF7987B13DF 30  mylibrarydll0.00007FF7987B13DF          User
      00000076EB8FF928 00007FFECA637034 00007FF798B4A175 30  mylibrarydll0.sub_7FF798B4A0B4+C1       System
      00000076EB8FF958 00007FFECB49D0D1 00007FFECA637034 80  kernel32.BaseThreadInitThunk+14         System
      00000076EB8FF9D8 0000000000000000 00007FFECB49D0D1     ntdll.RtlUserThreadStart+21             User
12168                                                                                                
      00000076EB9FF6E8 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14  System
      00000076EB9FF9E8 00007FFECA637034 00007FFECB4623D7 30  ntdll.TppWorkerThread+2F7               System
      00000076EB9FFA18 00007FFECB49D0D1 00007FFECA637034 80  kernel32.BaseThreadInitThunk+14         System
      00000076EB9FFA98 0000000000000000 00007FFECB49D0D1     ntdll.RtlUserThreadStart+21             User
2428                                                                                                 
      00000076EBAFF5D8 00007FFECB4623D7 00007FFECB4EFA04 300 ntdll.NtWaitForWorkViaWorkerFactory+14  System
      00000076EBAFF8D8 00007FFECA637034 00007FFECB4623D7 30  ntdll.TppWorkerThread+2F7               System
      00000076EBAFF908 00007FFECB49D0D1 00007FFECA637034 80  kernel32.BaseThreadInitThunk+14         System
      00000076EBAFF988 0000000000000000 00007FFECB49D0D1     ntdll.RtlUserThreadStart+21             User

【问题讨论】：

您在哪里阅读了“线程入口”和“线程启动”这两个术语？什么是“RIP/Horizon”？
我认为 RIP 指的是 x86-64 64 位指令指针，尽管我不知道 Horizon 在这种情况下是什么。
@Kevin 我更新了帖子以澄清。
“线程入口”是给CreateThread 或类似地址的地址，“线程开始”是当 Windows 向调试器发送“线程创建”事件时 RIP 所在的地址。它通常位于稍后将调用线程条目的ntdll 函数上。在给定的 Windows 版本上，它应该始终具有相同的功能。线程开始被赋予线程入口的地址作为参数，因此您可以在内存或寄存器中找到它。注意SetThreadContext可以改变一个（暂停的）线程的入口点，所以线程入口可能是一个诱饵地址。
@MargaretBloom 所以，当我暂停然后恢复一个线程时，线程条目发生了变化，是吗？最终我可以以可预测的方式追踪它（比如在装配的动态分析中）？

标签： c multithreading debugging assembly disassembly

【解决方案1】：

所讨论的术语在常用术语中不一定具有精确定义。您链接的 x64dbg 文档给出了以下定义：

线程条目

当一个线程即将运行时，在线程入口处设置一个单射断点。

和

线程开始

当一个新线程即将运行时暂停。

这些是调试器为它可以提醒您的明显不同类型的事件选择的标签。我的解释与您在问题中描述的一致，是“线程启动”是关于创建一个新线程，显然是在创建线程的上下文中，而“线程入口”是关于执行将在新线程中运行的代码，大概是在该线程的上下文中。

我倾向于认为，在这些术语中，线程启动必须始终发生在线程进入之前。执行不能在线程启动之前输入线程的代码。实际上，我倾向于猜测线程启动事件是调试器可以发出信号的最后一个事件，该事件肯定发生在相关线程的线程进入之前。
在一般意义上，我希望线程入口地址是线程入口点函数的地址，或者可能是其主体中的第一条指令的地址（不一定是同一件事）。对于不同的入口点函数，这不能期望是一致的，并且对于同一函数在程序的不同运行中可能不一样。如果您认为您看到了其他内容，请查阅该工具的文档。

【讨论】：

当我暂停然后恢复一个线程时，线程条目发生了变化，是吗？最终我可以以可预测的方式追踪它（比如在装配的动态分析中）？
@Soleil，线程进入事件是每个线程一次的事件。在暂停该线程之前，给定线程的条目必须已经发生，并且一旦该事件触发，任何事件的属性都是不可变的历史记录。

【解决方案2】：

Windows 向调试器发送一组特定的事件，您可以在 WaitForDebugEvent 的文档中找到它们。
其中一个事件是CREATE_THREAD_DEBUG_INFO，在 Windows 已创建但尚未启动线程时发送。
在 Windows 中，进程和线程的创建发生在内核中，但它们的最终初始化步骤发生在用户空间中（除非它是一个 pico 进程，我们不会在这里讨论）。 DLL ntdll.dll 在创建后立即映射到线程中，并且线程上下文的RIP 设置为指向此 DLL 的函数之一。该函数将执行必要的初始化，然后跳转到CreateThread 或类似地址中给出的地址。这个函数是一种线程的包装器。

当初始化函数的第一条指令即将执行时，线程启动是理所当然的（认为它就像 Windows 在那里设置了一个断点）。
thread entry 只是提供给线程创建 API 的地址。这很重要，因为它是调用者打算执行的实际代码。事实上，出于调试或 RE 的目的，您几乎可以（如果不是总是）忽略线程启动事件。

让我们举个例子。考虑这个简单的 64 位程序。

BITS 64

EXTERN CreateThread 
GLOBAL _start 

SECTION .text 

_start:
    and rsp, -16 
    
    push 0
    push 0
    sub rsp, 20h
    xor r9, r9 
    lea r8, [REL _thread1]
    xor edx, edx 
    xor ecx, ecx 
    call CreateThread

.loop:
    TIMES 1000 pause 
jmp .loop

_thread1:
    TIMES 1000 pause
jmp _thread1

它所做的只是创建一个线程，指向循环中执行的pause 指令集。主线程也将执行一个类似但不同的循环。
循环的目的是让线程的RIP 发生变化，但仍然不在 Windows API 中。循环中的任何指令，只要它没有错误，都可以。我选择了pause，因为:)

组装和链接程序。
打开x64dbg，打开程序，然后设置Thread start和Thread entry事件。

现在按 F9 到达程序入口点，然后再次按 F9 放开它。调试器将收到新线程创建的通知。

请注意，执行在RtlUserThreadStart 的开头停止。我的 Windows 版本（Windows 7 之类的）总是如此。鉴于此答案开头的介绍，这是有道理的。
另请注意，线程入口点在rcx，这意味着它是RtlUserThreadStart 的第一个参数。

现在，这是 Windows 发送给调试器的事件，所以执行在这里停止是很自然的。
但是线程入口事件不存在，x64dbg在这里做什么？
您可以通过查看断点选项卡来揭开这个谜团。

您会看到调试器在线程入口点设置了一次性（即它将被调试器本身自动删除）断点。
因此，虽然 Windows 不支持在线程第一次开始执行其用户代码时生成调试事件，但调试器可以通过在线程实际启动之前放置断点来轻松模拟它。
请注意，这意味着调试器总是对线程启动事件做出反应，当在选项中禁用时，它不会停止、显示并等待您执行某项操作。

暂停和恢复线程不会更改线程入口点，该入口点在线程创建时固定。
x64dbg 有一个线程选项卡，允许用户暂停和恢复线程。使用它不会改变线程入口点，只是RIPs 仍然指向两个循环中的某个位置（存在用于简化此测试）。

如果线程是使用挂起标志创建的，则在线程恢复之前不会触发线程启动事件。
但是，如果在恢复线程之前，对Get/SetThreadContext 进行了两次调用以更改线程的RIP，那么RtlUserStartThread 将永远不会被执行（IDK 这个函数究竟做了什么，但是一个线程可以没有它） 线程启动事件永远不会触发。
执行将直接转到更改后的RIP。
我不确定这是否是 Windows 调试界面的遗留错误，可以通过在线程的第一个调度之前设置 TF 来生成线程启动事件（并在捕获相关异常时立即将其删除）。在debug/REing线程的时候，我通常做的就是在线程入口点（很容易搞定）或者被劫持的RIP（也很容易搞定，因为这种线程创建挂起，所以你知道有些东西是可疑的）。
如果程序很糟糕并且线程RIP 处的代码还不清楚（例如仍然被混淆），请使用硬件断点。

注意同样的整个过程也发生在进程创建中，完全相同（仅使用 PE 入口点而不是线程入口点）。

【讨论】：