【旧文章搬运】PsVoid中IrpCreateFile函数在Win7下蓝屏BUG分析及解决

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

原文发表于百度空间，2010-04-05
==========================================================================

这也许是我这个假期唯一做的跟Code有关的事了，已经一个多月没写代码了~~
问题是这样的，某同学A，在自己的工程中使用了PsVoid的部分驱动源码(感谢炉子开源~~)，提到里面的IrpCreateFile函数在Win7下始终会蓝屏，希望我能帮忙解决一下。于是，拿出调试器开始debug之旅~~
先简单介绍下，IrpCreateFile中PsVoid中Irp文件操作库中的一个函数，主要功能就是直接发IRP实现文件打开操作。该函数在WinXP/2003下均正常工作，但是在Win7下总是会蓝屏。写了个测试驱动扔到Vmware里，挂上调试器跟踪了一下，初步发现问题出在填充完IRP准备向下IoCallDriver时。现场如下：

kd> u IofCallDriver
nt!IofCallDriver:
83a7b458 8bff mov edi,edi
83a7b45a push ebp
83a7b45b 8bec mov ebp,esp
83a7b45d push ecx
83a7b45e a15c7aba83 mov eax,dword ptr [nt!pIofCallDriver (83ba7a5c)]
83a7b463 push esi
83a7b464 8bf1 mov esi,ecx //DeviceObject参数保存至esi
83a7b466 33c9 xor ecx,ecx
....
83a88492 8a08 mov cl,byte ptr [eax] //eax指向IoStackLocation，這里是判断MajorFunction
83a88494 mov dword ptr [eax+14h],esi //取刚才保存的DeviceObject参数，赋给IrpStack->DeviceObject
83a88497 80f916 cmp cl,16h
83a8849a jne nt!IofCallDriver+0x57 (83a884b0)
kd> p
nt!IofCallDriver+0x57:
83a884b0 8b4608 mov eax,dword ptr [esi+] //取DeviceObject->DriverObject，很不幸这里DeviceObject是NULL，于是杯具发生了。。。

大概就是这样的，DeviceObject是IrpCreateFile函数中的一个局部变量，当IoCallDriver时DeviceObject参数竟然是NULL，那取DeviceObject->DriverObject必然会蓝屏了~~

刚开始，我怀疑前面取到的DeviceObject就是NULL，代码如下：

DbgPrint("The Volume FileObject=0x%08X\n",pFile);
DeviceObject = pFile->Vpb->DeviceObject;
DbgPrint("pFile->Vpb->DeviceObject = 0x%08X\n",DeviceObject);
RealDevice = pFile->Vpb->RealDevice;
DbgPrint("pFile->Vpb->RealDevice = 0x%08X\n",RealDevice);

但是再次调试，发现这里是正常的，DeviceObject的值有效，不知怎的在准备IoCallDriver时变成了0，于是，再次调试~~

这次调试时，密切监视DeviceObject值的变化。终于发现，在走过以下代码之后，DeviceObject变成了0

RtlZeroMemory(&AuxData, sizeof(AUX_ACCESS_DATA));
ntStatus = SeCreateAccessState( &AccessState,
&AuxData,
DesiredAccess,
IoGetFileObjectGenericMapping());

在调用完SeCreateAccessState之后，DeviceObject变成了0，很莫名的问题啊。不过，目标已经锁定在SeCreateAccessState，再重启，再次来过。。。

过程如下：
在IrpCreateFile中：

//DeviceObject = pFile->Vpb->DeviceObject;
93f14759 8b4df4 mov ecx,dword ptr [ebp-0Ch]
93f1475c 8b5108 mov edx,dword ptr [ecx+]
93f1475f 8b4208 mov eax,dword ptr [edx+]
93f14762 898550ffffff mov dword ptr [ebp-0B0h],eax //DeviceObject保存在了ebp-b0处，如下:
kd> dd ebp-b0
807e1994 85bcb020 807e19b4 83e16b29 //可以看到,此时DeviceObject=85bcb020，是有效值
807e19a4 83b2ac02 3c8fb9d2 83b2ac02
807e19b4 807e19c0 83e16cca 534fa145 807e19d0

继续往下，一直到调用SeCreateAccessState之前，这个值都没有变化。

到了SeCreateAccessState，跟进去，发现这个函数只是直接调用了SeCreateAccessStateEx函数，WRK中源码如下，Win7中也没什么变化。

NTSTATUS
SeCreateAccessState(
__out PACCESS_STATE AccessState,
__out PAUX_ACCESS_DATA AuxData,
__in ACCESS_MASK DesiredAccess,
__in_opt PGENERIC_MAPPING GenericMapping
)
{
return SeCreateAccessStateEx (PsGetCurrentThread (),
PsGetCurrentProcess (),
AccessState,
AuxData,
DesiredAccess,
GenericMapping);
}

继续跟进至SeCreateAccessStateEx。。。

发现了两个memset调用~~

kd>
nt!SeCreateAccessStateEx+0x23:
83c6f633 e8e0440400 call nt!RtlMapGenericMask (83cb3b18)
83c6f638 8b7d10 mov edi,dword ptr [ebp+10h] //取第三个参数至edi
83c6f63b 6a74 push 74h
83c6f63d 6a00 push
83c6f63f push edi
83c6f640 e8fbe7e0ff call nt!memset (83a7de40) //将第三个参数AccessState指向的内存清零
83c6f645 8b7514 mov esi,dword ptr [ebp+14h] ////取第三个参数至esi
83c6f648 83c40c add esp,0Ch
83c6f64b 68c0000000 push 0C0h
83c6f650 6a00 push
83c6f652 push esi
83c6f653 e8e8e7e0ff call nt!memset (83a7de40) //将第四个参数AuxData指向的内存清零

这两句对应于以下代码：

RtlZeroMemory(AccessState, sizeof(ACCESS_STATE));
RtlZeroMemory(AuxData, sizeof(AUX_ACCESS_DATA));
//在SeCreateAccessStateEx这个函数中:
kd> p
nt!SeCreateAccessStateEx+0x3b:
83c3664b 68c0000000 push 0C0h
83c36650 6a00 push
83c36652 push esi
83c36653 e8e8e7e0ff call nt!memset (83a44e40) //准备清零
kd> dd esp l4
8cc678cc 8cc6793c 000000c0 8cc67958 //memset的参数
kd> dd 8cc67994 //此时局部变量DeviceObject的值，仍然是正确值
8cc67994 85bd4020 8cc679a0
8cc679a4 8cc679a0
kd> ? 8cc6793c+c0
Evaluate expression: - = 8cc679fc

也就是说，要memset清零的区域是从8cc6793c到8cc679fc，我们的局部变量的地址8cc67994就在这之间，于是被清零了。。。

为什么会出现这样一个结果呢？AuxData是一个结构体，该参数是从IrpCreateFile中传过来的，和DeviceObject都是局部变量。而现在，对AuxData的操作竟然影响到了DeviceObject，能想到的，就是从他们在栈中的布局入手了。

可以看到，AuxData位于ebp-108h处，与它相邻的局部变量是SourceString，位于ebp-ECh处。
也就是说，AuxData的实际大小只有0x108-0xEC=0x1C
而在SeCreateAccessStateEx中，我们明显可以看到系统认为这个结构的大小是0xC0，那么进行memset时，实际影响的范围是
从ebp-108h到ebp-108h+0xC0=ebp-48h，而我们的局部变量DeviceObject位于ebp-B0h处，正位于这个范围之间，于是就被清零了，同样受影响的还有位于该范围内的SourceString,NameBuffer,ntStatus,ObjectAttributes,DeviceObject,Event,Handle,AccessState等局部变量，如果要再使用这些变量的话，同样会出现问题，比如你要使用Handle的时候，发现竟然成无效句柄了。。。
所以，根本原因就是使用了不正确的结构定义，导致SeCreateAccessStateEx函数对局部变量AuxData清零初始化时同时修改了其它局部变量的值。
原因既然找到了，解决起来就容易了。经询问，A同学说这个结构是他根据PsVoid源码中的定义自己修改的，是一个未文档化的结构。恩，未文档化的东西，用起来难免会有不可靠的时候啊~~~
解决方案：修改AUX_ACCESS_DATA的定义就行了。该结构原来的定义为:

typedef struct _AUX_ACCESS_DATA {
PPRIVILEGE_SET PrivilegesUsed;
GENERIC_MAPPING GenericMapping;
ACCESS_MASK AccessesToAudit;
ACCESS_MASK MaximumAuditMask;
} AUX_ACCESS_DATA, *PAUX_ACCESS_DATA;

该结构现在的大小为0x1C，而Win7中该结构实际大小为0xC0。(0xC0-0x1C)/sizeof(ULONG)=0x29=41，那么修改定义如下：

typedef struct _AUX_ACCESS_DATA {
PPRIVILEGE_SET PrivilegesUsed;
GENERIC_MAPPING GenericMapping;
ACCESS_MASK AccessesToAudit;
ACCESS_MASK MaximumAuditMask;
ULONG Unknown[];
} AUX_ACCESS_DATA, *PAUX_ACCESS_DATA;

修改之后，经测试，蓝屏问题解决~~