ThreadHideFromDebugger无效，因内核仅将其作为枚举提示位，不阻止DebugActiveProcess等调试操作；现代调试器完全无视该标志，且需正确权限与句柄才能调用NtSetInformationThread。
不能靠 NtSetInformationThread + ThreadHideFromDebugger 真正防附加，它只对部分旧版调试器（如 OllyDbg 1.x）有干扰效果，现代调试器（x64dbg、WinDbg、VS Debugger）完全无视该标志，且 Windows 内核本身不强制执行此隐藏逻辑。
为什么 ThreadHideFromDebugger 实际无效
Windows 内核中 ThreadHideFromDebugger 并非安全机制，而是一个仅影响调试器“枚举线程列表”的提示位。内核不会阻止调试器调用 DebugActiveProcess 或直接 attach 到进程，只要目标进程可被打开（PROCESS_ALL_ACCESS 权限足够），附加就成功。
- 该标志仅在调试器调用
Toolhelp32ReadProcessMemory或EnumThreads类接口时可能跳过该线程 —— 但调试器根本不需要枚举就能 attach - 从 Windows Vista 起，内核明确忽略该标志对调试权限的任何约束；Windows 10/11 中该行为更彻底
- 即使设了标志，用
OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid)+DebugActiveProcess(pid)仍 100% 成功
常见误用：NtSetInformationThread 调用失败或无反应
很多代码直接硬调 NtSetInformationThread 却没检查前置条件，导致静默失败：
- 必须使用
THREAD_SET_INFORMATION权限打开线程句柄（不能用GetCurrentThread()的伪句柄，要OpenThread(THREAD_SET_INFORMATION, FALSE, GetCurrentThreadId())） -
NtSetInformationThread是未文档化函数，需手动解析ntdll.dll导出，且不同 Windows 版本函数签名略有差异（如 Win11 22H2 后部分结构体对齐变化） - 传入的
ThreadInformationClass必须是ThreadHideFromDebugger (0x11)，但某些内核版本会直接返回STATUS_INVALID_PARAMETER（尤其在 WOW64 进程中） - 没有 SEH 或异常处理时，非法参数可能触发 STATUS_ACCESS_VIOLATION，而非返回错误码
真正影响调试附加的环节在哪
能实际提高附加门槛的，是控制调试权限和进程对象访问控制，而非线程级隐藏：
立即学习“C++免费学习笔记（深入）”；
- 调用
SetKernelObjectSecurity修改进程句柄的 DACL，移除DEBUG_PROCESS权限（需 SeDebugPrivilege） - 在启动时用
SetInformationJobObject配合JobObjectBasicUIRestrictions或JobObjectSecurityLimitInformation限制调试行为 - 检测父进程是否为已知调试器（如检查
GetParentProcessId+QueryFullProcessImageName匹配devenv.exe、windbg.exe） - 频繁轮询
NtQueryInformationProcess(..., ProcessDebugPort, ...)，若返回非零值说明已被附加 —— 这比隐藏线程更可靠
线程隐藏只是表层障眼法，内核调试接口（如 DbgkpPostFakeThread）和 ETW 事件（Microsoft-Windows-Kernel-Process）都能绕过它。真要防附加，得从权限控制、反调试检测、运行时混淆三方面入手，单靠一个 ThreadHideFromDebugger 标志，连入门门槛都算不上。
