对嘛... 在“当前进程”里不切换怎么能够看到其它进程的空间呢？ 另楼主先下载符号。 附上我原来一份代码的 PEB 遍历输出图：

嗨，想验证简单 整一驱动，直接操作那些地址，蓝了，就对了 :P

nt!_section_object 和 PE 里面的节没什么关系的。

这种示意图没必要当真的 呵呵

昨天不在，见到了 HD Moore。呵呵 楼主没想清楚在 Win-2000 下不支持所谓的 msr，nt!KiSystemService 例程就是最终''服务派遣''的实现者。此时 nt!KiFastCallEntry 函数虽然存在，但不会被调用(试验看就是这样的)，从反汇编来看即使被调用了它也只是前者的一个封装。Win-2000 之后，nt!KiFastCallEntry 函数变成了核心，所以''服务派遣''工作改由它来实现。但 idt 0x2E 的处理例程 (nt!KiSystemService) 依然存在，为的是方便那些 ''在不支持 SYSENTER / SYSCALL 的老处理器上安装 Win-XP+'' 的机器可以工作(它们还要依靠中断陷入内核)。此时 ...

楼主很细心，内核陷入的代码 (细节) 变动的相对频繁，这个问题要分情况说明。《软件调试》一书里列出的 nt!KiFastCallEntry 应该是 Win-2000 平台下的，大致如下：kd> u nt!KiFastCallEntrynt!KiFastCallEntry:804647dd 368b2540f0dfff  mov     esp,dword ptr ss:[0FFDFF040h]804647e4 8b642404        mov     esp,dword ptr [esp+4]804647e8 ...

.hh dg ↙↙

楼主什么平台？ Vista？ 不晓得了 很奇怪... 要不试着看看 idt 0x2d 那的信息还有不？ 这样： 先找到 idt 0x2d    2d: 805425fc (nt!KiDebugService) 0: kd> bp 805425fc 0: kd> gBreakpoint 0 hitnt!KiDebugService:805425fc 6a00            push    0 1: kd> kbChildEBP RetAddr  Args to ...

1. 是符号有问题 2. 其他的解决方法就是直接断那个地址 0: kd> rdmsr 176 msr[176] = 00000000`80541510 0: kd> bp 00000000`80541510 0: kd> bl 0 e 80541510 0001 (0001) nt!KiFastCallEntry

1. 看源码 2. 跟踪初始化流程 3. 用 Windbg 等看看符号信息 0: kd> dd KeServiceDescriptorTableShadow8055d6c0  80505460 00000000 0000011c 805058d48055d6d0  bf999e80 00000000 0000029b bf99ab908055d6e0  00000000 00000000 00000000 000000008055d6f0  00000000 00000000 00000000 000000008055d700  80505460 00000000 0000011c 805058d48055d710  ...