ntdll导出函数在Windows10/11各子版本中是否保持一致？

问题背景 #

我计划Hook NTDLL的部分导出函数以实现监控，希望方案能在Windows 10和11的所有子版本中生效。在我检查过的所有计算机中，关注的导出函数均采用以下结构：

mov eax, functionID
mov edx, ptr_to_ntdll_wow64Transition
call edx
ret {} ; number of bytes to pop out
; followed by a NOP after the ret

这类结构的函数长度均为18字节（不含NOP），这意味着我可以通过将开头的mov eax, functionID替换为jmp指令来实现Hook，执行自定义逻辑后再执行复制的18字节代码。但要实现这一点，我需要确认NTDLL的导出函数在Windows各版本中足够稳定，请问有相关经验的人士可以分享吗？

经验总结 #

• 32位WOW64进程下的稳定性：你观察到的这个结构是32位进程调用64位NTDLL时的标准跳板逻辑——必须通过wow64Transition完成位数中转。这个结构在Win10 RTM到Win11 24H2的所有32位进程环境里基本保持一致：

  • 开头mov eax, functionID占5字节（B8 xx xx xx xx），刚好能容纳一个5字节的jmp指令，完美替换实现Hook。
  • 整个跳板核心代码固定18字节，后续的NOP是填充字节，不影响核心执行逻辑。
  • 仅在Win10 1507这类早期小众版本中，个别函数的ret弹出字节数有细微差异，但整体结构未变，不影响Hook方案落地。

• 64位原生进程的差异：如果你的场景包含64位原生进程，这个结构完全不适用——64位NTDLL导出函数没有WOW64中转逻辑，入口是直接的函数执行代码，结构差异极大，不能复用这套Hook方式。

• 版本迭代的风险控制：

  • Windows月度更新偶尔会微调NTDLL的代码布局，但这类WOW64跳板属于兼容性核心逻辑，微软不会轻易改动，否则会影响大量32位软件运行。
  • 目前Win11全版本都没有重构WOW64层的迹象，短期内这个结构不会失效。

• 落地前的验证建议：

  • 针对你关注的具体导出函数，批量收集Win10/11各主流子版本（1909、20H2、22H2、24H2等）的NTDLL样本，对比入口代码结构。
  • 在Hook逻辑中加入前置校验：替换jmp前先检查目标函数开头5字节是否为mov eax, xxx，后续代码是否符合你观察到的结构，避免因版本差异触发崩溃。

内容的提问来源于stack exchange，提问作者Nox