Development of filter driver for Windows File System

File System drivers are one of the most complex types of drivers in windows. I can't hold too much hope for the help in ifsddk. In my experience, the DDK help related to the file system is extremely simple, and many important parts have only been omitted. If ifsddk is installed, read the documents under srcfilesysosr_docs. Not just the help of DDK.

There are few books on file system-driven development. I have only seen two or three chapters in a driver development book translated by Hou Jie. It is only applicable to the VxD driver of 9X. I have met an English document on the NT file system. I don't even remember the titles of these two books.

If you want to develop a 9x or NT file system driver, we recommend that you download the book mentioned above online. Both books have free electronic version downloads. If you want to develop a file system driver for windows2000windowsxpwindow2003, read this tutorial. This tutorial only describes the file system filter driver. However, if you want to develop a new file system driver, this tutorial will be of great help to you.

Before learning file system driver development, you should install ifsddk on the machine. The more advanced the DDK version is, the more system calls are provided in the header file. It is often asked whether the driver compiled by xpddk can run on 2000. I think it can be explained as follows: the DDK of the advanced version can always compile the code of the low-level driver, and the obtained binary version can always run on the low-level system. However
In turn, it may not be possible. If you want to write a driver for a low-level system on an advanced system, pay attention to calling only some system calls on the low-level system.
Ifsddk can be downloaded for free on some FTP.

I use ifs DDK for XP, but one of the two machines I used for development is Windows 2000 and the other is Windows 2003. I try my best to make the compiled driver pass the test on any of the 2000x2003 systems.

There are many introductions on how to install and configure DDK and develop drivers in VC. After ifsddk is installed, the filesys directory under the src directory contains an example of a file system driver. By reading this code, you can quickly learn file system driver development.

The sfilter in the filter directory is an example of a file system filter driver. Another filespy is completely complicated by the code in this example.

For more information about how to compile this example with DDK, see related documents.

After the file system filter driver is compiled, you get a file with the extension sys. At the same time, you need to write a. inf file to install the driver. I will not discuss the details of the. inf file here. You can directly use the INF file under the sfilter directory to modify it.

Right-click the INF file and choose "Install" from the shortcut menu to install the filter driver. However, it takes effect only after the system is restarted.

If the blue screen cannot be started after restart, you can use other methods to boot the system and then delete your. SYS file in the system32drivers directory and restart the system. In this case, I tried to use the security mode and returned

It is a blue screen. So I had to install two 2000 systems on the machine later. In the case of two systems, one system crashes and starts with another system. Just delete the original driver.

To debug the code, install SoftICE.

Open the file sources under the sfilter directory (this file does not have an extension) and add a line browser_info = 1.

Then open the symbol loader, file-> open, select the compiled XXX. sys, modul-> load, modul-> translate, and then debug the program.

Open SoftICE and enter file * to view the code.

If you are ready, we can start to figure out the development of the filter driver for the Windows file system.

Section 1st Hello world, driver object and device object

The driver object mentioned here is a data structure named driver_object in DDK. Any driver corresponds to a driver_object. How can I obtain the driver_object corresponding to the driver I wrote? The driver entry function is DriverEntry. Therefore, when you write a driver, you will write the following code:

Ntstatus DriverEntry (in pdriver_object driverobject, in punicode_string registrypath)
{
}

This function is equivalent to the main () that you commonly use in C language (). in is a meaningless macro, which only indicates that the following parameter is an input, and the corresponding out parameter indicates that this parameter is a return. Reference is not used here, so if you want to return results in the parameter, all input pointers.

Driverobject is the driver_object corresponding to the driver you wrote. It is allocated when the system loads your driver. Registerypath is the Registry path used to record Driver-related parameters.

Driverobject has a set of function pointers called dispatch functions.

The main task of development driver is to write these dispatch functions by yourself. When the system uses your driver, it will send IRP to your do (this is the way all windows drivers work together ). Your task is to process these requests in the dispatch function. You can make the IRP fail, return it successfully, modify the IRPs, or even issue the IRPs by yourself.

The device object refers to device_object. Do.

But in fact, Each IRP is sent to do. Only the IRP of the DO generated by the driver,
Will be sent to the driver for processing.

When an application opens a file and reads and writes a file, the Windows system converts these requests into IRPs and sends them to the file system driver.

The file system filter driver can filter these IRPs. In this way, you have the ability to capture and change file system operations.

File Systems (FS) such as FAT32 and NTFS may generate several devices. First, the file system driver itself often generates a control device (CDO). The main task of this device is to modify the internal configuration of the entire driver. Therefore, a driver only corresponds to one CDO.

Another device is the volume mounted by the file system. One FS may have multiple volume volumes, or none of them. To explain, if you have four partitions: C:, D:, E:, F. C:, D: Is NTFS, E:, F: Is fat32. then C:, D: Is the two volume device objects of fat.

In fact, "C:" Is the Symbolic Link name of the device. Instead of the real device name. You can open the symbolic links viewer and you can see:

C: deviceharddiskvolume1

Therefore, the device name is "deviceharddiskvolume1 ".

It can also be seen that the file system driver generates a deviceobject for each volume, rather than for each file. In fact, the IRPs for reading and writing files are all sent to the volume device object. It does not generate a "file device object ".

Having mastered these concepts, we now use simple code to generate our CDO, which is the first step for us to develop a file system driver.

I don't like Microsoft-style code. It's too long and ugly. I have redefined most data structures and functions. For this reason, I wrote a header file named WDF. h to help me convert the file. Interested readers can send an email to ask for this file. It doesn't matter. I always write the prototype of the wd_xxx series in the DDK.

// ----------------- Content in wdf_filter.c -------------------------

# Include "WDF. H"

Wd_stat wdff_cdo_create (in wd_drv * driver,
In wd_size exten_len,
In wd_ustr * Name,
Out wd_dev ** device)
{
Return wd_dev_create (
Driver,
Exten_len,
Name,
Wd_dev_disk_fs,
Wdf_dev_secure_open,
Wd_false,
Device );
}

Wd_stat wd_main (in wd_drv * driver,
In wd_ustr * reg_path)
{
Wd_ustr name;
Wd_stat status = wd_stat_suc;

// Then I generate a control device, although my control device does nothing
Wd_ustr_init (& name, l "/filesystem/filters/our_fs_filter ");
Status = wdff_cdo_create (driver, 0, & name, & g_cdo );

If (! Wd_suc (Status ))
{
If (status = wd_stat_path_not_found)
{
// This occurs when the filesystemfilters path does not exist. This path is
// Added on XP. So it will run here in 2000
Wd_ustr_init (& name, l "/filesystem/our_fs_filter ");
Status = wdff_cdo_create (driver, 0, & name, & g_cdo );
};
If (! Wd_suc (Status ))
{
Wd_printf0 ("error: create CDO failed. RN ");
Return status;
}
}

Wd_printf0 ("success: create cdo OK. RN ");
Return status;
}

To make the Code look like the above, I have to make a lot of conversions. For example

# Define DriverEntry wd_main

It's a good feeling that you can finally work in a function that looks more like main. The function wd_dev_create internally calls iocreatedevice. While wd_suc is actually a macro like success.

// ---------------------- Content in WDF. h ------------------------------
# Include "ntifs. H"

# Define in
# Define out
# Define optional
# Define wd_ustr unicode_string
# Define wdp_ustr punicode_string
# Define wd_main DriverEntry

// Device and driver object type
Typedef driver_object wd_drv;
Typedef device_object wd_dev;
Typedef driver_object wd_pdrv;
Typedef pdevice_object wd_pdev;

Enum {
Wd_dev_disk_fs = file_device_disk_file_system,
Wd_dev_cdrom_fs = file_device_cd_rom_file_system,
Wd_dev_network_fs = file_device_network_file_system
};

// Status-related types and macros
Typedef ntstatus wd_stat;

Enum {
Wd_stat_suc = STATUS_SUCCESS,
Wd_stat_path_not_found = status_object_path_not_found,
Wd_stat_insufficient_res = status_insufficient_resources,
Wd_stat_invalid_dev_req = status_invalid_device_request,
Wd_stat_no_such_dev = status_no_such_device,
Wd_stat_image_already_loaded = status_image_already_loaded,
Wd_stat_more_processing = status_more_processing_required,
Wd_stat_pending = status_pending
};

_ Inline wd_bool wd_suc (wd_stat state)
{
Return nt_success (State );
}

# Define wd_printf0 dbuplint

_ Inline wd_void wd_ustr_init (in out wd_ustr * STR,
In const wd_wchar * chars)
{
Rtlinitunicodestring (STR, chars );
};

_ Inline wd_void wd_ustr_init_em (
In out wd_ustr * STR,
In wd_wchar * chars,
In wd_size size)
{
Rtlinitemptyunicodestring (STR, chars, size );
};

In the WDF. h file, I only extract the required parts. You have a simple "driver" complete code. It can even be compiled and installed. (modify the sfilter. inf file. The method is to change multiple sfilters to "our_fs_filter". I hope you will not encounter any problems during this process ). Then place WDF. h and wdf_filter.c in your new directory, which should contain two other files. One is makefile. Copy it from the sfilter directory. The other is sources. Enter the following content:
Targetname = our_fs_filter
Targetpath = OBJ
Targettype = driver
Drivertype = FS
Browser_info = 1
Sources = wdf_filter.c

After compiling with DDK, you will get our_fs_filter.sys. Install this file in the same directory as the INF file described above.

This driver does not play any role, but you have successfully completed "Hello World ".