嗨，黑客们。
AmdTools64.sys 是 AMD uProf 附带的已签名 Special Tools 驱动。无需 UAC 绕过，也不存在标准用户边界。一旦拿到句柄，MSR 索引就没有任何白名单限制，因此你可以随意读写任何 MSR。
读取侧本身就能破坏 KASLR。读取 IA32_LSTAR（0xC0000082），驱动就会免费把 ntoskrnl!KiSystemCall64 交给你。写入侧才是真正的问题所在。IA32_LSTAR 是 CPU 在每次系统调用时跳转到的地址，而该驱动允许普通用户覆盖它。把它指向你控制的代码，下一次系统调用就会以 CPL0 运行你的代码。SMEP 是唯一的障碍，因此该漏洞利用首先读取 IA32_LSTAR 来定位 ntoskrnl，从磁盘解析导入目录，找到几个用 mov cr4, rax 清除 SMEP 的 gadget，运行一小段 shellcode 将 SYSTEM 令牌复制到当前进程，并在退出时恢复 IA32_LSTAR，使机器继续正常工作。
只有两个 IOCTL，这就是全部内容。0xFFF02804 读取 MSR，0xFFF02808 写入 MSR，两者都使用 20 字节缓冲区，且没有索引校验。分发器只检查缓冲区长度。此外还有物理内存读写和用户态物理映射（0xFFF0281C、0xFFF02820、0xFFF028A4），但映射路径在任意 RAM 上可能触发 PFN_LIST_CORRUPT，因此这里使用的是 MSR 路径。
我在 Windows 10 x64 22H2（build 19045.6456）上使用 AMD uProf 5.3.521.0 进行了测试。驱动版本为 1.7.16.218。没有竞态条件，也没有堆布局操纵，每次运行都成功。该驱动随 uProf 一起分发，并安装在大量 AMD 机器上，因此它已经为你加载好了。截图是 Win10 机器：之前 whoami 是 subhan\windows10，之后是 nt authority\system。
在 Windows 11 26300 上，我可以安装驱动并读取 IA32_LSTAR，但当内存完整性开启时，对 LSTAR 的 wrmsr 会失败，VBS/HVCI 会拦截它。已知的 Win11 EPROCESS 布局为 UniqueProcessId 0x1D0、ActiveProcessLinks 0x1D8、Token 0x248、ImageFileName 0x338，并已在该版本中对照 PsGetProcessId、PsReferenceProcessToken 和 PsGetProcessImageFileName 进行核对。
其价值在于已签名的驱动和内核原语：管理员可以加载 AMD 驱动并获得 ring-0 代码执行能力。这里的 LSTAR 到 SYSTEM 的链路是漏洞利用部分，而不是新发现的驱动。
我于 2026-08-17 向 AMD PSIRT 报告了此事。然而，他们竭尽全力避免承认这一缺口，甚至在我的 Gmail 上封禁了我，使我无法再用自己的地址给他们发送邮件。这只是开始；今后，我不会再直接或通过他们的其他渠道与他们分享我关于 AMD 产品的发现。我会继续在这里分享一切。敬请关注，继续黑客之旅！
