JP2018510403A - Method and apparatus for detecting fake user interaction with a mobile device for improved malware protection - Google Patents

Abstract

The computing device processor may be configured with processor-executable instructions for implementing a method for detecting and responding to false user interaction (UI) events. Whether the user interaction event is a fake user interaction event by analyzing raw data generated by one or more hardware drivers for user interaction event information generated or received by a high-level operating system Can be determined. Further, the processor identifies a malicious behavior or performance that degrades the computing device based on whether the detected user interaction event is a genuine user interaction event or a fake user interaction event. May be comprised of processor-executable instructions for implementing methods that use behavior analysis techniques and machine learning techniques to prevent, correct, or otherwise respond to them.

Description

  The present invention relates to a method and apparatus for detecting fake user interaction with a mobile device for improved malware protection.

  Cellular and wireless communication technologies have experienced explosive growth over the past few years. Wireless service providers currently offer a wide variety of functions and services that provide users with an unprecedented level of access to information, resources and communications. To keep pace with these enhancements, personal devices and consumer electronic devices (e.g., cellular phones, watches, headphones, remote controls, etc.) have become more powerful and complex than ever, and now generally, Includes powerful processors, large memory, and other resources that allow complex and powerful software applications to run on their devices.

  With these and other improvements, personal and consumer electronic devices have become ubiquitous in modern society and have an unprecedented level of access to information generated by or related to that user. In addition, people frequently use their devices to store sensitive information (eg, credit card information, contacts, etc.) and / or accomplish tasks where security is important. For example, mobile device users frequently use their devices to purchase goods, send and receive confidential communications, pay bills, manage deposit accounts, and perform other sensitive transactions. With these trends, personal devices and consumer electronic devices are rapidly becoming the next pioneering area for malware and cyber attacks. Thus, new and improved security solutions that better protect resource-constrained computing devices such as mobile devices and wireless devices are beneficial to consumers.

  Various embodiments include comparing raw data received from a user input device of a computing device with user interaction event information received within the computing device to generate analysis results, and user interaction (UI). Using a generated analysis result to determine whether the event correlates with a user of the computing device. The method includes analyzing a software application activity running on the computing device. In a further embodiment, the raw data received from the user input device can include raw data received from the device driver, and the user interaction event information received within the computing device is a high-level operating system of the computing device. Interaction information received from the system can be included.

  In a further embodiment, the method may include categorizing the activity of the software application as non-benign in response to determining that the user interaction event does not correlate with the user of the computing device. In a further embodiment, the method generates a behavior vector characterizing the activity of the software application and, in response to determining that the user interaction event does not correlate with a user of the computing device, To apply to a classifier model that may include a decision node that evaluates whether there is a user interaction event corresponding to, and a behavior vector generated to determine whether the activity of the software application is non-benign Using the result of applying to the classifier model.

  In a further embodiment, the method includes generating a behavior vector characterizing the activity of the software application and determining that the user interaction event does not correlate with a user of the computing device, wherein the user interaction event corresponding to the activity is Selecting a classifier model that does not include a decision node to test for existence, applying a generated behavior vector to the selected classifier model to generate additional analysis results, and software Using the generated additional analysis results to determine whether the activity of the application is non-benign.

  In a further embodiment, the method includes selecting a robust classifier model family in response to determining that the user interaction event does not correlate with a user of the computing device, and the software application activity is non-benign. Applying a plurality of behavior vectors to a selected family of robust classifier models to determine whether or not. In a further embodiment, the method includes determining whether the raw data received from the first sensor of the computing device matches the raw data received from the second sensor of the computing device. Comparing the raw data received from the first sensor with the raw data received from the second sensor can include comparing the raw data received from the user input device of the computing device to generate an analysis result. Comparing the data with user interaction event information received within the computing device is performed in response to determining that the raw data received from the first sensor is consistent with the raw data received from the second sensor. Is done.

  In a further embodiment, comparing the raw data received from the first sensor with the raw data received from the second sensor may include comparing the result of applying the behavior vector to the classifier model. In a further embodiment, raw data received from a user input device can include raw data received from a user input sensor, and user interaction event information received within the computing device is a device for the user input sensor. Data received from the driver can be included, and using the generated analysis results to determine whether a user interaction event correlates with a user of the computing device received from the user input sensor In response to the raw data not correlating with data received from the device driver for the user input sensor, the method may include determining that the user interaction event does not correlate with the user of the computing device.

  In a further embodiment, the user input sensor can include a touch screen and the device driver can include a touch screen device driver. In a further embodiment, the method may include categorizing the activity of the software application as non-benign in response to determining that the user interaction event does not correlate with the user of the computing device. In a further embodiment, the method includes generating a behavior vector characterizing the activity of the software application and determining the generated behavior vector in response to a determination that the user interaction event does not correlate with a user of the computing device. Applying the generated behavior vector to the classifier model to determine whether the activity of the software application is non-benign Using the results applied to the model.

  Further embodiments may include a computing device having a processor configured with processor-executable instructions for performing various operations corresponding to the methods discussed above.

  Further embodiments may include a computing device having various means for performing functions corresponding to the method operations discussed above.

  Further embodiments may include non-transitory processor-readable storage media having stored thereon processor-executable instructions configured to cause a processor to perform various operations corresponding to the method operations discussed above.

  The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the present invention, and are described in general terms below and below. Together with the detailed description provided, it will serve to explain the features of the invention.

FIG. 2 is an exemplary system-on-chip architecture diagram suitable for implementing various embodiments. Exemplary components and information flows within a computing device of an embodiment, including a fake user interaction (UI) event detection module configured to identify and respond to fake UI events, according to various embodiments. FIG. FIG. 7 is a block diagram illustrating exemplary logical components and information flow within an embodiment computing device configured to determine whether a particular mobile device's behavior is benign or non-benign. is there. 6 is a process flow diagram illustrating a method for detecting and responding to false UI events according to various embodiments. 6 is a process flow diagram illustrating a method for detecting and responding to false UI events according to various embodiments. 2 is a process flow diagram illustrating a method for detecting and responding to a corrupted user input sensor device driver, according to an embodiment. FIG. 4 is a process flow diagram illustrating a method of using a family of classifier models to classify device behavior according to an embodiment. FIG. 4 is an example decision node that may be generated and used to generate a classifier model. FIG. 3 is a process flow diagram illustrating a method for performing adaptive observations according to an embodiment. FIG. 3 is a component block diagram of a mobile device suitable for use in an embodiment.

  Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.

  In general, various embodiments include a method of using behavior-based machine learning techniques to detect and respond to fake user interaction (UI) events, and a computing device configured to implement the method. . In certain embodiments, a computing device implements a method of analyzing raw data generated by one or more hardware drivers or user input devices for UI event information generated or received by a high-level operating system; Use the results of this analysis to determine whether UI events correlate with the user of the computing device and / or classify detected UI events as authentic UI events or as false UI events Can be configured. A computing device may have non-benign device behavior (e.g., behavior caused by malicious or performance degrading software applications) based on whether the UI event is a genuine or fake UI event. Can also be included and include a comprehensive behavior-based security system configured to respond.

  In general, each software application program performs several tasks or activities on a computing device. Some of the application tasks / activities are directly or essentially related to or require some form of user interaction with the device. For example, using a camera, activating a microphone to record audio, and sending a premium short message service (SMS) message are all for the user to activate the microphone, which activates the shutter release button for the camera Tasks / activities related to some form of user interaction with the device, such as pressing the record button, typing text to send an SMS message, and touching the send button.

  Most user interaction with the device will cause the computing device to generate one or more UI events (eg, View :: onTouchEvent, onKeyDown, onKeyUp, onTrackBallEvent, etc.). For example, touching the electronic touch screen display of a computing device may cause a device driver to generate a “touch event” that identifies the area touched (eg, by Cartesian coordinates X and Y). The operating system may receive a UI event (eg, a “touch event”) from the device driver and execute the software application procedure associated with the UI event accordingly.

  Thus, some tasks / activities are directly or essentially related to or require some form of user interaction, and most user interactions generate some form of UI events. Therefore, the execution of certain tasks / activities in the application program without the corresponding UI event is a strong indicator that the application program is non-benign or otherwise deserves closer scrutiny, monitoring or analysis It can be. Accordingly, in some embodiments, a behavior-based security system for a computing device is suspicious of activities that are directly or essentially related to or require user interaction but are not associated with UI events. Or it can be configured to classify as non-benign. For example, in some embodiments, a behavior-based security system monitors the activity of a software application program, and the monitored activity (e.g., camera usage) is directly or essentially related to some form of user interaction. Respond to the monitored activity in response to a determination that the monitored activity is directly or essentially related to or requires user interaction Determining whether there is a UI event (eg, onTouchEvet), determining that the monitored activity is directly or essentially related to or requires user interaction, and monitored activity Non-benign (or more scrutinized, more detailed analysis, etc.) in response to determining that there are no UI events corresponding to It may be configured to classify the application program as a main).

  Behavior-based security systems are generally effective in identifying non-benign behavior and preventing degradation of device performance and power utilization levels over time. For example, by using UI event information as an indicator of whether an activity or software application is benign, a behavior-based security system allows a computing device to determine the amount of its processing, memory, or battery resources. Allows non-benign device behavior (eg, malicious software applications) to be identified and responded to without consuming excessively. As a result, behavior-based security systems have limited resources, run on battery power, and into mobile computing devices and resource-constrained computing devices such as smartphones where performance and security are important. Suitable for inclusion or use therein.

  While the above system is generally effective, malicious software applications may bypass or avoid detection by the security system by generating fake UI event information and sending it to the device operating system. For example, a malicious software application activates a computing device's camera to capture images without user recognition or consent, and then sends a fake onTouchEvent to the device's operating system to detect detected activity (camera Activation) is associated with the corresponding UI event, which can cause the security system to determine incorrectly. This can cause the security system to incorrectly classify malicious application programs as benign.

  Various implementations by using behavior-based machine learning techniques to analyze raw data generated by one or more hardware / device drivers for UI event information received by high-level operating systems The form determines whether a UI event is a fake UI event and prevents malicious software applications from using fake UI event information to circumvent or bypass detection. This information can be used when analyzing device behavior.

  Various embodiments provide computing device functionality by allowing a device to more accurately and efficiently identify, prevent, correct, and / or otherwise respond to non-benign software applications. To improve. Various embodiments also allow a computing device (or its behavior-based security system) to use the UI event information to intelligently concentrate on its monitoring and / or analysis operations, thereby enabling the device's Improve the functionality of the computing device by reducing its impact on responsiveness, performance, and power consumption characteristics.

  Additional improvements to the functionality, functionality, and / or operation of computing devices will become apparent from the detailed description of the embodiments provided below.

  The term `` performance degradation '' refers herein to longer processing times, slower real-time responsiveness, shorter battery life, loss of personal data, malicious economic activity (e.g., unauthorized premium SMS messages Mobile devices for denial of service (DoS), improperly written or designed software applications, malicious software, malware, viruses, fragmented memory, espionage or botnet activity Is used to refer to a wide variety of undesirable operations and characteristics of computing devices, such as operations relating to hijacking or utilizing a telephone. Also, behaviors, activities, and conditions that degrade performance for any of these reasons are referred to herein as “not benign” or “non-benign”.

  The terms “mobile computing device” and “mobile device” refer to cellular phones, smartphones, personal or mobile multimedia players, personal digital assistants (PDAs), laptop computers, tablet computers, smart books, ultrabooks, palmtops Computers, wireless email receivers, multimedia internet-enabled cellular phones, wireless game controllers, and memory and programmable processors where performance is critical, as well as operating on battery power where power saving methods are beneficial Are used interchangeably herein to refer to any one or all of the personal electronic devices. Although various embodiments are particularly useful for mobile computing devices such as smartphones that have limited resources and operate on batteries, these embodiments generally include a processor and execute application programs. Useful in any electronic device.

  In general, mobile device performance and power efficiency degrade over time. In recent years, anti-virus companies (eg McAfee, Symantec, etc.) have begun selling mobile anti-virus, firewall and encryption products aimed at slowing down this degradation. However, many of these solutions rely on periodically running a computationally intensive scanning engine on the mobile device, which consumes much of the mobile device's processing and battery resources, It may slow down or disable the mobile device for a longer period and / or otherwise degrade the user experience. In addition, these solutions are usually limited to the detection of known viruses and malware, and combined contributions to mobile device degradation over time (for example, when performance degradation is not caused by viruses or malware) Do not deal with multiple complex factors and / or interactions that are often done. For these and other reasons, existing anti-virus, firewall, and encryption products prevent mobile device degradation to identify a number of factors that can contribute to mobile device degradation over time. Does not provide a sufficient solution for efficiently recovering or aging mobile devices to their original conditions.

  Furthermore, modern mobile devices are highly configurable and complex systems. Thus, the features that are most important for determining whether a particular device behavior is benign or non-benign (eg, malicious or degrades performance) may be different for each mobile device. In addition, over time degradation of mobile computing device performance and power usage levels, including poorly written or designed software applications, malware, viruses, fragmented memory, background processing, etc. There are a wide variety of factors that can contribute. Because of the number, diversity, and complexity of these factors, the factors that may contribute to the degradation of the performance and / or level of power utilization of the complex but resource-constrained systems of modern mobile computing devices Assessing everything is often not feasible. Thus, it is difficult for a user, operating system, and / or application program (eg, anti-virus software, etc.) to accurately and efficiently identify the source of the problem. As a result, mobile device users are currently able to prevent degradation of mobile device performance and power usage levels over time or to restore aged mobile devices to their original performance and power usage levels. Have few measures.

  To overcome the limitations of existing solutions, various embodiments allow non-benign software applications (e.g., malignant applications, improperly written applications, applications that are not compatible with the device, etc.) Behavior monitoring and configured to efficiently identify and prevent such applications from degrading computing device performance, power usage levels, network usage levels, security, and / or privacy over time A computing device with an analysis system is included. The behavior monitoring and analysis system identifies and prevents identified problems without significant, negative, or user perceptible effects on the responsiveness, performance, or power consumption characteristics of the computing device; Can be configured to modify. In certain embodiments, the behavior monitoring and analysis system may be a behavior based security system.

  A behavior-based monitoring and analysis system may include observation processes, daemons, modules, or subsystems (collectively referred to herein as “modules”), behavior extractor modules, and analyzer modules. Observer modules are defined as various application programming interfaces (APIs), registers, counters, or other device components (collectively “measured components” herein) at various levels of a computing device system. ) Is measured or coordinated, collects behavior information from the measured components, and communicates the collected behavior information to the behavior extractor module (e.g., via a memory write operation, function call, etc.) Can be done. A behavior extractor module is an observed event, condition, task, activity, and / or behavior (book) each associated with one or more specific threads, processes, software applications, modules, or components of the device. In the description, the collected behavior information can be used to generate behavior vectors that collectively represent or characterize many or all of the “behaviors”). The behavior extractor module can communicate the generated behavior vector to the analyzer module (e.g., via a memory write operation, a function call, etc.), and the analyzer module can generate the behavior vector to generate an analysis result. To the classifier model to determine whether the behavior of the software application or device is benign or non-benign (e.g., malicious, poorly written, degrades performance, etc.) The analysis results can be used to The device processor can then perform various operations to correct, repair, correct, isolate, or otherwise resolve the identified problem (eg, behavior determined to be non-benign).

  Each behavior vector may be an information structure that includes or encapsulates one or more “behavior features”. A behavior feature may be a number or symbol that represents all or part of an observed event, condition, activity, action, relationship, interaction, or behavior in a computing device. Each behavioral feature can be associated with a data type that identifies the range of possible values, the actions that can be performed on those values, the meaning of the values, and other similar information. The data type can be used by a computing device to determine how the corresponding behavioral feature (or feature value) should be measured, analyzed, weighted, or used.

  A classifier model is a specific feature, factor, data point, entry, API, state, condition, behavior, software application, process, behavior, component (collectively "feature" herein), etc., or device Can be a behavioral model that includes data, entries, decision nodes, criteria, and / or information structures that can be used by a device processor to quickly or efficiently test or evaluate other embodiments of the behavior. The classifier model can also include information that can be used by the device processor to determine the relationship between software applications and / or the nature of the behavior to be monitored within the mobile device.

  Each classifier model may be categorized as a complete classifier model or a concise classifier model. A complete classifier model can be a robust data model that is generated in response to a large training data set that can include thousands of features and billions of entries. A concise classifier model was generated from a reduced data set that includes or prioritizes tests on features / entries that are most relevant to determining if the behavior of a particular mobile device is not benign, It can be a more dedicated data model. The local classifier model can be a concise classifier model generated at a computing device. The user-specific classifier model includes a decision node that tests or evaluates the most relevant device features / entries to determine whether the device behavior matches the normal use of the computing device by a particular user, Or it can be a local analyzer model that includes a highly dedicated data model to prioritize.

  Each person generally interacts with the computing device in a unique or characteristic way. For example, mobile device users often have a distinct working or communication style, use a specific software application or type of software application, and use that mobile device to perform a specific activity. Perform or accomplish a specific task, perform activities in a specific order, perform specific activities at specific points in time, interact with specific software applications in specific ways, and so on. The unique way a user interacts with his device can be learned over time and used to determine if a software application is non-benign. For example, in one embodiment, a computing device may use this information to determine whether a user interacts with his device over time and an activity, task, or behavior should be associated with a corresponding UI event. Use to generate behavior vectors and / or classifier models that reveal the presence of corresponding UI events, and apply behavior vectors to classifier models to generate analysis results and to activity, task, or behavior It may be configured to learn a unique method of using the analysis results to determine whether the associated software application is non-benign (eg, malicious, etc.).

  Current computing devices have an unprecedented level of access to information generated by or related to that user. For example, mobile computing devices often include sensors (eg, accelerometers, gyroscopes, geospatial positioning sensors, cameras, heart rate monitors, glucometers) that collect or generate detailed personal information about the user. In addition, mobile computing devices currently have applications for navigating the web, applications for purchasing goods, applications for monitoring user health, applications for controlling home appliances, games Complex software applications, including applications for viewing, video viewing / recording, navigation for new cities, training tracking, financial transactions, etc. Includes a powerful processor that allows you to run. These software applications often collect or generate detailed personal information about the user. Information collected, generated or used by these software applications and sensors is used to generate user persona information that characterizes user activity, preferences, age, occupation, customs, mood, emotional state, personality, etc. It can be used by certain embodiments of computing devices. The computing device of an embodiment can be used by such users to determine the normal operating pattern of the device over time, including whether activities, tasks, or behaviors should be associated with the corresponding UI events. Persona information may be configured to be collected and used. User persona information also generates behavior vectors and / or classifier models (eg, user-specific classifier models) that are suitable for use in determining whether a software application is non-benign. Can be used for.

  Some tasks / activities are directly or essentially the operating system or software application (or process, thread, etc.) that is in a running state that supports or is compatible with those tasks / activities. Related to or need it. For example, using a camera, sending a short message service (SMS) message, and collecting accelerometer data are all tasks / activities that generally require some form of user interaction with the device. Thus, these activities generally must be performed in a “foreground” execution state or in another execution state that supports user interaction with the computing device. When these or other similar tasks / activities are executed in an execution state that does not support advanced user interaction with the device, such as a background execution state, this operating condition is associated with the device associated with that activity It can be an indicator that the behavior is non-benign or otherwise deserves additional or more detailed scrutiny, monitoring or analysis. Thus, in certain embodiments, a computing device determines whether an activity, task, or behavior should be associated with a corresponding UI event, and reveals the execution state and / or presence of the corresponding UI event To generate a behavior vector and / or classifier model, apply the behavior vector to the classifier model to generate analysis results, and use the analysis results to determine if the software application is non-benign It can be configured to use a specific execution state in which an activity or task is executed.

  In certain embodiments, the behavior monitoring and analysis system may generate an analysis result that is used to determine whether a software application is non-benign (e.g., by applying a behavior vector to a classifier model). ) The presence of UI events can be used as a factor to be tested / evaluated.

  In the above example, the computing device uses information generated by user interaction with the device, such as the presence of a corresponding UI event, to determine whether the software application is non-benign. Such information is typically sent to the operating system for transfer to a behavior monitoring and analysis system (e.g., by an operating system that stores the information in a log) (e.g., a user touches the device's touch screen). Data generated by the device's sensors or hardware. Because the behavior monitoring and analysis system uses this information to determine if the software application is non-benign, the malicious software application may not recognize the presence of UI events in the operating system. It may attempt to bypass or avoid detection by the system by generating fake UI event information and sending it to the operating system, such as for accurate reporting.

  In order to prevent a software application that generates fake user interaction information (e.g., fake UI events) by a behavior monitoring and analysis system (e.g., behavior-based security system), according to an embodiment A computing device receives raw data from sensors and hardware drivers and UI event information from the operating system to determine whether the UI event is a genuine or fake UI event A false UI event detection module configured to compare the received raw data with the received UI event information and report the false UI event to the behavior monitoring and analysis system.

  In certain embodiments, the behavior monitoring and analysis system may be configured to classify software applications associated with fake UI events as non-benign.

  In some embodiments, the behavior monitoring and analysis system classifies software associated with fake UI events as suspicious (e.g., uses a more robust classifier model, monitors more activity of the software application). (Eg, by generating a larger behavior vector, etc.) that can be configured to increase the level of its scrutiny or analysis.

  In some embodiments, the behavior monitoring and analysis system may ignore UI events that have been determined to be fake UI events, such as by using a classifier model that does not test conditions regarding the presence or presence of corresponding UI events. Can be configured. This allows the system to concentrate on the features or factors that are most important for its monitoring and / or analysis operations to determine whether the activity and behavior are non-benign.

  In some embodiments, the device processor of the computing device compares information received from different device drivers or hardware components to determine whether the detected UI event is a fake UI event, Can be configured to correlate. For example, when a user touches a touch screen display of a computing device, the display generates raw data in the form of a time stamp that identifies the time the display was touched and coordinate information that identifies the touched display area. Can be made. In addition, because computing devices generally move when touched on their display (by the user's touch), the gyroscope and accelerometer indicate that the device has moved slightly at the same time as the touch event. Raw data can be generated. Thus, the device processor can determine whether the movement of the device when the touch event is generated matches the user interaction.

  Various embodiments (including those described with reference to FIGS. 2-7) include several different mobile devices, including single processor systems and multiple processor systems, as well as system-on-chip (SOC). ). FIG. 1 is an architectural diagram illustrating an example system-on-chip (SOC) 100 architecture that may be used within a computing device that implements various embodiments. The SOC 100 may include a number of disparate processors, such as a digital signal processor (DSP) 102, a modem processor 104, a graphics processor 106, and an application processor 108. The SOC 100 may also include one or more coprocessors 110 (eg, vector coprocessors) connected to one or more of the heterogeneous processors 102, 104, 106, 108. Each processor 102, 104, 106, 108, 110 may include one or more cores, and each processor / core may perform operations independent of other processors / cores. For example, SOC 100 includes a processor that runs a first type of operating system (eg, FreeBSD, LINUX, OS X, etc.) and a processor that runs a second type of operating system (eg, Microsoft Windows 10). obtain.

  SOC100 also manages analog data and analog data to convert sensor data, analog-to-digital conversion, wireless data transmission, and perform other special operations such as processing encoded audio signals for games and movies Custom circuitry 114 may be included. SOC100 is a voltage regulator, oscillator, phase lock loop, peripheral bridge, data controller, memory controller, system controller, access port, timer, and others used to support processors and clients running on computing devices It may further include system components / resources 116, such as

  System components / resources 116 and custom circuitry 114 may include circuitry that interfaces with peripheral devices such as cameras, electronic displays, wireless communication devices, external memory chips, and the like. Processors 102, 104, 106, 108 include an array of reconfigurable logic gates and / or through interconnect / bus module 124, which may implement a bus architecture (e.g., CoreConnect, AMBA, etc.) One or more memory elements 112, system components / resources 116, and custom circuitry 114 may be interconnected. Communication can be provided by advanced interconnects such as high performance network on chip (NoCs).

  SOC 100 may further include input / output modules (not shown) for communicating with resources external to the SOC, such as clock 118 and voltage regulator 120. Resources outside the SOC (e.g. clock 118, voltage regulator 120) are shared by two or more of the internal SOC processors / cores (e.g. DSP 102, modem processor 104, graphics processor 106, application processor 108, etc.) obtain.

  SOC100 also includes sensors, cameras for monitoring speakers, user interface elements (e.g., input buttons, touch screen displays, etc.), microphone arrays, physical conditions (e.g., position, orientation, movement, orientation, vibration, pressure, etc.) Sensors, including compass, GPS receivers, communication circuits (e.g., Bluetooth (R), WLAN, WiFi, etc.), and other well-known components of modern electronic devices (e.g., accelerometers, etc.) Hardware and / or software components suitable for collecting sensor data from

  In addition to the SOC 100 discussed above, various embodiments may be implemented in a wide variety of computing systems that may include a single processor, multiple processors, multi-core processors, or any combination thereof.

  FIG. 2 illustrates example logical components and information flow in an embodiment computing device 200 configured to identify fake UI events in accordance with various aspects. In the example shown in FIG. 2, the computing device 200 includes various sensors and hardware components 202, a device driver module 204, an operating system 206, a fake UI event detection module 212, and a behavior-based security module 214. , Including activity log 220. The computing device also includes a software application program 208 and a malicious software application, both of which can operate or execute on the computing device 200 via one or more of its processors or processing cores. Includes program 210.

  The software application programs 208, 210 can activate services of the operating system 206 using an application program interface (API). The operating system 206 serves as a software interface between the sensor / hardware component 202 and the operating system 206 or communicates with the sensor / hardware component 202 via a device driver module 204 that can provide it. can do. Device driver module 204 may be configured to control or communicate with sensor / hardware component 202 via opcodes and native commands implemented by sensor / hardware component 202. Device driver module 204 may be configured to use raw data received from sensor / hardware component 202 to generate information suitable for interpretation and use by operating system 206.

  The sensor / hardware component 202 can be configured to generate raw data and send it to the device driver module 204 upon detection of a user interaction event, which is interpreted and used by the operating system 206 Can be configured to use raw data received from the sensor / hardware component 202 to generate UI event information suitable for. For example, the sensor / hardware component 202 may be an electronic touch screen display configured to send raw data to the device driver module 204 in the form of X location coordinates and Y location coordinates each time a user touches the touch screen ( For example, a capacitive sensing touch screen panel or the like. Device driver module 204 may be configured to convert this raw data (i.e., location coordinates X and Y) into UI event information suitable for interpretation and use by operating system 206 (e.g., screenTouch (X, Y)). . The operating system 206 receives the UI event information and uses it to determine that the onTouch (X, Y) function of the software application program 208 should be invoked and to the software application program 208 onTouch (X, Y) Execute the function operation. Such operations may include opening the camera shutter, supplementing the image, processing the supplemented image, and the like.

  Operating system 206 and software application program 208 may record their respective operations, activities, and / or tasks in activity log 220. For example, the operating system can record the detection of a UI event (e.g., screenTouch (X, Y)) in the activity log 220, and the software application program 208 can capture an action (e.g., open a camera shutter, image Capture, write information into memory, etc.) or its associated API calls can be recorded in the activity log 220.

  The behavior-based security module 214 monitors behavior, activity of the software application program 208, collects behavior information from the activity log 220, generates behavior vectors using the collected behavior information, and generates analysis results To do so, the generated behavior vector can be applied to the classifier model and configured to use the analysis results to determine whether the software application program 208 is non-benign. As part of these operations, the behavior-based security module 214 determines that the behavior or activity of the software application program 208 is directly or essentially related to or requires some form of user interaction with the device. Determine whether the activity log 220 includes UI events corresponding to the behavior / activity, depending on the decision that the behavior / activity is directly or essentially related to or requires user interaction. When determining and determining whether the software application program 208 is non-benign, a behavior vector and / or classifier model that evaluates the presence or presence of the corresponding UI event can be used.

  In the example shown in FIG. 2, the malicious software application program 210 attempts to bypass or avoid detection by the behavior-based security module 214 by generating a fake UI event and sending it to the operating system. For example, the malicious software application program 210 activates the camera, supplements the image without the user's knowledge or consent, and causes the operating system to incorrectly record the presence of UI events corresponding to the camera activation. there is a possibility. This may cause the behavior-based security module 214 to incorrectly determine that there is a UI event corresponding to the monitored activity.

  The fake UI event detection module 212 may be configured to prevent malicious software application programs 210 from bypassing or avoiding detection by the behavior-based security module 214. The device driver module 204 can include a driver instrumentation module 216 configured to send raw data to the fake UI event detection module 212, and the operating system 206 sends UI event information to the fake UI event detection module 212. The operating system measurement module 218 may be included. The fake UI event detection module 212 receives the raw data from the driver measurement module 216 and the UI event information from the operating system measurement module 218, compares the received raw data with the received UI event information, Can be configured to determine whether is a genuine UI event or a fake UI event and report the false UI event to the behavior-based security module 214.

  In response to receiving a report of a fake UI event, the behavior-based security module 214 classifies the software application associated with the fake UI event as non-benign, and classifies the software application associated with the fake UI event as suspicious. Update the classification model to exclude decision nodes that test for the presence / presence condition of UI events, or select / use behavior vectors and classifier models that do not test the conditions for presence / presence of UI events be able to.

  FIG. 3 illustrates an example in a computing device of an embodiment that includes a behavior-based security module 214 configured to use behavior analysis techniques to identify and respond to non-benign device behaviors. Logical components and information flow are shown. In the example shown in FIG. 3, the computing device is a device processor (e.g., mobile device) configured with an executable instruction module that includes a behavior observer module 302, a behavior extractor module 304, a behavior analyzer module 306, and an actuator module 308. A mobile device 300 including a device processor). Each of modules 302-308 may be a thread, process, daemon, module, subsystem, or component implemented in software, hardware, or a combination thereof. In various embodiments, modules 302-308 are within a portion of an operating system (eg, in the kernel, in kernel space, in user space, etc.), in a separate program or application, in a dedicated hardware buffer or processor. Or in any combination thereof. In certain embodiments, one or more of the modules 302-308 may be implemented as software instructions that execute on one or more processors of the mobile device 300.

  The behavior observer module 302 measures application programming interfaces (APIs), counters, hardware monitors, etc. at various levels / modules of the device, and activities, conditions, operations, and events at various levels / modules over a period of time. (Eg, system events, state changes, etc.) may be configured to be monitored. The behavior observer module 302 can collect behavior information related to the monitored activity, condition, action, or event and store the collected information in a memory (eg, a log file, etc.).

  In some embodiments, the behavior observer module 302 is user-based information (from a software application running within a computing device, a sensor of the computing device, and / or user interaction with the computing device or its software application). For example, user persona information) may be collected. User-based information may include any information suitable for identifying or characterizing device user activity, device usage patterns, habits, moods, occupations, and / or emotional states. By way of example, user-based information may include user interaction with the device, the number and type of customizations performed on the device, the type of software application downloaded or used by the user, the user touching or interacting with the screen Rate of use of the device's graphics processing unit (GPU), how often the user uses the device to communicate with others, the communication method preferred by the user (e.g., text-to-speech), It may include information specifying how fast it communicates, the memory size of the device, and the like. The device processor uses the collected user-based information to learn how a user typically interacts with a computing device, determine the normal operating pattern of the device, and / or activities, tasks Or whether a behavior should be associated with a UI event. For example, a device processor may use user-based information to determine the normal operating pattern of a device, that a specific activity is associated with a specific UI event, and / or a specific activity without its corresponding UI event. To indicate that the performance of the device does not match the normal operating pattern of the device.

  The behavior observer module 302 is a calendar application, reminder application, communication application, financial application, application to achieve specific tasks (e.g. word processing, tax return preparation, presentation application, accounting application, etc.), location based Applications (e.g. mapping and geolocation applications), social media applications, web (e.g. to get information about past searches, browsing history, visited website type, visited website content, etc.) Browser, entertainment application (e.g. audio player or multimedia player application) Monitor any of a variety of software applications (or software application types), including applications for accessing user accounts (e.g. banking apps), personal training and development applications, etc. Thus, it may be configured to collect user persona information.

  The behavior observer module 302 obtains data from a heart rate monitor, blood pressure monitor, thermometer, pedometer, blood glucose meter, humidity sensor, alcohol detector, electrical skin reaction sensor, or other sensor in the device, User persona information can also be collected. For example, the behavior observer module 302 may include the user's current location (e.g., at the office, at home, at a restaurant, office work, traveling, etc.), the user's current movement (e.g., currently traveling, exercising). Travel history (e.g. travel extensively, never leave town), whether users follow their established routines (e.g. arrived at work on time, The user's by monitoring the device's geospatial positioning and navigation system to determine whether it is still at work) or out of its routine (e.g., arrived later than usual, left earlier than usual) Persona information can be collected.

  In some embodiments, the device processor of the mobile device 300 is configured to generate a behavior vector and / or classifier model using user persona information and / or information that characterizes user interaction with the device. obtain. For example, the device processor dynamically determines monitored device features, behavior information contained in behavior vectors, specific device features contained within the classifier model (and thus evaluated by the classifier model), etc. Can be configured to use user interaction information. As another example, the device processor may generate a classifier model that evaluates conditions / features dedicated to identifying the presence of UI events during the use or execution of certain types of software applications (e.g., games). Can be configured.

  In some embodiments, the device processor determines whether the user interaction information is relevant to analyzing all or part of the collected behavior information and evaluates device characteristics for user interaction (if relevant). Generated to determine whether the device behavior is non-benign A behavior vector may be configured to apply to the generated classifier model.

  The behavior observer module 302 also includes an application framework or runtime library, system call API, file system and networking subsystem operation, device (including sensor device) state changes, and library application programming interfaces within other similar events ( API) calls may be configured to monitor the activity of the mobile device 300 by collecting information about the call. In addition, the behavior observer module 302 can monitor file system activity, such as searching for file names, file access categories (personal information or regular data files), files (e.g. , Type exe, zip, etc.), file read / write / search operations, changing file permissions, etc.

  The behavior observer module 302 also enables mobile devices by monitoring data network activity that may include connection type, protocol, port number, server / client to which the device is connected, number of connections, amount or frequency of communication, etc. 300 activities can also be monitored. The behavior observer module 302 can monitor telephone network activity, which is the type and number of outgoing or received or intercepted calls or messages (e.g., SMS, etc.) Monitoring the number of calls).

  The behavior observer module 302 can also monitor the activity of the mobile device 300 by monitoring system resource usage, which can include monitoring the number of forks, memory access activity, the number of opened files, etc. . The behavior observer module 302 may include monitoring various factors such as whether the display is on or off, whether the device is locked or unlocked, battery level, camera status, etc. 300 states can be monitored. The behavior observer module 302 can also monitor interprocess communication, for example by monitoring intentions for critical services (browser, contract provider, etc.), degree of interprocess communication (IPC), pop-up windows, etc. .

  The behavior observer module 302 also includes cameras, sensors, electronic displays, WiFi communication components, data controllers, memory controllers, system controllers, access ports, timers, peripheral devices, wireless communication components, external memory chips, voltage regulators, oscillators One or more hardware component drivers that may include: a phase-locked loop, a peripheral bridge, and other similar components used to support a processor and a client running on the mobile device 300 The activity of the mobile device 300 can also be monitored by monitoring the statistical data and / or status of the device.

  The behavior observer module 302 may also monitor the activity of the mobile device 300 by monitoring one or more hardware counters that indicate the state or status of the mobile device 300 and / or a subsystem of the computing device. it can. The hardware counter may include a processor / core dedicated register configured to store a count value or state of hardware related activities or events that occur within the mobile device 300.

  The behavior observer module 302 also includes software application activity or behavior, software download from an application download server (eg, Apple® App Store server), computing device information used by the software application, call information, text Messaging information (for example, SendSMS, BlockSMS, ReadSMS), media messaging information (for example, ReceiveMMS), user account information, location information, camera information, accelerometer information, browser information, browser-based communication content, voice-based communication Content, short-range wireless communication (eg Bluetooth®, WiFi, etc.), text-based communication content, recorded audio file content, phone book or contact information, contact list, etc. Therefore, it is also possible to monitor the activities of the mobile device 300.

  Behavior observer module 302 includes communication including voice mail (VoiceMailComm), communication including device identifier (DeviceIDComm), communication including user account information (UserAccountComm), communication including calendar information (CalendarComm), communication including location information ( Monitoring mobile device 300 activity by monitoring mobile device 300 transmissions, including LocationComm), communications containing recorded audio information (RecordAudioComm), communications containing accelerometer information (AccelerometerComm), etc. You can also.

  The behavior observer module 302 monitors the mobile device 300 by monitoring the use of compass information, computing device settings, battery life, gyroscope information, pressure sensors, magnetic sensors, screen activity, etc. and updates / changes to them. You can also monitor your activity. The behavior observer module 302 can monitor notifications (AppNotifications), application updates, and the like communicated with the software application. The behavior observer module 302 can monitor conditions or events related to the first software application requesting the download and / or installation of the second software application. The behavior observer module 302 can monitor conditions or events related to user verification, such as password entry.

  The behavior observer module 302 can also monitor the activity of the mobile device 300 by monitoring conditions or events at multiple levels of the mobile device 300, including application level, radio level, and sensor level. Application level observations include observing users via face recognition software, observing social streams, observing annotations entered by users, PassBook (registered trademark), Google (registered trademark) Wallet, Such as observing events related to the use of Paypal®, and other similar applications or services. Application level observations include events related to the use of virtual private networks (VPNs), and synchronization, voice search, voice control (e.g., phone lock / unlock by speaking one word), language translators, computational Observing events related to data offloading, video streaming, camera usage without user activity, microphone usage without user activity, etc. may also be included.

  Radio level observation includes user interaction with mobile device 300 prior to establishing a wireless communication link or transmitting information, dual / multiple subscriber identity module (SIM) card, Internet radio, mobile phone tethering, calculations Includes determining the presence, presence, or amount of any or more of data offloading, device state communication, use as a game controller or home controller, vehicle communication, computing device synchronization, etc. obtain. Radio level observations also include positioning, peer-to-peer (p2p) communication, synchronization, vehicle-to-vehicle communication, and / or machine-to-machine (m2m) wireless (WiFi, WiMax, Bluetooth, etc.) Monitoring usage can also be included. Radio level observations may further include monitoring network traffic usage, statistical data, or profiles.

  Sensor level observations may include monitoring magnetic sensors or other sensors to determine the usage environment and / or external environment of mobile device 300. For example, the computing device processor may have a device in the holster (e.g., via a magnet sensor configured to sense a magnet in the holster) or light detected by a camera or light sensor (e.g., May be configured to determine whether it is in the user's pocket (via the amount of For example, active use by the user (e.g. taking a photo or video, sending a message, making a voice call, recording a sound, etc.) that occurs while the mobile device 300 is in the holster Because the activities and functions associated with the mobile device 300 may be in the holster because it may be a sign of a rogue process running on the device (e.g., to track or spy users) Detecting may relate to recognizing suspicious behavior.

  Other examples of sensor level observations related to the usage environment or external environment include detecting near field communication (NFC) signaling, collecting information from a credit card scanner, barcode scanner, or mobile tag reader, Detecting the presence of a universal serial bus (USB) power charging source, detecting that a keyboard or auxiliary device is coupled to the mobile device 300, if the mobile device 300 is another (e.g., via USB) Detect that it is coupled to a computing device, determine whether an LED, flash, flashlight, or light source has been altered or disabled (e.g., maliciously disabling emergency signaling applications, etc.) The speaker or microphone is turned on. Detecting that or is powered on and, detecting the charging or power supply event, the mobile device 300 may include such as by detecting that it is used as a game controller. Sensor level observations include collecting information from medical or healthcare sensors or from scanning the user's body, collecting information from external sensors plugged into USB / audio jacks (e.g., Collecting information from a tactile sensor or tactile sensor (such as via a vibration interface), collecting information about the thermal state of the mobile device 300, and the like may also be included.

  To reduce the number of monitored factors to a manageable level, in one embodiment, the behavior observer module 302 is a small subset of all factors that can contribute to the degradation of the computing device. Or it can be configured to perform a coarse observation by monitoring / observing an initial set of factors. In some embodiments, the behavior observer module 302 can receive an initial set of behaviors and / or factors from a server and / or a component in a cloud service or network. In certain embodiments, an initial set of behaviors / factors may be specified in a machine learning classifier model.

  The behavior observer module 302 can communicate the collected behavior information to the behavior extractor module 304 (eg, via a memory write operation, a function call, etc.). The behavior extractor module 304 may be configured to receive and retrieve collected behavior information and use this information to generate one or more behavior vectors. Each behavior vector can briefly describe the behavior of the device, software application, or process in a value or vector data structure. The vector data structure may contain a series of numbers, each of which is whether the mobile device's camera is being used (e.g., zero or one), how much network traffic from the mobile device Or how much network traffic is being generated by the computing device (for example, 20KB per second), how many Internet messages are being communicated (for example, the number of SMS messages), And / or a mobile device characteristic or behavior, such as any other behavioral information collected by the behavior observer module 302. In some embodiments, the behavior extractor module 304 allows a behavior vector to allow a mobile device system (e.g., behavior analyzer module 306) to quickly recognize, identify, or analyze device behavior. The behavior vector can be generated so as to function as an identifier.

  In an embodiment, the behavior extractor module 304 includes behavior that includes information that can be input to a feature / decision node in a machine learning classifier to generate an answer to a query for the monitored activity or activities. It can be configured to generate a vector.

  In certain embodiments, behavior extractor module 304 may be configured to generate a behavior vector to include execution information. Execution information can be part of a behavior (e.g., a camera used 5 times in 3 seconds by a background process, a camera used 3 times in 3 seconds by a foreground process, etc.) or as part of an irrelevant feature. It may be included in the behavior vector. In some embodiments, the execution state information may be included in the behavior vector as a shadow feature value subvector or data structure. In some embodiments, the behavior vector may store a shadow feature value subvector / data structure in relation to features, activities, and tasks that have associated execution states.

  The behavior extractor module 304 can communicate the generated behavior vector to the behavior analyzer module 306 (eg, via a memory write operation, a function call, etc.). The behavior analyzer module 306 is a non-benign where device behavior contributes (or is likely to contribute) to device degradation over time and / or may cause problems on the device. A behavior vector may be configured to be applied to the classifier model to determine whether it is behavior.

  Each classifier model is a data and / or information structure (e.g., feature vector, behavior vector, component) that can be used by a computing device processor to evaluate a particular feature or embodiment of the behavior of the computing device. It can be a behavioral model including a list). Each classifier model also includes several features, factors, data points, entries, APIs, states, conditions, behaviors, applications, processes, operations, components, etc. within the computing device (collectively referred to herein as `` Criteria for monitoring feature ") may be included. The classifier model may be pre-installed on the computing device, downloaded or received from a network server, generated within the computing device, or any combination thereof. The classifier model can be generated by using crowdsourcing solutions, behavior modeling techniques, machine learning algorithms, and the like.

  Each classifier model may be categorized as a complete classifier model or a concise classifier model. A complete classifier model can be a robust data model that is generated in response to a large training data set that can include thousands of features and billions of entries. A concise classifier model only features / entries that are most relevant to determine if a particular activity is an ongoing critical activity and / or whether a particular mobile device's behavior is not benign Can be a more dedicated data model generated from a reduced data set containing / testing. As an example, the device processor receives a complete classifier model from the network server, generates a learning classifier model in the mobile device based on the complete classifier, and changes the device behavior to benign or non-benign (i.e. May be configured to use a locally generated learning classifier model to classify as either malicious, degraded performance, etc.

  A locally generated concise classifier model is a concise classifier model generated at a computing device. That is, because mobile devices are highly configurable and complex systems, the most important characteristics for determining whether a particular device behavior is non-benign (e.g., malicious or performance degradation) is Can vary in device. In addition, different combinations of features may require monitoring and / or analysis at each device in order for that device to quickly and efficiently determine whether a particular behavior is non-benign. However, the exact combination of features that require monitoring and analysis, as well as the relative priority or importance of each feature or combination of features, is often the specific device in which behavior is to be monitored or analyzed Can only be determined using information obtained from. For these and other reasons, various embodiments can generate a classifier model in the mobile device where the model is used. These local classifier models are specific features that are most important for the device processor to determine if the behavior on that particular device is non-benign (contributes to degraded device performance). It is possible to specify accurately. The local classifier model also allows the device processor to prioritize features that are tested or evaluated according to their relative importance for classifying behavior within that particular device.

  A device-specific classifier model is dedicated data that includes / tests only computing device-specific features / entries that are determined to be most relevant to classifying activities or behaviors within a particular computing device A classifier model including a model.

  An application-specific classifier model is a classifier model that includes a dedicated data model that includes / tests only the features / entries that are most relevant to evaluating a particular software application.

  The user-specific classifier model identifies the user of the device, determines the user's persona, determines whether the device behavior matches the identified user's persona, and the device behavior is identified Testing on the most relevant features / entries to determine if it is consistent with normal use of the device by one of the users or to determine if the user's activity exhibits non-benign device behavior Or a local classifier model that includes a dedicated data model that prioritizes.

  By dynamically generating a user-specific, device-specific, and / or application-specific classifier model locally on a mobile device, various embodiments enable a device processor to monitor its analysis and analysis operations. To determine whether the behavior of a particular software application on and / or within a mobile device is consistent with the known user's personality, habits, or normal usage patterns of that particular device Allows you to devote to the most important decimal features.

  In some embodiments, the behavior analyzer module 306 classifies a behavior as “suspected” when the result of the behavior analysis operation does not provide sufficient information to classify the device behavior as either benign or non-benign. Can be configured to. The behavior analyzer module 306 may be configured to notify the behavior observer module 302 in response to determining that the device behavior is suspicious. In response, the behavior observer module 302 adjusts the granularity of that observation (i.e., the level of detail when the characteristics of the computing device are monitored) and / or received from the behavior analyzer module 306. Change monitored factors or behaviors based on information (e.g., results of real-time analysis operations), generate or collect new or additional behavior information, and new / add for further analysis / classification Can be sent to the behavior analyzer module 306. Such feedback communication between the behavior observer module 302 and the behavior analyzer module 306 identifies the source of behavior that is suspicious or degrades performance until the collective behavior is classified as benign or non-benign. Until the processing or battery consumption threshold is reached, or from further changes, adjustments, or improvements in the granularity of observation, the device processor may not be able to determine the source of behavior that is suspicious or degrades performance Until determined, it is possible for the mobile device 300 to repeatedly improve the granularity of observation (ie, observe more finely or in more detail) or change the observed features / behavior. Such feedback communication also allows mobile device 300 to adjust or modify behavior vectors and classifier models without consuming excessive amounts of processing, memory, or energy resources of the computing device. Become.

  In an embodiment, the behavior analyzer module 306 receives and analyzes information collected by various mobile device subsystems and / or over various time periods, under various circumstances and conditions. Is configured to learn the normal operational behavior of mobile devices and generate models of normal mobile device behavior under various situations / conditions (for example, in the form of a classifier model) obtain. In one embodiment, the behavior analyzer module 306 correlates the collected behavior information or behavior vector with the generated behavior model, performs a behavior analysis operation based on the correlation, and the received observations are learned. It may be configured to determine if it is inconsistent (or inconsistent) with normal operational behavior.

  As a high-level example, the mobile device 300 is using a camera, the mobile device 300 is trying to upload a photo to a server, and the mobile device is in the holster and attached to the user's belt While being done, it can detect (via collected behavior information) that an application on the device has taken a picture. The mobile device 300 can determine whether this detected behavior (eg, use of the camera while in the holster) is acceptable to the user or is a general behavior for the user. This may be accomplished by comparing the detected behavior (eg, generated behavior vector) with the mobile device 300 or the user's past behavior. Because taking photos while in the holster and uploading them to the server is anomalous behavior (as can be determined from the normal behavior observed in the holster situation) In this situation, the computing device will recognize this as inconsistent with the user's normal usage pattern of the computing device and initiate an appropriate response (e.g., shut off the camera, sound an alarm, etc.) Can do.

  In various embodiments, the mobile device 300 can use a network to intelligently and efficiently identify features, factors, and data points that are most relevant to determining whether an activity or behavior is non-benign. It can be configured to operate in conjunction with a server. For example, the device processor receives a complete classifier model from a network server and is a concise classifier model (i.e. ) May be configured to use the received complete classifier model. The device processor can use the complete classifier model to generate a family of concise classifier models of varying levels of complexity (or “conciseness”). The most concise class of concise classifier models (i.e., concise classifier models based on the fewest test conditions) cannot be categorized as either benign or non-benign. It may be applied routinely until a behavior is encountered (categorized as suspicious), at which point a more robust (i.e. less concise) concise classifier model is used in an attempt to classify behavior. Can be applied. Application of a more robust concise classifier model within the family of generated concise classifier models can be applied until a final classification of behavior is achieved. In this way, the device processor can limit the use of the most complete but resource-intensive concise classifier model to situations where a robust classifier model is required to ultimately classify behavior. Balance between efficiency and accuracy.

  In various embodiments, the device processor is configured to generate a concise classifier model by converting the finite state machine representation or representation contained within the complete classifier model into a boosted decision stock. obtain. The device processor prunes or screens the complete set of boosted decision strains based on the user's persona information or user-specific device characteristics, and the boosted decision strain included in the complete classifier model. A concise classifier model containing the subset can be generated. The device processor can then use a concise classifier model to intelligently monitor, analyze, and / or classify device behavior.

  A boosted decision strain has exactly one node (and therefore one test question or test condition) and a weight value, and is therefore well suited for use in binary classification of data / behavior. It is a level judgment tree. That is, applying a behavior vector to a boosted decision stock results in a binary answer (eg, Yes or No). For example, if the question / condition being tested by the boosted stock is "Short Message Service (SMS) transmission frequency is less than x times per minute", then the value of "3" is boosted stock Applying to yields either a “yes” answer (for “less than three” SMS transmissions) or a “no” answer (for “three or more” SMS transmissions). The boosted reference strain is efficient because it is very simple and fundamental (and therefore does not require significant processing resources). Boosted decision stocks are also highly parallelizable, so many stocks can be applied or tested in parallel / simultaneously (eg, by multiple cores or processors in a computing device).

  FIG. 4A illustrates a method 400 for detecting and responding to false UI events according to an embodiment. The method 400 may be performed by a device processor of a mobile computing device or a resource constrained computing device. At block 402, the device processor may receive raw data from one or more device drivers of the computing device. At block 404, the device processor may receive user interaction (UI) information from the high-level operating system (HLOS) of the computing device. At block 406, the device processor may compare the raw data received from the device driver with user interaction event information received from the HLOS to generate a first analysis result.

  At decision block 408, the device processor may use the generated first analysis result to determine whether a user interaction (UI) event correlates with the user interaction. This determination can evaluate whether the raw data received from one or more device drivers matches or otherwise correlates with the UI events reported to / by HLOS. If the device driver determines that the raw data does not correlate with (or does not match) the UI information from HLOS, this may indicate that the received UI event is false and the computing device has been detected UI events can be classified as fake UI events.

  In response to the determination that the UI event correlates with the user interaction, and thus the determination that the UI event is not a fake UI event (i.e., decision block 408 = “Yes”), the device processor performs a second analysis at block 410. A behavior vector can be applied to the classifier model to produce a result. At block 412, the device processor can use the second analysis result to determine whether the device behavior is non-benign. As part of the operations of blocks 410 and 412, the device processor may perform any or all of the operations discussed above with reference to FIG.

  In response to a determination that the UI event does not correlate with user interaction, and thus a determination that the UI event is a fake UI event (i.e., decision block 408 = “No”), the device processor, at block 414, returns a fake UI Events can be reported to the behavioral security system of the computing device. At block 414, the device processor may classify the device behavior as non-benign (eg, by a behavior-based security system). Thus, in certain embodiments, a behavior-based security system may be configured to classify all software application programs that are determined to be associated with fake UI events as non-benign.

  FIG. 4B illustrates another method 420 for detecting and responding to false UI events, according to another embodiment. The method 420 may be performed by a device processor of a mobile computing device or resource constrained computing device configured with processor-executable instructions for performing the operations of the method. At block 422, the device processor may compare the raw data received from one or more device drivers with the UI information received from HLOS. At decision block 424, the device processor can use the comparison result to determine whether the UI event correlates with the user interaction and, therefore, is a fake UI event. In response to a determination that the UI event correlates with user interaction, and thus a determination that the UI event is not a fake UI event (i.e., decision block 424 = `` Yes ''), the device processor, in block 426, determines the behavior vector, An analysis result can be generated by applying it to a classifier model that includes a decision node that tests conditions relating to user interaction. At block 428, the device processor may use the analysis results to determine whether the device behavior (eg, software application activity) is non-benign.

  In response to a determination that the UI event does not correlate with user interaction, and therefore a determination that the UI event is a fake UI event (i.e., decision block 424 = “No”), the device processor, in block 430, generates a fake UI Events can be reported to a behavior-based security system. At block 432, the device processor may generate an analysis result by applying the behavior vector to a classifier model that does not include any decision nodes that test conditions for user interaction at block 426. At block 428, the analysis results are used to determine whether the device behavior (eg, software application activity) is non-benign.

  Various embodiments may be used to recognize or at least identify the potential for impaired user input sensor device drivers. Such capabilities can be useful for recognizing when malware has been compromised or when a fake UI event has been inserted into a user input device or device driver for a sensor. For example, if the device driver for the touch screen is compromised, the raw data received from the device driver (e.g., at block 402) may itself be false, in this case comparing UI information from HLOS May not be enough to detect this level of attack.

  To address this possibility, FIG. 4C shows another method 450 for detecting and responding to corrupted user input device drivers, according to another embodiment. Method 450 may be performed by a device processor of a mobile computing device or resource-constrained computing device and may be performed in addition to or as an alternative to any of methods 400 and 420 described above. At block 452, the device processor may compare the raw data received from one or more user input sensors with the data received from the input sensor device driver. For example, the device processor can receive raw output data provided by the touch screen and compare the data with data received from the touch screen device driver.

  At decision block 454, the device processor can use the comparison results to determine whether user input sensor data correlates with corresponding device driver data. This determination can take into account sensor data and device driver data in different formats. For example, the device processor determines that the device driver has output the data to be received based on the raw sensor data, and then compares the received device driver data with the expected data and there is a match To determine whether the raw sensor data can be transformed or analyzed in the same manner as the device driver. For example, at decision block 454, the device processor taps into the output data stream provided by the touch screen, processes the touch screen data stream to determine the appropriate output from the touch screen device driver, and then The determined appropriate output can be compared to the raw data generated by the touch screen device driver.

  In response to determining that the raw UI sensor data correlates with the raw data received from the device driver for that sensor (i.e., decision block 454 = “Yes”), the device processor, as described above, blocks 426 Thus, an analysis result can be generated by applying the behavior vector to a classifier model including a decision node for testing a condition relating to user interaction.

  In response to determining that the raw UI sensor data does not correlate with the raw data received from the device driver for that sensor (i.e., decision block 454 = “No”), the device processor at block 456, the device driver is Can be reported to a behavior-based security system. In some embodiments, the absence of raw sensor data correlation with device driver data may be sufficient to determine that malware or similar unacceptable conditions exist, in which case against behavior-based security systems. The reporting may be sufficient to classify device behavior (eg, software application activity) as non-benign. However, in some embodiments, the comparison of raw sensor data to device driver data may not be sufficient to reliably determine that the device driver has been compromised, which may indicate that the data mismatch is Because of noise in the connection between the sensor and the device driver, the device driver being a different version than the one emulated by the device processor at decision block 454, and so on. Thus, in such an embodiment, the report to the security system may only be that the device driver may be compromised, in order to classify the device behavior as benign or non-benign (e.g. , In blocks 432 and 428) may require further analysis by a behavior-based security system.

  At block 432, the device processor may generate an analysis result by applying the behavior vector to a classifier model that does not include any decision nodes that test conditions for user interaction, as described above. In addition to avoiding being fooled by false UI events initiated at the device driver level, this analysis avoids false positives that can result from malfunctions in or between UI sensors and sensor device drivers be able to.

  At block 428, the device processor analyzes results from either block 426 or 432 to determine whether the device behavior (e.g., software application activity) is non-benign, as described above. Can be used.

  FIG. 5 illustrates an embodiment method 500 that uses a family of concise classifier models for classifying the device behavior of a computing device. Method 500 may be performed by a device processor of a mobile computing device or resource constrained computing device configured with processor-executable instructions for performing the operations of the method.

  At block 502, the device processor may perform observations and collect behavior information from various components measured at various levels of the mobile device system. In certain embodiments, this may be accomplished via the behavior observer module 302 discussed above with reference to FIG. At block 504, the device processor may generate behavior vectors that characterize the collected behavior information and / or the behavior of the mobile device. Also, at block 504, the device processor is received from the network server to generate a concise classifier model, or a family of concise classifier models with varying levels of complexity (or “conciseness”). A complete classifier model can be used. To accomplish this, the device processor screens the family of boosted decision strains included in the complete classifier model to include a reduced number of boosted decision strains and / or limited A simple classifier model can be generated that evaluates a large number of test conditions. In certain embodiments, one or more of the concise classifier models may be user-specific classifier models.

  At block 506, the device processor is the most concise classifier within the family of concise classifier models that have not yet been evaluated or applied by the mobile device (i.e., the state, feature, behavior, or Model based on conditions) can be selected. In certain embodiments, this may be accomplished by the device processor selecting the first classifier model in the ranked list of classifier models. At block 508, the device processor may apply the collected behavior information or behavior vector to each boosted decision stock in the selected concise classifier model. Since the boosted stock is a binary decision and a concise classifier model is generated by selecting many binary decisions based on the same test conditions, it is boosted within the concise classifier model. The process of applying the behavior vector to the judgment stock can be executed in parallel operation. Alternatively, the behavior vector may be truncated or filtered to just include a limited number of test condition parameters contained within a concise classifier model, thereby calculating when applying the model The amount is further reduced.

  At block 510, the device processor can calculate or determine a weighted average of the results of applying the collected behavior information to each boosted decision strain in the concise classifier model. At block 512, the device processor may compare the calculated weighted average with a threshold value. At decision block 514, the device processor may determine whether the result of this comparison and / or the result generated by applying the selected concise classifier model is suspicious. For example, the device processor can determine whether these results can be used to classify behavior as either malicious or benign with high confidence, otherwise Treat as suspicious.

  If the device processor determines that the result is suspicious (e.g., decision block 514 = “Yes”), the device processor repeats the operations in blocks 506-512 to behave maliciously or benign with high confidence A stronger (ie, less concise) classifier model that evaluates more device conditions, features, behaviors, or conditions can be selected and applied. If the device processor determines that the result is not suspicious (e.g., decision block 514 = “No”), such as by determining that the behavior can be classified as either malicious or benign with high confidence, In block 516, the device processor may use the result of the comparison generated in block 512 to classify the behavior of the mobile device as benign or potentially malicious.

  In an alternative embodiment method, the operations described above sequentially select boosted decision strains that do not yet exist in the concise classifier model, and the same mobile device state, characteristics as the selected decision strain Identify all other boosted test strains that depend on behavior or conditions (and therefore can be applied based on one decision result) and depend on the same mobile device state, characteristics, behavior or conditions This can be achieved by including all selected other boosted decision strains selected in a concise classifier model and repeating the process a number of times equal to the determined number of test conditions. Limiting the number of times this process is performed is concise because all boosted strains that depend on the same test conditions as the selected boosted strain are added to the concise classifier model each time. This limits the number of test conditions included in the classifier model.

  FIG. 6 illustrates an example method 600 suitable for generating a decision tree / classifier suitable for use in accordance with various embodiments. Method 600 may be performed by a device processor of a mobile computing device or resource constrained computing device configured with processor-executable instructions for performing the operations of the method. At block 602, the device processor generates and / or executes a decision tree / classifier, collects training samples by execution of the decision tree / classifier, and creates a new classifier model (h1 (x)) based on the training samples. Can be generated. Training samples may include information collected from previous observations or analyzes of mobile device behavior, software applications, or processes on the mobile device. Training samples and / or new classifier models (h1 (x)) are based on the type of questions or test conditions included in the previous classifier and / or the previous data / behavior model or classifier run / It can be generated based on accuracy or performance characteristics collected from the application.

  At block 604, the device processor weights the entries misclassified by the generated decision tree / classifier (h1 (x)) to generate a second new tree / classifier (h2 (x)). Can be boosted (or increased). In some embodiments, training samples and / or a new classifier model (h2 (x)) may be generated based on the error rate of the previous execution or use of the classifier (h1 (x)). In some embodiments, the training sample and / or the new classifier model (h2 (x)) is based on attributes determined to have contributed to the error rate or misclassification of data points in previous runs or uses of the classifier. Can be generated.

In certain embodiments, misclassified entries may be weighted based on their relative accuracy or validity. In operation 606, the processor generates a third new tree / classifier (h3 (x)) for the entry misclassified by the generated second tree / classifier (h2 (x)). The weight can be boosted (or increased). At operation 608, the operations of 604-606 may be repeated to generate a number “t” of new trees / classifiers (h _t (x)).

By boosting or increasing the weight of entries misclassified by the first decision tree / classifier (h1 (x)), the second tree / classifier (h2 (x)) It is possible to more accurately classify entries misclassified by the decision tree / classifier (h1 (x)), but how many of the entries correctly classified by the first decision tree / classifier (h1 (x)) May be misclassified. Similarly, the third tree / classifier (h3 (x)) can more accurately classify entries misclassified by the second decision tree / classifier (h2 (x)), but Some of the entries correctly classified by the second decision tree / classifier (h2 (x)) may be misclassified. In other words, to produce a family of trees / classifier _{h1 (x) ~h t (x} ) , there is not caused the system to converge as a whole, a number of decision trees / classifier that may be executed in parallel Bring.

  FIG. 7 illustrates an example method 700 for performing dynamic and adaptive observations according to an embodiment. Method 700 may be performed by a device processor of a mobile computing device or resource-constrained computing device configured with processor-executable instructions for performing the operations of the method. At block 702, the device processor can perform a coarse observation by monitoring / observing a subset of a number of factors, behaviors, and activities that can contribute to the degradation of the mobile device. At block 703, the device processor may generate a behavior vector characterizing the behavior of the coarse observation and / or the mobile device based on the coarse observation. At block 704, the device processor may identify subsystems, processes, and / or applications associated with the coarse observation that may potentially contribute to mobile device degradation. This can be accomplished, for example, by comparing information received from multiple sources with contextual information received from sensors of the mobile device. At block 706, the device processor may perform a behavior analysis operation based on the coarse observation.

  At decision block 708, the device processor can determine whether suspicious behavior or potential problems can be identified and corrected based on the results of the behavior analysis. When the device processor determines that suspicious behavior or potential problems can be identified and corrected based on the results of the behavior analysis (i.e., decision block 708 = “Yes”), at block 718, the processor corrects the behavior And the process can return to block 702 to perform additional coarse observations.

  When the device processor determines that suspicious behavior or potential problems cannot be identified and / or corrected based on the results of the behavior analysis (i.e., decision block 708 = “No”), at decision block 709, the device processor , Can determine if there is a potential problem. In one embodiment, the device processor calculates the probability that the mobile device encounters a potential problem and / or participates in suspicious behavior, and whether the calculated probability is greater than a predetermined threshold Can determine whether there is a potential problem. The device processor determines that the calculated probability is not greater than a predetermined threshold and / or that suspicious behavior or potential problems exist and / or cannot be detected (i.e., decision block) 709 = “No”), the processor can return to block 702 to perform additional coarse observations.

  When the device processor determines that suspicious behavior or potential problems exist and / or may be detectable (ie, decision block 709 = “Yes”), at block 710, the device processor is identified Deeper logging / observation or final logging can be performed on a subsystem, process, or application. At block 712, the device processor may perform deeper and more detailed observations on the identified subsystem, process, or application. At block 714, the device processor may perform further and / or deeper behavior analysis based on deeper and more detailed observations. At decision block 708, the device processor can again determine whether suspicious behavior or potential problems can be identified and corrected based on the results of the deeper behavior analysis. When the device processor determines that suspicious behavior or potential problems cannot be identified and corrected based on deeper behavior analysis results (i.e., decision block 708 = “No”), the level of detail identifies the problem The processor can repeat the operations of blocks 710-714 until it is fine enough to do so, or it can be determined that adding the details does not identify the problem or it does not exist .

  When the device processor determines that suspicious behavior or potential problems can be identified and corrected based on the results of the deeper behavior analysis (i.e., decision block 708 = “Yes”), at block 718, the device processor An action can be performed to correct the behavior, and the processor can return to block 702 to perform additional actions.

  In certain embodiments, as part of blocks 702-718 of method 700, the device processor may determine suspicious behavior from limited coarse observations, and dynamically determine behavior for more detailed observations. In order to dynamically determine the exact level of detail required for observation, a real-time behavior analysis of the system behavior can be performed. This allows the device processor to efficiently identify problems and prevent problems from occurring without having to use large amounts of processor, memory, or battery resources on the device.

  Various embodiments can be implemented by using behavioral analysis and / or machine learning techniques (rather than authorization, policy, or rule-based techniques) to monitor and analyze the collective behavior of selected groups of software applications. To improve the solution. Modern computing devices are highly configurable and complex systems, and the factors that are most important for determining whether a software application is collaborating can vary from device to device, so behavioral analysis or machine learning techniques Use is important. Furthermore, different combinations of device features / factors may require analysis at each device in order for that device to determine whether the software application is colluding. In addition, the exact combination of features / factors that often requires monitoring and analysis is obtained from the particular computing device on which the one or more activities are performed when the one or more activities are in progress It can only be determined using information. For these or other reasons, an existing solution is a multiple software solution in a computing device that does not consume a significant amount of processing, memory, or power resources of the computing device while the behavior is in progress. It is not sufficient to monitor, detect and characterize the collective behavior of software or relationships between software applications in real time.

  Various embodiments, including those discussed above with reference to FIGS. 2-7, may be implemented on various computing devices configured with processor-executable instructions, an example of which is a smartphone In the form shown in FIG. Smartphone 800 can include a processor 802 coupled to an internal memory 804, a display 812, and a speaker 814. In addition, the smartphone 800 can include a wireless data link coupled to the processor 802 and / or an antenna for sending and receiving electromagnetic radiation that can be connected to the mobile phone transceiver 808. Smartphone 800 typically also includes a menu selection button or rocker switch 820 for receiving user input.

  The typical smartphone 800 also digitizes the sound received from the microphone into data packets suitable for wireless transmission, decodes the received sound data packet, and generates an analog signal that is fed into the speaker to generate the sound. A speech encoding / decoding (codec) circuit 806. Also, one or more of processor 802, wireless transceiver 808, and codec 806 may include digital signal processor (DSP) circuitry (not separately shown).

  The processor 802 can be any programmable microprocessor, microcomputer, or one that can be configured with processor-executable instructions (applications) to perform various functions and operations, including the operations of the various embodiments described below. Or it may be multiple multiprocessor chips. In some mobile devices, multiple processors 802 may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications can be stored in internal memory 804 before they are accessed and loaded into processor 802. The processor 802 may include internal memory sufficient to store application software instructions. In various embodiments, the processor 802 may be a device processor, a processing core, or a SOC (such as the example SOC 100 shown in FIG. 1). In some embodiments, the smartphone 800 may include a SOC, and the processor 802 may be one of the processors included in the SOC (such as one of the processors 102, 104, 106, 108, 110 shown in FIG. 1). May be one.

  Various embodiments include means for comparing raw data received from a user input device with user interaction event information to generate analysis results, and user interaction (UI) events correlated with a user of the computing device. And a means for using the generated analysis results to determine whether to do so. In some embodiments, the means for comparing the raw data received from the user input device with the user interaction event information to generate the analysis result comprises: Means for comparing with the interaction information received from. In some embodiments, the computing device may further include means for classifying the software application activity as non-benign in response to determining that the UI event does not correlate with a user of the computing device. In some embodiments, the computing device is generated in response to a means for generating a behavior vector characterizing the activity of the software application and a determination that the UI event does not correlate with the user of the computing device. In order to determine whether the behavior vector is applied to a classifier model that includes a decision node that evaluates whether there is a UI event corresponding to the activity, and whether the activity of the software application is non-benign. Means for using the result of applying the generated behavior vector to the classifier model. In some embodiments, the computing device responds to the activity in response to determining a means for generating a behavior vector that characterizes the activity of the software application and a UI event does not correlate with the user of the computing device. A means for selecting a classifier model that does not include a decision node that tests whether there are UI events to be performed, and a generated behavior vector to the selected classifier model to generate additional analysis results It may further comprise means for applying and means for using the generated additional analysis results to determine if the activity of the software application is non-benign. In some embodiments, the computing device includes means for selecting a family of robust classifier models in response to a determination that the UI event does not correlate with a user of the computing device, and the activity of the software application Means for applying a plurality of behavior vectors to a selected family of robust classifier models to determine whether is non-benign.

  The terms “component”, “module” and the like used in this application are not limited to hardware, firmware, a combination of hardware and software, software configured to perform a specific operation or function. Or computer-related entities such as running software. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer. By way of illustration, both an application running on a computing device and the computing device can be referred to as a component. One or more components may be present in a process and / or thread of execution, one component may be localized on one processor or core, and / or two or more processors Or it may be distributed in the core. In addition, these components can execute from various non-transitory computer readable media having various instructions and / or data structures stored thereon. Components include local and / or remote processes, function calls or procedure calls, electronic signals, data packets, memory reads / writes, and other known network, computer, processor, and / or process related communication methods Can communicate with each other.

  Computer program code or "program code" for execution on a programmable processor to perform the operations of the various embodiments includes C, C ++, C #, Smalltalk, Java (registered trademark), JavaScript (registered trademark), It may be written in a high level programming language such as Visual Basic, structured query language (eg, Transact-SQL), Perl, or various other programming languages. As used in this application, program code or a program stored on a computer-readable storage medium may refer to machine language code (such as object code) whose format is understandable by a processor.

  Many mobile computing device operating system kernels are organized in user space (if unprivileged code executes) and in kernel space (if privileged code executes). This separation requires that the code that is part of the kernel space needs to be licensed under the General Public License (GPL), while the code that runs in user space does not have to be GPL licensed. And particularly important in other GPL environments. It should be understood that the various software components / modules discussed herein may be implemented in either kernel space or user space unless explicitly stated otherwise.

  The above method descriptions and process flow diagrams are provided merely as illustrative examples and do not require or imply that the operations of the various embodiments must be performed in the order presented. . As will be appreciated by those skilled in the art, the order of operations in the above-described embodiments can be executed in any order. The terms “subsequent”, “next”, “next”, etc. do not limit the order of operation, and these terms are merely used to guide the reader to explain the method. In addition, any singular reference to an element in a claim, such as using the article “a”, “an”, or “the” should not be construed as limiting the element to the singular.

  Various exemplary logic blocks, modules, circuits, and algorithm operations described with respect to the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in a variety of ways for each particular application, but such implementation decisions should not be construed as causing deviations from the scope of the present invention.

  The hardware used to implement the various exemplary logic, logic blocks, modules, and circuits described with respect to the embodiments disclosed herein includes general purpose processors, digital signal processors (DSPs), and application specific integrations. Circuit (ASIC), Field Programmable Gate Array (FPGA) or other programmable logic device, individual gate or transistor logic, individual hardware components, or any of them designed to perform the functions described herein Can be implemented or implemented using a combination of A general purpose processor may be multiprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, eg, a DSP and multiprocessor combination, multiple multiprocessors, one or more multiprocessors in conjunction with a DSP core, or any other such configuration. obtain. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function.

  In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more processor-executable instructions or code on a non-transitory computer-readable storage medium or non-transitory processor-readable storage medium. The operations of the methods or algorithms disclosed herein are embodied in processor-executable software modules that may be in the form of stored processor-executable software instructions on a non-transitory computer-readable storage medium or processor-readable storage medium. obtain. The non-transitory computer readable storage medium or non-transitory processor readable storage medium may be any storage medium that may be accessed by a computer or processor. By way of example, and not limitation, such non-transitory computer readable storage media or non-transitory processor readable storage media may be RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other It may include a magnetic storage device or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. As used herein, a disk and a disc are a compact disc (CD), a laser disc (registered trademark) (disc), an optical disc (disc), a digital versatile disc (disc). (DVD), floppy disk, and Blu-ray disc, which usually reproduces data magnetically, and a disc uses a laser to read data. Reproduce optically. Combinations of the above are also included within the scope of non-transitory computer readable storage media and processor readable storage media. In addition, the operation of the method or algorithm may be incorporated into a computer program product, one or any combination of code and / or instructions on a non-transitory processor readable medium and / or non-transitory computer readable medium or May exist as a set.

  The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Accordingly, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein. It is.

100 system on chip (SOC)
102 Digital signal processor (DSP), heterogeneous processor, processor, DSP
104 modem processor, heterogeneous processor, processor
106 Graphics processor, heterogeneous processor, processor
108 Application processor, heterogeneous processor, processor
110 coprocessor, processor
112 memory elements
114 Analog and custom circuits
116 System components / resources
118 clock
120 voltage regulator
124 Interconnect / Bus Module
200 computing devices
202 Sensors and hardware components
204 Device driver module
206 Operating system
208 software application programs
210 Malicious software application programs, software application programs
212 Fake UI event detection module
214 Behavior-based security module
216 Driver measurement module
218 Operating system measurement module
220 Activity Log
300 mobile devices
302 Behavior observation module, module
304 Behavior extractor module, module
306 Behavior analyzer module, module
308 Actuator module, module
400 methods
420 methods
450 methods
500 methods
600 methods
700 methods
800 smartphone
802 processor
804 internal memory
806 Audio encoding / decoding (codec) circuit, codec
808 Wireless data link and / or mobile phone transceiver, wireless traffic
812 display
814 Speaker
820 Menu selection button or rocker switch

Claims (30)

A method of analyzing the activity of a software application running on a computing device, comprising:
Comparing raw data received from a user input device of the computing device with user interaction event information received within the computing device to generate an analysis result;
Using the analysis result to determine whether a user interaction event correlates with a user of the computing device. The raw data received from the user input device includes raw data received from a device driver;
The method of claim 1, wherein the user interaction event information received within the computing device includes interaction information received from a high-level operating system of the computing device.   3. The method of claim 2, further comprising classifying the activity of the software application as non-benign in response to determining that the user interaction event does not correlate with a user of the computing device. Generating a behavior vector characterizing the activity of the software application;
In response to a determination that the user interaction event does not correlate with a user of the computing device, the behavior vector is a classifier model that includes a decision node that evaluates whether a user interaction event corresponding to the activity exists. Applying steps;
3. The method of claim 2, further comprising: using a result of applying the behavior vector to the classifier model to determine whether the activity of the software application is non-benign. Generating a behavior vector characterizing the activity of the software application;
Selecting a classifier model that does not include a decision node that tests whether a user interaction event corresponding to the activity exists in response to a determination that the user interaction event does not correlate with a user of the computing device; ,
Applying the behavior vector to the selected classifier model to generate additional analysis results;
3. The method of claim 2, further comprising: using the additional analysis result to determine whether the activity of the software application is non-benign. Selecting a family of robust classifier models in response to determining that the user interaction event does not correlate with a user of the computing device;
Applying a plurality of behavior vectors to the selected family of robust classifier models to determine whether the activity of the software application is non-benign. Method. Received from the first sensor to determine whether the raw data received from the first sensor of the computing device matches the raw data received from the second sensor of the computing device. Comparing the raw data with the raw data received from the second sensor,
The step of comparing the raw data received from the user input device of the computing device with the user interaction event information received within the computing device to generate the analysis result comprises the first step. 2. The method of claim 1, wherein the method is performed in response to a determination that the raw data received from a second sensor is consistent with the raw data received from the second sensor.   The comparing the raw data received from the first sensor with the raw data received from the second sensor comprises comparing a behavior vector application result with a classifier model. The method according to 7. The raw data received from the user input device comprises raw data received from a user input sensor;
The user interaction event information received within the computing device includes data received from a device driver for the user input sensor;
The step of using the analysis result to determine whether the user interaction event correlates with a user of the computing device, wherein the raw data received from the user input sensor is for the user input sensor. The method of claim 1, comprising determining that the user interaction event does not correlate with a user of the computing device in response to not correlating with the data received from the device driver. The user input sensor includes a touch screen;
The method of claim 9, wherein the device driver comprises a touch screen device driver. The method of claim 9, further comprising classifying the activity of the software application as non-benign in response to determining that the user interaction event does not correlate with a user of the computing device. Generating a behavior vector characterizing the activity of the software application;
In response to determining that the user interaction event does not correlate with a user of the computing device, the behavior vector is applied to a classifier model that does not include a decision node that evaluates a condition for user interaction with the computing device. Steps,
10. The method of claim 9, further comprising: using a result of applying the behavior vector to the classifier model to determine whether the activity of the software application is non-benign. A computing device,
Means for comparing raw data received from a user input device with user interaction event information to generate an analysis result;
A computing device comprising: means for using the analysis result to determine whether a user interaction event (UI) correlates with a user of the computing device.   The means for comparing the raw data received from the user input device with the user interaction event information to generate the analysis result receives the raw data received from a device driver from a high-level operating system. 14. A computing device according to claim 13, comprising means for comparing with the interaction information provided.   15. The computing device of claim 14, further comprising means for classifying software application activity as non-benign in response to determining that the user interaction event does not correlate with a user of the computing device. Means for generating a behavior vector characterizing the activity of the software application;
In response to a determination that the user interaction event does not correlate with a user of the computing device, the behavior vector is a classifier model that includes a decision node that evaluates whether a user interaction event corresponding to the activity exists. Means for applying;
15. The computing of claim 14, further comprising: means for using a result of applying the behavior vector to the classifier model to determine whether the activity of the software application is non-benign. device. Means for generating a behavior vector characterizing the activity of the software application;
In response to determining that the user interaction event does not correlate with a user of the computing device, for selecting a classifier model that does not include a decision node that tests whether a user interaction event corresponding to the activity exists. Means,
Means for applying the behavior vector to the selected classifier model to generate additional analysis results;
15. The computing device of claim 14, further comprising: means for using the additional analysis results to determine whether the activity of the software application is non-benign. Means for selecting a family of robust classifier models in response to determining that the user interaction event does not correlate with a user of the computing device;
Means for applying a plurality of behavior vectors to the selected family of robust classifier models to determine whether the activity of the software application is non-benign. Computing device. A computing device,
A processor, the processor comprising:
Comparing raw data received from a user input device with user interaction event information to generate analysis results;
Using processor executable instructions to perform operations including using the analysis results to determine if a user interaction (UI) event correlates with a user of the computing device.
Computing device.   The processor compares the raw data received from the user input device with the user interaction event information to generate the analysis result, and the raw data received from the device driver is a high-level operating system. The computing device of claim 19, wherein the computing device is comprised of processor-executable instructions for performing an operation that includes comparing with interaction information received from the computer.   Processor-executable instructions for performing operations such that the processor further comprises classifying software application activity as non-benign in response to determining that the user interaction event does not correlate with a user of the computing device. The computing device of claim 20, comprising: The processor is
Generating a behavior vector characterizing the activity of the software application;
In response to a determination that the user interaction event does not correlate with a user of the computing device, the behavior vector is a classifier model that includes a decision node that evaluates whether a user interaction event corresponding to the activity exists. Applying,
Processor-executable instructions for performing an operation further comprising: using a result of applying the behavior vector to the classifier model to determine whether the activity of the software application is non-benign. 21. The computing device of claim 20, wherein the computing device is configured. The processor is
Generating a behavior vector characterizing the activity of the software application;
In response to determining that the user interaction event does not correlate with a user of the computing device, selecting a classifier model that does not include a decision node that tests whether a user interaction event corresponding to the activity exists. ,
Applying the behavior vector to the selected classifier model to generate additional analysis results;
The processor executable instructions for performing operations further comprising using the additional analysis results to determine whether the activity of the software application is non-benign. A computing device as described in. The processor is
Selecting a family of robust classifier models in response to determining that the user interaction event does not correlate with a user of the computing device;
A processor executable for performing operations further comprising applying a plurality of behavior vectors to the selected family of robust classifier models to determine whether the activity of the software application is non-benign The computing device of claim 19, comprising the instructions. A non-transitory computer readable storage medium storing processor-executable instructions configured to cause a processor of a computing device to perform an operation, the operation comprising:
Comparing raw data received from a user input device with user interaction event information to generate analysis results;
Using the analysis result to determine whether a user interaction (UI) event correlates with a user of the computing device.   The stored processor-executable instructions compare the raw data received from the user input device with the user interaction event information when the raw data received from a device driver is received from a high-level operating system. 26. The non-transitory computer readable storage medium of claim 25, wherein the non-transitory computer readable storage medium is configured to cause the processor to perform an action that includes comparing to other interactive information.   The processor includes operations such that the stored processor executable instructions further include classifying software application activity as non-benign in response to determining that the user interaction event does not correlate with a user of the computing device. 27. The non-transitory computer readable storage medium of claim 26, wherein the non-transitory computer readable storage medium is configured to be executed by a computer. The stored processor executable instructions are
Generating a behavior vector characterizing the activity of the software application;
In response to a determination that the user interaction event does not correlate with a user of the computing device, the behavior vector is a classifier model that includes a decision node that evaluates whether a user interaction event corresponding to the activity exists. Applying,
Configured to cause the processor to perform an operation further comprising: using a result of applying the behavior vector to the classifier model to determine whether the activity of the software application is non-benign. 28. The non-transitory computer readable storage medium of claim 27. The stored processor executable instructions are
Generating a behavior vector characterizing the activity of the software application;
In response to determining that the user interaction event does not correlate with a user of the computing device, selecting a classifier model that does not include a decision node that tests whether a user interaction event corresponding to the activity exists. ,
Applying the behavior vector to the selected classifier model to generate additional analysis results;
28. The system of claim 27, further configured to cause the processor to perform an operation further comprising: using the additional analysis result to determine whether the activity of the software application is non-benign. Non-transitory computer-readable storage medium. The stored processor executable instructions are
Selecting a family of robust classifier models in response to determining that the user interaction event does not correlate with a user of the computing device;
Causing the processor to perform an operation further comprising: applying a plurality of behavior vectors to the selected family of robust classifier models to determine if the activity of the software application is non-benign. 27. The non-transitory computer readable storage medium of claim 26, configured.

Images