Windbg vtop 输出大于内存的物理地址
Windbg vtop outputs physical address larger than memory
我正在研究 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
我正在研究 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