0: kd> !object \filesystem\ntfs Object: 89ddce20 Type: (89e63e70) Driver ObjectHeader: 89ddce08 (old version) HandleCount: 0 PointerCount: 8 Directory Object: e14f1838 Name: Ntfs 0: kd> dt nt!_driver_object 89ddce20 +0x000 Type : 4 +0x002 Size : 168 +0x004 DeviceObject : 0x89b4d318 _DEVICE_OBJECT +0x008 Flags : 0x92 +0x00c DriverStart : ...

^_^ 现在工作时间好紧 有空我再整理一些经典文章！

楼主想研发样本行为分析工具吗？Raymond 老师姓张 呵呵呵...

文件完整吗？

那篇文章是我用 LaTeX 整理的。之所以要整理是因为那是篇好文章，但是部分内容过时了。所以我整理的时候做了脚注更新，楼主啊，您没仔细看啊......在 Win-XP-SP1 时代是文章中的这样：0: kd> u ntdll!ZwReadFilentdll!NtReadFile:77f761e8 b8b7000000      mov     eax,0xb777f761ed ba0003fe7f      mov     edx,0x7ffe030077f761f2 ...

先不需要看 Intel 手册，楼主对操作系统的内存管理没有正确的概念，建议先阅读操作系统教材 —— 例如楼主可能没有分清逻辑地址、虚拟地址/线性地址、物理地址之间的关系。我简单抛块砖。1. 在实模式时代，CPU 限定了操作系统的寻址能力为 1MB。段基址左移 4位 累加 16位 偏移地址得出20位的物理地址（实模式下段寻址的上限）。在这种模式下缺乏必要的保护设计也没有高效的内存管理机制。2. 在保护模式时代，段寄存器的大小并没有变化仍然是16位，而偏移地址的“窗口”扩展到了32位。为了达到 2^32 的寻址能力，此时段寄存器（Selector 选择子）的实际作用是查表（GDT表），通过查表得出那被 Intel 为了兼容 80286 而打散的 32位 ...

呵呵~ ;)

稻香村 哈哈... 可惜了 中午吃了一个饼 没去吃稻香村。

刚吃完饭，看了一下 DUMP： 首先，栈上的参数确实是不一样，但这不是问题的所在： b8a60aa8 8084c103 0000001a 00003452 60839101 nt!KeBugCheckEx+0x1bb8a60c64 8084c24d 88cc8d88 88cc8d88 00000000 nt!MiDeleteAddressesInWorkingSet+0x155b8a60c84 8094b539 88cc8fb0 88cf12f8 88cf1538 nt!MmCleanProcessAddressSpace+0x111b8a60d0c 8094b68d 00000003 00000000 88cc8d88 nt!PspExitThread+0x5f1b8a60d24 ...

单从 dump 文件看隐藏的模块比较困难，除非是它的（Hook等）信息残留在栈上？ 如果有调试器事情就简单了一些，或者像 MJ、Joanna 等人的代码那样暴力找 PE / pdb 串等等。