2007 年 12 月
      1
2345678
9101112131415
16171819202122
23242526272829
3031   
上一年下一年   上一月下一月

站点统计
日志:516 篇
评论:331 篇
留言:31 篇
收藏夹:0 个书签
会员数:149 人

最新评论
上海地区广告伞太阳伞专业...
没附件了郁闷,还在的话麻...
已经发送到你的邮箱了,请...
写了一个进程间通讯的类....
行啊,二博客都一样
已经发送了附件到你的邮箱...
老马写的..可惜没的附件...
欢迎!
谢谢了。
第一次走进您的博客,^_...


filedisk分析手记之一   [ 2007-10-20 | 作者:马大哈 | 来自:本站原创]

我成功编译filedisk出来后,就对一个问题比较关心了:

为什么只能使用磁盘平面映象文件来作为一个映射目标,而不能使用一个逻辑驱动器?

现在使用如下语法就可以实现虚拟一个分区出来:

filedisk /mount 0 D:\temp\filedisk.img 128M Z:

我想的是,如果能够直接使用一个已经存在的逻辑驱动器就好了~~~就如系统自带的SUBST命令一样.

不过SUBST命令貌似只是建立了同一设备的不同符号连接,而并未再弄了个IFS,因此就无法实现完全控制读写....有空把那DefineDosDevice研究一下看看

扯回来.

分析了一下源代码,发现读文件操作的相关过程如下:

ZwReadFile(
device_extension->file_handle,
NULL,
NULL,
NULL,
&irp->IoStatus,
buffer,
io_stack->Parameters.Read.Length,
&io_stack->Parameters.Read.ByteOffset,
NULL
);

它的声明如下:

ZwReadFile(
IN HANDLE FileHandle,
IN HANDLE Event, /* optional */
IN PIO_APC_ROUTINE ApcRoutine, /* optional */
IN PVOID ApcContext, /* optional */
OUT PIO_STATUS_BLOCK IoStatusBlock,
OUT PVOID Buffer,
IN ULONG Length,
IN PLARGE_INTEGER ByteOffset, /* optional */
IN PULONG Key /* optional */
);

这个API其实就是应用层下的ReadFile与ReadFileEx最终所调用的API,因此也有些许似曾相识的感觉...

第一个参数"device_extension->file_handle",就是驱动所需要的那个平面映象文件的句柄

这个句柄已经在之前打开了;

"&irp->IoStatus"这个参数大约是用于输出执行状态;

buffer是个指针,指向了一块缓冲区,用于保存读取回来的内容(如果有的话);

"io_stack->Parameters.Read.Length",这个就是读取的长度;

"&io_stack->Parameters.Read.ByteOffset"这个,就是偏移量.

整个过程到了这一步,已经很容易看明白了.

原因就是在于这个读取方式.

我还没有跟踪过这个驱动(再说了,也还没那功底... ),不过估计IRP包传到这个驱动时,已经被系统上面几层的"某些部件"处理成为了根本的对磁盘的物理读写了.

看看从IRP包那里得来的参数吧:偏移量,长度,仅此而已.

因此,如果给出一块单独的磁盘空间供读写,就可以用ZwReadFile/ZwWriteFile非常容易地实现"filedisk"了.

那么从这个角度来看,貌似要实现直接读写现有分区,只需要找到分区的起始偏移量后再物理读写就差不多了...

没办法上网,烦~~~~

想查下物理分区读写的API与技巧都不行,郁闷~~~

今天就到这里吧,一点了,睡觉......

标记一下:如何在DDK环境下编译驱动 可怕的超级电脑(21日梦)

暂时没有评论