WINDOWS 驱动 寒江独钓 TDI带来的疑问

梦是多么的重要 2014-04-30 07:09:56

//VOID BuildQueryAddressIrp(PIRP irp,PIO_STACK_LOCATION stack,PDEVICE_OBJECT Tarodl)
//{
// FILE_FULL_EA_INFORMATION * filebuf = (FILE_FULL_EA_INFORMATION *)irp->AssociatedIrp.SystemBuffer;
// if (filebuf!=NULL)
// {
// if (filebuf->EaNameLength==TDI_TRANSPORT_ADDRESS_LENGTH && memcmp(filebuf->EaName,TdiTransportAddress,TDI_TRANSPORT_ADDRESS_LENGTH)==0)
// {
// QueryRequest=TdiBuildInternalDeviceControlIrp(TDI_QUERY_INFORMATION,Tarodl,stack->FileObject,NULL,NULL);
// }
// }
//
//}


寒江独钓 一书中,TDI过滤中有这么一个函数;本菜鸟 简化代码,实现一个简单功能,就获取 生成的地址,好,有一段生成一个IRP,成功编译后,发现启动失败。找原因。一个一个函数的注释,现在发现只要这个函数给注释掉了,就成功了。

另外:还有一个 代码 导致了 TDI过滤启动失败,代码段如下:


NTSTATUS DeviceControlDispath(PDEVICE_OBJECT Device ,PIRP irp)
{
NTSTATUS status;
PIO_STACK_LOCATION stack;
PDEVICE_OBJECT DeviceClass;
ULONG CurrentId;
int UserState;



HANDLE handl;
OBJECT_ATTRIBUTES objectatt;
CLIENT_ID currentid;
PEPROCESS EProcess;
InitializeObjectAttributes(&objectatt,0,0,0,0);



stack=IoGetCurrentIrpStackLocation(irp);
DeviceClass=GetDeviceClass(Device);

if (DeviceClass==NULL)
{
return STATUS_INVALID_PARAMETER;
}
switch(stack->MajorFunction)
{
case IRP_MJ_CREATE:

CurrentId=(ULONG)PsGetCurrentProcessId();
/* if (DeviceClass!=NULL)
{
BuildQueryAddressIrp(irp,stack,DeviceClass);
}*/

if(buf!=NULL)
{
CurrentId=(ULONG)PsGetCurrentProcessId();
;currentid.UniqueProcess=(HANDLE)CurrentId;
currentid.UniqueThread=0;

status=ZwOpenProcess(&handl,PROCESS_ALL_ACCESS,&objectatt,¤tid);
if (!NT_SUCCESS(status))
{
KdPrint(("打开进程出错"));
return status;
}
status=ObReferenceObjectByHandle(handl,FILE_READ_DATA,0,KernelMode,&EProcess,0);
if (NT_SUCCESS(status))
{
/*UCHAR *name=PsGetProcessImageFileName(EProcess);*/
UCHAR *name=(UCHAR *)EProcess+0x174;
if (memcmp(name,buf,sizeof(name))==0)
{
status=STATUS_INVALID_PARAMETER;
IoCompleteRequest(irp,IO_NO_INCREMENT);
return status;
}
}
IoSkipCurrentIrpStackLocation(irp);
status=IoCallDriver(DeviceClass,IO_NO_INCREMENT);
return status;
}

SetCompleteDispath(irp,DeviceClass);
break;


/*UCHAR *name=PsGetProcessImageFileName(EProcess);*/ 注释掉的 这个函数,通过EPROCESS 获得进程名,但是这是一个未公开的函数,声明也可以用。在XP系统中也是存在的。 好,有这个 启动也失败,那我不用这个函数
我用: UCHAR *name=(UCHAR *)EProcess+0x174; // 在XP系统中 这个结构的 0x174位置一般是 进程的名字.那么也失败了.这是为什么呢?
什么原因导致的呢?
在线坐等检查。
...全文
150 14 打赏 收藏 转发到动态 举报
写回复
用AI写文章
14 条回复
切换为时间正序
请发表友善的回复…
发表回复
  • 打赏
  • 举报
回复
引用 13 楼 zzdmfk 的回复:
觉得可能是vc编译选项没有设置好。
谁能提供个,确认无错的 编译设置?
路人乙2019 2014-05-02
  • 打赏
  • 举报
回复
觉得可能是vc编译选项没有设置好。
路人乙2019 2014-05-02
  • 打赏
  • 举报
回复
引用 8 楼 luoxuechengbing 的回复:
[quote=引用 7 楼 zzdmfk 的回复:] [quote=引用 6 楼 luoxuechengbing 的回复:] [quote=引用 4 楼 zzdmfk 的回复:] 解决了跟大家分享一下。
问题在于 /*UCHAR *name=PsGetProcessImageFileName(EProcess);*/ UCHAR *name=(UCHAR *)EProcess+0x174; if (memcmp(name,buf,sizeof(name))==0) {} PsGetProcessImageFileName memcmp EProcess 我现在猜想的是:用VS编译呢,这几个函数呢,编译运行后,采用的是 动态连接;然后去虚拟机运行了.所以找不到这几个函数; 然后我在虚拟机里用WDK编译了,且是在虚拟机里,成功了。 个人猜想是: VS呢,没有把 这几个函数 给生成静态链接,编译进去; WDK呢,编译进去了;;; 嗯,就这么简单; 应该计算机 专业出生的 更加清楚,我们所看到的 .exe .sys都是一个 进程,他的本质就是一个进程;集合了很多资源. 但是我们用VS编译后,在另外的机器上呢;运行,发现 某个资源块是空的;只是一个 类似 索引的东西。 当然,这是我的猜测;;不过VS确实没 生成一个 完全的静态链接。。 这道理呢,很简单。但是就是让我这么 纠结了 二天..........................[/quote]即便是你做更多年程序员以后,还可能遇到这种纠结的问题,人之常情。[/quote] 无力啊;;大侠工作几年了?[/quote]五年,现在辞职没做it了,谈不上大侠。
  • 打赏
  • 举报
回复
引用 11 楼 zzdmfk 的回复:
[quote=引用 8 楼 luoxuechengbing 的回复:] [quote=引用 7 楼 zzdmfk 的回复:] [quote=引用 6 楼 luoxuechengbing 的回复:] [quote=引用 4 楼 zzdmfk 的回复:] 解决了跟大家分享一下。
问题在于 /*UCHAR *name=PsGetProcessImageFileName(EProcess);*/ UCHAR *name=(UCHAR *)EProcess+0x174; if (memcmp(name,buf,sizeof(name))==0) {} PsGetProcessImageFileName memcmp EProcess 我现在猜想的是:用VS编译呢,这几个函数呢,编译运行后,采用的是 动态连接;然后去虚拟机运行了.所以找不到这几个函数; 然后我在虚拟机里用WDK编译了,且是在虚拟机里,成功了。 个人猜想是: VS呢,没有把 这几个函数 给生成静态链接,编译进去; WDK呢,编译进去了;;; 嗯,就这么简单; 应该计算机 专业出生的 更加清楚,我们所看到的 .exe .sys都是一个 进程,他的本质就是一个进程;集合了很多资源. 但是我们用VS编译后,在另外的机器上呢;运行,发现 某个资源块是空的;只是一个 类似 索引的东西。 当然,这是我的猜测;;不过VS确实没 生成一个 完全的静态链接。。 这道理呢,很简单。但是就是让我这么 纠结了 二天..........................[/quote]即便是你做更多年程序员以后,还可能遇到这种纠结的问题,人之常情。[/quote] 无力啊;;大侠工作几年了?[/quote]五年,现在辞职没做it了,谈不上大侠。[/quote] 哦哦。。那你看下 我这问题 到底是不是应为 VC没有吧 函数给 嵌入到进程里面呢? 我自己猜测是这样,但是楼上否决了。。。你看~
  • 打赏
  • 举报
回复
引用 4 楼 zzdmfk 的回复:
解决了跟大家分享一下。
问题在于 /*UCHAR *name=PsGetProcessImageFileName(EProcess);*/ UCHAR *name=(UCHAR *)EProcess+0x174; if (memcmp(name,buf,sizeof(name))==0) {} PsGetProcessImageFileName memcmp EProcess 我现在猜想的是:用VS编译呢,这几个函数呢,编译运行后,采用的是 动态连接;然后去虚拟机运行了.所以找不到这几个函数; 然后我在虚拟机里用WDK编译了,且是在虚拟机里,成功了。 个人猜想是: VS呢,没有把 这几个函数 给生成静态链接,编译进去; WDK呢,编译进去了;;; 嗯,就这么简单; 应该计算机 专业出生的 更加清楚,我们所看到的 .exe .sys都是一个 进程,他的本质就是一个进程;集合了很多资源. 但是我们用VS编译后,在另外的机器上呢;运行,发现 某个资源块是空的;只是一个 类似 索引的东西。 当然,这是我的猜测;;不过VS确实没 生成一个 完全的静态链接。。 这道理呢,很简单。但是就是让我这么 纠结了 二天..........................
  • 打赏
  • 举报
回复
问题解决,建议以后 编译驱动不要用 VS了,尽量用WDK吧。太坑爹了
  • 打赏
  • 举报
回复
引用 9 楼 zhaoning_xueye 的回复:
[quote=引用 6 楼 luoxuechengbing 的回复:] [quote=引用 4 楼 zzdmfk 的回复:] 解决了跟大家分享一下。
问题在于 /*UCHAR *name=PsGetProcessImageFileName(EProcess);*/ UCHAR *name=(UCHAR *)EProcess+0x174; if (memcmp(name,buf,sizeof(name))==0) {} PsGetProcessImageFileName memcmp EProcess 我现在猜想的是:用VS编译呢,这几个函数呢,编译运行后,采用的是 动态连接;然后去虚拟机运行了.所以找不到这几个函数; 然后我在虚拟机里用WDK编译了,且是在虚拟机里,成功了。 个人猜想是: VS呢,没有把 这几个函数 给生成静态链接,编译进去; WDK呢,编译进去了;;; 嗯,就这么简单; 应该计算机 专业出生的 更加清楚,我们所看到的 .exe .sys都是一个 进程,他的本质就是一个进程;集合了很多资源. 但是我们用VS编译后,在另外的机器上呢;运行,发现 某个资源块是空的;只是一个 类似 索引的东西。 当然,这是我的猜测;;不过VS确实没 生成一个 完全的静态链接。。 这道理呢,很简单。但是就是让我这么 纠结了 二天..........................[/quote] 我敢保证不是这样的...[/quote] 哦,这位大侠;;;那你说说是怎样的; 状况是 vs编译,在虚拟机中100%启动失败; 然而wdk编译呢,启动是 100%成功; 大侠说说你的观点吧
zhaoning_xueye 2014-05-01
  • 打赏
  • 举报
回复
引用 6 楼 luoxuechengbing 的回复:
[quote=引用 4 楼 zzdmfk 的回复:] 解决了跟大家分享一下。
问题在于 /*UCHAR *name=PsGetProcessImageFileName(EProcess);*/ UCHAR *name=(UCHAR *)EProcess+0x174; if (memcmp(name,buf,sizeof(name))==0) {} PsGetProcessImageFileName memcmp EProcess 我现在猜想的是:用VS编译呢,这几个函数呢,编译运行后,采用的是 动态连接;然后去虚拟机运行了.所以找不到这几个函数; 然后我在虚拟机里用WDK编译了,且是在虚拟机里,成功了。 个人猜想是: VS呢,没有把 这几个函数 给生成静态链接,编译进去; WDK呢,编译进去了;;; 嗯,就这么简单; 应该计算机 专业出生的 更加清楚,我们所看到的 .exe .sys都是一个 进程,他的本质就是一个进程;集合了很多资源. 但是我们用VS编译后,在另外的机器上呢;运行,发现 某个资源块是空的;只是一个 类似 索引的东西。 当然,这是我的猜测;;不过VS确实没 生成一个 完全的静态链接。。 这道理呢,很简单。但是就是让我这么 纠结了 二天..........................[/quote] 我敢保证不是这样的...
  • 打赏
  • 举报
回复
引用 7 楼 zzdmfk 的回复:
[quote=引用 6 楼 luoxuechengbing 的回复:] [quote=引用 4 楼 zzdmfk 的回复:] 解决了跟大家分享一下。
问题在于 /*UCHAR *name=PsGetProcessImageFileName(EProcess);*/ UCHAR *name=(UCHAR *)EProcess+0x174; if (memcmp(name,buf,sizeof(name))==0) {} PsGetProcessImageFileName memcmp EProcess 我现在猜想的是:用VS编译呢,这几个函数呢,编译运行后,采用的是 动态连接;然后去虚拟机运行了.所以找不到这几个函数; 然后我在虚拟机里用WDK编译了,且是在虚拟机里,成功了。 个人猜想是: VS呢,没有把 这几个函数 给生成静态链接,编译进去; WDK呢,编译进去了;;; 嗯,就这么简单; 应该计算机 专业出生的 更加清楚,我们所看到的 .exe .sys都是一个 进程,他的本质就是一个进程;集合了很多资源. 但是我们用VS编译后,在另外的机器上呢;运行,发现 某个资源块是空的;只是一个 类似 索引的东西。 当然,这是我的猜测;;不过VS确实没 生成一个 完全的静态链接。。 这道理呢,很简单。但是就是让我这么 纠结了 二天..........................[/quote]即便是你做更多年程序员以后,还可能遇到这种纠结的问题,人之常情。[/quote] 无力啊;;大侠工作几年了?
路人乙2019 2014-05-01
  • 打赏
  • 举报
回复
引用 6 楼 luoxuechengbing 的回复:
[quote=引用 4 楼 zzdmfk 的回复:] 解决了跟大家分享一下。
问题在于 /*UCHAR *name=PsGetProcessImageFileName(EProcess);*/ UCHAR *name=(UCHAR *)EProcess+0x174; if (memcmp(name,buf,sizeof(name))==0) {} PsGetProcessImageFileName memcmp EProcess 我现在猜想的是:用VS编译呢,这几个函数呢,编译运行后,采用的是 动态连接;然后去虚拟机运行了.所以找不到这几个函数; 然后我在虚拟机里用WDK编译了,且是在虚拟机里,成功了。 个人猜想是: VS呢,没有把 这几个函数 给生成静态链接,编译进去; WDK呢,编译进去了;;; 嗯,就这么简单; 应该计算机 专业出生的 更加清楚,我们所看到的 .exe .sys都是一个 进程,他的本质就是一个进程;集合了很多资源. 但是我们用VS编译后,在另外的机器上呢;运行,发现 某个资源块是空的;只是一个 类似 索引的东西。 当然,这是我的猜测;;不过VS确实没 生成一个 完全的静态链接。。 这道理呢,很简单。但是就是让我这么 纠结了 二天..........................[/quote]即便是你做更多年程序员以后,还可能遇到这种纠结的问题,人之常情。
路人乙2019 2014-04-30
  • 打赏
  • 举报
回复
解决了跟大家分享一下。
  • 打赏
  • 举报
回复
引用 1 楼 zzdmfk 的回复:
这个比较难,我也看过此书,自始至终最后几章还是没完全搞明白,且很多不能应用于win7。也许第一个函数是个回调函数,有默认的实现。第二个是不是权限问题,你有没有用windbg下断点调试过?
问题已经定位了,一个小时后能解决,请教了几位 大侠;远程帮忙看了下,发现依旧是个人不足。稍后 说明真相; 不过大侠们的答案不一致,还在验证中》
  • 打赏
  • 举报
回复
引用 1 楼 zzdmfk 的回复:
这个比较难,我也看过此书,自始至终最后几章还是没完全搞明白,且很多不能应用于win7。也许第一个函数是个回调函数,有默认的实现。第二个是不是权限问题,你有没有用windbg下断点调试过?
................启动都启动不了,必须没断点调试过》
路人乙2019 2014-04-30
  • 打赏
  • 举报
回复
这个比较难,我也看过此书,自始至终最后几章还是没完全搞明白,且很多不能应用于win7。也许第一个函数是个回调函数,有默认的实现。第二个是不是权限问题,你有没有用windbg下断点调试过?
编写Windows内核程序,就意味着这个程序可以执行任意指令,可以访问计算机所有的软件、硬件资源。因此,稍有不慎就有可能将系统变得不稳定。Windows的设计者设计了各种驱动模型或者框架,如NT式内核驱动模型、WDM框架和新推出的WDF框架。在这些模型框架下编程,就使内核编程变得简单,同样也降低了内核程序崩溃的机会。其实,Windows驱动程序员和黑客都在写内核程序,唯一不同的是驱动程序员按照微软设计的模型写程序,而黑客可以不按照这些框架写。Windows设计的这些框架,可以将操作系统的原理隐藏起来,只暴露一些接口,驱动程序员只要把这些接口写好就可以了。从这个角度看,驱动开发并不难,尤其是读完本书后,更会觉得不难了。但是想完成一些特殊的功能,如内核级隐藏进程等,Windows的这些框架就没什么用处了,程序员就需要对Windows内核有全面的了解,通过直接修改Windows内核来实现这些目的。往往黑客对这种技术乐此不疲,通过修改Windows内核,你会发现你的程序几乎无所不能。   编写内核程序是一件很痛苦的事情,回想起这些年学习内核程序开发的经历,真是感慨万千。就如同谭文所说:编写内核程序的人从某种程度讲是孤独的。当一个经验并不丰富的小程序员面对庞大复杂的并且不开源的Windows框架时,那是一种怎样的无助感啊!谭文是我比较钦佩的程序员之一,他对技术非常执着,并且精力充沛。内核程序的知识涉及面非常广,不同类别的内核程序差别也特别大,他几乎都有所涉猎。相信读者在读完这本书后,能对Windows内核开发有比较详细的了解,同时也能结合书中的实例写出很优秀的内核程序了 本书从Windows内核编程出发,全面系统地介绍了串口、键盘、磁盘、文件系统、网络等相关的Windows内核模块的编程技术,以及基于这些技术实现的输入密码保护、防毒引擎、文件加密、网络嗅探、网络防火墙等信息安全软件的核心组件的具体编程。主要知识重点包括:Windows串口与键盘过滤驱动Windows虚拟存储设备与存储设备过滤驱动Windows文件系统过滤驱动、文件系统透明加密/解密驱动Windows各类网络驱动(包括TDI过滤驱动及3类NDIS驱动),以及最新的WDF驱动开发模型。有助于读者熟悉Windows内核驱动的体系结构,并精通信息安全类的内核编程技术。本书的大部分代码具有广泛的兼容性,适合从Windows 2000一直到目前最新的Windows 7 Beta版。  本书则基本上介绍的是正统的内核编程技术,是微软在内核编程中给信息安全软件开发者提供的相关接口的大集合,是名门正派的技术,不沾邪气。一个好的内核程序员,“正邪兼修”是有必要的。   本书既适合于有志于成为软件程序员的学生使用,也适合于希望加强自己的技术实力的Windows程序员阅读,同时更适合于从事信息安全行业的Windows软件的开发者作为手头参考。

2,640

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC 硬件/系统
社区管理员
  • 硬件/系统社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧