Ariadnima - Android Component Flow Reconstruction and Visualization

Transcription

1 2017 IEEE 31st International Conference on Advanced Information Networking and Applications Ariadnima - Android Component Flow Reconstruction and Visualization Dennis Titze, Konrad Weiss, Julian Schütte {dennis.titze, konrad.weiss, julian.schuette}@aisec.fraunhofer.de Abstract Android applications are built with a set of different component types that serve specific purposes. Thanks to Android s system design they can interact with each other in a variety of ways, which makes it possible to complete complex tasks. The downside of the flexible interconnectivity of system components is that the relationship between them can be very complex and hard to understand. To give a better understanding of the interconnectivity of components, this work focuses on the reconstruction of relationships between the components of an app. Our approach focusses on real world applications by minimizing the need for complex calculations (e.g., flow analysis) where possible. On the basis of static code analysis component transitions will be reconstructed, and in a second step these transitions are then visualized to allow an analyst to easily understand the relationships of the app s components. Keywords. Android component transitions, component reconstruction, static analysis, visualization I. INTRODUCTION In the last years Android has risen to be the dominating smartphone OS with a market share of 87,6% in Q [5]. This is also reflected in the huge amount of Android applications available: over 2.4 million only on the Google play store [10]. Android apps are typically comprised of many different components which interact in many different ways with each other. Although this offers flexibility for the developers, it also makes it difficult to grasp the relationship between components. This can lead to developers having a hard time understanding how components depend on each other when they newly enter a project. That fact makes it also difficult for security analysts to uncover flaws in Android applications that emerge from the combination of different components, inside and across applications. In Android four different types of components (Activities, Receivers, Services and Providers) are used for four different purposes. The main component users see are activities. Activities are components that represent a visual interface to the user which can contain sensitive application information. By reconstructing the flow of activities in an application, information on what tasks can be completed with this application can often be uncovered, which also helps in the discovery of wanted and unwanted behaviour. But since the transitions between the app s components is not obvious, the reconstruction of the transitions is helpful for understanding the app s functionality. To solve the problem of reconstructing the transitions existing research already worked on Inter Component Communication (ICC) reconstruction [7]. Focus of their work was to produce a highly precise reconstruction based on dataflow analysis which can be very time- and resource consuming for real life applications. In contrast to this approach, our approach uses a data flow agnostic reconstruction of component transition parameters which makes it more usable for real life applications, albeit at the price of a lower accuracy. The reconstruction of the Android Component Flow Graph (AFG) is a special form of the Inter Component Communication problem, as not all ICC is relevant for our approach since only the first communication between components starts the target component and is therefore counted as transition. All further communication between these two components does not start any new component and is therefore not relevant in our case. The contribution of this paper is to statically reconstruct component transitions to solve the problem of unclear application component relationships. Transitions are defined as communication over API calls between two components, where the second component is started by the first component via this call. First, all API calls which trigger such transitions are specified. In the second step the parameters of these calls are reconstructed using a backward tracking to calculate the target component. The third step is to determine the caller of the transition, which is also done by backtracking from the API call. An architecture called Ariadnima was developed for this research to reconstruct component transitions and visualize them as a Android Component Flow Graph with special focus in a detailed representation of the activity component. This paper is structured as follows: Section II introduces work related to this paper, Section III details the background necessary for understanding possible component transitions and their reconstruction. Section IV shows how the transitions can be reconstructed and then in Section V how these can be visualized. Section VI evaluates the proposed solution followed by a discussion in Section VII. Section VIII concludes this paper X/17 $ IEEE DOI /AINA

2 II. RELATED WORK Some researchers already worked on related topics, especially the reconstruction of intents. The static intraprocedural reconstruction of Intents by Dienst et. al. [2] uses information from the AndroidManifest.xml and static analysis on top of Dalvik bytecode to reconstruct intent based application dependencies. Our approach considers a broader spectrum of functionalities that can cause component transitions and also uses an interprocedural reconstruction approach. The most prominent approach for reconstructing Inter Component Communication is Epicc [7] which reduced intent reconstruction to an Interprocedural Distributive Environment (IDE) problem. Their approach aims at a very precise reconstruction of the possible ICC. Although their work solved a superset of problems our approach tries to solve, the tools and approach were not considered because they used forward flow analysis which was considered too expensive for the reconstruction of an AFG in bigger applications. As we are only interested in the starting of components itself, and not the full interaction, a full data flow analysis can be skipped. Instead, our approach reconstructs the relevant objects in the inverse direction of program execution. Epicc uses the algorithm described by Sagiv et. al. [8] which has a runtime of O(ED 3 ) (E being the number of edges in the program, D being the symbols), but since not all prerequisites are met the runtime of Epicc is even longer. Since we only traverse the graph once for each API call that starts a transition, our approach has a runtime of O(ED). Our approach still relates to several of the concepts such as the ICC locations and metrics to specify reconstruction accuracy, the view on Intent filters, runtime registered receivers, URI reconstruction, entry and exit points in the application. Similar to Dexteroid [6], Android life cycle models and related callback methods of the four main components and other views or callbacks have been included in our approach to catch all entry points in the application s execution. III. BACKGROUND This section shortly describes the most important terms used in this paper: in the rest of the background: Inter Component Communication: The process of application components interacting with each other. This happens using specific API methods and can be done internally in an application or across components of different applications. Component transition: Subset of ICC where one component causes another component to become active. If that component was not started before, it will be also created. Call site: A call site is a location inside a function where a given method or function is invoked. A. Application Components Developers can extend four different component types to fulfil different tasks when building an application. To be known by the system components have to be declared in the AndroidManifest.xml or added programmatically. Components that are implicitly or explicitly exported in the manifest are reachable by third party applications as interfaces to access some of the applications functionality or data. 1) Activities: As UI controllers, activities manage what is shown to the user and what code is executed on a users input. The activities callback methods and all callback methods of added View components are the beginning of code executed in this component. 2) Services: Services handle long running background tasks that should run independently of what is currently visible to the user and continuously run in the background until the task is finished or the service is stopped. They start running when they are started or bound to by other components via startservice(...) or bindservices(...). 3) Broadcast receivers: Broadcast receivers are components that can be implemented to handle certain broadcasts and perform actions when they are received. After their callback method onreceive(...) is called they have only a limited time to react to the received broadcast before they are terminated if they are not specified to run on a separated thread than the main thread. 4) Content providers: Content providers are used to provide access to the internal data of the app to other apps. Providers are used to have a safer and more secure interface to the data providing create, request, update and delete operations (CRUD interface) by overriding the respective methods of the ContentProvider class. The content providers CRUD-methods are the callback methods that start the provider. B. Component lifecycle Every component type has a specific life cycle that is managed by Android. The Android system changes the life cycle state of a specific component and notifies the component by invoking one of its callback methods. These callback methods are the start of every execution path that occurs in the application. If a component is exported to other applications the callback methods represent entry points into the application. C. Component transitions In Android certain functions on certain objects trigger the system to start a new component. Those functions are the transition points from one component to another. The functions and objects they are executed on may already specify the component type that is started. Intent objects for Activity, Receiver or Service components and URIs for 337

3 Providers are then used as parameters to further specify the transitions target. 1) Intents and Intent filters: Several functions use Intent objects as parameters such that the underlying messaging system can identify the transition target. When intents are used in a transition, the target component name can be set explicitly making it an explicit intent. In the other case, the intent can specify four information types to limit Android in which components such an implicit intent will be delivered to. An action string specifies which task a resolved component should be able to perform. A data URI and/or MIMEtype can be specified that the resulting component has to handle certain data. One or more intent categories further limit the intent according to certain context information. Finally the transition can be limited to a component with a certain package name. Every component that wants to receive implicit intents has to tell the Android systems which Intents can be delivered to it by specifying one or multiple intent filters. Action strings, categories, data URIs and types can be set for every Intent filter statically in the AndroidMainfest.xml or dynamically during runtime. 2) Further transitions: Other actions can further result in component transitions: Intent Sender: can be used to directly cause an intent based transition. The IntentSender object contains an Intent to be send, an action to be performed with the Intent and the identity of the creating application. IntentSender instances can not be created directly, but have to be retrieved from a instance of PendingIntent. Pending Intents: To allow the delegation of intents to other applications Android allows the creation of pending intents. These are wrappers for IntentSender objects created from an Intent and designed to be handed over to third-party applications. Every application, creating or recipient of the object, can trigger a transition by using the objects send methods. Activity Hierarchy: Every activity can declare a parent activity in the AndroidManifest.xml. If that activity is visible when the navigate Up button is pressed by the user, Androids default behaviour is to start the parent activity, causing an additional type of component transitions. D. Exported components Several of the internal components may be exported in the AndroidManifest.xml to make them reachable (i.e., startable or callable) by components of other applications. Their exported status can be explicitly set by setting the android:exported attribute to true or false. If the flag is not set implicit rules are applied: Activities, Receivers and Services are implicitly exported if they have specified an intent filter. Providers where implicitly exported until Android 4.2 and then changed to be exported only if the attribute android:exported is set to true. IV. TRANSITION RECONSTRUCTION Figure 1: The six main phases of the AFG generation Table I: Example Functions Starting an Activity Using Intents Base class Return type Function Context void startactivity(intent i,...) Context void startactivities(intent[] i,...) Activity void startactivity(intent i,...) Activity void startactivities(intent[] i,...) Activity void startactivityforresult(intent i,...) Figure 1 shows the steps needed for reconstructing a Android Component Call Graph. Step 1 and 2 are the preparation of the app which is done using the analysis framework Soot [9]. Step 3 determines the target of the component transition, and Step 4 determines the source of the transition. The targets and sources are then condensed into a graph in Step 5. To make the resulting more comprehensive, a dynamic analysis step generates screenshots of all activities of the app. A. Argument Reconstruction Callee Determination The first step to reconstruct the transition is to find the line of code which starts it. For each of the components described in Section III-A, many API calls exist which start such a transition. Therefore, the Android Developer Documentation [3] and the Android Source Code [4] was searched for any API call which starts such a transition. Some example transitions for Activities are listed in Table I. To find the component that will be the target of a component transition, the arguments going into the API call that starts the transition will have to be reconstructed. Our approach reconstructs objects backwards from the API call where they are used by traversing all possible intraand interprocedural execution paths. The objects used as arguments for the transition starting API call are primarily String, Class and ComponentName objects. These will be reconstructed in this step.the objects can be directly used as arguments for the call sites or to define the content of an Intent. Ariadnima will reconstruct them interprocedurally to get more defining values for the call sites but ignores intraprocedural data and control flows 338

4 Figure 2: Code Example of Activity Transition (DC-agnostic) to get a faster reconstruction at the price of an overapproximation. When the reconstructing of one of these objects is started Ariadnima will search for all defining assignment units or units where those objects are used for an invocation and resumes reconstructing them there. Due to the DC-agnostic analysis, this can cause unused values to be part of the final set of assumed values for that object. An example is shown in Listing 1: the String reference is assigned multiple string constants which overwrite each other: only the last assigned string will be valid but the analysis will consider all of them as valid, therefore overapproximating the possible targets. String str = "Activity1"; str = "Activity2"; starttransitionwithstring ( str ); Listing 1: Overapproximated String B. Caller Determination Until now the possible contents of objects that go into transition-causing API calls were reconstructed and sets of possible target components for those transitions were defined. That leaves the analysis with reconstructing the source components. As explained in Section III-B, the components of an app are managed by the Android system. For all components, several functions exist which can be called by the Android system at certain times during the app s lifecycle. For example, the function oncreate() of an activity is started as the activity is created. To determine possible callers, the call graph is traversed backwards from the call site to search any such functions started by the Android system. Since the calls can originate in different classes of the app, a simple lookup of the current function is not sufficient, and the full backward analysis of the call graph is needed. The result of the caller determination is a list of components which can if a certain call path is executed lead to the transition to the other component. As the caller determination is only a static analysis, the call path might not be executed during runtime (e.g., if certain conditions are never met, which could not be determined statically). C. Activity flow graph construction After collecting valid targets and sources for the defined API call sites the graph is built. First the construction will add all internal components as nodes. Then the construction will iterate over all edges and add both internal edges between the app s components to the graph, as well as all external edges (e.g. an Intent which would start a component of another app) to nodes representing the externally started components. D. Example Figure 2 shows an example of an App containing two Activities MainActivity and SecondActivity. 1) The first step searches through all code locations if an API call exists which can initiate a component transition. In our example, only the API call startactivity(intent) is found. 2) As the value of intent is not known at this location, the Argument Reconstruction phase performs a backward search for all possible values of intent. As described in Section IV-A, only performs a DCagnostic search. In this example the search yields the value SecondActivity.class as possible target of the transition. 3) In the next step, the caller of the transition is reconstructed by reversing the call graph until all lifecycle methods which can lead to this call site are found. The classes containing those lifecycle classes are the possible callers of the transition. In this example, the call graph is traversed backwards to the function oncreate which is a lifecycle function. The class MainActivity containing this function is therefore one possible caller of the transition. The algorithm therefore determined that there is a possible component transition from the activity MainActivity to 339

5 Figure 3: Graph showing incoming and outgoing paths to one component the activity SecondActivity using the API function startactivity(intent). V. VISUALIZATION The result of the previous analysis phase is a textual representation of all nodes, connecting edges and meta information including the type of edge, which Intent resulted in which transition, etc. Additionally, the activities of the app are started to capture a screenshot of the activity. In many cases the screenshot reveals the intention of the activity to an analyst. For example, it might be easy to distinguish a settings activity from a terms-of-service activity. For visualization, this data can be presented to the analyst using many different readily available tools. For our visualization, the network graph component of visjs [1] was used to display the graph. Figure 3 shows such a graph of an example app. This graph shows different named activities and their connection between each other. The graph also shows an external Intent com.google.android.c2dm.intent.register which will be sent from the app to the Android system, which then forwards it to any app registered to the Intent. Further optimizations to simplify the resulting graph were implemented including merging of identical edges (i.e, an activity starts the same other activity in different code locations), and a configurable hiding of certain edges (e.g. hiding of all internal edges to only show which external components the app tries to start). VI. EVALUATION In an evaluation, 100 apps taken from Google Play s newest and most-popular category were randomly selected (in March 2016). The apps ranged in size between 380kB and 50MB (average: 14.9MB). The evaluation was done on a virtual machine with 16 Gigabytes of memory 4 CPU cores. The timeout for the Soot Call Graph construction and code parsing phase was set to two hours. If Soot stopped due to the timeout, the Android Component Flow Graph was not further reconstructed. This was the case for 5 apps, which were excluded for the following time measurements. A. Reconstructed transitions To measure the completeness of the target reconstruction process a similar metric will be used as in the measurements in Epicc [7]. After the reconstruction process that started with a set of call sites our tool considered relevant, the ratio of call sites where at least some target information was found to the original set of call sites will be calculated. This metric does not perfectly reflect the accuracy of the reconstruction as the number of different target information going into one call site is neither measured nor known. Additionally the metric only counts the API call sites that were considered in the analysis. So missed transitions due to not considered API functions have no influence on the measurement. After the analysis 54% of the initial call sites had some reconstructed target information and for 47% of all processed call sites not only target information was found, but at least one source component could be identified. Those 47% of call sites will have edges in the resulting Activity flow graph. B. Runtime Table II shows the median time spend in the different phases and the median total time. The runtime evaluation 340

6 Table II: Median Runtimes of the Reconstruction Phases Phases Unpacking Screenshots Soot Targets Sources AFG Total Time (s) Relative (%) shows that the main efforts for the static analysis are spent in the preparation phase (Soot). Reconstructing the targets and sources and the resulting graph takes much less time. Another big part of the runtime is the screenshot phase where a screenshot of each app is taken using a virtual device. This could be further improved, e.g., by using a real device instead of a virtual one. VII. DISCUSSION The approach of this work allows the reconstruction of the parameters needed for target reconstruction. As new Android versions often introduce new API functions, the analysis is specific to one Android version. For any other version, all possible transition API functions need to be identified and added to the tool. If new parameters need to be reconstructed, their reconstruction needs to be added to the tool as well. The main analysis is based upon Soot which e.g., produces the Call Graph. Soot currently does not analyse any native code, which is therefore also not analysed in our tool. Further the analysis of Ariadnima is dependant on the precision of the Call Graph produced by Soot. This Call Graph does e.g., not include calls made using Java Reflection. As Ariadnima uses a DC-agnostic approach to reconstruct the arguments of a transition, the resulting Android Component Flow Graph lacks precision compared to other approaches (although at the big benefit of a much lower complexity). In the future we plan to increase the reconstruction precision in those cases the resulting graph will most benefit from the higher precision, e.g., by performing flow analysis on very limited parts of the code. The evaluation showed that the taking of screenshots consumes a lot of time, which will further be improved in the future. VIII. CONCLUSION The goal of this work was to build a tool to reconstruct an Android Component Flow Graph representing the direct and indirect transitions between components in an application, and the transitions into the Android system. The focus of our work was not to have a graph which is as precise as possible, but to have an approach capable of analysing real life applications. To achieve this, several simplifications were used in the approach, mainly a data and call graph agnostic reconstruction of transition call arguments. The second focus of the work was to generate a meaningful visualization, which was realized by capturing screenshots of all activities and representing the graph with all connected components and their screenshots. An evaluation of Ariadnima has shown that although being practical in terms of runtime for real apps, the data and call graph agnostic reconstruction of transition call arguments results in several missed transitions. In our tests, 47% of the transitions were recovered. An analyst therefore needs to decide if a high precision is needed which requires a resource intensive data flow analysis, or missing several transitions is acceptable. In the latter case, Ariadnima can provide a sufficient solution. REFERENCES [1] vis.js - A dynamic, browser based visualization library. [2] S. Dienst and T. Berger. Static Analysis of App Dependencies in Android Bytecode. 0:1 10, [3] Google Inc. Android Developer Documentation. [4] Google Inc. Android Open Source Project. [5] IDC. Smartphone OS Market Share, 2016 Q2. [6] M. Junaid, D. Liu, and D. Kung. Dexteroid: Detecting Malicious Behaviors in Android Apps Using Reverse- Engineered Life Cycle Models [7] D. Octeau, P. McDaniel, S. Jha, A. Bartel, E. Bodden, J. Klein, and Y. L. Traon. Effective Inter-Component Communication Mapping in Android with Epicc: An Essential Step Towards Holistic Security Analysis. USENIX Security Symposium, pages , [8] M. Sagiv, T. Reps, and S. Horwitz. Precise interprocedural dataflow analysis with applications to constant propagation. Theoretical Computer Science, 167(1): , [9] T. U. D. Secure Software Engineering Group. A framework for analyzing and transforming Java and Android Applications. [10] Statista. Google Play Store Statistics September