上传的附件：

• 无标题.jpg （72.04kb，219次下载）

[QUOTE=KiDebug;947886]　　　　　　　[/QUOTE]

多谢KiDebug这幅图，很明了~~~，感觉很像利用DRIVER_OBJECT的DriverSection成员
来获取LDR_DATA_TABLE_ENTRY~。想问问这幅图在哪里找的？

不知道有没有问题1和问题2的答案呢？

这图做PPT时自己画的，利用的是内核中FS指向kpcr。

1、对于combojiang大侠给出的系统地址空间分布，有没有windows版本或者是平台
     的差异性？还是说这是intel本身的架构？
特指windows平台。“我们的驱动程序就是加载在系统布局图的80000000h到a0000000h的区间中”这不准确，看了WRK中NtLoadDriver的实现，确定加载驱动基址是在MiLoadImageSection函数中

以下是WRK中部分代码（有删除）：
FirstPte = MiReserveSystemPtes (NumberOfPtes, SystemPteSpace);
PointerPte = FirstPte;
SystemVa = MiGetVirtualAddressMappedByPte (PointerPte);
*ImageBaseAddress = SystemVa;

MiReserveSystemPtes 从系统PTE中申请NumberOfPtes个页面，系统PTE的起始地址由MmNonPagedSystemStart指定，不会低于MM_LOWEST_NONPAGED_SYSTEM_START（0xEB000000），所以我们的驱动程序加载地址不会小于0xEB000000（当然，对ntoskrnl不适用）。系统PTE的结束地址在MmNonPagedPoolExpansionStart之前，另外还有一个叫系统PTE额外区，详细介绍可以参考《Windows内核原理与实现》P223 4.2.3系统PTE区域的管理

ImageBaseAddress 为驱动加载的基址

以ntkrnlpa.5.1.2600.6055为例，在805A3C0E处调用MiReserveSystemPtes，返回值左移9位就是驱动的加载基址，

PAGE:805A3C0E                 call    _MiReserveSystemPtes@8

windbg中调用堆栈，
kd> kp
ChildEBP RetAddr  
f7a40ac4 805a4d81 nt!MiLoadImageSection+0xea
f7a40c6c 80577595 nt!MmLoadSystemImage+0x4c9
f7a40d4c 805779a1 nt!IopLoadDriver+0x371
f7a40d74 80535ca0 nt!IopLoadUnloadDriver+0x45
f7a40dac 805c72c2 nt!ExpWorkerThread+0x100
f7a40ddc 80542e82 nt!PspSystemThreadStartup+0x34
00000000 00000000 nt!KiThreadStartup+0x16

2、下面combojiang大侠补充说，并没有考虑到多核的情况是怎么一回事？
ntoskrnl.exe单核，没有启用PAE
ntkrnlpa.exe单核，启用PAE
ntkrnlmp.exe多核，没有启用PAE
ntkrpamp.exe多核，启用PAE

Intel的CPU，双核情况下，系统安装时将ntkrnlmp.exe拷贝为ntoskrnl.exe，系统加载时加载这个（原来是ntkrnlmp.exe的）ntoskrnl.exe。
所以Intel双核情况下，内核文件名仍然是ntoskrnl.exe，但是其源文件名是ntkrnlmp.exe，如果加载符号，符号文件名也是ntkrnlmp.pdb。
因此单核双核下都叫ntoskrnl.exe是正确的。

http://bbs.pediy.com/showthread.php?t=97717

3、下面回复中，说到了内核中FS指向的问题，不知道有没有详细一点的资料？
内核中FS指向kpcr，用户态指向TEB

再次感谢KiDebug，我终于明白为什么我的驱动程序是装载到0xf9xxxxxx的位置去。

但是我还有疑问要补充。

对于1的解释，意思是不是说我们写的驱动装载区域有2个 ？

对于问题2的解析俺在《软件调试》已经有了解，其实俺想问的是：代码的意思应该是
从我们驱动DriverEntry例程的返回地址往前搜索PE特征0x00905a4d~~.，这个返回地址
其实就是在ntkrnlpa（ntoskrnl）中的代码段中的IopLoadDriver这个没有导出的函数
里的某个位置（nt!IopLoadDriver+0x66d）。也就是说，只要是使用ntkrnlpa（ntoskrnl）
中的IopLoadDriver来调用我们的DriverEntry入口例程的话，那么这种方法应该是没
有局限性的吧~，但是下面的讨论却说存在多核的差异性~~，不知道是不是俺在哪里理解错了？

对驱动加载地址刚才说错了，编辑了一下。。。

“从我们驱动DriverEntry例程的返回地址往前搜索PE特征"PE\0\0"~~.，”这个我觉得是可以的。下面的“的确没考虑多核的情况。”就无从考证combojiang当时的想法了。。

真的很感谢KiDebug不厌其烦的解答俺这个菜鸟的问题~~，希望combojiang大侠能看到俺的帖子，进来说说当时的想法~~~

KiDebug的图是用什么工具画的？很漂亮啊~~

用的Visio 2007，呵呵。。

感谢KiDebug的解答