| | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | |      |
|
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与技巧都不行,郁闷~~~ 
今天就到这里吧,一点了,睡觉......
|
|
|
|
|