Inside On-Access Virus Scanners

Building virus-scanning functionality with file system filter drivers

As our reliance on computers has grown, so have the networks thatconnect computers. We typically connect computers via a LAN, and either directlyor indirectly via the Internet. Although this connectivity facilitates sharingprograms and documents, it heightens the risk of infecting files with annoyingor destructive viruses. Consequently, you rarely find a Windows NT system thatdoesn't run a virus-scanning product to check files for the presence of virusesand prevent them from entering the system.

This month, I'll explore the internals of on-access virus scanners for NT.First, I'll briefly describe how on-access virus scanners work. Next, becauseon-access virus scanners work with file system drivers to check files forviruses, I'll introduce how file system drivers (FAT, NTFS, etc.) interact withNT through the I/O Manager. I'll conclude by describing where on-access virusscanners fit into NT.

Virus Scanning Basics
Virus scanners check files in one of two ways. An on-demand virusscanner examines every file on a disk (or within subdirectories that youspecify) and searches for viruses it knows about or for signatures common tocertain types of viruses. You can usually trigger on-demand virus scannersmanually, or automatically at regular intervals (e.g., during system boot). Thedrawback of on-demand virus detection is that files you download or copy ontothe system can infect the computer before the virus scanner checks for viruses.

On-access virus scanning is proactive. On-access virus scannersstop virus activation because the scanners check files at the time you open orexecute them. Thus, if you download an infected Microsoft Word document to yourhard disk, before Word can open the file, the virus scanner makes sure the fileis clean. When the virus scanner detects a virus in a file, the scanner eitherremoves the virus or returns an error code to the application opening the fileto prevent the open operation from proceeding.

Virus-scanning products for NT perform either or both types of virusscanning. Implementing on-demand virus scanning is relatively straightforward:The scanner opens the files and looks for signs of viruses. A Win32 program thatuses standard APIs can easily provide this functionality.

Implementing an on-access virus scanner is much trickier. You cannot usethe Win32 API to direct NT to check files whenever other programs (including NT)open or execute the files. Furthermore, scanning must be transparent to theapplications running on the system. For example, Word must be able to open filesin its usual manner. The only way to provide this functionality is to write aspecial type of device driver known as a file system filter driver.

The I/O Manager and File Systems
File system filter drivers hook themselves on top of file systems so thatthey can intercept requests headed toward the file systems. The drivers revieweach request and reject it, pass it to the file system, or change it on the wayto the file system. The drivers can also examine the results of requests on theway back from the file systems. On-access virus scanners ensure that files arefree of viruses when you open them, so the file system filter drivers processonly open requests.

To better understand this design, you need to understand how file systemsare integrated with NT and how a file system services I/O requests (e.g., from aWin32 program). The following description generally holds true for all types offile system requests (e.g., create, read, write), but I'll concentrate on whathappens when a typical Win32 program uses the ReadFile API to read from a file.

Figure 1 shows the main system components involved in servicing the readrequest. NT implements the ReadFile API in Kernel32.dll, a standard NT componentthat's part of the Win32 subsystem. Kernel32 is the library in which NTimplements all file, process, and memory-management Win32 APIs. Some APIs, suchas CreateProcess, require that the library send messages to the Win32 subsystemprocess to service the APIs. However, most APIs (including ReadFile) do not.Kernel32 takes the parameters passed in the ReadFile call and constructs a callto NT's kernel-mode API. In the kernel-mode API (also known as NT's native API),all the functions begin with "Nt." The kernel-mode function forreading a file is NtReadFile.

When Kernel32 issues a native NT API call, the processor switches intokernel mode, and the native API call enters the NT kernel. All native API callsenter through the same doorway: The kernel funnels requests to the kernel-modefunction that handles them. The kernel-mode NtReadFile function constructs anI/O request packet (IRP) and initializes it with all the information to describethe request (e.g., which file to read from, the starting offset and length ofthe read, and the buffer that will receive the data on successful completion).NtReadFile calls the I/O Manager to send the IRP to the file system of the drivewhere the file resides. For example, if the C drive is an NTFS drive, readingC:mark1 causes the I/O Manager to call the NTFS driver.

File systems resolve some requests without ever touching the disk. In theread example, if the data resides in the file system cache, NTFS completes theIRP immediately. If the cache does not contain the data, NTFS must create one ormore new IRPs that instruct the hardware device driver managing the C drive'shard disk to fetch the data from the disk. When the driver completes these IRPs,NTFS can complete the IRP that NtReadFile sent. When the target file systemcompletes NtReadFile's IRP, the call to ReadFile ends and control returns to theWin32 program; the program can now look at the file data.

Well, that's the general idea, anyway. I've described a synchronoussystem, in which control does not return to the originator of an IRP (NtReadFileor NTFS in the read example) until the IRP finishes. NT can service requestssynchronously, but it more often services requests asynchronously. Whena file system cannot process a request immediately because a disk driver mustfetch some data, the file system returns a pending status for therequest. Through an event object associated with the IRP, the I/O Managerreports the IRP's completion to the initiator of the IRP. When the caller wantsto wait for the IRP to finish, the caller waits for the event object's signal.The I/O Manager creates an event object in an un-signaled state and switches itto a signaled state when the IRP finishes.

NtReadFile (from the read example) is by default an asynchronous API. NtReadFile returns control to Kernel32 whether or not the request has finished;Kernel32 must wait for the call's event object signal. This arrangementpreserves the design behavior of Win32 ReadFile, which is by default asynchronous API.

File System Filter Drivers
The I/O Manager provides a facility whereby a device driver can attachitself to another driver, letting the attaching driver filter the requestsdirected to the other driver. File system filter drivers are very popular andversatile; you can build in all types of functionality with them. For example, afile system filter driver can encrypt data on the way into a file system anddecrypt it on the way out. You can design a file system filter driver to encryptspecific files or an entire disk, providing high levels of security. A filesystem filter driver can function as a license manager, which ensures that usersobtain a token from a controller before they can open (and run) certainapplications. Of course, file system filter drivers are also ideal forimplementing on-access virus scanners.

Figure 2 shows how a virus-scanning file system filter driver mightintercept and process a request to open a file. NT uses CreateFile IRPs tocreate new files or open existing files. Therefore, virus scanners interceptCreateFile requests to ensure that any file being opened is free of viruses.Most NT virus scanners let you specify that only certain types of files (e.g.,with .dll, .exe, or .doc extensions) be scanned. The file system filter driverfirst checks to see whether a file is on the list of file types to scan. If thefile does not need to be scanned, the file system filter driver gets out of theway of the request, passing the IRP to the file system and ignoring the IRP'sreturn status.

If the file needs to be scanned, the file system filter driver lets theCreateFile IRP continue to the file system and waits for the IRP to finish. Ifthe IRP's result status shows that an error occurred during opening of the file,the virus scanner simply passes the status back to the I/O Manager. Thisarrangement prevents the scanner from doing extra work when the file beingopened does not exist, or the user does not have permission to access the filein the way the user requested. If the file system determines that the file wasopened successfully, the file system filter driver sends ReadFile IRPs to thefile system to obtain the contents of the entire file. The scanner waits for theIRPs to complete before it continues its proprietary scanning step.

The virus scanner's library of viruses and virus signatures guides thescanning step. A virus-scanning file system filter driver will usually obtainthis library from a Win32 program that runs as the system boots, or by readingthe library from a file when the virus scanner initializes. The value of anon-access virus scanner is the comprehensiveness of its library; as long as thescanner works transparently, users don't care how cleverly the virus scanner'sprogrammers have implemented the file system filter driver.

If the scanner detects a virus in the file, the file system filter drivercloses the file and returns an error to the I/O Manager. The default error codeon many virus-scanning packages is access denied, which is the errorcode returned when you open a file for exclusive access and another programalready has it open, or when you try to open a file and its security settingsprevent you from doing so. Most NT virus scanners also have options to logdetections to a file, copy infected files to a specified location, or deleteinfected files.

Once a virus scanner identifies a virus, it can often eliminate the virusfrom the file. If you've enabled virus removal, the virus scanner's file systemfilter driver removes the virus and writes a clean version of the file to thefile system before the file open operation continues. This process istransparent to the program opening the file because the file system filterdriver holds the CreateFile IRP until it finishes the scanning and cleaningsteps. An application cannot distinguish introduced delays from delays that theapplication encounters when other programs read and write files.

The organization I've presented in Figure 2 isn't the only strategy thaton-access virus scanners can implement. Some solutions perform part of theirprocessing in a Win32 program with a tight communications link to the filesystem filter driver. This off-loaded processing can include anything fromscanning or cleaning the file to moving the file to the dedicated directory andnotifying the user via a dialog box.

That's a Wrap
Remember that when you evaluate a virus scanner for your systems, the keyfactor is how many viruses the scanner's library contains, rather than how muchof the program the developers implement in a device driver. Of equal importanceis whether the vendor provides online access to virus-library updates. Withthese points in mind and with your understanding of how on-access virus scannersintegrate with NT, you're well-equipped to select a virus scanner that meetsyour needs.