FIELD OF THE INVENTION

&null;0002&null; The present invention relates to wireless device security, and more particularly to scanning wireless devices for malware.

BACKGROUND OF THE INVENTION

&null;0003&null; The last decade has seen a rapid growth in the number and use of mobile cellular telephones. More recently, wireless devices have been introduced which combine the functionality of mobile telephones and Personal Digital Assistants (PDAs). It is expected that this area will undergo massive growth in the near future as new cellular telecommunication standards (e.g. GPRS, UMTS, and WAP) make possible the high speed transfer of data across the wireless interface.

&null;0004&null; It can be expected that such platforms will be susceptible to attack from so-called &null;malware&null; such as viruses, Trojan horses, and worms (referred to collectively hereinafter as &null;viruses&null;) in much the same way as present day personal computers and workstations are susceptible to malware attack. A number of mobile telephone viruses have already been identified.

&null;0005&null; In order to resist virus attacks, anti-virus software must be deployed into mobile platforms in much the same way as it has been deployed in the desktop environment. A number of different desktop anti-virus applications are currently available. The majority of these applications rely upon a basic scanning engine which searches suspect files for the presence of predetermined virus signatures. These signatures are held in a database which must be constantly updated to reflect the most recently identified viruses.

&null;0006&null; Typically, users download replacement databases every so often, either over the Internet, from a received e-mail, or from a CDROM or floppy disk. Users are also expected to update there software engines every so often in order to take advantage of new virus detection techniques (e.g. which may be required when a new strain of virus is detected).

&null;0007&null; Mobile wireless platforms present a series of problems for software developers (including developers of anti-virus software). Chief among these are the limited memory and processing power of mobile platforms, and the limited input/output capabilities which they possess (i.e. no CDROM or floppy drive, and no high bandwidth fixed line network or Internet connectivity).

&null;0008&null; Moreover, mobile wireless platforms are traditionally not standardized like conventional desktops. For example, instead of running Microsoft&null; Windows&null;, such mobile wireless platforms may have installed thereon a variety of types of operating systems. This complicates the act of designing an anti-virus scanner that is capable of operating on any one of a plurality of mobile wireless platforms.

DISCLOSURE OF THE INVENTION

&null;0009&null; A system, method and computer program product are provided for scanning a mobile wireless device for malware. Initially, data stored in persistent memory of a mobile wireless device is accessed. Next, the data is scanned utilizing an anti-malware scanner of the mobile wireless device. Such data is accessed utilizing an abstract file system interface.

&null;0010&null; To this end, any type of data native to any particular platform may be accessed without platform-dependencies. A versatile technique is thus provided which is tailored for mobile wireless environments.

&null;0011&null; In one embodiment, the abstract file system interface may be implemented for each class of the data stored in the persistent memory. In various embodiments, the abstract file system interface may include an abstract directory interface, an abstract directory entry interface, and/or an abstract file interface.

&null;0012&null; In another embodiment, the abstract file system interface may include data structures with call back functions. Such call back functions may enumerate the data. Moreover, the call back functions may manipulate the data.

BRIEF DESCRIPTION OF THE DRAWINGS

&null;0013&null; FIG. 1 illustrates an exemplary architecture for scanning a mobile wireless device for malware, in accordance with one embodiment.

&null;0014&null; FIG. 2 illustrates an overview of the component architecture associated with the anti-malware scanner running on the mobile wireless devices.

&null;0015&null; FIG. 3 illustrates a method for scanning a mobile wireless device for malware utilizing a user interface, in accordance with one embodiment.

&null;0016&null; FIG. 4 illustrates a sample user interface screen that shows the features exposed by the anti-malware scanner.

&null;0017&null; FIG. 5 illustrates a block diagram showing the interaction between a component manager and other subsystems such as the user interface.

&null;0018&null; FIG. 6 illustrates a method for scanning a mobile wireless device for malware utilizing a component manager, in accordance with one embodiment.

&null;0019&null; FIG. 7 illustrates a system including an on-access scanner, in accordance with one embodiment.

&null;0020&null; FIG. 8 illustrates a framework with an on-access scanner interfacing with a file system, and filtering all file I/O related events.

&null;0021&null; FIG. 9 illustrates the manner in which the on-access scanner is enabled and disabled during use based on on-demand scanning.

&null;0022&null; FIG. 10 illustrates a Java scanning module interfacing with Java, and filtering all Java applet and Java script executions.

&null;0023&null; FIG. 11 illustrates an on-demand scanner system including an on-demand scanner interacting with a component manager and a scan engine.

&null;0024&null; FIG. 12 illustrates a method for performing on-demand scanning, in accordance with one embodiment.

&null;0025&null; FIG. 13 illustrates a scan engine system including a scan engine module, a file parser, and an interpreter.

&null;0026&null; FIG. 14 illustrates a service agent (SA) architecture, in accordance with one embodiment.

&null;0027&null; FIG. 15 illustrates a method for scanning a mobile wireless device for malware, involving service agents.

&null;0028&null; FIG. 16 illustrates a sample service agent activation method, in accordance with one embodiment.

&null;0029&null; FIG. 17 provides a method for client and server package handling.

&null;0030&null; FIG. 18 illustrates the various steps of a package installation process, in accordance with one embodiment.

&null;0031&null; FIG. 19 illustrates the components of the platform abstraction layer and the manner in which they interface with a mobile wireless device and operating system thereof.

&null;0032&null; FIG. 20 illustrates a transaction server command process flow, in accordance with one embodiment.

&null;0033&null; FIG. 21 illustrates a plurality of personal device database table relationships, in accordance with one embodiment.

&null;0034&null; FIG. 22 shows an exemplary client information flow, in accordance with one embodiment.

DETAILED DESCRIPTION

&null;0035&null; FIG. 1 illustrates an exemplary architecture 100 for scanning a mobile wireless device for malware, in accordance with one embodiment. As shown, the architecture 100 includes a mobile wireless device 102. Such mobile wireless device 102 may include, but is not limited to a cellular phone, personal digital assistant (PDA), a palm computer, or any combination thereof Further, such mobile wireless device 102 may rely on any desired operating system. It should be noted that the vast variety of mobile wireless devices 102 operate different operating systems, unlike traditional desktop and laptop environments which typically run Microsoft&null; Windows&null; operating systems.

&null;0036&null; As may soon become apparent, the mobile wireless device 102 is associated with an application service provider and is equipped with an anti-malware scanner for providing active content security service. In the context of the present description, such anti-malware scanner may include any program adapted to scan or detect malware (i.e. virus, Trojan horse, worm and other forms of data or program that may result in an unexpected and/or unwanted outcome).

&null;0037&null; In use, the application service provider is initiated utilizing the mobile wireless device 102. Next, the anti-malware scanner installed on the mobile wireless device 102 is updated over a wireless network utilizing the application service provider. The mobile wireless device 102 is then scanned utilizing the updated anti-malware scanner.

&null;0038&null; In communication with the mobile wireless device 102 are server-side systems, or a back-end architecture 104. Such back-end architecture 104 is located at a service-provider site and provides centrally managed provisioning, component updates and usage reporting for serviced mobile wireless devices 102.

&null;0039&null; As shown in FIG. 1, the back-end architecture 104 may, in one embodiment, include a carrier gateway 106 for communicating with the mobile wireless device 102. A load distributor 108 may be coupled between the carrier gateway 106 and a plurality of hypertext transfer protocol (HTTP) servers 110 which, in turn, are coupled to a plurality of transaction servers 112. Further included is a database 114 coupled between the transaction servers 112 and a configuration/reporting server 116.

&null;0040&null; In use, the back-end architecture 104 receives device requests, and sends and receives client-specific data to and from the mobile wireless devices 102. The transaction servers 112 make database queries to store and retrieve information to/from the database 114. Client configuration information, usage information and component update packages are stored in the database 114. Configuration and reporting may be accomplished via Web interfaces 118. More information regarding such back-end architecture 104 will be set forth hereinafter in greater detail.

&null;0041&null; More information will now be set forth regarding an exemplary design of the mobile wireless devices 102. As wireless devices have limited resources, the anti-malware scanner on the mobile wireless devices 102 may be specifically designed with the following objects set forth in Table 1A in mind.

1

TABLE 1A

Maintain a low memory footprint.

Consume as little CPU resources as possible, yet maintain

active monitoring for malicious software on the device.

Minimize bandwidth requirements to the back-end server.

Use the back-end server to minimize the work the device is

required to perform.

Maximize the flexibility of the scanner to address new

threats.

&null;0042&null; The anti-malware scanner may evolve over time as new computer viruses and other malicious code are discovered.

&null;0043&null; The anti-malware scanner is designed to protect wireless devices 102 from malicious code. The scope of this protection includes, but is not limited to the following set forth in Table 1B.

2

TABLE 1B

Identify malicious code in persistent data stored on the

device. This includes native executables as well as

scripting languages embedded in documents.

Prevent malicious code from being executed by actively

intervening when the data is accessed.

Potentially monitor network activity to detect and intervene

against external threats on the device.

Provide a means for cleaning programs and documents that have

been infected by malicious software.

Report the necessary information to track active threats on

the network of wireless devices.

&null;0044&null; A glossary of terms that will be used in the present description is set forth in Table 1C.

3

TABLE 1C

Term

Description

Virus

A piece of executable binary or script that replicates by modifying and attaching

to programs or executable/automation scripts. Viruses may damage data, cause

the computer to crash, display messages, or lie dormant.

Trojan Horse

A program that either pretends to have, or is described as having, a set of useful

or desirable features, but actually contains a damaging payload. Most frequently

the usage is shortened to &null;Trojan&null;. Trojan Horses are not technically viruses,

since they do not replicate.

Worm

A malware that replicates itself using computer networks, such as via email or

IRC (Internet Relay Chat).

Malware

Virus, Trojan horse, worm and other forms of data or program that result in

unexpected and/or unwanted outcome.

Storage

Disk, flash-memory or other forms of non-volatile memory device.

File

Single storage object entity such as a program or a data file.

Directory

A storage index that contains a list of files or sub-directories.

Archive File

Single file containing multiple files organized by a directory structure. Example:

ZIP, CAB, JRE, SIS

File Scanning

The process used for detecting, identifying and removing malware on a storage.

Process Scanning

The process used for detecting, identifying and removing malware in execution.

Application-

Malware scanning process for a particular application.

specific Scanning

Example: hostile SMS/MMS scanning, Email attachment scanning, hostile Java

Applet scanning

On-demand

Malware scanning process initiated by the user or another application. Usually

Scanning

involves a complete system-wide scanning, and the process is terminated when

scanning is completed.

On-access

Scanning process triggered by an OS or an application event. The on-access

Scanning

scanner stays resident in the system.

&null;0045&null; Anti-Malware Scanner Architecture

&null;0046&null; The anti-malware scanner architecture is based on a collection of components. These components are further analysed to expose properties and interfaces. This design helps isolate defects to specific components as well as providing a framework for porting the design to other devices with different hardware requirements.

&null;0047&null; FIG. 2 illustrates an overview of the component architecture 200 associated with the anti-malware scanner running on the mobile wireless devices. As shown, a user interface 202 is provided which communicates with a component manager 204. Such component manager 204 is responsible for controlling and managing an on-access scanner module 206, on-demand scanner module 208, Java-scanner module 210, service manager module 212, and activity logging module 214. As shown, the on-access scanner module 206, on-demand scanner module 208, and the Java-scanner module 210 utilize a common scan engine 216.

&null;0048&null; For reasons that will soon become apparent, the anti-malware scanner component architecture 200 further includes a platform abstraction layer 218 that provides an interface between an operating system 220 of the mobile wireless device and the component manager 204 and the components associated therewith. Each of the foregoing components will be discussed subsequently in greater detail.

&null;0049&null; User Interface Design (202 of FIG. 2)

&null;0050&null; FIG. 3 illustrates a method 300 for scanning a mobile wireless device for malware utilizing a user interface, in accordance with one embodiment. Initially, in decision 302, it is determined whether an update command is received from a user utilizing a graphical user interface of a mobile wireless device. As an option, the update command may be received upon the selection of an update icon displayed on the graphical user interface of the mobile wireless device. In operation 304, an anti-malware scanner installed on the mobile wireless device is then updated over a wireless network in response to the update command.

&null;0051&null; Next, it is determined in decision 306 as to whether a scan command has been received via the selection of a scan icon displayed on the graphical user interface of the mobile wireless device. More information regarding an exemplary interface with such icons will be set forth hereinafter during reference to FIG. 4. The mobile wireless device is then scanned utilizing the updated anti-malware scanner, as indicated in operation 308. Such anti-malware scanner may be conditionally updated based on the update command so as to regulate usage of the wireless network with the mobile wireless device.

&null;0052&null; As an option, a version number of a last update may be displayed utilizing the graphical user interface of the mobile wireless device. Further, a time of a last update may be displayed utilizing the graphical user interface of the mobile wireless device.

&null;0053&null; The anti-malware scanner user interface is very effective in design. Configuration settings and updates are handled by the back-end system, relieving the user from any responsibilities. Some basic feedback such as the product name, logo, and version information is provided. The user may check for product updates, and initiate a scan for malicious programs on removable media. The details for these capabilities are provided below.

&null;0054&null; Manual Virus Scanning

&null;0055&null; Manually virus scanning of the entire device is performed according to the configuration settings set by the IT administrator. That is, either all files may be scanned or only certain types of files. Also, the IT Administrator specifies how the anti-malware scanner responds to any infected file that is found. Upon scan completion, a report is created that reflects what was scanned and whether any computer viruses were found.

&null;0056&null; Check for Product Updates

&null;0057&null; Checking for product updates is made available from the main user interface. When update checking is requested, the anti-malware scanner attempts to update itself using a service agent in a manner that will soon be set forth.

&null;0058&null; About the Anti-Malware Scanner

&null;0059&null; An &null;About the anti-malware scanner&null; dialog box is displayed upon user request. The contents of this dialog box contain the information of Table 1C-1.

4

TABLE 1C-1

All the necessary anti-malware scanner copyright messages.

Scan engine and virus definition file version numbers.

Last time the product was updated.

&null;0060&null; FIG. 4 illustrates a sample user interface screen 400 that shows the features exposed by the anti-malware scanner. The user interface screen 400 may be displayed upon the selection of an anti-malware scanner tab 401 always shown on the user interface screen 400. Of course, other tabs such as a contacts tab 401-A, a mail tab 401-B, a browser tab 401-C, an address book tab 401-D, and a notes tab 401-E may also be provided. As shown in FIG. 4, a scan icon 402, an update icon 404, and an about icon 406 are illustrated upon the selection of the anti-malware scanner tab 401 for allowing a user to carry out the functionality of the anti-malware scanner.

&null;0061&null; Component Manager Design Specification (204 of FIG. 2)

&null;0062&null; The component manager inside the anti-malware scanner is the logic layer that instantiates the following subsystems of Table 1D.

5

TABLE 1D

On-access scanning subsystem.

On-demand scanning subsystem.

Activity logging subsystem.

Service agent subsystem.

&null;0063&null; The component manager contains logic on how to instantiate the different subsystems, how to configure them, and manages when to activate and deactivate subsystems. It drives the entire application and can provide the user interface with feedback on subsystem progress.

&null;0064&null; The user interface relies on the component manager to initiate actions such as manually scanning for computer viruses and to check for product updates.

&null;0065&null; FIG. 5 illustrates a block diagram 500 showing the interaction between the component manager 502 and the other subsystems 504 such as the user interface 506. As shown, any number of subsystems 508 may be employed per the desires of the user.

&null;0066&null; How the Component Manager Works

&null;0067&null; FIG. 6 illustrates a method 600 for scanning a mobile wireless device for malware utilizing a component manager, in accordance with one embodiment. The component manager is initially instantiated, in operation 602, just like any other core technology component of the present embodiment. As an option, the operation 602 may be executed in response to a scan command received from a user utilizing the user interface of the mobile wireless device.

&null;0068&null; Next, in operation 604, memory is allocated to store private data information for the component manager. The configuration manager is then used to load in anti-malware scanner scan settings in the private memory just allocated. See operation 606.

&null;0069&null; Based on the scan settings, the specialized subsystems are initiated. See operation 608. These subsystems may include the on-access scanning, activity logging and/or a service agent function. The on-demand scanning subsystem is only instantiated on a per need basis in order to save system resources. On-demand scanning is only needed when manual device scanning is requested. Based on these initialisation steps, a completion return code is returned to the owner of this subsystem.

&null;0070&null; The on-access scanning subsystem is initiated so real-time monitoring for viruses begins. When a computer virus is detected, a component manager callback function is called by the on-access scanning subsystem. Within this callback function the component manager determines based on the scan settings how it wishes the on-access scanning subsystem to deal with infected items. The completion status of this event is then passed to the activity logging subsystem for recording purposes.

&null;0071&null; When manual scanning is requested, it is performed according to the established configuration provided by an IT administrator. Manual scanning involves accessing several files or databases on the device and this same action is what the on-access scanner also monitors. In order to not cause system resources to be spent unnecessarily, the on-access scanning subsystem is disabled for the brief time period that the on-demand scanning is active.

&null;0072&null; Component Manager API

&null;0073&null; The component manager exposes all its functionality through an API layer. No platform dependencies are necessarily assumed. All interfaces follow a sandwiched approach where there is an initialisation to obtain an instance handle. Based on this instance handle, the component manager worker functions are available and when the object is not needed anymore the object is destroyed. The number of features that a user interface can request to be performed by the component manager may be limited. All knowledge on how scanning is performed may be contained within the component manager. A user interface can request from the component manager to do the following steps of Table 1E.

6

TABLE 1E

Start an on-demand scan.

Start the service agent to check for updates.

Find out the version of the scan engine and DAT files.

Find out when was updating done the last time.

&null;0074&null; As the component manager handles different specialized subsystems, all events that are generated may be communicated back to the owner of the component manager handle using a callback function. To some of these events the callback function may return a TRUE Boolean value to indicate an affirmative answer that the core technology in question should proceed with the action that is about to happen, or return a FALSE to indicate that the action should not be performed.

&null;0075&null; As an example, when the service agent indicates that it is about to check for updates, if the callback function returns FALSE, this action may not happen.

&null;0076&null; See Table 2A for an exemplary component manager API.

7

TABLE 2A

CMgrCreate( )

Description

The CMgrCreate( ) function creates an instance of the component manager. A user interface layer

that wraps the core technology should make this call. The handle that is returned by this function

call should be passed to all subsequent calls to the component manager.

Prototype

HCMGR CMgrCreate( &null;&null;&null;&null;// Creates a component manager instance

&null;&null;PFNCMGRNOTIFY pfnNotify, // &null;in&null; Function to notify.

&null;&null;PVOID&null;&null;pUserParam // &null;in&null; Any user defined value.

&null;&null;);

Parameters

pfnNotify

&null;in&null; Pointer to a notification function that is called to notify the owner of this object about events

that are happening. See the description of CMgrNotify( ) function for more information.

pUserParam

&null;in&null; optionally the owner of this object can specify a user specific pointer size value that should

be passed to the callback function. This can be handy to eliminate the need of static variables on

platforms where static variables are not allowed.

Return Values

A handle to a component manager object. If NULL value is returned then this function call

failed. To find out the reason why this call failed call the ErrGet( ) function. This function is

thoroughly documented in the platform abstraction layer. If the function succeeds it may be a

valid handle that should be freed up using the CMgrDestroy( ) function when it is not needed

anymore.

See Also

CMgrDestroy( ), CMgrActivate( ), CMgrNotify( )

CMgrDestroy( )

Description

The CMgrDestroy( ) function destroys a component manager object that was created using

CmgrCreate( ). When this call is made all specialized subsystems are terminated and all resources

associated with these subsystems are freed up.

Prototype

int CMgrDestroy(&null;&null;// Destroys component manager instance.

&null;&null;HCMGR&null;&null;hCmgr&null;&null;&null;// &null;in&null; handle to component manager.

&null;&null;);

Parameters

hCmgr

&null;in&null; handle to a component manager to destroy. It must have been created using CMgrCreate( ).

Return Values

Zero is returned to indicate success. &null;1 is returned to indicate error To find out the reason why

this call failed called the ErrGet( ) function. This function is thoroughly documented in the

platform abstraction layer.

See Also

CMgrCreate( ), CMgrActivate( ), CMgrNotify( )

CMgrActivate( )

Description

The CMgrActivate( ) function starts the specified core technology component. It should be called

by the user interface to start certain actions such as a manual scan of the device or to start

checking for an update.

Prototype

int CMgrActivate(&null;&null;// Activates a component.

&null;&null;HCMGR&null;&null;&null;hCmgr,&null;&null;// &null;in&null; handle to component manager.

&null;&null;COMPID&null;&null;CompID&null;&null;&null;// &null;in&null; subsystem to activate

);

Parameters

hCmgr

&null;in&null; handle to a component manager that was created using CMgrCreate( ).

CompID Core component identifier that should be activated. This value can be any of the

following values. If some other core component value is given an error is returned.

COMPID_ONDEMAND, starts a manual scan of the device.

COMPID_SERVAGENT, start to check for a product update.

Return Values

Zero is returned to indicate success. &null;1 is returned to indicate error To find out the reason why

this call failed called the ErrGet( ) function. This function is thoroughly documented in the

platform abstraction layer.

See Also

CMgrCreate( ), CMgrDestroy( ), CMgrActivate( ), CMgrNotify( )

CMgrNotify( )

Description

The CMgrNotify( ) function must be implemented by the calling application and a pointer to it

must be passed during initialisation to CMgrCreate( ). This component manager may notify the

caller about different events as they are about to occur so the application can record these events

if it has to. The application can also indicate using the return code whether the event that it is

being notified about should be allowed or disallowed from happening.

Prototype

BOOL CMgrNotify(&null;&null;// Notification callback function.

&null;PCOMPMGRNOTIFYINFO pNotify &null;// Notification structure.

&null;);

Parameters

pNotify

&null;in&null; pointer to a notification structure. This structure hold everything needed to properly notify

the owner of this object about the events that are happening within the anti-malware scanner core

technology. This structure is defined as:

typedef struct tagCOMPMGRNOTIFYINFO

&null;

&null;&null;PVOID&null;&null;pUserParam;

// User defined value used in

CompMgrCreate( )

&null;&null;COMPID&null;&null;CompID;

// Component that generates this

event.

&null;&null;VSCNEVENT&null;&null;hEvent;

// Why the notification function

was called.

&null;&null;COMPMGRVALID Valid;

// Fields that are valid to check.

&null;&null;HVSCNITEM&null;&null;hItem;

// Item that scanner is notifying

about.

&null;&null;SCNDONEACTION DoneActionz;

// Status of completion status

&null; COMPMGRNOTIFYINFO, * PCOMPMGRNOTIFYINFO;

The structure members should be interpreted by the caller as:

pUserParam: The same user defined pointer size value that was given to the core component

manager during creation is returned in this field. This is a convenient way for applications to not

have to resort to global static data usage since this is not supported on many platforms.

CompID: This field indicates the component identification number that is notifying about an

event that is about to happen, or about an event that just happened. The possible component

identification numbers are as follows:

COMPID_ONACCESS, On-access scanning subsystem.

COMPID_ONDEMAND, On-demand scanning subsystem.

COMPID_ACTILOG, Activity logging subsystem.

COMPID_SERVAGENT, Service agent subsystem.

hEvent: This is the event that the CompID subsystem is notifying about. The possible event

identifiers for this field are as follows:

VSE_CANCELLED

The previous request that the component manager notified about was cancelled as requested by

the object owner. This is nothing more than a confirmation message indicating that the request

was understood. At this point the return code from this function has no meaning and it is ignored.

VSE_INFECTED

The component manager is indicating that a computer virus or some malicious code was found.

The subsystem that found this malicious code is known from the CompID component

identification number. If the component that found this malicious code is the on-demand scanner,

a return code of TRUE indicates that scanning should continue. A return code of FALSE

indicates that scanning should be stopped. If FALSE is returned a confirmation notification

message VSE_CANCELLED may be sent to the owner of this object. On the on-access and the

on-demand scanning subsystems can generate this event.

VSE_COMPLSTATUS

This event indicates the completion status of the action that was taken on an infected file. This

event can only be generated by the on-access and by the on-demand subsystems. For possible

completion status codes please see the DoneAction structure member. If the component that

found this malicious code is the on-demand scanner, a return code of TRUE indicates that

scanning should continue. A return code of FALSE indicates that scanning should be stopped. If

FALSE is returned a confirmation notification message VSE_CANCELLED may be sent to the

owner of this object. On the on-access and the on-demand scanning subsystems can generate this

event.

VSE_SCANNINGITEM

This is a notification event that tells the owner of this object that a file is about to be scanned for

viruses. The file that is about to be scanned has already been pre-filtered based on the IT

Administrator specified scan setting so at this way the user interface has no say about what files

are being scanned. The only core components that can generate this event are the on-access and

the on-demand scanners. Because the user can choose to cancel a user initiated on-demand scan,

the return code may only be respected if this event was generated by the on-demand scanner

subsystem. A return code of TRUE indicates that scanning should continue. A return code of

FALSE indicates that scanning should be stopped. If FALSE is returned a confirmation

notification message VSE_CANCELLED may be sent to the owner of this object.

VSE_START

This event indicates to the caller that the core technology component identified in the CompID

structure member just finished initialising. This is only a notification message so any return code

that is returned to the component manager from this event notification may be ignored.

VSE_END

This event indicates to the caller that the core technology component identified in the CompID

structure member just terminated. This is only a notification message so any return code that is

returned to the component manager from this event notification may be ignored.

Valid: This structure member indicates what other fields below this structure member contains

valid values. This structure field should be interpreted as a bit field and the individual bits should

be access the standard documented &null;C&null; coding guideline way. The named bit fields are as

follows:

bit_hItem, indicates that the hItem structure member is valid.

bit_DoneAction, indicates that the DoneAction structure member is valid.

hItem: This is a handle to a anti-malware scanner scan item. Information that is associated with

this handle can be accessed using the ScnItem family of functions.

DoneAction: This structure member indicates the completion status of an action that was

performed on an infected item. The completion status can be one of the following values:

SCNDONE_NOACTION, Nothing was done about the infected item.

SCNDONE_DENIEDACCESS, Infected item was denied access to.

SCNDONE_CLEANED, Infected item was cleaned.

SCNDONE_CLEANFAILED, Infected item could not be cleaned.

SCNDONE_DELETED, Infected item was deleted.

SCNDONE_DELETEFAILED, Infected item could not be deleted.

Return Values

The Boolean return value depends on the type of event that the owner of this object is being

notified with. Please see the description of each event for description on what the appropriate

return code should be.

See Also

CMgrCreate( ), CMgrDestroy( ), CMgrActivate( )

&null;0077&null; On-Access Scanner Module (206 of FIG. 2)

&null;0078&null; FIG. 7 illustrates a system 700 including an on-access scanner 702, in accordance with one embodiment. In general, the on-access scanner 702 is governed by operating system hooks 704 which provide document access notification. Further, the on-access scanner 702 interfaces with a scan engine 706 to scan documents. Still yet, the on-access scanner 702 reports scan activity to a component manager 708. More information relating to such operation will now be set forth.

&null;0079&null; The on-access scanner 702 identifies malware as documents are being access on the device. The on-access scanner 702 may be entirely transparent to the user until malicious code is discovered. Scanning can be performed on all executables and documents. This includes word processor documents or files being downloaded by a web browser. The on-access scanner can be configured to only scan certain types of documents.

&null;0080&null; The on-access scanner 702 is notified of various events related to accessing documents. It then determines whether the document needs to be scanned. The scan engine 706 is used to detect malicious code. When malicious code is discovered, the on-access scanner 702 notifies the component manager 708. It is then the component manager's responsibility to determine which of the following actions in Table 2B to perform.

8

TABLE 2B

Notify the user that malicious code was discovered.

Clean the infected file. Once successfully cleaned, the user

may access the file.

Delete the infected file. This results in an error message

displayed to the user that the file could not be accessed.

Optionally ask the user whether the infected items should be

cleaned, deleted, or just denying access to it.

&null;0081&null; On-access file scanning is accomplished by hooking into a file access notification mechanism that resides inside the operating system. For a comprehensive protection it is crucial to be able to hook into all file access events prior to them happening and after they have occurred.

&null;0082&null; The purpose of hooking into all file access events prior to them happening is so they can be intercepted. The purpose of hooking into all file access events after they have occured is so the file in question can be analyzed prior to control being returned to the operating system. An important part of this notification interception is that an application that is part of this notification chain must have the capability to allow or disallow an event from continuing through the file system notification. Of course nothing can be allowed or disallowed once the event has already happened, such as a close event, but in case an infected file is opened, the hooking application must indicate to the operating system that this event should not traverse further in the file system.

&null;0083&null; The file system related events that are filtered are as follows.

&null;0084&null; File Create Event

&null;0085&null; When a file create event is received it may be because the user has decided to download, beam or install some sort of application. When a create event occurs, the anti-malware scanner keeps track of a reference information that is associated with this event, and matches it up with the corresponding close event. This is done because when a new file is created it does not contain any information that can be analyzed for malicious code. It is important to know that if a &null;file create&null; event is the same as a file open event, these two are combined into one.

&null;0086&null; File Open, Execute Program Event

&null;0087&null; Prior to opening a file, the anti-malware scanner must make sure that the file is not infected. If the file is not infected, identification information is obtained from it. This way, when the file is closed this same information is compared to determine if any changes were made to the file. If changes were made, the anti-malware scanner resorts to a more resource intensive task to ensure that the file does not contain any malicious code. It is important to note that if application execution is a different event from a regular file open event, file execution should be monitored the same way.

&null;0088&null; File Close Event

&null;0089&null; The close event must be monitored for several reasons. As described above, when a file is created, it is scanned after the close operation occurred so the anti-malware scanner can analyze its content for computer viruses.

&null;0090&null; File Rename Event

&null;0091&null; This is yet another important part of the protection because a smarter computer virus could try to create a text file that contains malicious executable code and prior to launching it, rename it to an executable file type.

&null;0092&null; On-Access Scanner Subsystem Interaction

&null;0093&null; The on-access scanner subsystem is made usable with the help of other application subsystems. Each subsystem that on-access scanning interacts with are described below. A reason why this interaction is needed is also explained.

&null;0094&null; Component Manager

&null;0095&null; When the on-access scanning subsystem determined that there is something important to notify about such as an error condition or that an infected files was found, it informs the component manager.

&null;0096&null; Scan Engine

&null;0097&null; The scan engine is the component that takes a file and analyzes it to see if the file contains any malicious code. The scan engine is invoked prior to an open event happening and after a close event has happened.

&null;0098&null; Operating System

&null;0099&null; The on-access scanning subsystem must interact with the underlying operating system that informs of all file related events that take place. The operating system may always inform about the following information in Table 2C.

9

TABLE 2C

The full path and filename of the file that is being handled

by the operating system.

The function that the operating system is about to perform on

the indicated file.

Any time a drive is being connected and disconnected.

&null;0100&null; It is important to know that the file system should allow for re-entrancy so when a file system event is intercepted, the file system hooking function can open any file on any drive and perform I/O operations.

&null;0101&null; On some operating systems it is not possible for an application to use static or global data. Therefore, it would be required on those platforms that a mechanism is provided where the hooked function can access some previously allocated and initiated data.

&null;0102&null; An example way of accomplishing this would be to have a file system hook installation function that accepts a pointer to a callback function and a void pointer to application defined data. This application defined data would then be passed with every call to the hooking function. An example set of functions that are required to perform comprehensive file system hooking is described in Table 3.

10

TABLE 3

FsInstallHook( )

Description

The FsInstallHook( ) function installs a file system hook. All file I/O related events that occur

within the operating system are piped through this function.

Prototype

int FsInstallHook(

&null;&null;PFNFSHOOK pAppCallback,

&null;&null;void&null;*pUser,

&null;&null;PFNFSHOOK *ppPrevHook

&null;&null;);

Parameters

pAppCallback

&null;in&null; application defined callback function that should be called for all file system events. See

function definition for FsHookFunc( ) for a detailed description.

pUser

&null;in&null; is a user defined data that is passed to the callback function with every call so it can access

its own initialized data.

pPrevHook

&null;out&null; pointer to a pointer to the previous file system hooking function. This is required so file

system events can be chained. See function definition for FsHookFunc( ) for a detailed

description.

Return Values

A return value of zero should be returned for success or any other number to indicate an error

condition.

See Also

FsUninstallHook( ), FsHookFunc( )

FsUninstallHook( )

Description

The FsUninstallHook( ) function removes a previously installed file system hook.

Prototype

int FsUninstallHook(PFNFSHOOK pAppCallback);

Parameters

pAppCallback

&null;in&null; application defined file system callback function that was installed. See function definition

for FsHookFunc( ) for a detailed description.

Return Values

A return value of zero should be returned for success or any other number to indicate an error

condition.

See Also

FsInstallHook( ), FsHookFunc( )

FsHookFunc( )

Description

The FsHookFunc( ) is an application defined function that the operating system calls before a file

event occurs. This allows an application to be notified of all file I/O related events before they

occur and the application has the capability of allowing or disallowing a file I/O event from

continuing. Because FsHookFunc( ) is called before the event occurs, the hooking function may

most likely chain this event to the next caller in the list using the pPrevHook value that was

returned during hook installation. In case the hooking function determines that further chaining

of this file I/O event should not continue, it may return an error indicating this intent. As noted

previously, the file system should allow for reentrancy so within FsHookFunc( ) the application

can perform I/O operations on any other file that it chooses.

Prototype

int FsHookFunc(POSFILESTRUCT pOsFileInfo, void * pUserParam);

Parameters

pOsFileInfo

&null;in&null; this is an operating system dependent structure that contains all the necessary information

needed by the operating system to perform a file I/O related function. As an example of

information that a hooking function could obtain from here are:

Full path and filename to the file being accessed.

File system function identifier that is currently being requested such as CREATE, OPEN,

EXECUTE, CLOSE, READ, WRITE, Etc.

Function specific attributes such as file open attributes for an open function and file handle for a

close function.

Return Values

A return value of zero indicates success and any other number to indicate an error condition.

When an error is returned the operating system should not process this event.

See Also

FsInstallHook( ), FsUninstallHook( )

&null;0103&null; On-Access Scanner API

&null;0104&null; To protect against malicious code such as computer viruses, the anti-malware scanner requires access to all files being accessed through system provided APIs. The on-access scanning subsystem resides parallel to the other specialized subsystems and as such the component manager manages it.

&null;0105&null; FIG. 8 illustrates a framework 800 with an on-access scanner 801 interfacing with the file system 802 and filtering all file I/O related events. Every file that is about to be accessed is passed to the scan engine 804 that determines whether it is safe to access it. If the scan engine 804 determines that it is not safe, the component manager 806 may be notified and, based on established scan settings, some action may be done on the infected file. See Table 4 for an exemplary API.

11

TABLE 4

OnAccCreate( )

Description

The OnAccCreate( ) function creates an instance of the on-access scanning subsystem. If the

creation returns success the subsystem is ready to monitor for viruses in real-time. The actual

monitoring may begin when the OnAccEnable( ) function is called to request the subsystem to

enable itself.

Prototype

HONACCESS OnAccCreate(&null;&null;// Creates on-access scan instance

&null;&null;PFONACCNOTIFY pfnNotify,&null;&null;// &null;in&null; Function to notify.

&null;&null;PVOID&null;&null;pUserParam&null;&null;// &null;in&null; Any user defined value.

&null;&null;);

Parameters

phOnAccess

&null;out&null; pointer to an on-access scanner handle. This is the same handle that must be passed to

OnAccDestroy( ) before the application terminates.

pfnNotify

Address to a notification function. If NULL is passed in, all notifications may be turned off.

Please see OnAccNotify( ) function for a detailed description of this function.

pUserParam

A user defined value that may be passed to the call-back function.

Return Values

Zero is returned to indicate success. &null;1 is returned to indicate error To find out the reason why

this call failed called the ErrGet( ) function. This function is thoroughly documented in the

platform abstraction layer.

See Also

OnAccDestroy( ), OnAccEnable( ), OnAccNotify( )

OnAccDestroy( )

Description

The OnAccDestroy( ) function destroys an on-access scan instance that was created using

OnAccCreate( ). There is no need to call OnAccEnable( ) function to disable the on-access

scanning subsystem prior to destroying.

Prototype

int OnAccDestroy(&null;&null;//Destroys on-access scan instance.

&null;&null;HONACCESS&null;&null;hOnAccess&null;&null;// &null;in&null; handle to destroy

&null;&null;);

Parameters

hOnAccess

&null;in&null; handle to an on-access scanner subsystem. This is the same handle that was created using

OnAccCreate( ).

Return Values

Zero is returned to indicate success. &null;1 is returned to indicate error To find out the reason why

this call failed called the ErrGet( ) function. This function is thoroughly documented in the

platform abstraction layer.

See Also

OnAccCreate( ), OnAccEnable( ), OnAccNotify( )

OnAccEnable( )

Description

The OnAccEnable( ) function allows the caller to enable and disable the on-access scanning

subsystem that was created using OnAccCreate( ). The on-access scanner is enabled and disabled

internally to the anti-malware scanner when an on-demand scan is started. This is done so the on-

access scanner does not interfere with the on-demand scanners work. When on-demand scanning

is completed, on-access scanning is re-enabled.

Prototype

int OnAccEnable(&null;&null;//Enable on-access scan subsystem.

&null;&null;HONACCESS hOnAccess, // &null;in&null; handle to on-access scanner.

&null;&null;BOOL&null;&null;bEnable&null;&null;// &null;in&null; TRUE/FALSE to enable/disable.

&null;&null;);

Parameters

hOnAccess

&null;in&null; handle to an on-access scanner subsystem. This is the same handle that was created using

OnAccCreate( ).

bEnable

&null;in&null; A Boolean TRUE to indicate that the on-access scanning subsystem should be enabled, that

is it should monitor for file activities and scan files as they are being accessed. A Boolean value

of FALSE disables the on-access scanning subsystem.

Return Values

Zero is returned to indicate success. &null;1 is returned to indicate error To find out the reason why

this call failed called the ErrGet( ) function. This function is thoroughly documented in the

platform abstraction layer.

See Also

OnAccCreate( ), OnAccDestroy( ), OnAccNotify( )

&null;0106&null; Table 5 illustrates additional optional components of the on-access scanner API.

&null;0107&null; FIG. 9 illustrates the manner 900 in which the on-access scanner is enabled and disabled during use based on on-demand scanning. Upon on-demand scanning being requested in operation 902, on-access scanning is disabled in operation 904. Thus, on-demand scanning may be performed in operation 906.

&null;0108&null; Once the on-demand scanning is complete, the on-access scanning may be enabled in operation 908. By this design, the on-access scanning is disabled when on-demand scanning to preserve resources on the mobile wireless device. In the context of the foregoing interface, the OnAccEnable( ) command may be used to effect the enabling and disabling of the on-access scanning. More information on the on-demand scanning will be set forth hereinafter in greater detail.

&null;0109&null; Java Scanner (210 of FIG. 2)

&null;0110&null; Java Applet and Script Scanning

&null;0111&null; To protect against malicious Java applets and Java scripts, the anti-malware scanner requires access to executable images and scripts through system provided APIs. The Java applet/script scanning subsystem resides parallel to on-access scanning and on-demand scanning subsystems and, as such, it is managed by the component manager.

&null;0112&null; FIG. 10 illustrates the Java scanning module 1000 interfacing with the Java VM 1002 and filtering all Java applet and Java script executions. Every Java object that is about to be executed is passed to the scan engine 1004 that determines whether it is safe to execute the Java object. If the scan engine determines that it is not safe, the component manager 1006 may be notified and, based on established scan settings, some action may be done on it.

&null;0113&null; See Table 6 for an exemplary Java Scanner API.

12

TABLE 6

JavaInstallHook( )

Description

The JavaInstallHook( ) function installs a Java applet interpreter or a Java script interpreter hook.

All I/O related events that occur within the Java interpreter are piped through this function.

Prototype

int JavaInstallHook(

&null;&null;PFNJAVAHOOK pAppCallback,

&null;&null;void&null;&null;* pUser,

&null;&null;PFNJAVAHOOK * ppPrevHook

&null;&null;);

Parameters

pAppCallback

&null;in&null; application defined callback function that should be called for all Java events. See function

definition for JavaHookFunc( ) for a detailed description.

pUser

&null;in&null; is a user defined data that is passed to the callback function so it can access its own

initialized data.

pPrevHook

&null;out&null; pointer to a pointer to the previous Java interpreter hooking function. This is required so

Java events can be chained. See function definition for JavaHookFunc( ) for a detailed

description.

Return Values

A return value of zero should be returned for success or any other number to indicate an error

condition.

See Also

JavaUninstallHook( ), JavaHookFunc( )

JavaUninstallHook( )

Description

The JavaUninstallHook( ) function removes a previously installed Java interpreter hook.

Prototype

int JavaUninstallHook(

&null;&null;PFNJAVAHOOK pAppCallback

&null;&null;);

Parameters

pAppCallback

&null;in&null; application defined Java interpreter callback function that was installed. See function

definition for JavaHookFunc( ) for a detailed description.

Return Values

A return value of zero should be returned for success or any other number to indicate an error

condition.

See Also

JavaInstallHook( ), JavaHookFunc( )

JavaHookFunc( )

Description

The JavaHookFunc( ) is an application defined function that the Java interpreter calls before a

Java applet or a Java script is executed. This allows an application to analyze and allow or

disallow the execution of the Java script. Because JavaHookFunc( ) is called before the execution

occurs, the hooking function may most likely chain this event to the next caller in the list using

the pPrevHook value that was returned during hook installation. In case the hooking function

determines that further chaining of this event should not continue, it may return an error

indicating this intent.

Prototype

int JavaHookFunc(

&null;&null;PJAVAINTINFO pInterpreterInfo,

&null;&null;void&null;&null;* pUserParam

);

Parameters

&null;in&null; pInterpreterInfo

This is a Java interpreter dependent structure that contains all the necessary information needed

by the Java interpreter to perform I/O related function. As an example of information that a

hooking function could obtain from here are:

Name of the Java object about to be accessed.

Java interpreter specific function identifier that is being performed such as EXECUTE, CLOSE,

Etc.

Any Java interpreter data that is required to complete the request. As an example for an execute

event there should be a buffer pointer to the Java applet or Java script that is about to be

executed.

&null;in&null; pUserParam

This is the user defined value that was passed to JavaInstallHook( ) function. It is provided to this

function with every call.

Return Values

A return value of zero indicates success and any other number to indicate an error condition.

When an error is returned the Java interpreter should not process this event.

See Also

JavaInstallHook( ), JavaUninstallHook( )

&null;0114&null; On-Demand Scanner Module (208 of FIG. 2)

&null;0115&null; FIG. 11 illustrates an on-demand scanner system 1100 including an on-demand scanner 1101 interacting with a component manager 1102 and a scan engine 1004. Further provided is plug-in support 1006 which interfaces a plurality of abstract file system plug-ins 1108.

&null;0116&null; The on-demand scanner 1101 is a component of the anti-malware scanner system responsible for scanning collections of data objects. The component manager 1102 initiates calls to the on-demand scanner 1101. The on-demand scanner 1101 makes use of the scan engine 1102 to detect and clean malware. It also makes use of plug-ins 1106, 1108 to determine if a given file can be interpreted as a directory. For example, a compress archive can be enumerated like a directory. The plug-ins 1108 may supply alternate translations to files for decompression, decryption, or other aspects of using the file.

&null;0117&null; The on-demand scanner 1101 recursively enumerates all data objects on the device from a given starting location. While scanning files, three callback functions are used: pScanFile, pScanDirectory, and pCleanFile. To use the on-demand scanner 1101, the caller must initialise an SE_SCANNER from the scan engine 1104 and the proper callback functions.

&null;0118&null; FIG. 12 illustrates a method 1200 for performing on-demand scanning, in accordance with one embodiment. As shown, the scanner is started in operation 1202, after which a first entry is identified in operation 1204. It is then determined whether the entry is of a file type or a directory type in decision 1206.

&null;0119&null; If the entry is of a file type, a filter is obtained in operation 1208, after which a file callback is executed in operation 1210. Based on the callback function, the file is then conditionally scanned in operation 1212. If the file is deemed infected, a clean callback is executed. See operation 1214.

&null;0120&null; If, on the other hand, the entry is of a directory type (see decision 1206), a directory callback is executed in operation 1216. Next, a recursive scan is executed in operation 1218. The foregoing method 1200 is continued until all of the entries are identified (see operation 1220).

&null;0121&null; On-Demand Scanner API

&null;0122&null; An exemplary API for carrying out the foregoing functionality is set forth in Table 7.

&null;0123&null; Scan Engine (216 of FIG. 2)

&null;0124&null; FIG. 13 illustrates a scan engine system 1300 including a scan engine module 1302, a file parser 1304, and an interpreter 1306. The scan engine system 1300 interfaces the on-access and on-demand scanner modules 1308 to carry out virus detection and clean files. See operation 1310.

&null;0125&null; The scan engine system 1300 is responsible for scanning individual data objects for malware and to repair infected documents. Potentially infected data is presented to the scan engine system 1300 from the on-access and on-demand scanner modules 1308. It is built to be system independent, and thus has an abstraction for data objects that can be scanned and cleaned.

&null;0126&null; Scan Engine API

&null;0127&null; The purpose of the scanner API is to enable the on-demand and on-access scanner modules 1308 to initiate detection and cleaning of malware in a given data object. This involves providing the necessary detection and cleaning files as well as providing data objects to scan.

&null;0128&null; An abstract file system is used to make the scan engine system 1300 portable to new devices and enable scanning of many different data objects. More information about ADIR, ADIRENT, and AFILE data objects of the abstract file system will be set forth hereinafter in greater detail.

&null;0129&null; Table 8 illustrates an exemplary scan engine API.

13

TABLE 8

SEOpenScanner

Description

Create an instance of the scanner. The scanner is initialized with files found in the provided

pADir. As the scanner doesn't know how to parse file names (being ASCII and Unicode

agnostic), the ADIR must filter out any non-PD files.

Prototype

SCANNER *SEOpenScanner(HDIR hDir);

Parameters

hDir

&null;in&null; The supplied HDIR must enumerate only the PD files that are to be used by the scanner.

Return Value

The function return is an initialized SCANNER data structure. The contents of the SCANNER

data structure are internal to the scan engine implementation.

See Also

SECloseScanner( )

SECloseScanner

Description

When done using the scanner, it must be closed. This releases any resources that were used by

the scanner.

Prototype

void SECloseScanner (SCANNER *pScan);

Parameters

pScan

&null;in&null; pScan is the scanner to close.

See Also

SEOpenScanner( )

SEScanFile

Description

Scan the given file for malware. The return value may usually be &null;1 for no malware detected.

Otherwise, SEScanFile returns an identifier for the discovered malware.

The returned ID is used with the SECleanFile( ), SEGetScanName( ), and SEGetScanVariant( )

functions. The ID doesn't completely identify the malware as the scanner state holds information

about what was discovered.

Prototype

scan_result_t SEScanFile (

&null;&null;SCANNER *pScan,

&null;&null;FILEPATH *pFileName,

&null;&null;HFILE hFile);

Parameters

pScan

&null;in&null; pScan is the scanner to use.

pFileName

&null;in&null; The name of the file being scanned.

hFile

&null;in&null; The file opened for read access. The hFile may be a specialized interface for reading this

type of file.

Return Value

The returned scan_result_t is an identifier for the malware detected. If malware is not detected,

then the return value is &null;1.

See Also

SECleanFile( ), SEGetScanName( ), SEGetScanVaraint( ).

SECleanFile

Description

Attempt to repair the given infected file. This can only be called after SEScanFile( ) to identify

malware. The clean function may include deleting the file.

Prototype

int SECleanFile (

&null;&null;SCANNER *pScan,

&null;&null;FILEPATH *pFileName,

&null;&null;AFILE *pFile,

&null;&null;scan_result_t id)

Parameters

pScan

&null;in&null; pScan is the scanner to use.

pFileName

&null;in&null; The file name of the file being scanned.

hFile

&null;in&null; The file opened for read access.

Return Values

On success, SECleanFile returns Otherwise, it returns &null;1.

See Also

SEScanFile( ).

SEScanGetName

Description

Returns the base name of the malware detected. The returned name may change in subsequent

calls to SEScanFile( ).

Prototype

char *SEScanGetName(SCANNER *pScan, scan_result_t id)

Parameters

pScan

&null;in&null; The scan engine used with SEScanFile( ).

id

&null;in&null; The returned ID from SEScanFile( ).

Return Values

Returns a UTF-8 encoded, zero terminated string. The string is the base name of the malware

detected. If no name is available, NULL is returned.

See Also

SEScanGetVariant( ), SEScanFile( ).

SEScanGetVariant

Description

Returns the variant of the malware detected. Normally this is concatenated with the base name to

form the full name of the malware.

Prototype

char *SEScanGetVariant(SCANNER *pScan, scan_result_t id)

Parameters

pScan

&null;in&null; The scan engine used with SEScanFile( ).

id

&null;in&null; The returned ID from SEScanFile( ).

Return Values

Returns a UTF-8 encoded, zero terminated string. The string is the extended name of the

malware detected. Concatenate this to the end of the base name to get the complete name. If no

name is available, NULL is returned.

See Also

SEScanGetName( ), SEScanFile( ).

&null;0130&null; PD File Format

&null;0131&null; The purpose of this file is to provide the necessary information to detect and clean malware on handheld devices.

&null;0132&null; The PD file is composed of a header and a collection of records. The header provides general information about the use and management of the PD file. The records contain details about scanning and cleaning malware.

&null;0133&null; One of the design considerations is that 2-byte entries is desired to be 2-byte aligned, and 4-byte entries to be 4-byte aligned. This resolves some portability issues to processors that can't or have difficulty accessing non-aligned memory references. Note that aligned 4-byte values are not enforced with the instruction byte-code unless the target platform requires it.

&null;0134&null; Other than keeping the scan engine small, one may also want to support incremental updates for the PD file. One goal is to keep file transfers to the PD devices small.

&null;0135&null; The following capabilities of Table 9 may be required.

14

TABLE 9

After the file header, the rest of the file is a list of

records

New records can be added to the end of the file

Records can be marked as free

Free records can be re-used for new records

Neighboring free records are merged to create a larger

free record

A record may be moved in memory when updating the contents

of that record

It's possible that all records may be moved when de-

fragmenting the file

Avoid re-encrypting the entire file because of a small

change

An updated checksum needs to be supplied with patches to

verify the update

&null;0136&null; File Header

&null;0137&null; Table 10 illustrates an exemplary file header.

15

TABLE 10

Bytes

Description

48&null;

Copyright notice, end with CTRL&null;Z

2

Header size

2

Target platform identifier

2

Scan class identifier

2

Reserved. (To be determined - used as 4-byte alignment padding)

4

File version number (major, minor, revision, build)

4

File format version number

4

Date of creation

4

Date of last incremental update

4

Checksum of contents

4

Encryption seed

4

First scan record offset

4

First check record offset

4

First clean record offset

4

First free record offset

&null;0138&null; Header Size

&null;0139&null; This is used for future expansion. One can add new information to the header without breaking compatibility with older scan engines. This may never actually be used. Byte order for this value is target platform dependant.

&null;0140&null; Target Platform Identifier

&null;0141&null; To simplify parsing the PD file on the target machine, the PD file is formatted for the target. The target platform identifier denotes which type of target the file is intended. From this, the following information of Table 11 can be deduced.

16

TABLE 11

Big-endian or little endian byte order

Text encoding format

Byte alignment

&null;0142&null; The only defined combination is the following set forth in Table 12.

17

TABLE 12

Little endian byte order

UTF-8 text encoding

2-byte values are 2 byte aligned, 4 byte values are

4-byte aligned

&null;0143&null; The definition of Table 12 is used for the target platforms of Table 13.

18

TABLE 13

Windows variants on IA-32 processors

Linux on IA-32 processors

Symbian EPOC on ARM processors

&null;0144&null; Scan Class Identifier

&null;0145&null; The scan class identifier is a value for identifying what class of data the PD file is designed to scan. The following classes of Table 14 are identified at this time.

19

TABLE 14

Value

Description

1

File system

2

Process

3

Data stream

&null;0146&null; Record Header

&null;0147&null; The records have a common layout to make incremental update simple and aide in finding records without making the scan engine large. An update would send only those records that need to be deleted, replaced, or added. See Table 15.

20

TABLE 15

Offset

Bytes

Description

0

2

Record length (N)

2

2

Record type (Scan, name, check, clean, or free)

4

4

Record identifier

8

4

Address of next record of this type (0 if end of list)

12

Record data

0-3

Pad record out to 4-byte align

&null;0148&null; Instead of referencing parts of the file by address, the PD file uses record ID's. This makes it possible to move a record without having to change every reference to the record.

&null;0149&null; The record header uses addresses to create a linked list of each type of record. This may help improve performance in finding the proper record. Eventually this could be used to sort records by record ID.

&null;0150&null; Record lengths are only 2-byte values. This is intentional to make porting between 16-bit processors simple. For example, a mobile wireless device such as a Palm&null; Pilot&null; uses a database instead of a file system. Each record can be at most 64 KB. Nearly all scan functions may be very small. As they get larger, new instructions should be added to the language to move the functionality into the scan engine.

&null;0151&null; It may be interesting to apply a simple Huffman compression algorithm to the PD byte codes on a record-by-record basis.

&null;0152&null; Scan Records

&null;0153&null; This record contains a function for doing an initial scan of the selected file. The amount of code needed for this scan may exceed 64 KB (the maximum record size). Thus, the first scan record starts the process, but may reference other scan records. One goal is to keep the initial scan record small, yet able to eliminate 80% of the clean files. This keeps the scan engine's memory footprint small as well as making efficient use of the processor.

&null;0154&null; If malware is discovered, the scan function may return the record ID of the name record for this item. This table entry may provide the proper check function to verify the malware variant present. Though this does a double reference, it may not be important. Most of the time is spent eliminating files so that this step may be rare.

&null;0155&null; Check Records

&null;0156&null; Check records contain functions for identifying the specific malware variant once identified by the scan records.

&null;0157&null; The check record starts with the following header information in Table 16.

21

TABLE 16

Offset

Bytes

Description

0

4

Record ID of the clean function to call (or 0 if none)

4

2

Number of bytes in name section (N)

6

1

Number of names provided

7

1

Length of malware name, (N0)

8

N0

Text name of the malware

1

Length of variant name (N1)

N1

Text name of the variant

. . . (Repeat for k variants)

1

Length of variant name (Nk)

Nk

Text name of the variant

0-1

Pad record out to 2-byte align length

N &null; 4

Instructions for the check function

&null;0158&null; If no variants are detected, then &null;0 is returned. Otherwise, the index for the variant is returned. A 0 is used if the generic malware detection suffices.

&null;0159&null; It should be noted that many different check functions can be merged into a single record to reduce the file size if they are sufficiently similar. However, this can cause trouble for incremental updates.

&null;0160&null; Clean Records

&null;0161&null; A clean record contains a function for removing the malware and repairing files if possible.

&null;0162&null; It should be noted that multiple detected malware may use the same clean function.

&null;0163&null; Free Records

&null;0164&null; When a record is deleted, it is merged with other free records or added to the free record list. This allows the system to re-use space when performing incremental updates. It solves the problem of re-writing the entire file just because a portion was modified.

&null;0165&null; Replacing a record is the same as deleting the original, and then adding a new record in its place.

&null;0166&null; Free records may be set to zero to make predicting the checksum easier.

&null;0167&null; Activity Logging Module (214 of FIG. 2)

&null;0168&null; The activity logging subsystem is responsible for recording significant events to be collected at the back-end for analysis. This aids in providing information from the field to track outbreaks, detect and diagnose issues, and help determine how to improve the product.

&null;0169&null; The following are logged events in Table 17.

22

TABLE 17

Error conditions and warnings

Detection of malware

Infected file name and path

Malware name and variant

Response to malware

File name and path

Action taken

Starting and stopping of services

On-demand scan

On-access scanner

Virus scanner application

Service agent upgrades

&null;0170&null; The detection of and response to malware is separated. Detection is logged immediately when the malware it detected. Once the action is taken and successfully completed, the response is logged. If anything were to go wrong with the response, one would at least see the detection entry.

&null;0171&null; Adding log file entries is supported at two levels. The most common are functions that handle specific logging needs. These require all the necessary information and add them to the log file with the minimum effort from the programmer. The lower layer manages the log file rotation and a generic mechanism for adding entries.

&null;0172&null; Configuration

&null;0173&null; The activity log requires the following configuration values in Table 18.

23

TABLE 18

Log file rotation size

Log file maximum size

Log trace messages (yes/no)

&null;0174&null; A single log file is used until is reaches the log file rotation size. At which point, it is renamed and a new log file is started. Once the total space used by all of the log files exceeds the maximum, the oldest log file is removed. As log files are uploaded from the device, they are deleted from the device.

&null;0175&null; The log file location and naming conventions are configured per platform when the program is compiled.

&null;0176&null; Requirements

&null;0177&null; See Table 19 for possible requirements.

24

TABLE 19

It must be reasonable to translate the log file to multiple

languages.

Limit the log file size to a reasonable (configurable) maximum

Scroll log file entries as the log file becomes too large (&null;)

Track time and date of log entries

Available to the service agent for transmission to the back-end

Once transferred, the log file may be truncated.

It must be resilient to system crashes

Output in a simplified, structured XML format with header for

ASCII or UNICODE encoding

Enforce log file structure and completeness if information

presented

Ability to detect when log files have been lost due to exceeding

the maximum log file size.

&null;0178&null; Table 20 illustrates an exemplary interface associated with the activity logging module.

25

TABLE 20

High level API

LogOpen

Description

Open the log file for reading.

Prototype

HLOG LogOpen(HVSOPTS opts);

Parameters

opts

&null;in&null; A handle to the configuration options manager.

Return Value

Returns a handle to the log file. It is needed for all of the log functions.

If reading the log file, call LogTruncate( ) after the last log file that is successfully transferred

from the device. Call LogClose( ) when the log file is no longer being used. If LogTruncate( ) is

not called, then the entries may be read the next time LogOpen( ) is called.

LogClose

Description

Closes the log file. This de-allocates all resources related to using the log file.

Prototype

void LogClose(HLOG log)

Parameters

log

&null;in&null; The log file to close.

LogMessage

Description

Adds a message entry into the log file. The type of message is based on

LOG_MESSAGE_TYPE.

LOG_TRACE is used to help diagnose problems by logging certain milestones in the program.

Normally, trace messages are not added into the log file unless configured.

LOG_WARNING is provided when a problem is encountered, but does not prevent the proper

operation of the program.

LOG_ERROR should be used when a recoverable error is encountered. Some functionality of

the program may be hindered.

LOG_FATAL should only be used when the error is severe, non-recoverable, or prevents the

program from running. This may be useful in a post-mortem analysis if the device is returned.

Note that the messages are intended for diagnosing field errors by the anti-malware scanner

software engineers, and not intended for administrators to understand. Thus, these messages can

be in English.

Prototype

typedef enum &null;

&null;&null;LOG_TRACE,

&null;&null;LOG_WARNING,

&null;&null;LOG_ERROR,

&null;&null;LOG_FATAL

&null; LOG_MESSAGE_TYPE;

void LogMessage(HLOG log, LOG_MESSAGE_TYPE type, VSWSTATUS status,

&null;&null;char *pMessage)

Parameters

log

&null;int&null; This is a handle for the log file.

type

&null;in&null; The type of message being logged.

status

&null;int&null; This is the status code associated with the message. For non-English speaking countries,

this may be used to display the error message in the native language.

pMessage

&null;in&null; A UTF-8 encoded, zero terminated string. This is used for extra information our engineers

can use to diagnose problems.

LogMalwareDetect

Description

This must be called as soon as malware is detected. The file path must be converted into UTC-8

as a zero terminated string. The scan engine provides malware names and variant names in

UTC-8.

Prototype

void LogMalwareDetect(

&null;&null;HLOG log,

&null;&null;FILEPATH *pFilePath,

&null;&null;char *pMalwareName,

&null;&null;char *pMalwareVariant

)

Parameters

log

&null;in&null; A handle to the log file.

pFilePath

&null;in&null; This specifies a full description of the infected data object. In a file system, this is the file

path. In a database, it uniquely identifies the record. Etc.

pMalwareName

&null;in&null; This is the malware name as returned by SEGetScanName( ).

pMalwareVariant

&null;in&null; This is the malware variant as returned by SEGetScanVariant( ).

LogMalwareAction

Description

This must be called once an action to the detected malware is completed. A log entry should also

be provided even for ignoring the malware. If the action does not successfully complete, a

warning or error message should be added instead.

The path provided must be converted to UTC-8. Note that 7-bit clean ASCII text is a subset of

the UTC-8 specification.

Prototype

typedef enum &null;

&null;&null;LOG_CLEAN,

&null;&null;LOG_DELETE,

&null;&null;LOG_QUARANTEEN,

&null;&null;LOG_IGNORE,

&null; LOG_ACTION;

void LogMalwareAction(HLOG log, FILEPATH *pPath, LOG_ACTION action)

Parameters

log

&null;in&null; A handle to the log file.

pPath

&null;in&null; This is a UTF-8 encoded, zero terminated string. It provides the full path description of the

data object identified. This should be the same string as sent to LogMalwareDetect( ).

action

&null;in&null; The action that was successfully completed on the infected data object.

LogServiceEvent

Description

This is used to track when services are started and stopped. Tracking these events can help

diagnose problems in the field. For example, log entries on starting the application without it

being stopped may denote that it crashed and was restarted. Onecan also detect whether the on-

access scanner is being disabled and whether the on-demand scanner is being used regularly.

More specific milestones should be tracked with the LOG_TRACE messages through the

LogMessage( ) function. Unlike the LOG_TRACE messages, the service events are always

available in the log file.

Prototype

typedef enum &null;

&null;&null;LOG_START_SERVICE,

&null;&null;LOG_STOP_SERVICE,

&null; LOG_EVENT;

typedef enum &null;

&null;&null;LOG_APPLICATION,

&null;&null;LOG_ON_DEMAND,

&null;&null;LOG_ON_ACCESS,

&null;&null;LOG_AGENT,

&null;&null;LOG_INSTALL

&null; LOG_SERVICE;

void LogServiceEvent(HLOG log, LOG_EVENT event, LOG_SERVICE service)

Parameters

log

&null;in&null; A handle to the log file.

event

&null;in&null; Specify whether the service is starting or was stopped.

service

&null;in&null; Specify which service.

Low level API

The low level API manages the log file rotation and adding generic entries to the log file. This

interface is agnostic to what data is added to the log file. The high level API is implemented

based on these functions.

The first group is for adding entries to the log file.

LogOpenEntry

LogEntryField

LogCloseEntry

The above functions are used to create new high-level API functions that are consistent with the

subset of XML that is supported. Be careful to define all English words that are used as

keywords. This way they can be parsed and translated easily to different languages. This

ensures that the raw log file is human readable, though in English, but is easy to also view in any

other language.

The next group of functions is for consuming log file entries:

LogOpen

LogRead

LogTruncate

LogClose

LogOpenEntry

Description

Open a new log entry. Each entry is automatically stamped with the time and date.

Prototype

HLOGENTRY LogOpenEntry(

&null;&null;HLOG log,

&null;&null;char *pEntryName)

Parameters

pEntryName

&null;in&null; The name that may be used for this entry. This is placed in the log file as follows:

&null;&null;<entry-name>

&null;&null;&null; fields &null;

&null;&null;</entry-name>

Where entry-name is replaced with pEntryName.

Return Value

A handle to the log entry is supplied, or NULL on error.

See Also

LogEntryField( ), LogCloseEntry( )

LogEntryField

Description

Add a field to the given log entry. The field name and value are provided to help structure the

log entry. This is useful for generating different tables of information in the log file.

Prototype

int LogEntryField(

&null;&null;HLOGENTRY hLogEntry,

&null;&null;char *pFieldName,

&null;&null;char *pFieldValue);

Parameters

pLogEntry

&null;in&null; This is a handle to the log entry to add the field.

pFieldName

&null;in&null; This is a UTC-8 encoded string for the field-value. It is used as in

<field-name>field-value</field-name>

pFieldValue

&null;in&null; This is a UTC-8 encoded string used as the field-value.

Return Value

The LogEntryField( ) function returns 1 on success, or 0 if it failed to add the entry.

LogCloseEntry

Description

Close the log entry. No more fields may be added to the entry.

Prototype

void LogCloseEntry(HLOGENTRY hEntry);

Parameters

hEntry

&null;in&null; The log entry to close.

LogRead

Description

Read an entry from the log file.

Prototype

char *LogRead(HLOG log)

Parameters

log

&null;in&null; The log file being read.

Return Value

The returned value a UTF-8 encoded, zero terminated string for the XML entry. It is

autonomous in the sense that the caller can stop reading at any time and have a valid XML file

from what was read.

The returned string is only valid until the next call to LogRead( ). At which point, it may be

overwritten with the next entry or de-allocated. A call to LogClose( ) also invalidates the string.

NULL is returned if there are no more log entries.

LogTruncate

Description

Remove all entries that were read from the log. This should be used once the log entries are

confirmed transferred off of the device.

Prototype

void LogTruncate(HLOG log);

Parameters

log

&null;in&null; A handle to the log file.

&null;0179&null; File Format

&null;0180&null; The file format may be based on XML. There is a common form that is supported by the low-level API. This is described as follows. Then below, specifics for each type of logged event are provided as well.

&null;0181&null; Each log file is numbered sequentially. This enables sorting and merging log files, as well as detecting when log files are missing. See Table 21.

26

TABLE 21

For UNICODE

<&null;xml version&null;&null;1.0&null; encoding&null;&null;ISO-10646&null;&null;>

For ASCII

<&null;xml version&null;&null;1.0&null; encoding&null;&null;ISO-8859-1&null;&null;>

Then the rest:

<log id&null;log_id>

<entry-name date&null;&null;time-date-stamp&null;>

<field-name> value </field-name>

. . .

</entry-name>

. . .

&null;0182&null; The strings entry-name and field-name are replaced with the actual entry and field names. The time-date-stamp is the time at which the entry is added to the log file. This is encoded as YYYYMMDDhhmmss, where YYYY is the year, MM is the month, DD is the day of the month, hh is the hour, mm is the minutes, and ss is the seconds.

&null;0183&null; A sample LogMessage object is shown in Table 22.

27

TABLE 22

<event date&null;&null;YYYYMMDDhhmmss&null;>

<type>message-type</type>

<message>message-body</message>

</event>

message_type is one of trace, warning, error, or fatal.

message_body is the text string provided for the message.

&null;0184&null; A sample LogMalwareDetect object is shown in Table 23.

28

TABLE 23

LogMalwareDetect

<detect date&null;&null;YYYYMMDDhhmmss&null;>

<path>file-path</path>

<name>malware-name</name>

<variant>malware-variant</variant>

</detect>

file-path is a string identifying where the infected item was found.

malware-name is the name of the detected infection

malware-variant is the verified variant name of the infection

LogMalwareAction

<action date&null;&null;YYYYMMDDhhmmss&null;>

<path>file-path</path>

<action>scanner-action</action>

</action>

scanner-action is one of &null;clean&null;, &null;delete&null;, &null;quarantine&null;, &null;ingore&null;.

&null;0185&null; A LogServiceEvent is shown in Table 24.

29

TABLE 24

<service date&null;&null;YYYYMMDDhhmmss&null;>

<name>service-name</name>

<action>service-action</action>

</service>

service-name is the name of the service: &null;on-demand&null;, &null;on-access&null;,

&null;application&null;, &null;agent&null;, &null;installer&null;.

service-action the word &null;start&null; or &null;stop&null;.

&null;0186&null; Service Agent

&null;0187&null; FIG. 14 illustrates a service agent (SA) architecture 1400, in accordance with one embodiment. As shown, a service agent 1402 interfaces with an user interface 1403, an on-access scanner module 1404, and an on-demand scanner module 1406. Such on-access scanner module 1404 and on-demand scanner module 1406, in turn, interface a scan engine 1408.

&null;0188&null; In use, the service agent 1402 communicates with the back-end architecture 1410 which may be controlled and monitored via a web-interface 1412. The service agent 1402 is thus responsible for communicating with the back-end architecture 1410. It handles delivering device-specific information such as log data to a remote back-end architecture 1410. The second responsibility is in retrieving the anti-malware scanner component installation and package updates. The component manager initiates service agent updates. This may be due to scheduled updates or by user initiated updates.

&null;0189&null; FIG. 15 illustrates a method 1500 for scanning a mobile wireless device for malware. Initially, in operation 1502, a service agent 1402 is initiated utilizing a mobile wireless device. In one embodiment, the service agent may be initiated by a user interface of the mobile wireless device. Further, the service agent may be initiated by the anti-malware scanner of the mobile wireless device. Still yet, the service agent may be initiated by a daemon of the mobile wireless device. As an option, the service agent may be initiated by a scheduler of the mobile wireless device or a trigger.

&null;0190&null; Next, in operation 1504, information describing the mobile wireless device is transmitted to a back-end server over a wireless network utilizing the service agent of the mobile wireless device. In one embodiment, the information describing the mobile wireless may include log data. Such log data may be specific to the mobile wireless device.

&null;0191&null; In operation 1506, an update is then received from the back-end server over the wireless network utilizing the service agent of the mobile wireless device. Optionally, the update may be wrapped. Further, the update may include a header and a plurality of parts. Such parts may include a part-header section and a part-data section.

&null;0192&null; Subsequently, in operation 1508, an anti-malware scanner installed on the mobile wireless device is updated so that the mobile wireless device may be scanned utilizing the updated anti-malware scanner. More information regarding the foregoing architecture 1400 and associated method 1500 will now be set forth.

&null;0193&null; Agent Activation Scenarios

&null;0194&null; FIG. 16 illustrates a sample service agent activation method 1600, in accordance with one embodiment. Depending on the operating system running on the wireless device, the service agent 1602 can be launched by the user-interface 1604, on-demand and on-access scanners 1606, a background process (daemon) and/or system scheduler 1608, itself 1609, and external signal/trigger 1610 originated from the service provider. More information regarding such triggers will now be set forth.

&null;0195&null; Activation Through User-Interface (Manual Trigger)

&null;0196&null; The agent can be directly launched from the wireless user-interface by the user. When the user selects an update-now button (or menu entry), the user-interface activates the agent.

&null;0197&null; Activation by the Agent (Self Trigger)

&null;0198&null; Under multi-process operating environment, the service agent stays resident and awaits (or sleeps) for update-interval time specified in the anti-malware scanner configuration before contacting the update server.

&null;0199&null; Scanner Activation (Scanner Trigger)

&null;0200&null; The agent is launched for new updates when the on-demand and/or on-access scanner notices that the update-interval-time has elapsed since the agent was activated last.

&null;0201&null; Scheduled Activation (Scheduled Trigger)

&null;0202&null; Operating system provided scheduler like cron&null; in Unix/Linux&null; is utilized to schedule the agent activation. Also, if the operating system allows daemon (or background process), a simple daemon is used to activate the service agent.

&null;0203&null; Carrier/Service Provider Activation (External Trigger)

&null;0204&null; This is an ideal method for deploying urgent virus signature updates while providing load balance. The wireless device/phone may support launching an application via a signal from its service provider. When an update signal from an external source is received by the device, it launches a pre-configured application, in this case the service agent, for immediate update.

&null;0205&null; Configuration

&null;0206&null; Like other the anti-malware scanner components on the device, the agent configuration information is kept in a central location. Table 25 lists the service agent communication configuration and status variables read/updated.

30

TABLE 25

Variable

Example

Description

server

http://update1.mcafeeasap.

Lists one or more update server URL's.

com/cgi-bin/update.fcg,

http://update2.mcafeeasap.

com/cgi-bin/update.fcg

method

&null;&null;1

Specifies server selection method.

0: direct-method - always attempt to connect

to the first server given, connect to next

server if the first one fails.

1: round-robin - attempt to connect to server

listed after previous connected server.

last_connect

167.68.79.100

IP address port number of the last update

server successfully connected.

last_check

20020110051530

Last time the agent made a successful server

connection.

Format: YYYYMMDDhhmmss

connect_timeout

5000

Server connection timeout in milliseconds.

read_timeout

3000

Socket read timeout value in milliseconds.

write_timeout

3000

Socket write timeout value in milliseconds.

connect_retry

&null;&null;5

Maximum connection open retry count.

read_retry

&null;&null;3

Maximum socket read retry count.

write_retry

&null;&null;3

Maximum socket read retry count.

download_dir

X$/vswsa/download

Where to store downloaded package.

&null;0207&null; Service Package

&null;0208&null; The term &null;package&null; refers to any data/information uploaded/downloaded to/from a remote update server. Each package is made up of a header and parts. Each part consists of part-header and part-data sections. Designed for simplicity, endian-ness independence, and extensibility, the anti-malware scanner package format is an HTTP-like transmission format that allows multiple inclusion of any types of data. The package format is composed by subsequent entries:

&null;0209&null; Table 26 illustrates an exemplary format.

31

TABLE 26

Format

<PART0>

.

.

.

<PARTn>

with each part is composed of:

<PART-HEADER>

<PART-DATA>

The end-of-file marks the end-of-package data.

Package and part header section has the following format:

<FIELDn> &null;:&null; <SP> <VALUEn> <CRLF>

.

.

.

<CRLF>

where:

<FIELDn> :: $NAMETOKEN

<SP> :: &null;&null;b&null; (space character)

<VALUEn> :: $VARTOKEN

<CRLF> :: &null;&null;r&null;n&null; (carriage return followed by

linefeed)

and:

$NAMETOKEN :: &null;a-z, A-Z, 0-9&null;

$VARTOKEN :: &null;{circumflex over (&null;)}&null;r&null;n&null;

Between the <FIELD> values, two are mandatory:

ContentName: ENRTY-NAME

ContentLength: LENGTH

&null;0210&null; where:

&null;0211&null; ENRTY-NAME is the object identification name, and

&null;0212&null; LENGTH is the length of the subsequent DATA section in bytes.