MOBILE APPLICATION MANAGEMENT
Code of a particular application is analyzed against a semantic model of a software development kit of a particular platform. The semantic model associates a plurality of application behaviors with respective application programming interface (API) calls of the particular platform. A set of behaviors of the particular application is identified based on the analysis of the code and a particular one of the set of behaviors is identified as an undesired behavior. The particular application can be automatically modified to remediate the undesired behavior. The particular application can be assigned to one of a plurality of device modes, and access to the particular application on a user device can be based on which of the plurality of device modes is active on the user device.
This disclosure relates in general to the field of computer security and, more particularly, to security of mobile devices.
The distribution and use of mobile devices, such as smart phones, PDAs, laptops, netbooks, and tablets have grown at a rapid pace. Further, adoption of such devices is also expanding and number overtaking that of desktop computers and feature phones in some developed markets. The sophistication of the operating systems and the hardware capabilities of mobile devices is also increasing and, in some cases, outpacing the features sets and functionality of traditional computers. For example, modem mobile devices can possess such varied sensors and subsystems as location sensors like global positioning systems (GPS), accelerometers, gyroscopes, near field communication (NFC), etc. that are ordinarily not included on traditional devices. Adding to this the always connected nature of some mobile devices and the tendency for their owners to constantly carry the devices, mobile devices have become attractive targets for malware developers, hackers, and other malicious actors. Further, “app stores” and other open marketplaces have enabled the development of tens of thousands of applications (or “apps”) that have been developed for such devices, including device platforms such as Google Android™, iOS™, Windows™, etc., with some of these applications being of questionable quality and purpose.
BRIEF DESCRIPTION OF THE DRAWINGS
Like reference numbers and designations in the various drawings indicate like elements.
In general, “servers,” “clients,” “client devices,” “user devices,” “mobile devices,” “computing devices,” “network elements,” “hosts,” “system-type system entities,” and “systems,” including system devices in example computing environment 100 (e.g., 105, 110, 115, 120, 125, 140, 145, etc.), can include electronic computing devices operable to receive, transmit, process, store, or manage data and information associated with the computing environment 100. As used in this document, the term “computer,” “processor,” “processor device,” or “processing device” is intended to encompass any suitable processing device. For example, elements shown as single devices within the computing environment 100 may be implemented using a plurality of computing devices and processors, such as server pools including multiple server computers. Further, any, all, or some of the computing devices may be adapted to execute any operating system, including Linux™, UNIX™, Microsoft Windows™, Apple OS™, Apple iOS™, Google Android™, Windows Server™, etc., as well as virtual machines adapted to virtualize execution of a particular operating system, including customized and proprietary operating systems.
Further, servers, user devices, network elements, systems, and other computing devices can each include one or more processors, computer-readable memory, and one or more interfaces, among other features and hardware. Servers can include any suitable software component or module, or computing device(s) capable of hosting and/or serving software applications and services (e.g., personal safety systems, services and applications of server 105, etc.), including distributed, enterprise, or cloud-based software applications, data, and services. For instance, in some implementations, an application management server 105, application servers 140, information servers 145, or other subsystems of computing system 100 can be comprised at least in part by cloud-implemented systems configured to remotely host, serve, or otherwise manage data, software services and applications interfacing, coordinating with, dependent on, or otherwise used by other services and devices in system 100. In some instances, a server, system, subsystem, or computing device can be implemented as some combination of devices that can be hosted on a common computing system, server, server pool, or cloud computing environment and share computing resources, including shared memory, processors, and interfaces.
User, endpoint, or client computing devices (e.g., 110, 115, 120, 125, etc.) can include traditional and mobile computing devices, including personal computers, laptop computers, tablet computers, smartphones, personal digital assistants, feature phones, handheld video game consoles, desktop computers, internet-enabled televisions, and other devices designed to interface with human users and capable of communicating with other devices over one or more networks (e.g., 130). Computer-assisted, or “smart,” appliances can include household and industrial devices and machines that include computer processors and are controlled, monitored, assisted, supplemented, or otherwise enhance the functionality of the devices by the computer processor, other hardware, and/or one or more software programs executed by the computer processor. Computer-assisted appliances can include a wide-variety of computer-assisted machines and products including refrigerators, washing machines, automobiles, HVAC systems, industrial machinery, ovens, security systems, and so on.
Attributes of user computing devices, computer-assisted appliances, servers, and computing devices generally, can vary widely from device to device, including the respective operating systems and collections of software programs loaded, installed, executed, operated, or otherwise accessible to each device. For instance, computing devices can run, execute, have installed, or otherwise include various sets of programs, including various combinations of operating systems, applications, plug-ins, applets, virtual machines, machine images, drivers, executable files, and other software-based programs capable of being run, executed, or otherwise used by the respective devices.
Some system devices can further include at least one graphical display device and user interfaces, supported by computer processors of the system devices, that allow a user to view and interact with graphical user interfaces of applications and other programs provided in system, including user interfaces and graphical representations of programs interacting with applications hosted within the system devices as well as graphical user interfaces associated with application management server services and other applications, etc. Moreover, while system devices may be described in terms of being used by one user, this disclosure contemplates that many users may use one computer or that one user may use multiple computers.
Turning now to the example block diagram of
In one example, a share engine 220 can be configured to provide functionality for managing crowdsourcing of information relating to applications (e.g., made available by application servers 140), as well as the sharing of such information and resources, including resources generated at least in part by or collected by application manager 205. For example, an example share engine 220 can allow modified applications 232 developed for particular users and associated user devices (e.g., 210) as well as defined application modes 240 to be shared across multiple user devices (e.g., 210), among other examples. An example user manager 222 can provide functionality for managing user accounts of various user devices (e.g., 210) that consume or otherwise make use of services of application manager 205. An example user manager 222 can associate various modified applications 232, application data and feedback data (e.g., 235), and application modes 240, including application modes developed or modified by particular users with one or more user accounts and user devices (e.g., 210) in a system, among other examples.
An application manager 205 can, in some implementations, additionally include components, engines, and modules capable of providing application management, security, and diagnostic services to one or more user devices (e.g., 210) in connection with user device attempts to download, install, activate, or otherwise use or procure various applications including applications provided through one or more application servers (e.g., 140). For instance, in one example implementation, application manager 205 can include an example behavior analysis engine 228 adapted to analyze and identify functionality of various applications made available to user devices on the system. Further, functionality of applications can be identified, for instance, by behavior analysis engine 228, that users or administrators may wish to block, limit, repair, or modify, among other examples. Accordingly, in some implementations, an example application manager 205 can include an example healing engine 225 configured to modify applications on behalf of users to eliminate undesirable application features detected, for example, by behavior analysis engine 228 and thereby generate modified applications 232. Modified applications 232 can, in some examples, be specifically modified and configured based on the requests, rules, settings, and preferences of a corresponding user. Additionally, application manager 205 may include an application intelligence engine 230 configured to collect application data (e.g., 235), for instance, from information servers 145 and other sources both internal and external application manager 205 and its client user devices (e.g., 210). An application intelligence engine 230 can be used to collect intelligence regarding one or more applications served, for instance, by application servers 144. The intelligence can be used in connection with services provided by application manager 205, such as behavior analysis and assessments of applications by application manager 205, among other examples.
In some implementations, a user device (e.g., 210) may include one or more processor devices 242 and one or more memory elements 245 as well as one or more other software- and/or hardware-implemented components including, for example, a mode manager 248, settings manager 252, security tools 250, and one or more applications 255 (e.g., procured through application servers 140). In one example implementation, a user device 210 can include a mode manager 248 that is equipped with functionality for defining, enforcing, and otherwise managing multiple application access modes 265 on the user device 210. Mode rules 270 can additionally be managed by mode manager 248, the mode rules 270 defining, for instance, particular conditions for automatically initiating or enforcing various modes 265 on the user device 210. Additionally one or more settings 260 can be defined by users, for instance, through an example settings manager 252, the setting corresponding to and in some cases used in connection with various modes 265 of the device 210, among other examples.
Turning to the example of
Generally, a platform software development kit (or “SDK”) can provide documentation, header files, libraries, commands, interfaces, etc. defining and providing access to the various platform subsystems accessible by applications compatible with the platform. In one example implementation, a platform SDK and corresponding APIs and API calls (i.e., calls to functions and routines of the API) can be represented in a model that can be used, for instance, by an application behavior engine, to determine behavior and functionality of applications compatible with the platform. The semantics of commonly used APIs is represented in a program readable form along with critical information necessary to derive application behavior. The semantics of the platform SDK can be represented so that an example application behavior engine can use the semantic model to understand and identify the operations and behaviors of a given application using the API call. For example, in one example implementation, all of the potential API calls of the platform can be represented, for instance through API intelligence 430, by tagging the name of each respective API call with the behavioral tag describing what the respective API call does on the platform as well as the corresponding parameters of the API's operations and behaviors. As an example, a template of such a semantic representation can be modeled, for instance, as:
In the foregoing example, a “category” can designate the type of an API call and be used to identify the general functionality of such API calls, such as, that the API call reads information from a particular subsystem, disk, etc. generates various messages, initiates various network behaviors, attempts to communicate with various outside servers, triggers particular device functions or elements (e.g., a camera, SMS controller, etc.). “Sensitivity” can represent the respective sensitivity of the subsystem affected or associated by the API in the context of the potential for malicious behavior in connection with the subsystem, such as whether reading to a particular memory location introduces the potential for spying, where the subsystem potentially permits the introduction of malware, unauthorized tracking or data collection, the unauthorized or undesired reading or sending of SMS or email messages, among many other examples. Further, “dependency” can represent whether the output of this API can have an impact on other parts of the program in a direct way. For instance, a sendTextMessage( ) API can be identified as having no dependency where the API simply sends an SMS message out and does not return anything, among other examples.
Other information can be used by a behavior heuristics/rule engine 435 (e.g., of an example analysis engine (e.g., 228)) to determine behaviors of an application under assessment, such as global threat intelligence (GTI) 440 aggregating intelligence from a community of sources 445, rules 450, and other information.
As noted above, an example application behavior analysis engine (e.g., 228) can possess functionality for identifying the control flows, operations, functionality, and behavior of a given application based, for instance, on a semantic representation of a standard platform SDK upon which compatible applications are based. In FIG. SA, representation 500 of a simplified application control now is shown for an example gaming application. While the functionality of the game may be in the main desirable, secure, and benign, deeper inspection of the code of the game application binary in comparison with the semantic representation of the platform SDK as well as ambient application intelligence for the game application, may yield identification of other functionality that is not immediately or otherwise identifiable, understood, or appreciated by users, such as the application sending SMS messages either with or without a user's explicit knowledge or permission. In another example, shown in
In some implementations, based for instance on a model of the semantic representation of the platform SDK, application logic can be modeled and rules can be applied to interpret the application logic and identify instructions and calls within a corresponding binary of the application that correspond with malicious, privacy infringing, policy violating, or other undesirable behaviors. The logical model of an application's functionality can include representation (e.g., 505) of the application logic through data flow structures and control flow structures, among other examples. A dataflow structure can represent the lifetime of data objects as they pass-through the application logic (e.g., 510) and onto other program units (e.g., 515) including external program units. A dataflow structure (e.g., 505) can be used to identify the flow of data from one part of the application program as it moves and is potentially transformed by the application logic. For example, a dataflow model can be used to deduce that particular data is being leaked by the application through an Internet communication post operation, among other examples. Further, control flow structures can represent the control flow of different function calls (e.g., 520, 525) to identify an originating source of an application call determined to be sensitive or undesirable. As an illustrative example, a call by the application to send an SMS message can be traced back, for example, to a UI element of an application interacted with by user, or even an autonomous event in a background process of the application, among potentially many other examples.
Turning to the examples of
As represented in the example of
In some implementations, a human readable description of a behavior identified and based on a description of API semantics can be constructed. In one example, human relatable verbs and nouns can be associated with template messages in the semantic representation and mapped to particular human understandable descriptions of functions and operations available to the APIs. Further, in connection with assessments of an application according to the semantic model performed, for example, by an application behavioral analysis engine, a human-readable summary of the behavior analysis results can be generated from the mapping and presented to a user that describes the various functionality, as well as, in some implementations, the control flow dataflow of the analyzed application. Such results can make use of the human readable description to generate a description of the functionality uncovered during analysis of the application, including functionality that may otherwise be invisible to or difficult to detect by the user. For example, in one implementation, the template can be utilized and populated so as to identify and describe an example application's functionality for reading SMS data from the user's device. As an illustrative example, corresponding description could be generated such as: “This application reads your SMS data from SMS inbox and sends to a web site.” Such a description could be constructed, for example, by filling in an example template based on the semantic representation of the platform SDK and APIs such as: “This application <verb: reads> your <noun:SMS data> from <noun: SMS inbox> and <verb: sends> to a <noun: website>”, among other examples.
In some examples, the analyzed application behavior can reveal the use of other applications, programs, or services by the analyzed application. Some instances, a call to a local application, remote service, or other program by the analyzed application may be undesirable, for instance, when the other called application is identified as unsecure, un-trusted, or unknown, among other examples. In other instances, a program called or used by the analyzed application may be identified as a trusted program. Accordingly, in some implementations, an application behavior analysis engine can make use of, generate, modify, and otherwise manage whitelists and/or blacklists that identify the status and reputations of various programs that have been known to or could be potentially called by various analyzed applications. In some implementations, applications and services hosted by remote servers can additionally be identified in such whitelists and/or blacklists by the respective URLs or other address information corresponding to their respective host servers, among other examples.
In some implementations, the behavioral analysis engine can identify the context in which a particular activity is performed, platform API is accessed, or functionality is employed by the application under assessment. As an example, an analyzed application's attempts to access a platform telephony subsystem can be assessed based upon the cause or context of the attempt. For instance, in some contexts, a particular API call may be perfectly acceptable while in other contexts the API call can be undesirable. For instance identified application functionality that accesses the telephony subsystem in response to a user interface interaction, such as a button press, may be assessed differently than an attempt by an application to access the telephony subsystem autonomously and not in response to a user provided directive, among other examples.
As noted above, in some implementations, rules can be defined that can be used in the assessment of application behaviors. Such rules can be represented and configured for use in performing heuristic analysis of an application's logic or of a potentially malicious behavior identified by an application behavior analysis engine, including contexts in which the behavior is to be determined to be malicious. For instance, a rule engine can apply one or more rules to an application logic model to identify one a more potentially malicious or otherwise undesirable behaviors present in the application. In some implementations, a rule can be represented as:
The rules can be generic or can be specific to a particular subsystem, etc., such as a rule to detect data leak of a memory element storing personal contact data, among other examples. A specific application behavior can be derived based on application of a single rule or multiple rules.
In some implementations, an application behavior analysis engine can be hosted on one or more server computing devices remote from the mobile user devices for which analysis performed. In other examples, at least a portion of application behavior analysis engine can be provided alternatively or redundantly with functionality of server-side application behavior analysis engine components. For instance, in one example implementation, a user computing device can be provided with application behavior analysis engine functionality allowing at least a partial or quick preliminary assessment of an application to be performed at the user device to thereby provide a user with fast feedback as well as assess whether an application should be quarantined, denied download or installation, and/or forwarded to a remote application behavior analysis engine, such as one provided in a cloud system, allowing then for a more robust behavioral analysis of the application (that could possibly introduce increased latency into the behavioral analysis assessment).
In some implementations, during an analysis of an application, downloading, insulation, or launching of the analyzed application may be prevented or delayed until the analysis is completed. In some instances, a user can be provided with a prompt identifying the analysis of the application as well as providing the user with various options for dealing with the installation, downloading, or launching of the analyzed application. For instance, a user may be provided with the option of skipping the analysis, delaying installation of the analyzed application, assigning the analyzed application to a particular mode, among other examples. Additionally, in some implementations, a prompt presented to the user in connection with the assessment may be presented together with information, such as preliminary information, gleaned from the behavioral analysis engine assessments and/or external intelligence relating to the analyzed application. Such intelligence can include, for example, intelligence gleaned by the behavioral analysis engine in previous assessments of the analyzed application, among other examples. Indeed, in some implementations, the behavioral analysis engine can indicate to the user behaviors discovered for the application, how other users have responded to feedback received from the behavioral analysis engine regarding the particular analyzed application, among other examples.
In some implementations, behavioral analysis engine can maintain blacklists, greylists, and/or whitelists of applications known to and/or previously analyzed by the behavioral analysis engine. Such blacklists, greylists, and/or whitelists can be based on historical intelligence collected from previous behavioral analyses, outside intelligence from other sources, and other users. The behavioral analysis engine can utilize such information to perform an initial assessment of an application and leverage information gleaned from previous analyses. Initial filtering or feedback can thereby be provided to a user to assist the user in determining how to deal with a particular application as well as whether to initiate further behavioral analysis on the application using the behavioral analysis engine.
Behavioral analysis of applications and/or blacklists/whitelists can further incorporate or consider general reputation information of developers or other parties identified as responsible for various applications, among other examples and considerations. Rules can be defined that consider the trustworthiness or untrustworthiness of the developer, distributor, etc. of an application. For example, an application development score rating can be computed for a developer based on aggregate analyses of applications of the developer by the behavioral analysis engine. For instance, such a rating can be derived as: AppDeveloper Rating=f(total number of apps, weighted average of undesired behavior in apps, popularity of the app, average ratio of low ratings), among other examples. For instance, in one Illustrative example, a weighted average of undesired behavior can be generated for a set of applications of a developer:
and average weight can be derived by Average Weight=Total Weight/Total number of Apps, among other example implementations.
Outside sources, such as intelligence databases, such as a global threat intelligence (GTI) feed, can be used for identifying malicious behaviors that have been detected across one or more networks that may be employed by applications assessed by behavioral analysis engines. For instance, various URLs, IP addresses, phone numbers, and files can be identified that have been previously determined to be associated with or used in other malicious attacks, malware, or suspect systems. Additionally, a behavioral analysis engine can interface with intelligence databases to provide additional intelligence gleaned from the behavioral analyses of applications performed by the behavioral analysis engine itself, among other examples.
Further, in some systems and platforms, applications offered by one or more application servers or storefronts may provide users with basic descriptions, ratings, user feedback, etc. collected for a given application. Unfortunately, in many instances, such ratings, application descriptions, content ratings, etc. may be provided by, manipulated by, or otherwise influenced by the application developers themselves thereby diminishing, potentially, the truthfulness or legitimacy of the information provided to users regarding some applications. Accordingly, in some of implementations, intelligence (e.g., behavioral descriptions) gleaned from behavioral analyses of applications performed by an example behavioral analysis engine may be used to supplement, correct, or otherwise modify descriptions provided to users in connection with their browsing, purchasing, and downloading of applications available on a platform. Further, in some implementations, a behavioral analysis engine can make use of these default application descriptions, content ratings, user feedback etc. as external intelligence considered in connection with a behavioral analysis. In still other examples, a behavioral analysis engine may be used to identify common behavioral traits between multiple applications that can serve as the basis for categorizing the applications according to behavior. Such categories can then be provided to users to assist users in better understanding the qualities and behaviors, as well as potential risks, of various applications, among other examples.
Turning now to the example of
As noted above, static healing and personalization of application behavior can be performed by a healing engine allowing the code of the application to be modified and generate a “safe” version of the application that allows the user to retain safe or legitimate functionality of the application while removing undesirable behaviors. Such healing can in some cases be personalized or customized to particularly-defined policies driving the healing, thereby allowing a user, service provider, device manufacturer, etc. to control and personalize the functionality of applications to be installed on corresponding user devices. In
A variety of healing methods can be employed by an application healer engine. For instance, a particular offending line of code functionality can be identified as a final or leaf node in a control chain. In such instances, the offending code may be determined to be able to be suppressed or removed without affecting other dependencies in the application, among other examples. In another example, if a removal of a particular API call is determined to likely have no impact on surrounding code, the removal healing method can be applied. The nature and character of APIs can be learned, for example, from the semantic platform SDK representation, among other examples. In other instances, the offending behavior can be from one or more sections of code and may result in multiple methods of healing applied to remediate the behavior, such as by replacing the data in a register to alter the behavior of the API or redirecting of the API call to a new version of the API with same interface by replacing the offending API code with the new API code, among other examples. In instances where a new version of an API is introduced, the new API may, for example, do nothing and set the register status so as not to impact other parts of the program, process the inputs in a different way to avoid the undesired behavior, or do pre-processing and/or post-processing of the input/output parameter and call the original API, among other example techniques that resolve the undesirable behavior.
In some implementations, functionality can be provided to define, enable, and employ defined usage modes on the user devices. Traditionally, user devices, such as smart phones and tablet computers, among other examples, are designed to support a single user and application profile. However, a single operation profile and mode may not be appropriate for all of the actual users of the device or the situations in which the device is used. For instance, a user may desire to loan their device to a friend for some short period of time, but would like to nonetheless retain control of the access to some of the sensitive applications and data on the device, email applications, contacts, calendars, messaging functionality, etc. In other instances, the user may desire to allow a child to temporarily use the device, for example, to play game, but would prefer for other applications (e.g., web browsers) and access to certain device settings and data to be blocked from the child. Additionally, users may desire to control usage of some subset of the applications on the device to specific times, locations, and situations. For instance, games and social networking applications may be desired to be disabled during school hours, among other examples.
In some implementations, a device mode can be composed of an exclusion list or inclusion list. Device modes can be defined as respective sets of applications that are either allowed or somehow protected in that mode, in the sense their usage is prohibited or limited. In some instances, an exclusion list can be defined for a mode that indicates a particular subset of the applications and/or subsystems of a device that are accessible under the corresponding mode (i.e., with the remaining applications protected or locked in that mode). For instance, a mode can be defined such as according to: <ModeName, inclusion/Exclusion, Access PIN, App1, App2, App3 . . . App N>. In some instances, each device mode can be protected and associated with a particular password. The master mode can be defined that allows access to the entirety of the device's functionality and applications. Accordingly, a master password can be provided that enables access to the master mode. Within the master mode, the user may be provided with access to a management console for managing the set of modes available or defined at the device. Accordingly the user may edit or define modes through the management console, as well as activate or delete predefined modes. An example management console can allow a user to select, from a listing of applications, those applications the user wishes to designate as protected or accessible in any given mode. In some cases, a single application can be allowed or protected under multiple different modes.
In some implementations, mode passwords may be stored in encrypted memory. For instance, the password of each mode can be encrypted using a key generated by the same password. A stored, encrypted password can then be validated by decrypting the password with a key generated from the password entered by the user. The decrypted data can then be compared with the user-entered password. Based on the password provided by user, a corresponding mode can be identified and authenticated to allow access to the mode by the user. In some implementations, the user may manually lock the device or the device may lock itself, for instance, after a prolonged period of inactivity. When attempting to unlock the device or wake up the device a user may be again presented with a login prompt requesting a password of one of the modes available and defined for the device.
In some implementations, modes can be hierarchical. For instance, a user logged into a higher level mode (i.e., a mode providing a relatively greater level of access), may be able to freely move to another mode without providing credentials for that lower-level mode. On the other hand, a user who has been authenticated to a lower level mode may be forced to enter additional credentials when attempting to access another mode at a higher level in the hierarchy than the lower-level mode to which the user was previously authenticated. For example, in one instance, four device modes can be defined where:
Mode1 is admin level mode;
Mode 2 guest level mode;
Mode 3 is guest level mode; and
Mode 4 is low privilege mode
and the hierarchy is defined as: Mode1>(Mode2 and Mode 3)>Mode 4, where Mode2 is the same level as Mode3, among other example implementations.
In some implementations, configuration of the device can be altered, customized, or at least partially restricted when certain modes are active. For example, a particular mode can activate or deactivate GPS functionality, data access, telephony, as well as certain applications. Further, in some examples, device modes can be provided that secure data of particular applications when mode. For instance, once a new mode has been created and assigned a corresponding access level to set of applications, the data of these applications may be protected by encryption through a separate encryption key. This can be implemented for example by using an encrypting file system for encrypting files and folders, among other examples.
In some implementations, the executable code of applications can be secured to protect against applications being used in modes that disallow access and/or use to one or more of the behaviors or features of the application. For instance, in one implementation, the application executable can be stored in encrypted secondary storage. An operating system loader of the user device can gain conditional unencrypted access to the executable code, in some examples, only if the application is found in an allowed application list for the active device mode in which access to the application is attempted, among other potential implementations.
In some examples, defining multiple device modes for a user device can further result in the provision of multiple unique home screens to be presented in each of the corresponding modes. As a result, in such implementations, the appearance of a given home screen can indicate to a user the mode that is active on the device as well as access privileges available in that mode. In some instances, home screens can include icons of applications that are available within that corresponding mode, hiding or obscuring the icons of other applications that are protected within that mode, among other examples.
Further, in some instances, device modes can be created automatically, for instance, based on identified behaviors and security profiles of applications that are detected or loaded on the user device. For instance, a mode manager can make use of behavioral analyses performed, for example, by an example application behavioral analysis engine, to identify applications that exhibit a common category of behaviors or category of security profiles. For instance, applications identified as permitting access to online resources may be grouped and assigned dynamically to one or more modes that have been defined as allowing such access. Other modes, such as modes dedicated for underage users, may be denied access to applications that allow users to access the Internet, among other examples. Other example categories may include applications that enable telephony or mobile messaging functionality, applications that make use of subsystems that utilize sensitive data, collect potentially private information (e.g., cameras, voice recorders, GPS systems, etc.), and other examples. In some implementations, ambient intelligence relating to an application, such as an age rating (e.g., 7+, 12+, 18+ years, etc.), user reviews, or other information may be used to categorize applications and group them in various modes. For example, a description of an application may include an age or maturity rating as well as reasons for the maturity rating. Accordingly, in one example, one or more modes may be defined, for example, that block access by child users to applications with higher maturity ratings, among other examples.
Other global or distributed intelligence can also be used to develop information for a given application, such as illustrated in the simplified block diagram 1900 of
Turning to the example of
Turning to the example of
In some implementations, such as shown in the example of
Turning now to the example of
The screenshot of
In the example of
In the example of
Although this disclosure has been described in terms of certain implementations and generally associated methods, alterations and permutations of these implementations and methods will be apparent to those skilled in the art. For example, the actions described herein can be performed in a different order than as described and still achieve the desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve the desired results. In certain implementations, multitasking and parallel processing may be advantageous. Additionally, diverse user interface layouts and functionality can be supported. Other variations are within the scope of the following claims.
Embodiments of the subject matter and the operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal per se, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices), including a distributed software environment or cloud computing environment.
Networks, including core and access networks, including wireless access networks, can include one or more network elements. “Network elements” can encompass various types of routers, switches, gateways, bridges, load balancers, firewalls, servers, inline service nodes, proxies, processors, modules, or any other suitable device, component, element, or object operable to exchange information in a network environment. A network element may include appropriate processors, memory elements, hardware and/or software to support (or otherwise execute) the activities associated with using a processor for screen management functionalities, as outlined herein. Moreover, the network element may include any suitable components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information.
The operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources. The terms “data processing apparatus,” “processor,” “processing device,” and “computing device” can encompass all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The apparatus can include general or special purpose logic circuitry, e.g., a central processing unit (CPU), a blade, an application specific integrated circuit (ASIC), or a field-programmable gate array (FPGA), among other suitable options. While some processors and computing devices have been described and/or illustrated as a single processor, multiple processors may be used according to the particular needs of the associated server. References to a single processor are meant to include multiple processors where applicable. Generally, the processor executes instructions and manipulates data to perform certain operations. An apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and execution environment can realize various different computing model infrastructures, such as web services, distributed computing and grid computing infrastructures.
A computer program (also known as a program, software, software application, script, module, (software) tools, (software) engines, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. For instance, a computer program may include computer-readable instructions, firmware, wired or programmed hardware, or any combination thereof on a tangible medium operable when executed to perform at least the processes and operations described herein. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
Programs can be implemented as individual modules that implement the various features and functionality through various objects, methods, or other processes, or may instead include a number of sub-modules, third party services, components, libraries, and such, as appropriate. Conversely, the features and functionality of various components can be combined into single components as appropriate. In certain cases, programs and software systems may be implemented as a composite hosted application. For example, portions of the composite application may be implemented as Enterprise Java Beans (EJBs) or design-time components may have the ability to generate run-time implementations into different platforms, such as J2EE (Java 2 Platform, Enterprise Edition), ABAP (Advanced Business Application Programming) objects, or Microsoft's .NET, among others. Additionally, applications may represent web-based applications accessed and executed via a network (e.g., through the Internet). Further, one or more processes associated with a particular hosted application or service may be stored, referenced, or executed remotely. For example, a portion of a particular hosted application or service may be a web service associated with the application that is remotely called, while another portion of the hosted application may be an interface object or agent bundled for processing at a remote client. Moreover, any or all of the hosted applications and software service may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure. Still further, portions of a hosted application can be executed by a user working directly at a server hosting the application, as well as remotely at a client.
The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), tablet computer, a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device, including remote devices, which are used by the user.
Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include any internal or external network, networks, sub-network, or combination thereof operable to facilitate communications between various computing components in a system. A network may communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. The network may also include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the Internet, peer-to-peer networks (e.g., ad hoc peer-to-peer networks), and/or any other communication system or systems at one or more locations.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.
While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.
The following examples pertain to embodiments in accordance with this Specification. One or more embodiments may provide an apparatus, a system, a machine readable medium, and a method to analyze code of a particular application against a semantic model of a software development kit of a particular platform, identify, based on the analysis of the code, a set of behaviors of the particular application, and identify that one or more of the set of behaviors are undesired behaviors. The semantic model can associate potential application behaviors with one or more of APIs of the particular platform.
In one example, identifying that one or more of the set of behaviors are undesired behaviors includes determining that the one or more behaviors violate one or more rules. The rules can be associated with a particular user.
In one example, a user input identifies one or more of the set of behaviors as undesirable. The user input can be received in connection with a user interface displaying human readable descriptions of the identified set of behaviors.
In one example, code of the particular application can be disassembled into a control flow and a model of application logic for the particular application can be generated based at least in part on the semantic model. The model of application logic can be further based, at least in part, on ambient application knowledge.
In one example, a remediation action can be performed based on the identification that one or more of the set of behaviors are undesired behaviors.
In one example, the code of the particular application is analyzed in connection with an attempt to implement the particular application on a particular user device.
One or more embodiments may provide an apparatus, a system, a machine readable medium, and a method to identify a particular behavior in a set of behaviors detected as included in a particular application, identify a section of code of the particular application corresponding to the particular behavior, and perform a remediation action on the section of code to remediate the particular behavior and generate a healed version of the particular application.
In one example, the remediation action preserves other behaviors of the particular application other than the particular behavior.
In one example, the remediation action includes deleting the section of code.
In one example, the remediation action includes rewriting the section of code.
In one example, the remediation action includes adding additional code to the application to nullify the particular behavior.
In one example, the remediation action is identified from a policy identifying a remediation pattern determined to be applicable to remedying the particular behavior.
In one example, the remediation action includes inserting application logic allowing a user to selectively enable a healed version of the particular behavior at launch of the healed application on a user device. The user can be further allowed to selectively enable an unhealed version of the particular behavior in lieu of the healed version.
In one example, the set of behaviors of the particular application can be detected through an analysis of code of the particular application.
In one example, the remediation action is triggered by a user request.
One or more embodiments may provide an apparatus, a system, a machine readable medium, and a method to activate a particular one of a plurality of modes defined for a particular user device, and restrict access to one or more applications installed on the particular user device in accordance with the activated particular mode. The restricted applications can be accessible when another one of the plurality of modes is activated.
In one example, the particular mode is activated in response to a particular passcode entered by a user of the particular user device, where each of the plurality of modes is associated with a corresponding passcode. Activation of the particular mode can include identifying the particular mode from the plurality of modes based on the entry of the particular passcode, and authenticating access to the particular mode based on the entry of the particular passcode.
In one example, one or more of the plurality of modes are user-defined modes.
In one example, an alternate device configuration can be applied to the particular user device based on activation of the particular mode. The alternate device configuration can restrict access to one or more subsystems of the particular user device.
In one example, one of the plurality of modes is an administrative modes allowing for modification of the plurality of modes.
In one example, at least one of the plurality of modes is an instance of a mode downloadable from a mode sharing service remote from the particular user device.
In one example, the particular mode is activated automatically based at least in part on the detection of a particular context using functionality of the particular user device.
In one example, at least a particular one of the applications is restricted based on a defined rule for the particular mode.
In one example, the defined rule pertains to detected behavior of the particular application.
In one example, the plurality of modes includes a mode designated as a quarantine mode for application awaiting behavioral analysis or remediation.
In one example, the particular mode is activated in response to a user command received at a device remote from the particular user device.
Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results.
75. At least one machine accessible storage medium having instructions stored thereon, the instructions when executed on a machine, cause the machine to:
- analyze code of a particular application against a semantic model of a software development kit of a particular platform, wherein the semantic model associates a plurality of application behaviors with respective application programming interface (API) calls of the particular platform;
- identify, based on the analysis of the code, a set of behaviors of the particular application; and
- identify that a particular one of the set of behaviors is an undesired behavior.
76. The storage medium of claim 75, wherein identifying that the particular behavior is an undesired behavior includes determining that the one or more behaviors violate one or more rules.
77. The storage medium of claim 76, wherein the rules are associated with a particular user.
78. The storage medium of claim 77, wherein at least a portion of the rules include rules defined by the particular user.
79. The storage medium of claim 76, wherein the rules are associated with a network service provider.
80. The storage medium of claim 75, wherein a user input identifies that the particular behavior is undesired.
81. The storage medium of claim 80, wherein the user input is received in connection with a user interface displaying human readable descriptions of the identified set of behaviors.
82. The storage medium of claim 81, wherein the human readable description is generated using a template for generating the description and the semantic model.
83. The storage medium of claim 75, wherein the particular user device is one of a smart phone and a tablet computing device.
84. A method comprising:
- analyzing code of a particular application against a semantic model of a software development kit of a particular platform, the semantic model associating a plurality of application behaviors with respective application programming interface (API) calls of the particular platform;
- identifying, based on the analysis of the code, a set of behaviors of the particular application; and
- identifying that a particular one of the set of behaviors is an undesired behavior.
85. The method of claim 84, further comprising disassembling code of the particular application into a control flow and generating a model of application logic for the particular application based at least in part on the semantic model.
86. The method of claim 85, wherein the model of application logic is further based, at least in part, on ambient application knowledge.
87. The method of claim 84, further comprising performing a remediation action based on the identification that one or more of the set of behaviors are undesired behaviors.
88. The method of claim 84, wherein the code of the particular application is analyzed in connection with an attempt to implement the particular application on a particular user device.
89. The method of claim 88, further comprising restricting implementation of the particular application on the particular user device based on identifying that one or more of the set of behaviors are undesired behaviors.
90. The method of claim 89, wherein restricting implementation includes blocking installation of the particular application on the particular user device.
91. The method of claim 89, wherein restricting implementation includes assigning the particular application to a device mode that is to limit access to the particular application.
92. The method of claim 89, further comprising modifying code of the particular application to remediate the undesired behavior.
93. A system comprising:
- at least one processor device;
- at least one memory element; and
- an application behavioral analysis engine, adapted when executed by the at least one processor device to: analyze code of a particular application against a semantic model of a software development kit of a particular platform, wherein the semantic model associates a plurality of application behaviors with respective application programming interface (API) calls of the particular platform; identify, based on the analysis of the code, a set of behaviors of the particular application; and identify that a particular one of the set of behaviors is an undesired behavior.
94. The system of claim 93, further comprising an application healer engine to:
- identify a section of code of the particular application corresponding to the particular behavior; and
- perform a remediation action on the section of code to remediate the particular behavior and generate a healed version of the particular application.
95. The system of claim 93, further comprising a mode manager to:
- activate a particular one of a plurality of modes defined for a user device; and
- restrict access to the particular application in accordance with the activated particular mode, wherein the particular application is made accessible when another one of the plurality of modes is activated.
96. The system of claim 93, further comprising a user device, wherein the application behavioral analysis engine is to communicate results of the analysis of the code to the user device based on an attempt by the user device to install the particular application on the user device.
97. A system comprising:
- means for analyzing code of a particular application against a semantic model of a software development kit of a particular platform, the semantic model associating a plurality of application behaviors with respective application programming interface (API) calls of the particular platform;
- means for identifying, based on the analysis of the code, a set of behaviors of the particular application; and
- means for identifying that a particular one of the set of behaviors is an undesired behavior.
Filed: Oct 18, 2013
Publication Date: Aug 6, 2015
Inventors: Srikanth Nalluri (Bangalore), Dattatraya Kulkarni (Bangalore), Raja Sinha (Bangalore), Venkatasubrahmanyam Krishnapur (Bangalore), Venkata Krishnan Nagarajan (Chennai), Kaushal Kumar Dhruw (Bilaspur), Kamlesh Halder (Bangalore)
Application Number: 14/126,866