Method and System for Allowing Computer Programs Easy Access to Features of a Virus Scanning Engine

1. Technical Field

The present invention relates generally to computer systems and computer viruses associated therewith. Specifically, the present invention relates to a method and system for allowing computer applications to directly access various features of a virus scanning engine without the need for user intervention.

2. Discussion of the Related Art

The generation and spread of computer viruses is a major problem in modern day computing. Generally, a computer virus is a program capable of attaching to other programs or sets of computer instructions, replicating itself, and performing unsolicited or malicious actions on a computer system utilizing the infected program. Computer viruses are designed to spread by attaching to programs on floppy disks or other computer-readable media, or to data transmissions between computer users, and are designed to inflict damage while remaining undetected. The damage done by computer viruses may range from mild interference with a program, such as the display of an unwanted message in a dialog box, to the complete destruction of data on a user's hard drive. It is estimated that new viruses are created at a rate of over one hundred per month.

A variety of methods have been developed to detect and destroy computer viruses. As is known in the art, one common method of detecting viruses is to use a virus scanning engine to scan for known computer viruses in, for example, executable files, application macro files, or disk boot sectors. Generally, computer viruses include identifiable binary sequences that may be referred to as "virus signatures." Upon the detection of a virus signature by the virus scanning engine, a virus disinfection program may then be used to extract the harmful information from the infected code, thereby disinfecting that code. Common virus scanning engines allow, for example, boot-sector scanning upon system bootup or on-demand scanning of programs or files at the explicit request of the user.

Historically, a user running a computer application such as a word processor has had to perform a series of cumbersome procedures to have a particular file, to be accessed by the application in use, scanned for viruses. In particular, the user has heretofore been required to call up the file to be accessed, call up a virus scanning engine, execute the virus scanning engine to scan the subject file, and then import the file, once scanned, into the word processor. This process is, of course, inefficient and results in time unnecessarily wasted.

It is therefore an object of the invention to provide a system and method for allowing computer applications to directly access various features of a virus scanning engine in an efficient manner without the need for user intervention.

In accordance with this and other objects of the present invention, a system and method for allowing computer programs to directly access various features of a virus scanning engine is provided. In an exemplary embodiment of the invention, the system includes a means for instantiating an object to act as an interface between the computer program and the virus scan engine, a means for setting properties of the object that are associated with the desired feature of the virus scan engine to be accessed, and a means for invoking a method of the object such as scan, the invocation resulting in access to the desired feature or features of the virus scan engine.

In another embodiment of the invention, the system additionally includes a means for examining properties of the object after the desired feature of the virus scan engine has been accessed. Illustrative examples of properties include action, file, infected, move to path, repairable, result, type, and virus name.

These and other features, aspects, and advantages of the present invention will become more readily apparent from the following detailed description, which should be read in conjunction with the following drawings, in which:

FIG. 1 is a block diagram of a representative computer system in conjunction with which the present invention may be practiced;

FIG. 2 is a block diagram according to the present invention illustrating the interaction between a computer application, a virus scan interface, and a virus scan engine;

FIG. 3 is a Visual Basic subroutine illustrating use of the action property;

FIG. 4 is a Visual Basic subroutine illustrating use of the file property;

FIG. 5 is a Visual Basic subroutine illustrating use of the infected property;

FIG. 6 is a Visual Basic subroutine illustrating use of the move to path property;

FIG. 7 is a Visual Basic subroutine illustrating use of the repairable property;

FIG. 8 is a Visual Basic subroutine illustrating use of the result property;

FIG. 9 is a Visual Basic subroutine illustrating use of the type property;

FIG. 10 is a Visual Basic subroutine illustrating use of the virus name property; and

FIG. 11 is a Visual Basic subroutine illustrating use of the scan method.

The following embodiments of the present invention will be described in the context of a system and method for allowing applications easy access to features of a virus scanning engine, although those skilled in the art will recognize that the disclosed methods and structures are readily adaptable for broader application. Note that whenever the same reference numeral is repeated with respect to different figures, it refers to the corresponding structure in each such figure.

FIG. 1 discloses a representative computer system in conjunction with which an embodiment according to the present invention may be implemented. Computer system 10 may be a personal computer or workstation, or a larger system such as a minicomputer. However, one skilled in the art of computer systems will understand that the present invention is not limited to a particular class or model of computer.

As shown in FIG. 1, representative computer system 10 includes a central processing unit (CPU) 12, a memory unit 14, one or more storage devices 16, an input device 18, an output device 20, and communication interface 22. A system bus 24 is provided for communications between these elements. Computer system 10 may additionally function through use of an operating system (not shown), such as WINDOWS, DOS, or UNIX.

Storage devices 16 may illustratively include one or more floppy or hard disk drives, CD-ROMs, DVDs, or tapes. Input device 18 comprises a keyboard, mouse, microphone, or other similar device. Output device 20 is a computer monitor or any other known computer output device. Communication interface 22 may be a modem, a network interface, or other connection to external electronic devices, such as a serial or parallel port.

Referring now to FIG. 2, a system is disclosed wherein a computer program or application 100 run by a user on computer system 10, for example, utilizes a virus scan interface 102 to directly access a virus scan engine 104. Computer application 100 may be any known computer application, such as a wordprocessor, database, or spreadsheet, but by way of example, and not by way of limitation, will be described herein as a word processor.

Virus scan engine 104 may be any of the variety of virus scan engines known in the art. However, again by way of example, and not by way of limitation, virus scan engine 104 will be described herein as VirusScan.TM., produced by McAfee Associates. It is emphasized that this example, as with the use of a word processor as an example of a computer application, is presented only for clarity of presentation, and does not limit the scope or context of the invention to certain software packages, software types, or operating system types. Indeed, the preferred embodiment of the invention is advantageously applied to many different types of virus scanning engines and computer applications on many different types of operating systems and computing configurations.

VirusScan.TM. is a virus scan engine offered for sale in a variety forms. VirusScan.TM. is described in documentation in printed form (see, e.g., "VirusScan Quick Start Guide", McAfee Associates 1997, accompanying the CD-ROM version of VirusScan for Windows 95, NT, 3.1x, DOS and OS/2), in computer-readable form (see, e.g., the directory .backslash.MANUALS on the CD-ROM version of VirusScan for Windows 95, NT, 3.1x, DOS and OS/2), and on McAfee's Internet site at http://www.mcafee.com. The content of this documentation is hereby incorporated by reference into the present application.

In one form, the VirusScan.TM. application is adapted for use on a user's computer running on a Windows 95.TM. platform. A main routine used by this antivirus application is "SCAN.EXE", a program file that is typically placed in the directory C:.backslash.PROGRAM.sub.-- FILES.backslash.MCAFEE.backslash.VIRUSSCAN on the user's hard drive. The program SCAN.EXE is adapted to be used for any of the following types of virus scanning: virus scanning of system boot-sectors at startup, on-demand virus scanning at the explicit request of the user, and on-access virus scanning of a file when that file is accessed by the operating system or an application. In the Windows 95.TM. environment, the registry files are often modified such that SCAN.EXE is run at computer startup, and also remains resident for scanning all files upon file access.

In a typical configuration, VirusScan.TM. is used in conjunction with a set of virus signature files having the names CLEAN.DAT, MCALYZE.DAT, NAMES.DAT, and SCAN.DAT. As of McAfee's Oct. 15, 1997 release of version 3010 of its VirusScan.TM. signature file updates, these virus signature files collectively comprise over 1.6 MB of virus information. In a typical configuration, the files CLEAN.DAT, MCALYZE.DAT, NAMES.DAT, and SCAN.DAT are also placed in the directory C:.backslash.PROGRAM.sub.-- FILES.backslash.MCAFEE.backslash.VIRUSSCAN on the user's hard drive. For purposes of clarity and simplicity in describing the background and preferred embodiments, this disclosure will refer to a generic antivirus program as virus scan engine 104.

According to one embodiment of the invention, virus scan interface 102 is a dynamic link library that is used by application 100 to access various features of virus scan engine 104. More particularly, virus scan interface 102 is a component object model (COM) object that exposes a set of methods and properties that can be used by computer programs or applications to perform virus scanning using virus scan engine 104, without having to understand and contend with the low-level details of virus scan engine 104. Since it is a COM object, it is language independent and may be used by any program or application that can create and call COM Objects. Access to virus scan interface 104 may illustratively be accomplished through OLE Automation (the IDispatch interface).

Virus scan interface 102 can be utilized to access virus scan engine 104 in two different ways. Because virus scan interface 102 can be made to conform to the ActiveX control specification, it can be added to a form in languages that support this paradigm, and then accessed like any other control in that environment. If used in this way, the control itself is invisible to the user at run time. Second, because virus scan interface 102 can provide its services via Automation methods and properties, any program that can create and call COM objects can perform virus scanning without having to host it as a control.

As mentioned, virus scan interface 102 is a COM object that exposes a set of methods and properties that can be employed by computer programs or applications to perform virus scanning using a virus scan engine 104. In one embodiment of the invention, virus scan interface 102 includes the following properties: action 110, file 112, infected 114, move to path 116, repairable 118, result 120, type 122, and virus name 124. Virus scan interface additionally includes a scan method 126.

FIGS. 3-11 disclose illustrative subroutines in Visual Basic for setting or getting, as appropriate, the above-listed virus interface properties, and for using scan method 126. As disclosed herein, each of these subroutines assumes either that there is a control on the current form with the ID "VirusInterface", or that there is an object variable with the name "VirusInterface, " created in Visual Basic as follows: ##EQU1##

Although these subroutines are preferably written in an object-oriented language such as Visual Basic or C++, one skilled in the art will appreciate that these subroutines may be programmed in suitable non-object-oriented computer languages without departing from the scope of the present invention.

Action property 110 specifies the operation to be performed when scan method 126 is invoked. The data type of this property is integer. Action property 110 must be set to one of the following values before scan method 126 is invoked to specify what scan operation should be performed:

Illustratively, the subroutine disclosed in FIG. 3 sets the action property to 1, so that when scan method 126 is invoked, the method will scan the previously-indentified file for viruses.

File property 112 specifies the file name that will be the object of a scan using scan method 126, and must be set before invoking the scan method. The data type of this property is string, and indicates the path, full or relative, of a single file to be acted upon. Illustrative examples are "C:.backslash.TopDir.backslash.SubDir.backslash.MyFile.exe," "SubDir.backslash.MyFile.exe, " and "MyFile.exe." In the subroutine of FIG. 4, the file property is set to "C:SomeFile.exe, " while the variable sFile is set to that path for the purpose of getting the property

Infected property 114 indicates whether a file has a virus. This property is an integer data type, and is only meaningful after a successful scan operation using scan method 126. It cannot be set by the caller. It can only be set by scanning a file. If the value is non-zero after a scan has been performed, the file is infected. FIG. 5 illustrates a means by which the caller can obtain the value of infected property 114.

The Move To Path property 116 specifies the directory name to which a file will be moved, and must be set before invoking scan method 126. This property is of a string data type, and indicates the path, full or relative, of a single directory. Illustrative examples are "C:.backslash.TopDir.backslash.SubDir," "TopDir.backslash.SubDir," and "SubDir." FIG. 6 illustrates a means by which the caller can set the value of move to path property to "C:.backslash.TopDir.backslash.SubDir," and then retrieve the property value through variable sMoveToPath.

Repairable property 118 indicates whether an infected file can be cleaned. This property is of an integer data type, and is only meaningful after a successful scan operation. It cannot be set by the caller. It can only be set by scanning a file. If the value is non-zero, the file can be repaired. FIG. 7 illustrates a means by which the caller can obtain the value of repairable property 118 using variable nRepariable.

Result property 120 indicates whether a method call succeeded or failed. This property is of an integer data type, and is only meaningful after a scan has been invoked. It cannot be set by the caller. It can only be set by invoking a method such as scan method 126. If the method call is successful, the result value will be zero. Any other value indicates a failure of some kind, in which case result property will illustrative be set to the "errno" or "LastError" that occurred, or the VSTATUS value returned from virus scan engine 104. FIG. 8 illustrates a means by which the caller can obtain the value of result property 120 using variable nResult.

Type property 122 identifies the type of virus infecting a file. This property is an integer data type, and is only meaningful after a successful scan operation. It cannot be set by the caller. It can only be set by scanning a file. Illustratively, the following values may defined:

Advantageously, these values are additive. If the virus infects COM and EXE files, for example, type property 122 will have a value of (1+2)=3. FIG. 9 illustrates a means by which the caller can obtain the value of result property 120 using variable nType.

Virus Name property 124 identifies the virus that infects the file. This property is a string data type, and is only meaningful after a successful scan operation. It cannot be set by the caller. It can only be set by scanning a file. If the virus name property is empty, the file is not infected. FIG. 10 illustrates a means by which the caller can obtain the value of virus name property 124 using variable sVirusName.

As mentioned, scan method 126 may be utilized by virus interface 102 to access features of virus scan engine 104. FIG. 11 discloses an illustrative subroutine whereby the action property 110 is set to 1 (indicating that a file scan for viruses is to be performed), file property 112 is set to "c:.backslash.somefile. exe" (indicating that somefile.exe is the file to be scanned), and the scan method is invoked to access the scan feature of virus scan engine 104. As also shown in FIG. 11, if the method call is successful (i.e., result property 120 equals 0), then the values of certain properties (infected, repairable, type and virus name for example) can be retrieved by the caller for further analysis.

The standard return value for method calls in a COM architecture is a result handle (HRESULT). This is a 32-bit value with four sub-sections:

VirusInterface will return the value of zero (all bits zero) for all method calls that succeed. Note, however, that in a Visual Basic implementation, HRESULT is not returned directly to the caller. If a method returns a value with a severity error (bit 31 set to 1), Visual Basic will raise an error that must be trapped by the caller, indicating to the caller that the call failed. If no error is raised, then the call succeeded.

VSTATUS, the value returned by a call to the McAfee VirusScan.TM. engine, can have any of the following illustrative values:

In summary then, the interaction between application 100, virus scan interface 102, and virus scan engine is straightforward and efficient. In a Visual Basic implementation, a VirusInterface object is first instantiated. This can be a control placed on a form at design-time, or an object created at run time. Second, the necessary properties are set; this will generally include action property 110 and file property 112, and may include others. Third, a desired method, such as scan method 126 is invoked to utilize a particular feature of virus scan engine 104. Finally, pertinent properties are checked, including result property 120, to determine if the method call succeeded, and if so, the results of that method call.

Various embodiments of the invention have been described. The descriptions are offered by way of illustration, not limitation. Thus, it will be apparent to those skilled in the art that modifications may be made to the invention as described without departing from the scope of the claims set out below.