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

如何解决线程入口和线程启动之间的确切区别和关系是什么？

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

到目前为止，我了解 ["banana","hello","rodeo","feel","pine","skit","sky"] 是从一个角度定义的，例如，在 Windows 中，它始终是 thread start（用户），但在程序库级别，它可以是任何函数。但是在创建线程 ntdll.RtlUserThreadStart+21（系统）之前不会调用 thread start。

ntdll.NtCreateThreadEx+14 是作为参数提供给 thread entry 函数的（库，即导出或私有）函数。

使用 x64dbg 制作的带有线程（线程 ID、地址、收件人、发件人、大小、评论、派对）的调用堆栈示例：

thread create

解决方法

Windows 向调试器发送一组特定的事件，您可以在 WaitForDebugEvent 的文档中找到它们。
其中一个事件是 CREATE_THREAD_DEBUG_INFO，在 Windows 创建但尚未启动线程时发送。
在 Windows 中，进程和线程的创建发生在内核中，但它们的最终初始化步骤发生在用户空间中（除非它是一个微微进程，我们不会在这里讨论）。 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 有一个线程选项卡，允许用户挂起和恢复线程。使用它不会改变线程入口点，只是仍然指向两个循环中某处的 RIP s（存在以简化此测试）。

---

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

注意同样的事情也发生在进程创建中，完全一样（只有 PE 入口点而不是线程入口点）。

,

1. 相关术语不一定在常用术语中有准确的定义。您链接的 x64dbg 文档给出了以下定义：

线程入口

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

和

线程开始

在新线程即将运行时暂停。

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

2. 我倾向于认为，在这些术语中，线程启动必须始终发生在线程进入之前。在该线程启动之前，执行不能输入该线程的代码。事实上，我倾向于猜测线程启动事件是调试器可以发出信号的最后一个事件，它肯定出现在相关线程的线程入口之前。

3. 一般来说，我希望线程入口地址是线程入口点函数的地址，或者可能是其主体中第一条指令的地址（不一定是同一件事）。对于不同的入口点函数，这不能期望是一致的，并且对于程序的不同运行，对于相同的函数，它可能不相同。如果您认为自己看到了其他内容，请查阅该工具的文档。