WO2016001814A1

WO2016001814A1 - System and method for determining the behavioral integrity of an application

Info

Publication number: WO2016001814A1
Application number: PCT/IB2015/054854
Authority: WO
Inventors: Krishna V. NANDIVADA; Raja Subramaniam THANGARAJ
Original assignee: Indian Institute Of Technology Madras
Priority date: 2014-07-02
Filing date: 2015-06-29
Publication date: 2016-01-07

Abstract

A method for determining the behavioral integrity of an application is disclosed. The method comprises analyzing, using a computing system, an application package binaries, tracing, using the computing system, one or more components within the package and constructing, using the computing system, a behavioral abstract of the application. Integrity of the application is determined by comparing the behavioral abstract with the developer- defined characteristics of the application.

Description

SYSTEM AND METHOD FOR DETERMINING THE BEHAVIORAL INTEGRITY

OF AN APPLICATION

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application claims the benefit and priority of the following: Indian patent application no. 3261/CHE/2014, filed on July 02, 2014, the full disclosure of which is incorporated herein by reference.

FIELD OF THE INVENTION

[0002] The present invention relates to an apparatus and method for determining the behavioral integrity of a system application. More specifically, the invention relates to apparatus and method for determining the behavioral integrity of system applications that follow component based application model like android applications.

DESCRIPTION OF THE RELATED ART

[0003] Nowadays, electronic devices, such as smartphones, tablet computers, and smart televisions, are an intrinsic part of our lifestyle and people entrust their handheld device with sensitive data ranging from their financial to personal details. Moreover, with the advent of "smart" functionality in even household appliances, applications can be downloaded to any device from application marketplaces. But, these application marketplaces may not be regulated and there is high risk of malware infiltrating a device. Along with the increasing importance of the data and the services supported by the devices, the proliferation and reach of malicious applications has also increased significantly.

[0004] In platforms like Android that follow component based application model, it is a challenge to ascertain the behavior of an application, as the behavior can vary based on the other application components present in the target system. This renders the traditional certification mechanisms which treat and certify the applications in a standalone manner difficult, especially in the context of assuring safety against collaborative malicious behavior of applications. On the other hand, certifying an application based on collaborative analysis of various applications present on the target system, from their executable files, can be costly (in terms of time and resource consumption), which is a severe drawback for resource- constrained systems like mobile phones. Current malware writers take advantage of such a situation and develop malwares that may otherwise look benign, but may collaborate with other application components to compromise the privacy of sensitive data present in the system based on some trigger (e.g. sending out sensitive data on receiving an SMS from a special number or at regular intervals, or erasing sensitive data based on an SMS received).

[0005] US20130212684 discloses a method for determination of permission list from the mobile application by generating and comparing a set of potential behaviors to the required behaviors of the application. WO2013089340 discloses a method for detecting similarity in behavior between applications by using the characteristic information of those applications. US20140096248 relates to identification of a malicious application by static analysis and comparing user interfaces between applications.

[0006] Further, existing methods have some shortcomings. Applications in a component based application model, unlike traditional applications, are a package of components. These components, each performing a specific task, collaborate together to provide the needed functionality. Hence the behavior of the application changes dynamically, based on the other components present in the target system. This poses a challenge in the context of static analysis of the android applications. Since components of different applications can collaborate together to achieve a malicious intent, it becomes necessary to analyze an application along with all the other applications present in the target system. On the other hand, devices are resource constrained which makes it non-pragmatic to perform complete static analysis of several applications at the target system, each time an application is installed.

[0007] Hence, there exists a need for analyzing an application statically and ensure that it is trustworthy before actually installing/executing it. Therefore, apparatus and method for determining integrity factor of an application's behavior by validating the application at the component level in a system is developed to eradicate the above mentioned problems.

SUMMARY OF THE INVENTION

[0008] In one aspect, a method for determining the behavioral integrity of an application is disclosed. The method comprises obtaining, in a computing system, a stated behavior of a first application and associating said behavior with a developer defined application level certificate. The method further comprises obtaining, using the computing system, an automatically generated component level certificate for the first application, wherein the component level certificate is configured to capture a flow of data out of one or more components of the first application and to abstract the behavior of the first application using a set of parameters. The method then determines, using the computing system, an integrity factor of the first application by validating the application level certificate against the component level certificate. The method may further comprise generating a component level certificate of one or more other applications and comparing said certificates with the component level certificate of the first application to obtain behavioral integrity of the first application in the context of the one or more other applications.

[0009] In one aspect of the method, the component level certificate comprises a certificate for an activity component, a service, broadcast receive, or a content provider. In one aspect, the component level certificate is generated by determining key actions performed by each of the components and tracking sensitive data in each of the components. In some aspects the method further comprises determining an interaction factor of at least two components where one or more components have a source outside of the application. In various aspects, the interaction factor is start of an activity, send mail, access shared data, use service, send SMS, register receiver, access DB, load Dex file, send broadcast, access file, read sensitive data, use contact provider, or access a network. The flow of data captured by the application level certificate may comprise contacts, SMS, MMS, IMEI number, or SIM details.

[0010] In one aspect of the method the application is a mobile application. In one aspect the application is an Android application.

[0011] In one aspect a system for determining the behavioral integrity of a first application is disclosed. The system comprises one or more computer processors, memory, and a non-transitory computer-readable storage medium with instructions, that when executed, control the one or more computer processors to be configured for obtaining a behavior of the application. The behavior is associated with a certificate, wherein the certificate comprises a developer defined application level certificate (DDAB) and an automatically generated component level certificate for the first application. The component level certificate is configured to capture a flow of data out of one or more components of the first application and to abstract the behavior of the application using a set of parameters. The system then determines an integrity factor of the first application by validating the application level certificate against the component level certificate. The system may further be configured to generating a component level certificate of one or more other applications and comparing said certificates with the component level certificate of the first application to obtain behavioral integrity of the first application in the context of the one or more other applications.

[0012] In one aspect of the system, the component level certificate comprises a certificate for an activity component, a service, broadcast receive, or a content provider. In one aspect the component level certificate is generated by determining key actions performed by each of the components and tracking sensitive data in each of the components. In one aspect the system further determines an interaction factor of two or more components and where one or more components have a source outside of the application. The interaction factor may be start an activity, send mail, access shared data, use service, send SMS, load Dex file, register receiver, access DB, send broadcast, access file, read sensitive data, use contact provider, or access a network. The flow of data captured by the application level certificate may comprise contacts, SMS, MMS, IMEI number, or SIM details.

[0013] In one aspect of the system the application is a mobile application. In one aspect the application is an Android application.

[0014] A method for determining the behavioral integrity of a first application is disclosed. The method comprises analyzing, using a computing system, application package binaries of the first application, tracing, using the computing system, one or more components within the package and constructing, using the computing system, a component level certificate for the first application. The component level certificate may include a behavior abstract of the first application as determined by a set of parameters. The method further comprises comparing the constructed component level certificate with a developer defined application level certificate (DDAB) of the first application, and determining an integrity factor of the application by validating the application level certificate against the component level certificate. The method may further comprise generating a component level certificate of one or more other applications and comparing said certificates with the component level certificate of the first application to obtain behavioral integrity of the first application in the context of the one or more other applications. The method may also comprise visually representing the application behavior.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The invention has other advantages and features that will be more readily apparent from the following detailed description of the invention and the appended claims, when taken in conjunction with the accompanying drawings, in which:

[0016] FIG. 1A illustrates a method for determining the behavioral integrity of an application.

[0017] FIG. IB illustrates a method for determining the behavioral integrity of a first application in the context of one or more other applications.

[0018] FIG. 2 shows one embodiment of a method for determining the behavioral integrity of an application.

[0019] FIG. 3 shows a system for determining the behavioral integrity of an application.

[0020] FIG. 4 shows stand-alone behavior of AppA and AppB.

[0021] FIG. 5 shows the collaborative behavior of AppA in presence of AppB.

[0022] FIG. 6 represents the ICSuite block diagram.

[0023] FIG. 7 shows a DDAB file for MessagePhisser app.

[0024] FIG. 8 shows a spoofed DDAB file for MessagePhisser app.

[0025] FIG. 9 represents the ICApps representation of MessagePhisser app.

[0026] FIG. 10 represents the behavior graph for MessagePhisser app.

[0027] FIG. 11 shows the flow chart of the application analysis process using ICSuite.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0028] While the invention has been disclosed with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt to a particular situation or material to the teachings of the invention without departing from its scope.

[0029] Throughout the specification and claims, the following terms take the meanings explicitly associated herein unless the context clearly dictates otherwise. The meaning of "a", "an", and "the" include plural references. The meaning of "in" includes "in" and "on." Referring to the drawings, like numbers indicate like parts throughout the views. Additionally, a reference to the singular includes a reference to the plural unless otherwise stated or inconsistent with the disclosure herein.

[0030] The proposed invention relating to apparatus and method for determining the behavioral integrity of a system application is further described with reference to the sequentially numbered figures.

[0031] One exemplary method 100 for determining the behavioral integrity of an application is shown in FIG. 1A. In one aspect, the method comprises downloading a software application in a device in step 101. The software application is associated in step 102, with a set of developer-defined characteristics, as made available, for example, through a portal. The developer defined characteristics are then associated with an application level certificate called the DDAB. In step 103, the behavior of the application is analyzed within the device by reviewing the flow of data out of the components using a set of parameters. An abstract of the behavior of the application is then prepared in step 104, based on the analyzed behavior of the application. In step 104, abstracting the behavior of the application involves creating a component-level certificate representative of the behavior of the application. In step 105, the component level certificate is validated against the developer-defined certificate (DDAB) to obtain a report of behavioral integrity of the application. In one embodiment, the method may determine that the application complies with integrity requirements if the two certificates match, or lacks behavioral integrity, in the event that the analyzed behavior is at variance with the developer defined characteristics. [0032] In one embodiment the method 200 comprises determining the integrity of a first application in the context of one or more other applications, as shown in FIG. IB. In step 201, the method comprises downloading and running two or more software applications in a device. In the next step (202), data flow out of the first application is analyzed to generate a component level certificate for that application. Then, the data flow out of the other applications is analyzed sequentially to generate a component level certificate for each of the other applications in step 203. The certificates of the first and the other applications are then compared in step 204 to obtain a behavioral integrity of the first application in the context of the other applications. In one embodiment the method may further comprise identifying confederacy of two or more applications based on the comparison in step 204.

[0033] In various embodiments, the abstracting the behavior of the application described with reference to FIG. 1A and IB comprises analyzing its behavior using a set of parameters including an activity component, a service, broadcast receive, or a content provider. In one embodiment the abstracting the behavior of the application includes determining key actions performed by each of the components and tracking sensitive data in each of the components associated with those actions. In some embodiments described with reference to FIG. 1A and IB the abstracting the behavior of the application may comprise determining an interaction factor of two components within the application, and may further include determining an interaction factor of one or more components having a source outside of the application. In various embodiments the interaction factor is start of an activity, send mail, access shared data, use of a service, send SMS, load a Dex file, register a receiver, access a DB, send a broadcast, access a file, read sensitive data, use contact provider, or access a network. In some embodiments the set of parameters used to capture a flow of data out of the application includes contacts, SMS, MMS, IMEI number, or SIM details.

[0034] In one embodiment, a method for determining the behavioral integrity of an application is shown in FIG. 2. The method comprises downloading a software application in a computing device in step 301. The application is endowed with developer defined characteristics (DDAB) that are identified and stored in the computing device. Then, the application package's binaries are analyzed using the computing device in step 302. One or more components within the package are traced in step 303 and a component level certificate is constructed using the computing system in step 304. The component level certificate comprises data representative a behavioral abstract of the application as determined by a set of parameters. The constructed component level certificate is compared with the developer defined application level certificate (DDAB) in step 305. In step 306, the application level certificate is validated against the component level certificate, and finally, in step 307, the validation results are used to obtain a factor representing the behavioral integrity of the application. In one embodiment, the method further comprises visually representing the behavior of the application. In one embodiment the method may further comprise classifying an application as safe or malicious based on the analysis.

[0035] In one embodiment, a system and apparatus for determining the behavioral integrity of an application is disclosed with reference to FIG. 3. The system 400 comprises a computing device 401 connected through a network 402 to a source of applications such as an application market 403. The computing device 401 may include one or more computer processors 410, memory 411, non-transitory computer-readable storage medium 412, network interface 413 and display 415. The computer-readable storage medium 412 comprises instructions, that when executed control one or more computer processors 410 to be configured for obtaining a behavior of an application downloaded from market 403. Obtaining the behavior of the application includes deriving a developer defined application level certificate (DDAB) and generating a component level certificate based on instructions executed in processor 410. The system and apparatus validates the generated component level certificate against the DDAB, thereby determining behavioral integrity of the application.

[0036] In one embodiment the application is a mobile application such as an Android application. In various embodiments, the component level certificate described with reference to FIG. 2 comprises a certificate generated using a set of parameters including an activity component, a service, broadcast receive, or a content provider. In one embodiment the component level certificate is generated by determining key actions performed by each of the components and tracking sensitive data in each of the components associated with those actions. In some embodiments, the method described with reference to FIG. 2 may comprise determining an interaction factor of two components within the application, and may further include determining an interaction factor of one component with one or more sources outside of the application. In various embodiments the interaction factor is a start of an activity including but not limited to send mail, access shared data, use of a service, send SMS, load a Dex file, register a receiver, access a DB, send a broadcast, access a file, read sensitive data, use contact provider, or access a network. In some embodiments described with reference to FIG. 2, the set of parameters used to generate the application level certificate captures a flow of data out of the components including contacts, SMS, MMS, IMEI number, or SIM details.

[0037] The invention is further explained in the following examples, which however, are not to be construed to limit the scope of the invention, which are circumscribed by the appended claims.

EXAMPLES

Example - 1

[0038] Android components are classified into four types:

Activity: A component with UI is an activity. Whatever could see in an Android application and interact with is an activity.

Services: A service is a background process with no UI. Usually services are used to perform tasks that are long running or CPU intensive. User can't interact with a service directly.

Broadcast Receiver: This is another component without UI and works in the background, just like services. But broadcast receivers are triggered by an event, say receiving a SMS (Short Message Service) or change in weather. It is the task of a broadcast receiver to handle the respective event.

Content Provider: As the name suggests, this component helps other components in storing and retrieving their data. It acts as a small database within the application.

[0039] Each component acts as an individual unit and provides a particular functionality. They can perform their piece of task without depending on any other component. At the same time they can interact with other components to make use of functionality provided by them. Components can be declared either public or private. Private component is visible only within the application whereas public component is visible to the components of other applications.

[0040] With the needed privilege, a component can be invoked at any instance by any other component from any other application, to make use of its functionality, as if invoked component is part of that application. This provides a seamless transition between the components of different application and facilitates the app developers in developing feature rich applications very easily, by making use of the existing functionality provided by other applications. [0041] Android provides an asynchronous message passing system for the components to interact with each other. Each such message is called intent. As the name suggests, intent carries the intention of a component. An intention can be anything ranging from seeking generic functionality like sending an email to seeking service of a specific component. When a component raises an intent, the Android framework resolves it by invoking a component (may be part of the same application as that of the component or not) that could serve this intent. Intent can optionally carry additional data along with them in the form of bundle. Each component declares one or more intent-filters along with a numeric priority. An intent- filter can be seen as a way of declaring which all intents a component can handle.

[0042] An intent can be marked for a specific component (called an explicit intent), or be implicit about the target component (called an implicit content). In the latter case, the Android system follows an intent-resolution-process that matches the intent against the intent filters of each component and among the matched ones it chooses the one with the highest priority. Thus through intent, set of components can collaborate together to provide rich features to the user.

[0043] In the Android system, application security is driven through a simple permission system. Each component, via its application, must have the needed permissions to access sensitive data and protected system APIs. Components can also protect themselves using permissions. For instance, a component can specify a set of permissions and then only those components having these permissions will be able to access it. Permissions are grouped under four levels:

a. Normal: Each application is given these set of default permissions (e.g. the permission to start).

b. Dangerous: These permissions are explicitly requested from the end-user, at the time of installation. If the user does not grant these permissions then the installation fails (e.g. the permission to read contact information).

c. Signature based: These permissions are granted only to those applications that have the same signature. This permission level is used when a developer has multiple applications and wants to share data/components within his applications.

d. System or Signature: These permissions are provided to system APIs apart from other applications having the same signature. [0044] Though Android provides sandboxing to protect applications, memory space and permission system to protect components from being exploited by other components, it is not sufficient to prevent security violations, since permissions may be misused (intentionally or unintentionally) leading to leakage of sensitive data.

[0045] The component driven application model of Android makes it easy for an attacker to develop feature -rich Trojans and trick users in granting needed permissions. An attacker can deliberately interleave valid functionality with malicious action. Without arousing any suspicion, the attacker can request permissions (from the "dangerous" category) for the declared benign behavior and can use these permissions to perform malicious actions. This makes the Android permission system quite ineffective in dealing with such malware.

[0046] Trusted applications may also be the sources of accidental bugs, which in turn can be exploited by malwares to gain sensitive data without needed permissions. In these cases, malware' s action become completely legal as per Android security policy and detecting them becomes a challenge.

[0047] Several sources distribute third party applications ranging from Google play to regional app stores. Further, the sources of many apps can also be directly downloaded. An attacker can download a popular app from one store, repackage it after injecting malicious action and distribute it in other stores. This simplifies the attacker's task of distributing malwares as repackaged popular apps.

Example - 2

[0048] To demonstrate the confederacy attack, two applications AppA and AppB are used. AppA contains two components Al and A2. The component Al reads sensitive contacts data. AppB contains two components Bl and B2. The component B2 sends out a mail. By analyzing the behavior of these two applications individually, AppA reads sensitive data but doesn't send any data out whereas AppB sends out data but doesn't read any sensitive data. Hence they both are deemed safe. Stand-alone behavior of these two apps is shown in FIG. 4. If the component B2 has the same intent-filters as that of the component A2 but with higher priority, then the behavior of AppA changes (in presence of AppB in the target system) such that Al calls B2. In this case Al reads sensitive data and B2 sends it out through mail. Thus AppA and AppB, though deemed safe independently, carry out a malicious action collaboratively. Behavior of AppA in presence of AppB is shown in FIG. 5. [0049] ICSuite stands for IITM Chipmunk Suite for analyzing Android applications. The main features of ICSuite are:

ICSuite can analyze a given application (downloaded) along with its DDAB file to

a. Locally reason about the application - ICSuite can be used to certify that in the absence of any other interacting application, the standalone application adheres to the behavior specified in the DDAB file,

b. Reason about the application globally - By additionally taking into consideration the ICApps of other prior-installed applications, ICSuite can be used to certify that the application does not do any malicious activity, when it is run along with the other applications installed on the system. c. Reason about the complete system - By additionally taking into consideration the DDAB files of other prior-installed applications, ICSuite can be used to certify that the given application does not help any currently installed application do any malicious activity.

[0050] ICSuite can be used to generate ICApps for a given application that can be stored and later used to modularly analyze the impact of a newly downloaded application on the complete system.

[0051] In some aspects, generating the ICApps: ICSuite takes an apk file as input and first determines the list of components present in it. Then each component is statically analyzed to infer various pre-defined key actions performed by them. Then, track the flow of (possible) sensitive data in each of the components in a standalone fashion. These details are captured in the generated ICApps. For any given application ICSuite generates a single ICApps that encapsulates the behavior of all the constituent components.

[0052] In some aspects, for each application, ICSuite generates and stores its corresponding ICApps. ICSuite makes inferences regarding the interactions among the constituent components of the application and other inter-application components that the application depends on (by analyzing all the corresponding ICApps). ICSuite then builds a behavior graph that depicts the flow of sensitive data across all the components present in the application and the components of the other application they depend on. This graph can be a forest, in general, where each connected graph corresponds to a group of interacting components. The nodes of the graph are drawn from the set of components and key actions. The edges (directed) of the graph give the details of the flow of data. Two component nodes in the behavior graph are said to be interacting, if data can flow from one node to other. Two applications are said to be interacting with each other if their components interact. The behavior graph helps ICSuite to visualize the exact behavior of the given application in the context of a given Android system. Since ICSuite is analyzing the ICApps of all the applications and not the full-fledged binaries, it makes the analysis faster (analyzing large binaries Vs analyzing the small ICApps), modular (ICApps are generated only once per application and updated only when the application changes) and scalable (analyzing large number of bloated up binaries corresponding to all the installed applications versus analyzing just the ICApps). Future malware detection software, aiming to detect confederacy attacks, can be performed on the target system.

[0053] Based on working with Android applications, fourteen key actions that a component can use to interact with an external system. These actions are listed below.

Example - 3

[0054] Referring to the FIG. 6, the block diagram for ICSuite, comprises the following eight components: 1) MFReader, 2) CompTracer, 3) ID IN - a Dalvik Interpreter, 4) FlowGen, 5) Data Flow Analyzer, 6) IMapper, 7) IChecker and 8) Malwalyzer. Besides these components, ICSuite uses two open source tools APKTool and Baksmali. APKTool is used to extract manifest file from a given apk file, whereas Baksmali is used to disassemble the apk binary file into various smali class files. The eight components of ICSuite are discussed as follows.

[0055] ManiFest Reader (MFReader) takes the manifest file (extracted by APKTool from the corresponding to an apk file of an application) as input and provides information about each component that is part of the application. MFReader is an XML parser that parses manifest file, filters the needed information (e.g. class name, intent-filters) for each component.

[0056] In one aspect, flow Generator (FlowGen) is a program slicing based tool that takes an instruction and a method as an input and generates a minimal executable slice (flow), which can be used to determine values of parameters used in the specified instruction. To generate the slice, FlowGen starts with the instruction and computes an intra-procedural backward data and control chop bound by the method boundary. FlowGen also includes all the control statements that affect the generated flow.

[0057] IDIN stands for IITM Dalvik INterpreter. It emulates register based execution model of Dalvik Virtual Machine (DVM) and is capable of executing a program slice or a method under a specified context and affect register values accordingly. Hence IDIN can be used to retrieve the end result of a procedure or value of a parameter in an executable flow.

[0058] CompTracer stands for 'Component Tracer'. It takes the smali files and the component info, generated by the MFReader, as input and outputs the actions-map. For any given component, the actions-map returns the set of key actions performed by that component. CompTracer uses baksmali to disassemble the input apk file into various smali class files. Based on the component info details (provide by MFReader), it traces the corresponding smali classes and determines various event handler classes used by each component. Corresponding to each component, it then constructs a set of precise call-graphs, one corresponding to each event handler present therein. Each of these call-graphs is traced to identify instructions that trigger the key actions. These triggering instructions are fed to FlowGen to create a program slice, which in turn is fed into IDIN to determine values of various parameters used to trigger an action. CompTracer populates the actions-map with the exact actions performed by each component and the corresponding action parameters.

[0059] Data Flow Analyzer performs data flow analysis based on the actions-map (populated by CompTracer) to determine the flow of sensitive data in each component. For each component, it tracks all the 'Read Sensitive data' actions and does a static analysis of the taint flow. Each kind of sensitive data is tainted with different flags so that they can be tracked separately. Note that the data that a component takes as input is also considered as sensitive data and is tainted with a special flag. The taint flow analysis is a variation of the standard points to analysis to track the flow of taints via the heap. If any argument of an action may be used to access tainted data (either directly, or via one or more levels of field dereferencing, e.g., arg.fl.f2.f3) then the corresponding action is flagged to indicate the use of sensitive data by that action. These details are captured in an ICApps.

[0060] ICApps stands for ΊΙΤΜ Certificate for Android apps'. ICApps is stored in as a file in some suitable format (e.g., XML format) and it contains the list of all the components present in an application and some details thereof. For each component, ICApps includes details about the key actions performed by the component along with details about the flow of sensitive data across them.

[0061] DDAB stands for Developer Defined Application Behavior. The developer of the application provides the DDAB file for the application to define how the application deals with the sensitive data, with respect to the external world. It contains all the actions that send sensitive data out of the application along with information about type of the sensitive data. Currently, track the following types of sensitive data: Contacts (to represent the information present in the address book of the phone), SMSDetails (representing the details of the stored SMS), Devicelnfo (representing the device specific information, such as IMEI number/ SIM details, Phone number and so on). An example DDAB is shown in FIG. 7. This DDAB declares that the corresponding application may send out sensitive "Contacts" and "SMSDetails".

[0062] IMapper stands for 'Intent Mapper'. As the name suggests it maps each intent request of a component to the respective component that can handle it. IMapper builds an overall behavior graph of all the components that interact with the components of the given application, based on their ICApps. It does so by simulating Android's intent resolution process.

[0063] Integrity Checker (IChecker) takes as input the DDAB file (bundled in the apk file and extracted by APKTool), the stored DDAB files of all the applications that interact with the given application, and the behavior graph generated by analyzing the ICApps. IChecker first compares the downloaded DDAB file with the behavior graph to guarantee that the declared behavior of the given application conforms to the actual behavior, thus ensuring application's behavioral integrity. It then verifies the behavioral integrity of all the applications that interact with the given application, by comparing their DDAB file with the behavior graph.

[0064] Malwalyzer stands for Malware Analyzer, is an exemplar malware analyzer. It takes the behavior graph constructed by IMapper as input and analysis it, by comparing against a pre-defined notion of malicious behavior. For example, the verification routine to detect data leaks will check all the actions that send data out of the application and ensure that their parameters are not tainted. If it is tainted then it indicates a possible data leak. Thus, the proposed system can also be used to build new scalable tools to detect malware.

[0065] The working of ICSuite is explained using an example Android application (MessagePhisser), whose DDAB is given in FIG. 8, while its component level certificate is shown in FIG. 7. MessagePhisser app is a Trojan that claims to be a SMS message helper utility that can do a few fringe tasks, such as storing the received SMSes from a selected set of contacts in a password protected vault, automatically sending replies to SMSes (to a select list of senders) when busy, and so on. However, in addition, when it receives an SMS from a specific number (that of the attacker), it can send out two types of sensitive data (Contact and SMSDetails) to the attacker without the knowledge of the user, which is clear from a comparison of FIG. 7 and 8.

Example - 4

[0066] In one embodiment, a MessagePhisser app is exemplarily shown to comprise nine components. FIG. 9 illustrates how ICApps represents the behavior of this application at component level. For example, the component MessageReceiver performs four actions 1) receives SMS 2) reads data from ContactsContentProvider component 3) passes data received from action 1 (Receive SMS) to MessageCContentProvider component and 4) starts another activity (in.ac.iitm.MessagePhisser.MessageViewActivity). Individually, none of the components look malicious. During analysis, ICSuite merges the behavior of the components defined in the ICApps to ascertain the behavior of the whole application. FIG. 10 shows the behavior graph of the application generated by ICSuite by unifying various components present in the ICApps. By taking a closer look at this behavior graph, it is apparent that there is leakage of sensitive data. In SendSMS action of MessageSendService, sensitive data tainted as dl and d2 are sent out. In this application taints dl and d2 corresponds to SMSDetails and Contacts, respectively, which again can be inferred from the behavior graph. ICSuite, during analysis, checks the associated DDAB file of the MessagePhisser app to see if the declared behavior of the app matches with that of the inferred behavior. If the app developer hides this information by providing a benign DDAB stating that the app does not send any sensitive data out (as shown in FIG. 8) then ICSuite' s conformance check fails. ICSuite reports this as potential vulnerability. On the other hand, if the DDAB of the application mentions that the application intends to send out SMS and contact information (as shown in FIG. 7) then the application conforms to the declared behavior. In this case, the user is aware (through DDAB file) that the app is sending out sensitive data and he is making an informed decision to install it. This example not only illustrates how efficient ICSuite is, in detecting malicious behavior, but also shows how good it is in aiding manual analysis.

Example - 5

[0067] FIG. 11 presents a flow chart depicting the complete application analysis process using ICSuite and ICApps. It can be summarized into the following six steps.

a. The application developer builds an app along with a corresponding DDAB file. b. The developer uses ICSuite to generate the ICApps from the app. The developer uses the ICApps as a blue print of his application and self-validates it manually, to ensure that it is free of accidental bugs and unintentional vulnerability.

c. While the application is being hosted on an App store, ICApps of the application can be tested to ensure that the application doesn't perform any malicious action.

d. Android package is delivered to end user along with the DDAB.

e. The end user validates the downloaded application against the DDAB, using ICSuite, to ensure that the application adheres to the defined behavior. Thus integrity of the behavior of the application is guaranteed.

f. ICSuite analyzes the ICApps of the downloaded app along with ICApps of other applications already present in the system to detect confederacies.

[0068] While the above is a complete description of the preferred embodiments of the invention, various alternatives, modifications, and equivalents may be used.

[0069] Therefore, the above description and the examples should not be taken as limiting the scope of the invention which is defined by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method for determining the behavioral integrity of an application, comprising: obtaining, in a computing system, a stated behavior of a first application;

associating said behavior with a developer defined application level certificate;

obtaining, using the computing system, an automatically generated component level certificate for the first application, wherein the component level certificate is configured to capture a flow of data out of one or more components of the first application and to abstract the behavior of the first application using a set of parameters; and

determining, using the computing system, an integrity factor of the first application by validating the application level certificate against the component level certificate.

2. The method of claim 1, further comprising generating a component level certificate of one or more other applications and comparing said certificates with the component level certificate of the first application to obtain behavioral integrity of the first application in the context of the one or more other applications.

3. The method of claim 1, wherein the component level certificate comprises a certificate for an activity component, a service, broadcast receive, or a content provider.

4. The method of claim 3, wherein the component level certificate is generated by determining key actions performed by each of the components and tracking sensitive data in each of the components.

5. The method of claim 4, further comprising determining an interaction factor of at least two components where one or more components have a source outside of the application.

6. The method of claim 5, wherein the interaction factor is start an activity, send mail, access shared data, use service, send SMS, load Dex file, register receiver, access DB, send broadcast, access file, read sensitive data, use contact provider, or access a network.

7. The method of claim 1, wherein the flow of data captured by the application level certificate comprises contacts, SMS, MMS, IMEI number, or SIM details.

8. The method of claim 1, wherein the application is a mobile application.

9. The method of claim 8, wherein the application is an Android application.

10. A system for determining the behavioral integrity of an application, comprising:

One or more computer processors, memory, and

a non-transitory computer-readable storage medium comprising instructions, that when executed, control the one or more computer processors to be configured for: obtaining a behavior of a first application;

associating said behavior with a certificate, wherein the certificate comprises a developer defined application level certificate (DDAB), and an automatically generated component level certificate for the first application, the component level certificate being configured to capture a flow of data out of one or more components of the first application to abstract the behavior of the application using a set of parameters; and

determining an integrity factor of the first application by validating the application level certificate against the component level certificate.

11. The system of claim 10, further configured to generating a component level certificate of one or more other applications and comparing said certificates with the component level certificate of the first application to obtain behavioral integrity of the first application in the context of the one or more other applications.

12. The system of claim 10, wherein the component level certificate comprises a certificate for an activity component, a service, broadcast receive, or a content provider.

13. The system of claim 12, wherein the component level certificate is generated by determining key actions performed by each of the components and tracking sensitive data in each of the components.

14. The system of claim 13, further comprising determining an interaction factor of at least two components where one or more components have a source outside of the application.

15. The system of claim 14, wherein the interaction factor is start an activity, send mail, access shared data, use service, send SMS, load Dex file, register receiver, access DB, send broadcast, access file, read sensitive data, use contact provider, or access a network.

16. The system of claim 10, wherein the flow of data captured by the application level certificate comprises contacts, SMS, MMS, IMEI number, or SIM details.

17. The system of claim 10, wherein the application is a mobile application.

18. The system of claim 17, wherein the application is an Android application.

19. A method for determining the behavioral integrity of a first application, comprising: analyzing, using a computing system, application package binaries of the first application;

tracing, using the computing system, one or more components within the package; and

constructing, using the computing system, a component level certificate for the first application, wherein the component level certificate comprises a behavior abstract of the first application as determined by a set of parameters.

20. The method of claim 19, further comprising comparing the constructed component level certificate with a developer defined application level certificate (DDAB) of the first application, and determining an integrity factor of the first application by validating the application level certificate against the component level certificate.

21. The method of claim 19, further comprising generating component level certificates of one or more other applications and comparing said certificates with the component level certificate of the first application to obtain behavioral integrity of the first application in the context of the one or more other applications.

22. The method of claim 21, further comprising visually representing the application behavior.