Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W8/00—Network data management
  • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
  • H04W8/24—Transfer of terminal data
  • H04W8/245—Transfer of terminal data from a network towards a terminal
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/55—Detecting local intrusion or implementing counter-measures
  • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/55—Detecting local intrusion or implementing counter-measures
  • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
  • G06F21/562—Static detection
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
  • G06F21/55—Detecting local intrusion or implementing counter-measures
  • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
  • G06F21/562—Static detection
  • G06F21/564—Static detection by virus signature recognition
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1441—Countermeasures against malicious traffic
  • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
  • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
  • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/12—Detection or prevention of fraud
  • H04W12/128—Anti-malware arrangements, e.g. protection against SMS fraud or mobile malware
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
  • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
  • H04L63/1416—Event detection, e.g. attack signature detection
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication

Definitions

• the present invention relates to wireless device security, and more particularly to scanning wireless devices for malware.
• malware such as viruses, Trojan horses, and worms (referred to collectively hereinafter as “viruses”) in much the same way as present day personal computers and workstations are susceptible to malware attack.
• viruses viruses, Trojan horses, and worms
• a number of mobile telephone viruses have already been identified.
• anti-virus software 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 vims signatures. These signatures are held in a database which must be constantly updated to reflect the most recently identified viruses.
• 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 viras detection techniques (e.g. which may be required when a new strain of vims is detected).
• Mobile wireless platforms present a series of problems for software developers (including developers of anti-vims 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).
• mobile wireless platforms are traditionally not standardized like conventional desktops. For example, instead of running MicrosoftTM WindowsTM, such mobile wireless platforms may have installed thereon a variety of types of operating systems. This complicates the act of designing an anti-vims scanner that is capable of operating on any one of a plurality of mobile wireless platforms.
• a system, method and computer program product are provided for scanning a mobile wireless device for malware. Initially, an application service provider is initiated utilizing a mobile wireless device. Next, an anti-malware scanner installed on the mobile wireless device is updated over a wireless network utilizing the application service provider. The mobile wireless device is then scanned utilizing the updated anti-malware scanner.
• the update may be effected by wirelessly communicating with a back-end server. Further, such communication with the back-end server may be effected only upon user authorization so as to regulate usage of the wireless network with the mobile wireless device.
• the application service provider may include a platform- independent component manager capable of running a plurality of functional modules on any one of a plurality of mobile wireless device platforms.
• Such platform-independent component manager may include a platform abstraction layer.
• the mobile wireless device may be updated on a schedule that is coordinated with a plurality of other mobile wireless devices for maintaining the performance of the wireless network.
• the update may include a package. Such package may possibly be wrapped.
• the mobile wireless device may be updated based on a manual trigger, a self trigger, a scanner trigger, a scheduled trigger, and/or an external trigger.
• Figure 1 illustrates an exemplary architecture for scanning a mobile wireless device for malware, in accordance with one embodiment.
• Figure 2 illustrates an overview of the component architecture associated with the anti-malware seamier running on the mobile wireless devices.
• Figure 3 illustrates a method for scanning a mobile wireless device for malware utilizing a user interface, in accordance with one embodiment.
• Figure 4 illustrates a sample user interface screen that shows the features exposed by the anti-malware scanner.
• Figure 5 illustrates a block diagram showing the interaction between a component manager and other subsystems such as the user interface.
• Figure 6 illustrates a method for scanning a mobile wireless device for malware utilizing a component manager, in accordance with one embodiment.
• Figure 7 illustrates a system including an on-access scanner, in accordance with one embodiment.
• Figure 8 illustrates a framework with an on-access scanner interfacing with a file system, and filtering all file I/O related events.
• Figure 9 illustrates the manner in which the on-access scanner is enabled and disabled during use based on on-demand scanning.
• Figure 10 illustrates a Java scanning module interfacing with Java, and filtering all Java applet and Java script executions.
• Figure 11 illustrates an on-demand scanner system including an on-demand scanner interacting with a component manager and a scan engine.
• Figure 12 illustrates a method for performing on-demand scanning, in accordance with one embodiment.
• Figure 13 illustrates a scan engine system including a scan engine module, a file parser, and an interpreter.
• FIG 14 illustrates a service agent (SA) architecture, in accordance with one embodiment.
• Figure 15 illustrates a method for scanning a mobile wireless device for malware, involving service agents.
• Figure 16 illustrates a sample service agent activation method, in accordance with one embodiment.
• Figure 17 provides a method for client and server package handling.
• Figure 18 illustrates the various steps of a package installation process, in accordance with one embodiment.
• Figure 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.
• Figure 20 illustrates a transaction server command process flow, in accordance with one embodiment.
• Figure 21 illustrates a plurality of personal device database table relationships, in accordance with one embodiment.
• Figure 22 shows an exemplary client information flow, in accordance with one embodiment.
• FIG. 1 illustrates an exemplary architecture 100 for scanning a mobile wireless device for malware, in accordance with one embodiment.
• 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 mn MicrosoftTM WindowsTM operating systems.
• 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.
• 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).
• the application service provider is initiated utilizing the mobile wireless device 102.
• 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.
• 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.
• HTTP hypertext transfer protocol
• a database 114 coupled between the transaction servers 112 and a configuration/reporting server 116.
• 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 maybe accomplished via Web interfaces 118. More information regarding such back-end architecture 104 will be set forth hereinafter in greater detail.
• 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.
• the anti-malware scanner may evolve over time as new computer vimses and other malicious code are discovered.
• 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 IB.
• Identify malicious code in persistent data stored on the device This includes native executables as well as scripting languages embedded in documents .
• 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.
• FIG. 2 illustrates an overview of the component architecture 200 associated with the anti-malware scanner mnning on the mobile wireless devices.
• 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.
• the on-access scanner module 206, on-demand scanner module 208, and the Java- scanner module 210 utilize a common scan engine 216.
• 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.
• 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.
• Figure 3 illustrates a method 300 for scanning a mobile wireless device for malware utilizing a user interface, in accordance with one embodiment.
• decision 302 it is determined whether an update command is received from a user utilizing a graphical user interface of a mobile wireless device.
• the update command may be received upon the selection of an update icon displayed on the graphical user interface of the mobile wireless device.
• an anti- malware scanner installed on the mobile wireless device is then updated over a wireless network in response to the update command.
• 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 Figure 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.
• 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.
• 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.
• Manually viras 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 vimses were found.
• Figure 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.
• 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.
• 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.
• the component manager inside the anti-malware scanner is the logic layer that instantiates the following subsystems of Table ID.
• 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.
• the user interface relies on the component manager to initiate actions such as manually scanning for computer viruses and to check for product updates.
• Figure 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. How the Component Manager works
• Figure 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.
• 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.
• 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.
• 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.
• the on-access scanning subsystem is initiated so real-time monitoring for vimses begins.
• a component manager callback function is called by the on-access scanning subsystem.
• 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.
• manual scanning 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.
• 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 IE.
• all events that are generated may be communicated back to the owner of the component manager handle using a callback function.
• 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.
• CMgrCreate() 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.
• PFNCMGRNOTIFY pfhNotify // [in] Function to notify.
• PVOID pUserParam // [in[ Any user defined value.
• 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.
• the CMgrDestroyO 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.
• the CMgrActivateO 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.
• 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 DNDEMAND starts a manual scan of the device.
• COMPID_SERVAGENT start to check for a product update.
• CMgrCreate ( ) CMgrDestroy O , CMgrActivate O , CMgrNotif y ( )
• CMgrNotifyO Description The CMgrNotifyO 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.
• COMPID CompID // Component that generates this event .
• VSCNEVENT hEvent // Why the notification function was called.
• COMPMGRVALID Valid // Fields that are valid to check.
• HVSCNITEM hltem // Item that scanner is notifying about.
• 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 3ERVAGENT 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:
• 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.
• 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
• 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
• 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 'C coding guideline way. The named bit fields are as follows: bit_hltem, indicates that the hltem structure member is valid.
• bit DoneAction indicates that the DoneAction structure member is valid.
• hltem This is a handle to a anti-malware scanner scan item. Information that is associated with this handle can be accessed using the Scnltem 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 None was done about the infected item.
• SCNDONE_DENIED ACCESS 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.
• 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.
• CMgrCreate ( ) CMgrDestroy O
• Figure 7 illustrates a system 700 including an on-access scanner 702, in accordance with one embodiment, hi 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.
• 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.
• 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.
• On-access file scanning is accomplished by hooking into a file access notification mechanism that resides inside the operating system.
• a file access notification mechanism that resides inside the operating system.
• the file system related events that are filtered are as follows.
• File Create Event When a file create event is received it may be because the user has decided to download, beam or install some sort of application.
• 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 "file create" event is the same as a file open event, these two are combined into one.
• the anti-malware scanner 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.
• 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.
• 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.
• the on-access scanning subsystem determines 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.
• 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.
• 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.
• 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.
• the FsInstallHookO 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 PFNFSHOOK pAppCallback, void * pUser, PFNFSHOOK * ppPrevHook
• a return value of zero should be returned for success or any other number to indicate an error condition. See Also
• the FsUninstallHookO function removes a previously installed file system hook.
• a return value of zero should be returned for success or any other number to indicate an error condition.
• the FsHookFuncO 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 FsHookFuncO 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 FsHookFuncO the application can perform I/O operations on any other file that it chooses.
• 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.
• information that a hooking function could obtain from here are:
• 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.
• 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.
• 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.
• Figure 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.
• the OnAccCreateO 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
• a user defined value that may be passed to the call-back function is a user defined value that may be passed to the call-back function.
• OnAccDestroyO 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.
• the OnAccEnableO 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.
• On-demand scanning is completed, on-access scanning is re-enabled.
• HONACCESS hOnAccess // [in] handle to on-access scanner.
• BOOL bEnable // [in] TRUE/FALSE to enable/disable. );
• 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.
• Boolean value of FALSE disables the on-access scanning subsystem.
• Table 5 illustrates additional optional components of the on-access scanner API.
• OnAccNotifyO function is only a placeholder and it should be defined by the calling application in case the application would like to be notified of events that are occurring within the on-access scanning subsystem. A pointer to this function should be passed to OnAccCreate().
• Prototype typedef BOOL (* PFONACCNOTIFY)(PONACCNOTIFYINFO pNotify);
• PVOID pUserParam // User defined value used in OnAccCreate 0
• VSCNEVENT hEvent // Reason why the notification was called.
• HVSCNITEM hltem // Item that scanner is notifying about.
• the possible event identifiers for this field are as follows:
• 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.
• the file that is about to be scanned has already been pre-filtered based on the IT A(lministrator 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.
• This event indicates to the caller that the core technology component identified in the CompID structure member just finished initializing. This is only a notification message so any return code that is returned to the component manager from this event notification may be ignored.
• 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, hltem: This is a handle to a scan item. Information that is associated with this handle can be accessed using the Scnltem 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_CLEANED Infected item was cleaned.
• SCNDONE_CLEANF AILED Infected item could not be cleaned.
• SCNDONEJDELETED Infected item was deleted.
• SCNDONE DELETEFAILED Infected item could not be deleted.
• 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.
• OnAccCreate () OnAccDestroy() , OnAccEnable () ScnltemCreateO
• the ScnltemCreateO function is used to create an object that contains all information that there is to know about a scan object that is scanned by the on-access scanning subsystem.
• a 'Scan Item' object could contain the name of the file, the virus it was infected with, what type of scan actions the anti-malware scanner attempted to perform on it and the outcome of this operation.
• ScnltemDestroy () , Scnlte Copy 0 , ScnltemGetltemName () , ScnltemGetVirusName 0 , ScnltemGetActions () , ScnltemSetActionO , ScnltemSetUserPara O , ScnltemGetUserParamO ScnltemDestroyO
• ScnltemDestroyO function is used to free up all resources associated with a scan item object that was created using ScnltemCreateO.
• Parameters hltem [in] handle to a scan item object that should be destroyed.
• ScnltemCreate ScnltemCopy ( ) , ScnltemGetltemName ( ) , ScnltemGetVirusName ( ) , ScnltemGetActions 0 , ScnltemSetAction O , ScnltemSetUserParam O , ScnltemGetUserParam O
• the ScnltemCopyO function is used to create a copy of a scan item object.
• the copied object may be a carbon copy of the source.
• ScnltemCreateO function Before calling this function make sure to call ScnltemCreateO function on the hltemTgt scan item object.
• ScnltemCreateO ScnltemDestroyO
• ScnltemGetltemName () ScnltemGetVirusName ()
• ScnltemGetActions () , ScnltemSetActionO, ScnltemSetUserParamO, ScnltemGetUserParam ( )
• ScnltemGetNameO Description The ScnltemGetNameO function is used to retrieve the name of the item that this object is referencing to.
• HVSCNITEM hltem // [in] handle of the scan item.
• text_t * pBuffer // [out] file name is placed here, size _t uSize // [in] buffer size in CHARACTERS ! );
• ScnltemCreateO ScnltemDestroyO
• ScnltemSetltemName ()
• ScnltemGetVirusName ()
• ScnltemGetActions ()
• ScnltemSetActionO ScnltemSetUserParamO
• the ScnltemSetNameO function is used to set the name of the item that this object is referencing to.
• HVSCNITEM hltem // [in] handle of the scan item.
• ScnltemGetVirusName ( ) , ScnltemGetActions 0 , ScnltemSetAction O , ScnltemSetUserParam O , Scn temGetUserParam ( ) ScnItemGetVirusName()
• the ScnItemGetVirusName() function is used to get the name of the virus that this object is referencing to.
• ScnltemSetVirusName ( ) , ScnltemGetActions ( ) , ScnltemSetActio O , ScnltemSetUserParam O , ScnltemGetUserParam ( ) ScnltemSetVirusNameO
• ScnltemSetVirusNameO function is used to set the name of the virus that this object is referencing to.
• ScnltemCreate O ScnltemDestroy O , ScnltemGetltemName () , ScnltemGetVirusName ( ) , ScnltemGetActions 0 , ScnltemSetAction O , ScnltemSetUserParam O ,
• the ScnltemSetActionO function is used to indicate what was done on this scan item by a subsystem such as the scan engine. As an example if cleaning this scan item was attempted, the outcome of this operation should be indicated so other subsystems, such as activity logging can retrieve this information. A queue of the 3 last scan actions is maintained within the object.
• HVSCNITEM hltem // [in] item that was scanned.
• SCNDONE_NOACTION None was done about the infected item.
• SCNDONE _DENIED ACCESS Infected item was denied access to.
• SCNDONE _CLEANED Infected item was cleaned.
• SCNDONE XEANFAILED Infected item could not be cleaned.
• SCNDONE _DELETED Infected item was deleted.
• SCNDONE _DELETEFAILED Infected item could not be deleted.
• the ScnItemGetActions() function is used to retrieve what actions were done on this scan item by subsystems such as the scan engine. A list of the 3 last scan actions is maintained within the scan item object. When the last item is of type OAS_NOACTION, that means no more actions are associated with this scan item.
• HVSCNITEM hltem // [in] item that was scanned.
• SCNDONE _DENIED ACCESS Infected item was denied access to.
• SCNDONE _CLEANED Infected item was cleaned.
• ScnltemCreateO ScnltemDestroyO
• ScnltemGetltemName 0 ScnltemGetVirusName ()
• ScnltemSetVirusName ScnltemGetActions
• ScnltemSetActionO ScnltemSetUserParamO
• ScnltemGetUserParamO ScnltemGetUserParamO
• the ScnltemSetUserParamO function is used to associate any pointer size argument with a scan item object.
• the meaning of this value is up to the application to define.
• ScnltemCreateO ScnltemDestroyO
• the ScnltemGetUserParamO function is used to retrieve any application associated value with this object.
• HVSCNITEM hltem // [in] scan item to associate with.
• PVOID * ppUserParam // [out] pointer to associated item.
• ScnltemCreateO ScnltemDestroyO
• Figure 9 illustrates the manner 900 in which the on-access scanner is enabled and disabled during use based on on-demand scanning.
• on-access scanning is disabled in operation 904.
• on-demand scanning may be performed in operation 906.
• the on-access scanning may be enabled in operation 908.
• the on-access scanning is disabled when on- demand scanning to preserve resources on the mobile wireless device.
• the OnAccEnableO 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.
• Java Applet and Script Scanning 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.
• Figure 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 maybe notified and, based on established scan settings, some action may be done on it.
• the JavalnstallHookO 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.
• a return value of zero should be returned for success or any other number to indicate an error condition. See Also
• JavaUninstallHook ( )
• JavaHookFunc ( )
• JavaUninstallHook() removes a previously installed Java interpreter hook.
• a return value of zero should be returned for success or any other number to indicate an error condition.
• JavalnstallHook() JavaHookFunc () JavaHookFuncO
• the JavaHookFuncO 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 JavaHookFuncO 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.
• plnterpreterlnfo This is a Java interpreter dependent stmcture that contains all the necessary information needed by the Java interpreter to perform I/O related function.
• information that a hooking function could obtain from here are:
• Java interpreter specific function identifier that is being performed such as EXECUTE
• 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.
• 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
• JavalnstallHoo O JavaUninstallHook ( )
• Figure 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.
• 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.
• the on-demand scanner 1101 recursively enumerates all data objects on the device from a given starting location.
• the caller To use the on-demand scanner 1101, the caller must initialise an SE_SCANNER from the scan engine 1104 and the proper callback functions.
• Figure 12 illustrates a method 1200 for performing on-demand scanning, in accordance with One embodiment.
• 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.
• 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.
• a directory callback is executed in operation 1216.
• a recursive scan is executed in operation 1218. The foregoing method 1200 is continued until all of the entries are identified (see operation 1220).
• the SCAN_ACTION enumeration is used by callback functions to tell the on-demand scanner what to do when the callback function returns.
• Skip the next item to be scanned This may be used to skip files or directories depending on the callback function that returns this value.
• the returned handle is used for setting callback functions and launching the recursive scan. It must be destroyed when no longer needed with ODDestroyScanner. See Also
• ODDesrroyScannerO ODSetFileCallback(), ODSetDirCallback(), ODSetCleanFileCallback().
• the pScanFileCallback () is called by the ODScanRecursiveDirO function just before each file is scanned.
• the data pointer sent to ODSetScanFileCallback () is passed to the pScanFileCallback(). This enables the application to supply context information.
• This function is implemented by the ODScanRecursiveDirO caller. It is used by ODScanRecursiveDirO to notify the caller when a file is about to be scanned, and provides an opportunity to direct the scanner's behaviour.
• Prototype typedef SCAN_ACTION (*PSCANFILECALLBACK)( void *pData, FILEPATH *pFName ); Parameters pData
• ScanFileCallbackO must return one of the following:
• CONTINUE_RECURSIVE_SCAN This is the normal return value so that the file may be scanned.
• ABORT_RECURSIVE_SCAN This is used to stop scanning entirely.
• the given file is not scanned.
• the given file is not scanned.
• the recursive scan continues with the next file.
• the callback fimction merely copies information for the timer to consume.
• the timer event displays progress and interacts with the user using a separate stack.
• ODScanRecursiveDirO to notify the caller when a directory is about to be scanned, and provides an opportunity to direct the scanner's behavior.
• Prototype typedef SCAN_ACTION (*PSCANDIRCALLBACK)( void *pData, DIRPATH *pFName
• the return values are the same as pScanFileCallback().
• the pCleanFileCallback () is called when malware is discovered by the ODScanRecursiveDir () function. All the information necessary to call SECleanFile () is supplied.
• SECleanFile It is up the to the callback function to call SECleanFile () if needed. As scanner state information is needed by the SECleanFile () function, it must be called before continuing the recursive scan, or not at all. Storing the scan_result_t id, and calling SECleanFile () after returning from the callback may have unexpected results.
• the CleanFileCallback () called when an infected file is discovered.
• the callback function is responsible for deciding what must be done with the malware, and executes the response.
• the response may be a call to SECleanFile().
• Prototype typedef SCAN ACTION (*PCLEANFILECALLBACK)( Void *pData, HODS hScan, FILEPATH *pFileName, scan_result_t id
• the CleanFileCallbackO may return CONTINUE_RECURSIVE_SCAN or ABORT RECURSIVE SCAN. See Also
• ODScanRecursiveDir O pScanDirCallback ( ) , pScanFileCallback ( ) , ODSetScanFileCallback ( ) .
• ODScanFileCallback ODScanDirCallback
• ODCleanFileCallback ODScanFileCallback
• the ODScanFileCallback () is called just before the given file is scanned. This provides the calling application an opportunity to track scan progress, to skip files, and abort scanning.
• the ODScanDirCallback () is called just before the given directory is scanned. Just like the ODScanFileCallbackO, the application can track progress, skip the directory, or abort scanning.
• the ODCleanFileCallback () is only used when malware is detected. The application then needs to choose the proper action. This may include calling the SECleanFile () function. Any callback not set, or set to NULL, is ignored.
• ODScanRecursiveDirO is done.
• the SCAN_ACTION returned denotes how the function ended: CONTINUE_RECURSIVE_SCAN or ABORT_RECURSIVE_SCAN.
• a return value of CONTI JE_ RECURSIVE_SCAN indicates that it successfully completed the scan.
• ABORT_RECURSIVE_SCAN indicates that the scan was aborted.
• the on-demand scanner supports adding plug-ins for new abstract directory and file types. This enables adding support for compressed archives and other special file formats.
• the caller supplies a callback function for creating HDIR instances.
• the callback function takes an HFILE and detects whether the HFILE can be interpreted as an ADIR.
• the callback function must return an HDIR or NULL.
• This callback function is responsible for deterrmning whether the given pAFile can be represented as an ADIR.
• compressed archives may be treated as an ADIR so that the contents can be enumerated and scanned.
• the callback must return NULL if it is not able to use the provided hFile. Otherwise, it returns a valid HDIR implementation for the pAFile.
• the callback can rely in the hFile to continue to be open for the life of the returned HDIR. See Also
• the caller supplies a callback function for creating AFILE instances.
• the callback function takes an hFile and detects whether it is supported. If supported, the callback function returns a new HFILE. Otherwise, NULL.
• This callback function is used to determine if this filter supports the given hFile. If the hFile is supported, this function creates an HFILE interface to wrap the hFile.
• the hFile must remain available for the returned HDIR to use in accessing the file.
• the caller is responsible for releasing both the HDIR and hFile. Note that the caller must not release the hFile until after releasing the returned HDIR. Returns NULL if no HDIR filter is available.
• the supplied hFile must remain available for the returned HFILE to access.
• the caller is responsible for releasing both the returned HFILE and supplied hFile. Note that the caller must not release the hFile until after releasing the returned HFILE.
• Figure 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 vims detection and clean files. See operation 1310.
• 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. Scan Engine API
• 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.
• 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.
• Table 8 illustrates an exemplary scan engine API.
• 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
• the supplied HDIR must enumerate only the PD files that are to be used by the scanner.
• the function return is an initialized SCANNER data stmcture.
• the contents of the SCANNER data structure are internal to the scan engine implementation.
• Scan the given file for malware.
• the return value may usually be -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.
• 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 -1. See Also
• the string is the base name of the malware detected. If no name is available, NULL is returned.
• This file is to provide the necessary information to detect and clean malware on handheld devices.
• 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.
• 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.
• One goal is to keep file transfers to the PD devices small.
• Table 10 illustrates an exemplary file header.
• 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.
• Table 12 The definition of Table 12 is used for the target platforms of Table 13.
• Table 13 The definition of Table 12 is used for the target platforms of Table 13.
• 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.
• 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.
• the PD file uses record ID's. This makes it possible to move a record without having to change every reference to the record.
• 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.
• Record lengths are only 2-byte values. This is intentional to make porting between 16-bit processors simple.
• a mobile wireless device such as a Palm® PilotTM uses a database instead of a file system.
• Each record can be at most 64KB. Nearly all scan functions may be very small. As they get larger, new instmctions should be added to the language to move the functionality into the scan engine.
• This record contains a function for doing an initial scan of the selected file.
• the amount of code needed for this scan may exceed 64KB (the maximum record size).
• 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.
• 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. Check records
• Check records contain functions for identifying the specific malware variant once identified by the scan records.
• the check record starts with the following header information in Table 16.
• a clean record contains a function for removing the malware and repairing files if possible.
• Replacing a record is the same as deleting the original, and then adding a new record in its place.
• Free records may be set to zero to make predicting the checksum easier.
• 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.
• Service agent upgrades 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.
• 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.
• the activity log requires the following configuration values in Table 18.
• 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.
• the log file location and naming conventions are configured per platform when the program is compiled.
• the log file may be truncated.
• Table 20 illustrates an exemplary interface associated with the activity logging module.
• 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.
• log entries on starting the application without it being stopped may denote that it crashed and was restarted.
• LogMessage() fimction Unlike the LOGJTRACE messages, the service events are always available in the log file.
• 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 fanctions.
• 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 fanctions 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.
• a handle to the log entry is supplied, or NULL on error.
• the LogEntryField() function returns 1 on success, or 0 if it failed to add the entry.
• 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.
• the file format may be based on XML.
• 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.
• 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 YYYYMMDDhlimmss, 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.
• message_type is one of trace, warning, error, or fatal.
• message_body is the text string provided for the message.
• a sample LogMalwareDetect object is shown in Table 23.
• ⁇ detect date "YYYYMMDDhhmmss"> ⁇ path>file-path ⁇ /path> ⁇ narae>malware- ⁇ ame ⁇ /name> ⁇ variant>2nalware-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
• a LogServiceEvent is shown in Table 24.
• service-name is the name of the service: "on-demand”, “on-access”, “application”, “agent”, “installer”. service-action the word “start” or "stop”.
• FIG 14 illustrates a service agent (SA) architecture 1400, in accordance with one embodiment.
• a service agent 1402 interfaces with an user interface 1403, an on-access scanner module 1404, and an on-demand scanner module 1406.
• 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.
• Figure 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.
• the service agent maybe 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.
• 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.
• the information describing the mobile wireless may include log data. Such log data may be specific to the mobile wireless device.
• an update is then received from the back-end server over the wireless network utilizing the service agent of the mobile wireless device.
• the update may be wrapped.
• the update may include a header and a plurality of parts. Such parts may include a part-header section and a part-data section.
• 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.
• Figure 16 illustrates a sample service agent activation method 1600, in accordance with one embodiment.
• 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.
• the agent can be directly launched from the wireless user-interface by the user.
• the user-interface activates the agent.
• 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.
• 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.
• the wireless device/phone may support launching an application via a signal from its service provider.
• 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.
• the agent configuration information is kept in a central location.
• Table 25 lists the service agent communication configuration and status variables read/updated.
• the term "package” 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:
• Table 26 illustrates an exemplary format.
• the end-of-file marks the end-of-package data.
• Package and part header section has the following format:
• ContentName ENRTY-NAME
• ContentLength LENGTH
• ENRTY-NAME is the object identification name
• LENGTH is the length of the subsequent DATA section in bytes.
• the part-data section is made up of a binary chuck of data whose length is LENGTH.
• the part-header section can contain other useful information, for example, content type, compression method, signatures, checksums, etc. Also, it's possible to contain information that does not carry any data by setting the ContentLength: to zero and by making the ⁇ FIELD> carry data.
• the device identification number is uploaded to a server by setting the ContentName to $DEV- UTD, including a field names X-DEVUID, and setting the ContentLength to zero. See Table 27 for a package containing device ID number.
• the content name part can easily contain pathname information that make the format suitable for multi-level packaging transfers.
• Table 28 shows an example package uploaded to a server. It contains three separate information: 1) device identification number, 2) device log information, and 3) product and component version information (catalogue).
• Three types of part contents are uploaded to a server for back-end processing are: 1) device identification number, 2) device system/log information in XML format, and 3) component version information.
• the device identification number is used by the back-end to validate a device connection.
• Uploaded system and log information is processed and stored in a back-end database for reporting.
• Product/component version information, catalogue is used by the back-end server in selecting an installation package to download.
• the upload package is created from data provided by individual components that are registered with the service agent to upload/report its information to the back-end server.
• the service agent simply requests the registered components for upload data.
• Table 29 illustrates sample upload parts.
• the server uses the device identification number specified by the X-Device-UTD field to verify and retrieve client-specific information. This verification is done as soon as any part of the HTTP POST data containing the device identification is received.
• Event Log Also given in the client upload package is a wireless component/application log entries. Like the catalogue information, the log entries are formatted in XML form. There are two types of log entries: detection log and application event log. The detection log entry contains detected malware name, its type, infected filename, and the action taken by the scanner. Application (or component) event log entry lists severity of the event and a short message describing the event. Both the detection and the event log entries have a timestamp specified in UTC. Table 30 illustrates a pair of XML formats.
• the log entry time stamp given in UTC has the following format in Table 31.
• MM month (01-12)
• DD day of the month (01-31)
• hh hour of the day in 24 hour format (00-23)
• mm minute (00-59)
• ss second (00-59)
• Table 32 illustrates a sample log.
• the device catalogue (version information) uploads lists on the anti-malware scanner components. This catalogue information along with the device identification number is used in constructing a download package for the specific-device/client. Each catalogue entry given in the client upload package follows the format in Table 33.
• the service agent does not directly generate or format the data in the upload package - the service agent uploads data obtained from its clients.
• the service agent uses a set of callback functions supplied by its caller (or client) to request upload information.
• the service agent API SaSetParameter (and SaSetParameters) is used to by service agent client(s) to specify how to obtain upload data from each component.
• each client is notified by the S A to construct a package part to upload.
• the service agent After uploading a package, the service agent awaits for the server to download an installation package.
• the package header specifies the total package size, and the SA uses it to determine if the package contains installation part(s). The package size specified is greater zero, the SA downloads and saves the entire package data onto a download directory and calls the component installer.
• Each install part in an install package is identified by the content name that specifies the data format. The installer uses the format identifier in selecting an appropriate unpacker/decompressor for extracting and installing files contained in the part. Table 34 illustrates a sample installation package.
• Figure 17 provides a method 1700 for client and server package handling.
• a package is prepared by a mobile wireless device to be uploaded. See operation 1702.
• This client package is then posted for access by the server in operation 1704.
• the client package is received in operation 1706, after which the client is verified in operation 1708. If an error is detected in decision 1712, an error message is posted in operation 1710. If not, however, the database is updated based on the client package in operation 1714.
• a server package is generated in operation 1716, after which the server package is posted for access by the client in operation 1718.
• the client process 1701 then proceeds by receiving the server package in operation 1720. If an error is identified in decision 1722, the process is terminated. If, however, no error is detected, the contents that are listed in operation 1724 are installed in operation 1726. Further, the catalogue is updated in operation 1728.
• the client-server communication is thus initiated by the service agent by posting an upload package to a remote server.
• HTTP(S) POST is made to the server
• the client connection is verified and the entire client package is received.
• the server updates database with the uploaded information, and then returns a package generated based on the information uploaded.
• the client installs components in the server package and updates its installed component catalogue.
• the device update process may take place by preparing the package format (MPF) that may be basically composed by an LTD entry, an XML file containing device catalogue information like dat/engine/applications versions and log entries and eventually quarantine files.
• MPF package format
• the service agent may lookup its configuration searching for the URL to which to post the request.
• the URL may have the form shown in Table 35 Table 35
• the package may be sent to the remote back-end agent (RBA) with a standard HTTP POST request like given that in Table 36.
• RBA remote back-end agent
• the RBA may be invoked and it may unpack the package looking for the catalogue information coming from the device (i.e. details of what happens inside the RBA are described in another document ). Based on the device current catalogue, the RBA may prepare a custom package whose format may be device dependent to better utilize intrinsic device capabilities and hence reduce the code footprint of the SA application. The RBA may send the prepared package as data inside the HTTP POST response given in Table 37. Then, the connection to the RBA may be closed and the SA may be free to process the package.
• the service agent uses system-provided secure channel (e.g. SSL) for server communication and authentication APIs for downloaded package verification. Data uploaded from a device to a server is done through secure channel to protect private information.
• the download package containing viras detection files and component upgrades need to be cryptographically signed and authenticated. Without proper authentication, the device may be vulnerable to a third party attack.
• Table 38 illustrates an exemplary service agent API.
• the SaOpen() call creates a service agent(SA) instance and returns its handle.
• the returned handle must be released using the SaClose() call.
• NULL indicates failure
• SaClose releases system resources used by a service agent handle. If the SA is mnning as a separate process, SARUNJFORK model, the process is terminated.

Applications Claiming Priority (6)

Publications (1)

Family

ID=27358127

Family Applications (1)

Country Status (2)

Cited By (9)

Families Citing this family (401)

Citations (4)

Family Cites Families (61)

• 2002
  • 2002-04-12 US US10/122,087 patent/US7861303B2/en not_active Expired - Lifetime
  • 2002-04-12 US US10/121,639 patent/US7096368B2/en not_active Expired - Fee Related
  • 2002-04-12 US US10/122,095 patent/US7827611B2/en active Active
  • 2002-04-12 US US10/122,092 patent/US20040010703A1/en not_active Abandoned
  • 2002-04-12 US US10/122,100 patent/US7540031B2/en not_active Expired - Lifetime
  • 2002-04-12 US US10/121,374 patent/US7171690B2/en active Active
  • 2002-04-30 WO PCT/US2002/013570 patent/WO2003012644A1/en not_active Application Discontinuation

Patent Citations (4)

Also Published As