GB2515326A

GB2515326A - Detecting malware via outgoing radio messages

Info

Publication number: GB2515326A
Application number: GB1310988.9A
Authority: GB
Inventors: Marko Thure; Mikko Suominen
Original assignee: F Secure Oyj
Current assignee: WithSecure Oyj
Priority date: 2013-06-20
Filing date: 2013-06-20
Publication date: 2014-12-24
Also published as: GB201310988D0

Abstract

The presence of malware on a radio device, such as a mobile phone, is detected by identifying that an outgoing message or call has been or is about to be sent from the device; determining the state of the device; analyzing that state to see if the outgoing message/call was prepared by a user of the device; and providing an alert to the user if it is determined that the suspicious activity was not prepared by the user. The outgoing messages may include SMS/MMS and/or TCP/UDP messages. Some examples of the detected state that is analyzed include whether: a keyguard and/or screensaver is on; or a default messaging application and/or any full screen application is running. The system may prevent the message from being transmitted if it has not yet been sent, or may terminate the process that caused the transmission if it has been sent. This allows for dynamic detection of malware without relying on malware signatures that may be out-of-date.

Description

DETECTING MALWARE VIA OUTGOING RADIO MESSAGES

TEculqlcAL FiiiLD: [0001] The exemplary and non-limiting embodiments of this invention relate generally to security systems, methods, devices and computer programs. and more specifIcally relate to detecting malware by examining outgoing radio messages that are sent from or about to be sent from a mobile electronic device such as a smart phone for example.

BACKGROUND:

[0002] As larger numbers of people utilize their mobile phones to perform more and varied functions, trojans and other types of malware are becoming a more pressing concern. For example there has been an increase in the amount of malware directed toward the Android mobile operating system. One typical payload for mobile device malware is sending short message service (SMS) messages to premium rate numbers, because this offers the malware author a straight-forward way of extracting money from the malware victim particularly where the mobile device has the user's financial information such as credit card numbers andior bank account information. The victim in turn will suffer financial losses if the malware is not caught. Anti-virus signatures have traditionally been used to detect malware. But SMS messages can also be used to send stolen data from the infected mobile device back to the attacker. These malware generated SMS messages can be sent in the background and without user interaction, either when the trojan is installed, or when it is started for the first time, or for more advanced variants at some later undetermined time. Anti-virus signatures are generally added only after a new trojan or variant has been discovered, which in the case of a malware-generated SMS is too late for the individual victims who suffer direct monetary losses. For this reason it is important to be more proactive in this type of malware detection.

[0003] Embodiments of these teachings address the problems above and some implementations can even proactively block such malware-generated SMSs before the victim's data is compromised.

SUMMARY:

[0004] In a first embodiment of some of the teachings set forth herein there is a method for detecting malware on a radio device. In this example the method comprises: detecting that an outgoing data message has been sent or is about to be sent from a radio device and/or that an outgoing call has been initiated or is in progress at the radio device; detecting a state of the radio device; analyzing the detected state to determine whether the outgoing data message and/or the outgoing call was prepared or initiated by a user of the radio device; and if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device, then causing a user interface of the radio device to provide an alert to a user of the radio device.

[0005] In a second embodiment of some of the teachings set forth herein there is an apparatus comprising a processing system, and the processing system comprises at least one processor and a memory storing a set of computer instructions for detecting malware on a radio device. The apparatus in this case may be the who]e radio device or only one or more components therefore such as the processing system. In this embodiment the processing system is configured to cause the apparatus to at least: detect that an outgoing data message has been sent or is about to be sent from a radio device and/or that an outgoing call has been initiated or is in progress at the radio device; detect a state of the radio device; analyze the detected state to determine whether the outgoing data message and/or the outgoing call was prepared or initiated by a user of the radio device; and cause a user interface of the radio device to provide an alert to a user of the radio device if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.

[0006] In a third embodiment of some of the teachings set forth herein there is a computer readable memory tangibly storing a set of computer executable instructions for detecting malware on a radio device. In this third embodiment the set of computer executable instructions comprise code for detecting that an outgoing data message has been sent or is about to be sent from a radio device; code for detecting a state of the radio device and/or that an outgoing call has been initiated or is in progress at the radio device; code for analyzing the detected state to determine whether the outgoing data message andlor the outgoing call was prepared or initiated by a user of the radio device; and code for causing a user interface of the radio device to provide an alert to a user of the radio device if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.

[0007] These and other aspects are detailed below with more particularity.

BRifiP DESCRIPTION OF TITh DRAWINGS:

[0008] Figure 1 is a logic flow diagram that illustrates a method, arid a result of execution by an apparatus of a set of computer program instructions embodied on a computer readable memory for detecting malware from outgoing radio data messages, in accordance with certain exemplary embodiments of these teachings.

[0009] Figure 2 is a simplified block diagram of an example mobile terminal, and a network access node which are example electronic devices suitable for use in practicing the exemplary embodiments of these teachings.

Dur AILED DEscRwnoN: [0010] The invention detailed by the non-linñting examples below may be implemented as a stand-alone application resident on the host mobile device, or it may in other embodiments be implemented as one of several functionally distinct components of a more generalized security product solution for the host mobile device.

Such a more generalized security solution may for example ako include anti-virus definitions and also functionality for scanning files/applications/data blocks and quarantining the same which are found to be suspect. among other security functionalities.

[0011] While the non-limiting examp'es below assume the host device is a mobile terminal/smart phone, this is merely an example of a type of host radio device in which these teachings offer promise of aiding a wide number of potential victims. But increasingly other types of electronic devices are being used for various types of data messaging that traditionally have been only done with mobile phones. For example, some tablet computers now have functionality for SMS/MMS messaging. The skilled artisan will appreciate that these teachings can be readily employed on any electronic or optica' device having wireless radio communication means including laptop and tablet type computers with wireless capability, auto or other vehicle based radio devices, and human wearable radio devices (such as for example Google® g]ass) among others. The communication means may be one or more radios (such as a transmitter and receiver, or a combined transceiver) configured to operate according to any wireless communication standard such as for example any of the various cellular technologies, wireless local area network (WLAN), mesh-type Zigbee or long range type Bluetooth protocols, device-to-device protocols, and the]ike. Such communication means are typically integrated into the host device but in some deployments they may be removable such as a USB dongle with radio functionality.

[0012] The first group of examples below assumes that an outgoing data message from the mobile terminal is an SMS but this is for clarity of explanation of the inventive concepts herein and not limiting to the broader teachings. The skilled artisan will recognize that the concepts revea]ed by the SMS example apply equally to multi-media messages (MMSs) and similarly to other types of messages canying data such as TCP and UDP data messages, and following the SMS examples below are also some further examples for these other types of data messages.

[0013] Data message is used herein consistent with its normal meaning. a message having content other than merely control information. Typically the data in a data message refers to user data but for the case of a malware-induced data message generated in the background the content that would normally be considered user data may have been placed in the outgoing message by the malware without the user's actual knowledge, rather than placed in the data message by the user him!herself.

[0014] In the example embodiment of the invention detailed below, SMS messages which are not sent by the user of the mobile terminal are identified as such based on the state of the phone/terminal and its user interface.

[0015] Regardless of whether an SMS-sending trojan is a stand-alone application or a component combined into otherwise clean software, the malicious code of the trojanized software causes the mobile terminal to send SMS messages without the user inputting the message content or selecting the message destination. Embodiments of these teachings exploit this characteristic to identify messages that are not originating from the user by examining the state of the phone/terminal at the moment the message is sent, or immediately prior to an impending send or very soon after the message is sent. Example embodiments of the invention detailed herein can be implemented with a software component installed on to a local memory of a mobile phone/terminal.

[0016] An example embodiment of such software performs the following functions.

Firstly it monitors outgoing SMS messages. Technically this is a relatively simple task to implement since mobile phone operating systems typically offer a method for performing this function. For example, in the Android® mobile operating system by Google, Inc. there is a class that inherits and implements the abstract class ContentObserver, which embodiments of these teachings can use to monitor outgoing SMS messages. Outgoing SMS messages can also be detected by monitoring the location where outgoing messages are placed by the operating system as they are sent (typically referred to as the outbox'). The content of the outbox can be checked at regular short interva]s for new entries to identify new messages that are being sent or that have been sent since the last periodic check of the outbox (or other location). The iOS® by Apple, Inc., Windows Phone® by Microsoft Corporation, and B]ackberry lO® by Research in Motion Corporation are some of the other common mobile operating systems and while they do not have the same abstract class arrangement as the Android OS they similarly allow for monitoring of outgoing messages.

[0017] Secondly, when an SMS is being sent (or about to be sent) the example software imp]ementing these teachings analyze the state of the phone and its user interface to

S

deduce if the SMS is being sent by the user or directly by an application. Some of the properties that most clearly indicate that the user is not sending an SMS him or herself include the phone's keyguard being on, the phone's screensaver being on, the phone's graphical display screen being off and the phone's default messaging application not running and/or not active immediately prior to when the SMS was sent. The graphical display screen encompasses not only smartphone cothr displays but also mono-color display screens that display only text and a few predefined icons. The screen being off does not necessarily mean that it or its display driver chip is fully depowered, in some mobile devices rather than the screen being fully depowered it may be that the screen displays fully blank to the user while remaining in a low power state to conserve battery power. Again using the Android® operating system as a non-limiting example for how these properties can be monitored, the keyguard state can be checked with Android's KeyguardManager, the screensaver and screen states can be checked with Android's PowerManager, and whether the defauli messaging application is or has recently been running/active can be checked with Android's ActivityManagei These three checks require features that are rather basic and so they should be available in most mobile phone operating systems. Software implementing these teachings can check or otherwise monitor any one or more of the above three states to use in determining whether or not the SMS message was generated by the user.

[0018] Other factors that imply the user is not sending the SMS message include that a full screen application is running, that no virtual keyboard is visible (for touch-screen phones), that the SMS is being sent by an application that does not have a user interface, and that the SMS is being sent by a service and not a normal' process such as an SMS/MMS application. Non-limiting examples for how these properties can be monitored when Android® is the phone's operating system include checking the WindowManager to determine whether a full screen application is running and checking the lnputManager to determine whether a virtual keyboard is visible. Some of these four checks may require functionality that is not available in all operating systems, in which case the implementing software can include strings of code to perform the needed monitoring/checking itself or it can simply check those phone states that are directly supported by the phone's operating system. However implemented for different operating systems, the implementing software can in some embodiments first look to one or more of the states listed in the preceding paragraph to decide if the SMS is being sent by the user or directly by an application, and can use one or more of the other factors listed by example in this paragraph to either confirm that original decision or to resolve any ambiguity if two or more of those earlier-checked states are not consistent. In this manner the implementing software can allocate different weight to different states and/or properties of the phone that it checks when making its decision whether or not the message was sent by the device's user [00191 Thirdly, when a message not sent by the user is detected, the monitoring software can prompt the user with both visual and aural alerts as deemed sufficient. The software can display what message will be sent and to which desdnation. Further actions can be performed according to what the operating system makes possible: the sending can be prevented automatically or if the user chooses so. If the sending cannot be blocked the software can provide the user with information which process or application sent the SMS message, further actions can include terminating the process that sent the SMS or even uninstalling the entire application. A quarantine feature that stores the message can also be implemented so the user can later approve its sending.

For convenience default actions can be defined in the software settings so the required user interaction will be minimal.

[0020] In one particular but non-limiting embodiment the implementing software may also have a whitelist in which the user can enter certain applications, destination numbers or messages with certain content (partial or full message). There are different ways in which the implementing software can deal with outgoing messages that are consistent with the whitelist. Normally the implementing software would detect a state of the mobile terminal, analyzing the detected state to determine whether the outgoing data message was prepared by a user of the mobile terminal, and if it is determined that the outgoing data message was not prepared by a user of the mobile terminal the software would cause the mobile tentnal's user interface to provide an alert to a user of the mobile terminal. Where the outgoing message is consistent with one (or more) entries in the whitelist, the software can a) check the message against the whitelist first and if it is consistent then not detect the mobile terminal state, and/or b) regardless of the detected state it can conclude that the message was prepared by the user, and/or c) suspend any conective action it might otherwise take, such as the user interface alert, regardless of the detected state andlor the determination about whether the message was from the user.

[0021] This whitelist option is useful to enable very specialized (non-malware) applications that for some reason need to send SMS messages independent of the user to still function. Certain software or applications that do send messages independent of the user, for example as part of the initial software registration process, should prompt the user and clearly state where a message will be sent and what the cost to the user will be. Many if not all of these initial registration messages will not be consistent with a whitelist entry since each is a new software registration and different programs/app]ications may be registered to different publishers. In these cases the software implementing these teachings will also allow the user to check via the mobile terminal's user interface that the message destination, content and number of sent messages match those declared by the application.

[0022] Outgoing MMS messages can be detected and the phone state analyzed similar to the examples above for SMS messages. For the case of other types of data traffic messages (such as for examp]e transmission control protocol TCP and/or user datagram protocol UDP) the concepts in general similar to the above SMS examples but there may be some differences in the specifics of implementation. Certain embodiments of these teachings provide an application stored on a loca] memory of the host radio device that checks both outgoing SMS/MMS type messages and also checks outgoing TCP/UDP type messages (or more generally non-SMS/PvIMS type messages) in parallel using slightly different phone states against which to analyze to determine whether or not the outgoing message was originated by a user.

[0023] As an example of some such differences, instead of monitoring for a new SMS/MMS message the implementing software may for other types of data messages monitor new outgoing network connections, either directly or in one indirect example by comparing an amount of network traffic that is accumulated over a short interval against a threshold amount of traffic to identify when new connections are created.

When a new outgoing network connection is detected the state of the phone and its user inteiface is analyzed to deduce if the connection is being or has been created from user actions or if the connection was created automatically by an application or other software resident on the mobile terminal. Properties or mobile terminal states that most clearly indicate that user actions are not the cause for creating the network connection are similar to three of the SMS examples above: whether the keyguard is on, which as mentioned above can be checked in the Android® operating system using the KeyguardManager; in Android applications), and/or whether the screensaver is on and/or whether the display screen is off. As noted above both of these latter phone states can be checked in the Android® operating system using the PowerManager.

These are non-limiting examples. And of course for the case in which the destination of an outgoing data message is to an Internet address (uniform resource location URL) rather than a mobile phone number as is the case with SMS/MMS messages, the destination URL can be checked against the whitelist for implementations with destination addresses in a whitelist.

[0024] When an outgoing connection is determined not to have been created by some user action on the mobile terminaL the monitoring software can prompt the user with both visual and aural alerts as detailed above for the SMS examples. But in this case the software may display the destination URL of the suspect connection (either a full URL or a partial one, such as listing only the top level domain), in addition to or in place of the other example visual alerts noted for the above SMS examples.

[0025] Further actions in response to determining that an outgoing message is suspect can be performed according to what the operating system makes possible: for example some may allow the connection to be prevented automatically while others may allow that only under a user preference setting. If the connection cannot be b]ocked the software implementing these teachings may, as part of the alert, provide the user with onscreen information about which process or application created the connection, and the implementing software may in some embodiments also automatically terminate the suspect process that created the connection or uninstall the entire application. For convenience to the user, there can be certain default actions for the above and other choices that are defined in the software settings which the user can oven-ide if he/she prefers, so that while the implementing software is setup and executing there would be minimal need for active interaction by the user of the mobile terminal.

[0026] There is another class of trojan maiware that can initiate a phone call from the host mobile phone without the user's input or awareness. Such a trojan-initiated phone call can be in place of or in addition to the Trojan-initiated data messages as were outlined in the above examples. Such a phone call also poses a threat to the user, for example by calling a premium number with per-minute charges. Detecting trojan-initiated phones calls can be done by the software installed on the user's mobile device that implements these teachings, in place of or in addition to also detecting data messages.

[0027] Detecting that an outgoing phone call has been sent or is about to be sent from a mobile phone or other radio device is similar to detecting that an outgoing data message has been sent, and the analysis of the relevant phone state or states that the implementing software detects for the outgoing call embodiment is, in the example below, similarly used to determine whether the outgoing phone cal] was initiated by the mobile phone user.

[0028] For example, the implementing software when operating in conjunction with an Android® operating system can detect if there is an outgoing call by checking for new intents of the type android.intent.action.NEW_OUTGOING_CALL. The software module that gets notified of a new one of this intent can cal] the application-programming interface (API) SetResultData and give it a null' parameter, which causes the operating system to abort the call.

[0029] Other mobile operating systems use different names for this outgoing call phone state, so more generically the implementing software can check the outgoing call state of the phone to detect that an outgoing phone call is being initiated or is in progress at the mobile phone. Once a new outgoing call is detected the state of the mobile phone and its user interface are examined to deduce if the ca]l was initiated by the phone's user, checking similar states as mentioned above that are relevant for phone calls such as whether the keyguard is on andlor whether the screensaver is on andlor whether the display screen is off.

[0030] Figure 1 presents a summary of the above teachings for detecting malware on a mobile terminal. This does not necessarily mean the source of the malware is detected in all implementations of these teachings; while some embodiments may identify the application or process that is the source of the malware others may only detect that malware is likely present by identifying via the alert at the user interface that an outgoing data message is suspect. Specifically, Figure i summarizes from the perspective of the software implementing these teachings that is stored on a local memory of the mobile terminal prior to an outgoing message being sent, but as noted above the implementing software may be installed on other types of radio devices also.

At block 102 there is detected an outgoing data message that has been sent or that is about to be sent from the mobile terminal and/or that an outgoing cal] has been initiated or is in progress at the radio device, and then a state of the mobile terminal is detected at block 104. The detected state is analyzed at block 106 to determine whether the outgoing data message and/or the outgoing call was prepared or initiated by a user of the mobile terminal, and if it is determined that the outgoing data message or ca]l was not prepared or initiated by a user of the mobile terminal then at block 108 a user interface of the mobile terminal is caused to provide an alert to a user of the mobile terminal.

[0031] In severa] of the examples above the outgoing data message was a SMS message and in some embodiments the implementing software can be limited to performing the process of Figure 1 on]y on SMS and MMS messages. Other embodiments do not limit the implementing software in this manner and so the process of Figure 1 is initiated for all outgoing data messages.

[0032] Block 106A summarizes some of the optional/non-limiting details from the above examples as to the detected state that is analyzed in block 106. Namely, the detected state that is analyzes maybe any one or more of the fo]lowing: * whether a keyguard of the user interface is on; * whether a screensaver of the user interface is on; * whether a graphical display screen of the radio device is off; * for the case in which the outgoing data message is an SMS or MMS message, whether a default SMS/MMS messaging application of the mobile terminal is running and/or has been running immediately prior to the outgoing message being sent; * whether a full screen application of the mobile terminal is running; * whether a virtual keyboard is visible on the user interface; * for the case in which the outgoing data message is an SMS or MMS message whether the outgoing SMS or MMS message is being sent by an application that does not support a graphical user interface; and * for the case in which the outgoing data message is an SMS or MMS message, whether the outgoing SMS or MMS message is being sent by a service as opposed to by a SMS or MMS application of the mobile terminal.

[0033] For the case in which the implementing software is checking other types of data messages apart from SMS/MMS messages, the detected state that is analyzed may be any one or more of the keyguard and screensaver checks above and also whether a radio connection over which the outgoing TCP/GDP data message is to be sent or has been sent is both new and created by a user of the radio device.

[0034] The alert mentioned at block 108 may be an audib]e/aural a]ert in which case the user interface would be a loudspeaker, or the alert may be a visual alert such as a text akrt or a flashing screen or some specialized icon displayed at a graphical user interface of the mobile terminal. In one embodiment the alert can be displaying the outgoing data message on a graphical user interface, since if it was originated by some malware rather than by the user himlherself the message would not have been displayed there as would be a normal SMSJMMS message before sending. If both aural and visual alerts are used then the user interface is both the speaker and the graphical user interface.

[0035] In one embodiment the implementing software can automatically prevent the outgoing data message from being sent andlor prevent an outgoing call from being connected if at block 106 it is determined that the outgoing data message or call was not prepared or initiated by a user of the mobile terminal. In this case the detecting at block 102 is of an outgoing data message that is about to be sent from the mobile terminal or of an outgoing call that has been initiated but which is not yet in progress (not yet connected to the destination/called number), rather than a data message which has already been sent or a call that has already been establishedlconnected. In this case, for a data message the software may also quarantine the outgoing data message that was prevented from being sent, such as by storing it in some reserved tile location in a local memory of the mobile terminal.

[0036] For the case in which the detecting of block 102 is of an outgoing data message that has already been sent from the mobile terminal or of an outgoing call that is in progress, then in some non-limiting embodiment the alert may show information about which process or application caused the outgoing data message to be sent or the call to be initiated. This may of course be used with other alerts such as for example an aural sound and/or flashing graphical screen. A specific embodiment with this quarantining functionality may additionally automatically terminate the process or application that caused the outgoing data message to be sent or the call to be initiated.

[0037] And for embodiments which incorporate the whitelist option detailed above, these may operate by providing the akrt of block 108 at the user interface of the mobile terminal upon meeting two conditions: a) the determination at block 106 that the outgoing data message was not prepared by a user of the mobile terminal, and b) that the outgoing data message does not satisfy any entries of a whitelist. In the above examples this whitelist included one or more of allowed message destinations, allowed message contents, andlor exempted applications. And also detailed above were several ways and stages at which the implementing software could interrupt the process of Figure 1 for a whitelisted message, so the alert being conditional on the whitelist check does not imply that the implementing software performs any or all of the functions described at Hocks 102, 104 and 106.

[0038] The specific elements of Figure 1 may be considered as steps of a method according to these teachings, of specific logica' code of a set of computer executable instructions that are stored in or on a computer readable memory, or actions talcen or functions executed by an apparatus that has one or more processors to execute such computer code stored on a memory. Such an apparatus may be the entire mobile terminal or other type of radio device, or one or more components thereof (such as for example a computer readable memory storing the implementing software and a processor for executing that software) which peitorm the functions shown at Figure 1 and which are detailed further in the above non-limiting examples.

[0039] Reference is now made to Figure 2 for illustrating a simplified block diagram of various electronic devices and apparatus that are suitable for use in practicing the exemplaiy embodiments of this invention. In Figure 2 there is a receiving terminal 24 representing one possible destination for the outgoing data message from the above examples, and in this case the outgoing data message may be routed through the illustrated radio network access node 26 as is currently typical for the majority of data messages or it may be that the outgoing message is sent directly to the receiving terminal 26 for the case of communications over a direct device-to-device (D2D) link

I

[0040] The imp]ementing software is in the Figure 2 example embodied in the radio device 22 which is illustrated more generically to represent any electronic device such as a user equipment, mobile terminal, tablet, smar phone, etc. for communication over any of the various types of wireless connections over which data messages may be sent.

Other than D2D links 27, most communication of a data message from the radio device 22 pass through over a bidirectional communication link 23 to some type of radio network access node 26 which may be implemented as a cellular base transceiver station, or a wireless local area network access point (WLAN AP), and the like, regardless of whether the message is addressed to a destination URL or a destination phone number.

[0041] The radio device 22 includes processing means such as at least one data processor (DP) 22A, and storing means such as at least one computer-readable memory (MEM) 22B storing at least one computer program (PROG) 22C including implementing software for detecting and analyzing outgoing messages as detailed in the above examples. The radio device 22 further includes communication means such as a transmitter TX 22D and a receiver RX 22E for bidirectional wireless communications with the access node 26 and/or with the D2D terminal 24. All of these wireless communications are via one or more antennas 22F. There is also a user interface (UI) shown at 22G as having both a graphical user interface (GUI) element such as a touch screen and a speaker, and it is through this UI 220 that the alerts are provided to the user of the radio device 22.

[0042] For completeness Figure 2 shows some functional details of the receiving terminal 24 and of the access node 26. The receiving terminal 24 is similar to the radio device 22 and inc]udes processing means such as at least one data processor (DP) 24A, stonng means such as at least one computer-readable memory (MEM) 24B storing at least one computer program (PROG) 24C. and communication means such as a transmitter TX 24D and a receiver RX 24E for bidirectional communications over the D2D link 27 with the radio device 22 (and with the access node 26 though that link is not specifically shown) via one or more antennas 24F. While not shown the receiving terminal 24 may also have a UI and another instance of software implementing these teachings stored as a PROG 24C in its local MEM 24B.

[0043] The access node 26 includes processing means such as at least one data processor (DP) 26A, storing means such as at least one computer-readable memory (MEM) 26B storing at least one computer program (PROG) 26C. and communication means such as a transmitter TX 26D and a receiver RX 26E for bidirectional communications with the radio device 22 via one or more antennas 26F, and possibly also with the receiving device 24. A modem at each of these devices 22, 24, 26 may also be the communication means of any of these devices and is well known in the wireless communication arts.

[0044] As noted above, at]east one of the PROGs 22C in the radio device 22 is assumed to include a set of program instructions that, when executed by the associated DP 22A, enable the device to operate in accordance with the exemplary embodiments of this invention, as detailed above. The receiving device 24 may ako have an instance of similar such software stored in its MEM 24B to imp]ement certain aspects of these teachings for its outgoing data messages. In these regards the exemplary embodiments of this invention may be implemented at least in part by computer software stored on the MEM 22B, 24B which is executable by the DP 22A of the radio device 22 and/orby the DP 24A of the receiving terminal 24; or by hardware, or by a combination of tangibly stored software and hardware (and tangibly stored firmware) in any one or more of these devices 22 and 24. Electronic devices embodying these aspects of the invention need not be the entire devices 22, 24 as depicted at Figure 2, but may be one or more components of same such as the above described tangibly stored software.

hardware, firmware and DP, or possibly the implementing embodiment may be integrated into a system on a chip SOC or an application specific integrated circuit ASIC.

[0045] Various embodiments of the computer readable MEMs 22B, 24B, 26B include any data storage technology type which is suitab]e to the local technical environment, including but not limited to semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, removable memory, disc memory, flash memory, DRAM, SRAM, EEPROM and the 111cc.

Various embodiments of the DPs 22A, 24A, 26A include but are not limited to general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and multi-core processors.

[0046] Various modifications and adaptations to the foregoing exemplary embodiments of this invention may become apparent to those skilled in the relevant arts in view of the foregoing descnption. While the exemplary embodiments have been described above in the context of the \VLAN systems, as noted above the exemplary embodiments of this invention are not limited for use with only this particular type of wireless radio access technology networks.

[0047] Further, some of the various features of the above non-limiting embodiments may be used to advantage without the corresponding use of other described features.

The foregoing description should therefore be considered as merely illustrative of the princip]es, teachings and exemplary embodiments of this invention, and not in limitation thereof.

Claims

CTATMS: What is claimed is: 1. A method for detecting maware on a radio device, the method comprising: detecting that an outgoing data message has been sent oris about to be sent from a radio device and/or that an outgoing call has been initiated or is in progress at the radio device; detecting a state of the radio device; analyzing the detected state to determine whether the outgoing data message andlor the outgoing call was prepared or initiated by a user of the radio device; and if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device, causing a user interface of the radio device to provide an alert to a user of the radio device.
2. The method according to claim,wherein the outgoing data message is one of a short message service (SMS) message and a multi-media message service (MMS) message.
3. The method according to claim I or 2, wherein the detected state that is analyzed comprises at least one of: whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is off; for the case in which the outgoing data message is one of a short message service (SMS) message and a multi-media message service (MMS) message, whether a default SMS/MMS messaging application of the radio device is running and/or has been running immediately prior to the outgoing message being sent; whether a full screen application of the radio device is running; whether a virtual keyboard is visible on the user interface; for the case in which the outgoing data message is one of a SMS message and a MMS message. whether the outgoing SMS or WIMS message is being sent by an application that does not support a graphical user interface; and for the case in which the outgoing data message is one of a SMS message and a MMS message, whether the outgoing data message is being sent by a service as opposed to by a SMS or MMS application of the radio device.
4. The method according to claim I, wherein the outgoing data message is one of a transmission control protocol (TCP) message and a user datagram protocol (UDP) message, and the detected state that is analyzed comprises at least one of: whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is off; and whether a radio connection over which the outgoing message is to be sent or has been sent is both new and created by a user of the radio device.
5. The method according to any of claims 1-4, wherein the alert comprises at least one of an aural and a visual alert at the user interface of the radio device.
6. The method according to claim 5, wherein the visual alert comprises displaying the outgoing data message on a graphical user interface of the radio device.
7. The method according to any of dlaims 1-6. wherein the detecting is of an outgoing data message that is about to be sent from the radio device or an outgoing call that has been initiated but is not yet in progress; and the method further comprises automatically preventing the outgoing data message from being sent or the call from being connected if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.
8. The method according to claim 7, the method further comprising quarantining the outgoing data message that was prevented from being sent in a local memory of the radio device.
9. The method according to any of daims I -6, wherein the detecting is of an outgoing data message that has been sent from the radio device or an outgoing call that is in progress; and the alert compnses information about which process or application caused the outgoing data message to be sent or the call to be initiated.
10. The method according to claim 9, the method further comprising: automatically terminating the process or application that caused the outgoing data message to be sent or the call to be initiated.
11. The method according to any of claims 1-10, wherein the alert is provided at the user interface of the radio device only if: if it is determined that the outgoing data message was not prepared by a user of the radio device, and the outgoing data message does not satisfy any entries of a whitelist comprising allowed message destinations, allowed message contents, andior exempted applications.
12. An apparatus comprising a processing system, the processing system comprising at least one processor and a memory storing a set of computer instructions for detecting malware on a radio device such that the processing system is configured to cause the apparatus at least to: detect that an outgoing data message has been sent or is about to be sent from a radio device and/or that an outgoing call has been initiated or is in progress at the radio device; detect a state of the radio device; analyze the detected state to determine whether the outgoing data message andlor the outgoing call was prepared or initiated by a user of the radio device; and cause a user interface of the radio device to provide an alert to a user of the radio device if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.
13. The apparatus according to claim 12, wherein the outgoing data message is oneIof a short message service (SMS) message and a multi-media message service (MMS) message.
14. The apparatus according to claim 13, wherein the detected state that is analyzed comprises at least one of: whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is off; for the case in which the outgoing data message is one of a short message service (SMS) message and a multi-media message service (MMS) message, whether a default SMSIMMS messaging application of the radio device is running and/or has been running immediately prior to the outgoing message being sent; whether a full screen application of the radio device is running; whether a virtual keyboard is visible on the user interface; for the case in which the outgoing data message is one of a SMS message and a MMS message, whether the outgoing SMS or MMS message is being sent by an appfication that does not support a graphical user interface; and for the case in which the outgoing data message is one of a SMS message and a MMS message, whether the outgoing data message is being sent by a service as opposed to by a SMS or MMS application of the radio device.
15. The apparatus according to claim 12, wherein the outgoing data message is one of a transmission control protocol (TCP) message and a user datagram protocol (UDP) message, and the detected state that is analyzed comprises at east one of: whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is off; and whether a radio connection over which the outgoing message is to be sent or has been sent is both new and created by a user of the radio device.
16. The apparatus according to any of claims 12-15, wherein the alert comprises at least one of an aural and a visual alert at the user interface of the radio device.I
17. The apparatus according to claim 16, wherein the visual alert comprises displaying the outgoing data message on a graphical user interface of the radio device.
18. The apparatus according to any of claims 12-17, wherein the detecting is of an outgoing data message that is about to be sent from the radio device or an outgoing call that has been initiated but is not yet in progress; and the processing system is configured to cause the apparatus further to automatically prevent the outgoing data message from being sent or the call from being connected if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.
19. The apparatus according to claim 18, wherein the processing system is configured to cause the apparatus further to quarantine the outgoing data message that was prevented from being sent in a local memory of the radio device.
20. The apparatus according to any of claims 12-17, wherein the detecting is of an outgoing data message that has been sent from the radio device or an outgoing call that is in progress; and the alert comprises information about which process or appfication caused the outgoing data message to be sent or the call to be initiated.
21. The apparatus according to claim 20, wherein the processing system is configured to cause the apparatus further to automatically terminate the process or application that caused the outgoing data message to be sent or the call to be initiated.
22. The apparatus according to any of claims 12-21, wherein the alert is provided at the user interface of the radio device only if: if it is determined that the outgoing data message was not prepared by a user of the radio device, and the outgoing data message does not satisfy any entries of a whitelist comprising allowed message destinations, a'lowed message contents, and/or exempted applications.
23. A computer readable memory tangibly storing a set of computer executable instructions for detecting malware on a radio device, the set of computer executable instructions comprising: code for detecting that an outgoing data message has been sent or is about to be sent from a radio device and/or that an outgoing call has been initiated or is in progress at the radio device; code for detecting a state of the radio device; code for analyzing the detected state to determine whether the outgoing data message and/or the outgoing call was prepared or initiated by a user of the radio device; and code for causing a user interface of the radio device to provide an alert to a user of the radio device if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.
24. The computer readable memory according to claim 23, wherein the outgoing data message is one of a short message service (SMS) message and a multi-media message service (MMS) message.
25. The computer readable memory according to claim 24, wherein the detected state that is analyzed comprises at least one of: whether a keyguard of the user interface is on; whether a screen saver of the user interface is on; whether a graphical display screen of the radio device is off; for the case in which the outgoing data message is one of a short message service (SMS) message and a multi-media message service (MMS) message. whether a default SN'IS/MMS messaging application of the radio device is running and/or has been running immediately prior to the outgoing message being sent; whether a full screen application of the radio device is running; whether a virtual keyboard is visible on the user interface; for the case in which the outgoing data message is one of a SMS message and aIMMS message. whether the outgoing SMS or MMS message is being sent by an appfication that does not support a graphical user interface; and for the case in which the outgoing data message is one of a SMS message and a MMS message, whether the outgoing data message is being sent by a service as opposed to by a SMS or MMS application of the radio device.
26. The computer readable memory according to claim 23, wherein the outgoing data message is one of a transmission control protocol (TCP) message and a user datagram protocol (UDP) message. and the detected state that is ana'yzed comprises at least one of: whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is off; and whether a radio connection over which the outgoing message is to be sent or has been sent is both new and created by a user of the radio device.
27. The computer readable memory according to any of claims 23-26. wherein the alert comprises at least one of an aural and a visual alert at the user interface of the radio device.
28. The computer readable memory according to claim 27, wherein the visual alert comprises displaying the outgoing data message on a graphical user interface of the radio device.
29. The computer readable memory according to any of claims 23-28, wherein the detecting is of an outgoing data message that is about to be sent from the radio device or an outgoing call that has been initiated but is not yet in progress; and the set of computer executable instructions further comprises code for automatically preventing the outgoing data message from being sent or the call from being connected if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.I
30. The computer readable memory according to claim 29, wherein the set of computer executable instructions further comprises code for quarantining the outgoing data message that was prevented from being sent in a local memory of the radio device.
31. The computer readable memory according to any of claims 23-28. wherein the detecting is of an outgoing data message that has been sent from the radio device or an outgoing call that is in progress; and the alert comprises information about which process or application caused the outgoing data message to be sent or the call to be initiated.
32. The computer readable memory according to claim 3i, wherein the set of computer executable instructions further comprises code for automatically terminating the process or application that caused the outgoing data message to be sent or the call to be initiated.
33. The computer readable memory according to any of claims 23-32, wherein the alert is provided at the user interface of the radio device only if: if it is determined that the outgoing data message was not prepared by a user of the radio device, and the outgoing data message does not satisfy any entries of a whitelist comprising allowed message destinations, allowed message contents, and/or exempted applications.IAmendments to the claims have been filed as follows CLAIMS: What is claimed is: 1. A method for detecting maiware on a radio device, the method comprising: detecting that an outgoing data message has been sent or is about to be sent from a radio device and/or that an outgoing call has been initiated or is in progress at the radio device; checking an operating system of the radio device to detect a state of at least one of a user interface and/or a messaging application of the radio device; analyzing the detected state to determine whether the outgoing data message and/or the outgoing call was prepared or initiated by a user of the radio device; and if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device, causing the user interface of the radio device to provide an alert to a user of the radio device.2. The method according to claim 1, wherein the outgoing data message is one of a short message service (SMS) message and a multi-media message service (MMS) message. r3, The method according to claim 1 or 2, wherein the detected state that is analyzed comprises at least one of: whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is ofe for the case in which the outgoing data message is one of a short message service (SMS) message and a multi-media message service (NIIvIS) message, whether a default SN'lS/MMS messaging application of the radio device is mnning and/or has been running immediately prior to the outgoing message being sent; whether a full screen application of the radio device is running; whether a virtual keyboard is visible on the user interface; for the case in which the outgoing data message is one of a SMS message and a MMS message, whether the outgoing SMS or MMS message is being sent by an application that does not support a graphical user interface; and for the case in which the outgoing data message is one of a SMS message and a MN'IS message, whether the outgoing data message is being sent by a service as opposed to by a SMS or IvllvIS application of the radio device.4, The method according to claim I, wherein the outgoing data message is one of a transmission control protocol (TCP) message and a user datagram protocol (UDP) message, and the detected state that is analyzed comprises at least one of whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is off; and whether a radio connection over which the outgoing message is to be sent or has been sent is both new and created by a user of the radio device.5. The method according to any of claims 1-4, wherein the alert comprises at least one of an aural and a visual alert at the user interface of the radio device.6. The method according to claim 5, wherein the visual alert comprises displaying the outgoing data message on a graphical user interface of the radio device.7. The method according to any of claims 1-6, wherein the detecting is of an outgoing data message that is about to be sent from the radio device or an outgoing call that has been initiated but is not yet in progress; and the method further comprises automatically preventing the outgoing data message from being sent or the call from being connected if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.8. The method according to claim 7, the method further comprising quarantining the outgoing data message that was prevented from being sent in a local memory of the radio device.9. The method according to any of claims 1-6, wherein the detecting is of an outgoing data message that has been sent from the radio device or an outgoing call that is in progress; and the alert comprises information about which process or application caused the outgoing data message to be sent or the call to be initiated.10. The method according to claim 9, the method further comprising: automatically terminating the process or application that caused the outgoing data message to be sent or the call to be initiated.L The method according to any of claims I-0, wherein the alert is provided at the user interface of the radio device only if if it is determined that the outgoing data message was not prepared by a user of the radio device, and the outgoing data message does not satisfy any entries of a whitelist comprising allowed message destinations, allowed message contents, and/or exempted I-ti-I' applications.(0 2. An apparatus comprising a processing system, the processing system i-comprising at least one processor and a memory storing a set of computer instructions for detecting malware on a radio device such that the processing system is configured to cause the apparatus at least to: detect that an outgoing data message has been sent or is about to be sent from a radio device and/or that an outgoing call has been initiated or is in progress at the radio device; check an operating system of the radio device to detect a state of at least one of a user interface and/or a messaging application of the radio device; analyze the detected state to determine whether the outgoing data message and/or the outgoing call was prepared or initiated by a user of the radio device; and cause the user interface of the radio device to provide an alert to a user of the radio device if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.13. The apparatus according to claim 12, wherein the outgoing data message is one of a short message service (SMS) message and a multi-media message service (/W1S) message.14. The apparatus according to claim 13, wherein the detected state that is analyzed comprises at least one of: whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is ofe for the case in which the outgoing data message is one of a short message service (SMS) message and a multi-media message service (IVIIIVIS) message, whether a default SMS/MMS messaging application of the radio device is running andlor has been running immediately prior to the outgoing message being sent; whether a full screen application of the radio device is running; whether a virtual keyboard is visible on the user interface; for the case in which the outgoing data message is one of a SMS message and a o MIVIS message, whether the outgoing SMS or MMS message is being sent by an (0 application that does not support a graphical user interface; and i-for the case in which the outgoing data message is one of a SMS message and a MIvIS message, whether the outgoing data message is being sent by a service as opposed to by a SMS or MMS application of the radio device.15, The apparatus according to claim 12, wherein the outgoing data message is one of a transmission control protocol (TCP) message and a user datagram protocol (UDP) message, and the detected state that is analyzed comprises at least one of whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is off and whether a radio connection over which the outgoing message is to be sent or has been sent is both new and created by a user of the radio device.6. The apparatus according to any of claims 12-15, wherein the alert comprises at least one of an aural and a visual alert at the user interface of the radio device.L/, The apparatus according to claim 16, wherein the visual alert comprises displaying the outgoing data message on a graphical user interface of the radio device.18. The apparatus according to any of claims 12-17, wherein the detecting is of an outgoing data message that is about to be sent from the radio device or an outgoing call that has been initiated but is not yet in progress; and the processing system is configured to cause the apparatus further to automatically prevent the outgoing data message from being sent or the call from being connected if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.19. The apparatus according to claim 18, wherein the processing system is configured to cause the apparatus further to quarantine the outgoing data message that was prevented from being sent in a local memory of the radio device.(0 20. The apparatus according to any of claims 12-17, wherein the detecting is of an outgoing data message that has been sent from the radio device or an outgoing call that is in progress; and the alert comprises information about which process or application caused the outgoing data message to be sent or the call to be initiated.2L The apparatus according to claim 20, wherein the processing system is configured to cause the apparatus further to automatically terminate the process or application that caused the outgoing data message to be sent or the call to be initiated.22. The apparatus according to any of claims 12-21, wherein the alert is provided at the user interface of the radio device only if: if it is determined that the outgoing data message was not prepared by a user of the radio device, and the outgoing data message does not satisñ' any entries of a whitelist comprising allowed message destinations, allowed message contents, and/or exempted applications 23. A computer readable memory tangiNy storing a set of computer executable instructions for detecting maiware on a radio device, the set of computer executable instructions comprising: code for detecting that an outgoing data message has been sent or is about to be sent from a radio device and/or that an outgoing call has been initiated or is in progress at the radio device; code for checking an operating system of the radio device to detect a state of at least one of a user interface and/or a messaging application of the radio device; code for analyzing the detected state to determine whether the outgoing data message and/or the outgoing call was prepared or initiated by a user of the radio device; and code for causing the user interface of the radio device to provide an alert to a user of the radio device if it is determined that the outgoing data message or call was not C prepared or initiated by a user of the radio device. (024. The computer readable memory according to claim 23, wherein the outgoing data message is one of a short message service (SMS) message and a multi-media message service (MMS) message.25, The computer readable memory according to claim 24, wherein the detected state that is analyzed comprises at least one of whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is oft for the case in which the outgoing data message is one of a short message service (SMS) message and a multi-media message service (TvllvlS) message, whether a default SMS/MMS messaging application of the radio device is running and/or has been running immediately prior to the outgoing message being sent; whether a full screen application of the radio device is running; whether a virtual keyboard is visible on the user interface; for the case in which the outgoing data message is one of a SMS message and a MMS message, whether the outgoing SMS or MMS message is being sent by an application that does not support a graphical user interface; and for the case in which the outgoing data message is one of a SMS message and a MIvIS message, whether the outgoing data message is being sent by a service as opposed to by a SMS or TvllvIS application of the radio device.26. The computer readable memory according to claim 23, wherein the outgoing data message is one of a transmission control protocol (TCP) message and a user datagram protocol (UDP) message, and the detected state that is analyzed comprises at least one of: whether a keyguard of the user interface is on; whether a screensaver of the user interface is on; whether a graphical display screen of the radio device is off and whether a radio connection over which the outgoing message is to be sent or has 0 been sent is both new and created by a user of the radio device. (027. The computer readable memory according to any of claims 23-26, wherein the alert comprises at least one of an aural and a visual alert at the user interface of the radio device.28. The computer readable memory according to claim 27, wherein the visual alert comprises displaying the outgoing data message on a graphical user interface of the radio device.29. The computer readable memory according to any of claims 23-28, wherein the detecting is of an outgoing data message that is about to be sent from the radio device or an outgoing call that has been initiated but is not yet in progress; and the set of computer executable instructions further comprises code for automatically preventing the outgoing data message from being sent or the call from being connected if it is determined that the outgoing data message or call was not prepared or initiated by a user of the radio device.30, The computer readable memory according to claim 29, wherein the set of computer executable instmctions further comprises code for quarantining the outgoing data message that was prevented from being sent in a local memory of the radio device.31. The computer readable memory according to any of claims 23-28, wherein the detecting is of an outgoing data message that has been sent from the radio device or an outgoing call that is in progress; and the alert comprises information about which process or application caused the outgoing data message to be sent or the call to be initiated.32. The computer readaNe memory according to claim 31, wherein the set of computer executable instructions further comprises code for automatically terminating the process or application that caused the outgoing data message to be sent or the call to Ft.-" be initiated.33. The computer readable memory according to any of claims 23-32, wherein the i-alert is provided at the user interface of the radio device only if: if it is determined that the outgoing data message was not prepared by a user of the radio device, and the outgoing data message does not satisfy any entries of a whitelist comprising allowed message destinations, allowed message contents, and/or exempted applications.