Traditional virus scanning

The traditional virus scanner consists of a host program, which incorporates a user interface and some form of file object traverser or real time hook. The host program loads and initializes the scanner engine. During initialization, the engine is told what routines should be used to handle the file object. These routines will perform open, read, write, and other operations on the given file objects. The routines are available in the standard Norman libraries, or can be written to allow handling of specialized objects.

As file objects are traversed or intercepted, they are given to the scanner engine. The engine accesses the file objects using the file routines given during engine initialization. It is also possible to switch file handling routines in mid-process. The figure below llustrates a typical virus control application. The host program and user interface is integrated with the file access routines (NRM library). In a typical Win32 environment, the engine is available as a DLL, which is loaded by the host. The DLL uses the same set of file handling routines as the host to access the disk subsystem. Communication between the file handling routines and the rest of the program is performed through standard stack-based routine invocations.

NVCnet architecture

The scanner engine resides within a supporting server process on an Intel platform. The actual file scanning is accomplished by transferring all file Input/Output (IO) across an IP-based network connection to a portable client which resides on the system where the files to be scanned are located. File IO commands are translated into a proprietary protocol, and are resolved on the client side using system-specific IO functions. To the engine, file handling appears as if standard NRM file routines were being used locally.

The scanner engine is multi-threaded. If the client has a need to run multiple sessions while checking files, this poses no problem.

The figure below illustrates the basic architecture of a scanner mechanism operating across a network. In this illustration, the scanning host program is implemented as an invisible service. The user interface is detached as a separate process, communicating with the service through a named pipe or via an administrative connection over the IP network.