如何解决Windbg vtop 输出大于内存的物理地址
我正在研究 Windows 内核的内部结构，我正在研究的一件事是分页和虚拟地址在 Windows 中是如何工作的。我在尝试使用 windbg 的 !vtop 函数时发现奇怪的事情，我得到了一个不可能的物理地址？
例如，这是我的 !process 0 0 命令输出：
PROCESS fffffa8005319b30
SessionId: none Cid: 0104 Peb: 7fffffd8000 ParentCid: 0004
DirBase: a8df3000 ObjectTable: fffff8a0002f6df0 HandleCount: 29.
Image: smss.exe
当我运行 !vtop a8df3000 fffffa8005319b30 时。我得到以下结果：
lkd> !vtop a8df3000 fffffa8005319b30 Amd64VtoP: Virt fffffa80`05319b30,pagedir a8df3000 Amd64VtoP: PML4E a8df3fa8 Amd64VtoP: PDPE 2e54000 Amd64VtoP: PDE 2e55148 Amd64VtoP: Large page mapped phys 1`3eb19b30 Virtual address fffffa8001f07310 translates to physical address 13eb19b30
我遇到的问题是我运行此测试的虚拟机只有 4GB，而 13eb19b30 为 5,346,794,288...
当我运行 !dd 13eb19b30 和 dd fffffa8001f07310 时，我得到了相同的结果，所以 Windows 似乎能够以某种方式访问这个物理地址......有谁知道这是如何完成的？
解决方法
我看到您发布了这是 RESE，我也看到它并没有完全理解您要做什么。
我看到了一些差异
您似乎使用了 PFN a8df3000，但似乎 Windbg 似乎使用了 PFN of 187000
顺便说一句，pfn iirc 应该是 dirbase & 0xfffff000
对于虚拟地址，您似乎也在使用进程的 EPROCESS 地址
您确定这是您要使用的正确虚拟地址吗？
您似乎也在使用 lkd，它是本地内核调试提示
我希望你明白 lkd 不是真正的内核调试
,所以我想我终于能够对这个问题给出一个合理的答案。事实证明，vmware 似乎并没有真正暴露给 VM 连续内存，而是将其分段为不同的内存“运行”。我能够通过使用波动性来确认这一点：
$ python vol.py -f ~/Desktop/Win7SP1x64-d8737a34.vmss vmwareinfo --verbose | less Magic: 0xbad1bad1 (Version 1) Group count: 0x5c File Offset PhysMem Offset Size ----------- -------------- ---------- 0x000010000 0x000000000000 0xc0000000 0x0c0010000 0x000100000000 0xc0000000
这是一篇关于波动性的 github wiki 文章，其中详细介绍了：volatility
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
