pPMCurrent=(MODULE_ENTRY*)((DWORD)DriObject + 0x14);
应该是
pPMCurrent=(MODULE_ENTRY*)(*(DWORD*)((DWORD)DriObject + 0x14));吧..

[/CODE]多谢，sysnap牛，不过应该不是那的问题，因为这样就没问题：

[CODE]pPMCurrent=(MODULE_ENTRY*)((DWORD)DriObject + 0x14);
pcurrentDriObj=(DRIVER_OBJECT *)((DWORD)pPMCurrent - 0x14);

这样的话，DriObject和pcurrentDriObj就一样，就是同一个驱动对象

但是通过我的试验仍然有以下疑问：

1.

pPMFirst=pPMCurrent;
	DbgPrint("pmfirst: %x\n", pPMFirst);
	DbgPrint("pPMCurrent: %x\n", pPMCurrent);
	pPMCurrent =  (MODULE_ENTRY*)pPMCurrent->le_mod.Flink;
	pPMCurrent =  (MODULE_ENTRY*)pPMCurrent->le_mod.Blink;
	DbgPrint("pmfirst1: %x\n", pPMFirst);
	DbgPrint("pPMCurrent1: %x\n", pPMCurrent);

这里按说先Flink再Blink应该，应该是pPMCurrent不变，但是pPMCurrent变化了，这里不太清楚什么原因？LIST_ENTRY不是双向链表吗？往前走一步再退一步，为何就变了呢？

2.比如我现在知道sysaudio的驱动对象为：SysAudioDriObject
通过

SysAudioPM=(MODULE_ENTRY*)((DWORD)SysAudioDriObject + 0x14);

得到了sysaudio这个驱动对象的SysAudioPM，再通过

pPMCurrent =  (MODULE_ENTRY*)SysAudioPM->le_mod.Flink;
	DbgPrint("Current Driver File Name is: %ws\n",  pPMCurrent->driver_Name.Buffer);

可以显示出sysaudio驱动的驱动文件名为sysaudio.sys

但是下面我采用遍历pPMCurrent时，

for(int i=0;i<200;i++)
	{
		// This works on Windows XP SP1 and Windows 2003.
		if ((pPMCurrent->unk1 != 0x00000000) && (pPMCurrent->driver_Path.Length != 0))
		{
			UNICODE_STRING sysName;
			RtlInitUnicodeString(&sysName,L"sysaudio.sys");
			if(RtlCompareUnicodeString(&pPMCurrent->driver_Name,&sysName,TRUE)==0)
			{
[COLOR="Red"]此处的pPMFirst和SysAudioPM竟然不一样，驱动对象当然也不对，难道一个驱动对象有两个循环的链？[/COLOR]
				DbgPrint("pPMFirst is: %x\n", pPMFirst);
				pcurrentDriObj=(DRIVER_OBJECT *)((DWORD)pPMFirst - 0x14);				
 				DbgPrint("Driverobjectname: %x\n", pcurrentDriObj);
			}
		}
		pPMFirst=pPMCurrent;
		DbgPrint("pPMFirst is: %x\n", pPMFirst);
		pPMCurrent =  (MODULE_ENTRY*)pPMCurrent->le_mod.Flink;
	}

主要就这两个疑问，而且现在的问题是用windbg调试，看不到这些变量的值，符号文件也对的啊

这是windbg调试时的截图：




第一个图的pPMCurrent查看不到值，第二图显示pdb文件也正确啊，为何呢？

上传的附件：

• 111.JPG （33.46kb，192次下载）
• 2222.JPG （29.70kb，192次下载）

driversection貌似是个_LDR_DATA_TABLE_ENTRY这样的结构
http://nanothyll.spaces.live.com/Blog/cns!3ACF4E28F83553CB!172.entry

PLDR_DATA_TABLE_ENTRY pDriverSection;
        PLDR_DATA_TABLE_ENTRY  pListHead;
       
        pDriverSection = pDriverObject->DriverSection;

        pListHead = (PLDR_DATA_TABLE_ENTRY)pDriverObject->DriverSection;

         pDriverSection = (PLDR_DATA_TABLE_ENTRY)pListHead->InLoadOrderLinks.Flink;

  

        while(pDriverSection != pListHead)
        {
                DbgPrint("0x%x %ws",pDriverSection->DllBase,pDriverSection->FullDllName.Buffer);
               
                pDriverSection = (PLDR_DATA_TABLE_ENTRY)pDriverSection->InLoadOrderLinks.Flink;
        }

楼主看的是Rootkits - Subverting the Windows Kernel?

引用http://www.smatrix.org/bbs/read.php?tid=4701中间一段话
===============================================
现在再回过来看《Rootkits - Subverting the Windows Kernel》第七章，你就会觉得，他们所说的“MODULE_ENTRY”结构纯粹是给狗熊的玉米，因为我Google了所谓的 “MODULE_ENTRY”(DDK、导出符号中均没有这样的东西)，它的定义是这样的：
/*MODULE_ENTRY struct*/
typedef struct _MODULE_ENTRY {
    LIST_ENTRY le_mod;
    DWORD unknown[4];
    DWORD base;
    DWORD driver_start;
    DWORD sectionsize;
    UNICODE_STRING driver_Path;
    UNICODE_STRING driver_Name;
} MODULE_ENTRY, *PMODULE_ENTRY;

其实就是一个简化的“_LDR_DATA_TABLE_ENTRY”，搞出这种东西的意义也就是：“熊～ 给你一个玉米，吃去吧，你就别打破沙锅问到底了。”
我们答曰：想的美！
=========================================================

哎

MODULE_ENTRY应该算是一个简化的_LDR_DATA_TABLE_ENTRY结构

sysnap给的方法也是取出驱动文件名称，但是从_LDR_DATA_TABLE_ENTRY结构要得到驱动对象，还是要自己减去0x14吧，根据驱动加载的基地址，应该不能直接得到驱动对象吧，其实对我上面的问题，我主要是觉得应该也可以，但是结果却和我的期望不是一样的，所以有一些疑问

对，我是根据《Rootkits - Subverting the Windows Kernel》用的那个结构，怎么了？这个结构有问题吗？

搞出这种东西的意义也就是：“熊～ 给你一个玉米，吃去吧，你就别打破沙锅问到底了。”
我们答曰：想的美！

还有这是什么意思？不太明白，呵呵，就是说这种方法行不通？？