Formal model for inter-component communication and its security in android

The Android application framework has a pervasive presence. In early 2021, Android has over 70%\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$70\%$$\end{document} share of the operating system mobile market (according to GlobalStats). Components are the main building blocks of Android Applications. These blocks communicate via a rich Inter-Component Communication (ICC) model rather than the traditional inter-process communication model. Intents, Intent-filters, and their Intents resolution (matching) algorithm are main elements of the ICC. However, the Intent resolution algorithm is not robust enough and has flaws that can lead to security breaches. In this paper, we present DLAIR, as an enrichment of the Intent resolution algorithm to overcome its security issues. To this end, we start by presenting a formal model to express and validate the ICC semantics. This includes defining key properties guaranteeing consistent and realistic semantic states. We then demonstrate how the semantics can be used to formally validate ICC aspects and to express and check ICC system updates. We verified our proposed model and all its lemmas and theorems in the Coq Proof Assistant, a machine-assisted verification tool. We extend our semantics to develop DLAIR which is assisted by a heuristic, and lightweight tool, LekInt. This tool identifies suspicious execution paths responsible for intent based sensitive user-information leakage. On a dataset of 2000 real-world apps, we evaluated LekInt against Flowdroid, a state-of-the-art information leakage analysis tool. Experiments show that LekInt is more effective and efficient than Flowdroid which has a higher false-negative rate and lower false-positive rate than LekInt. Considering the dynamic context in which LekInt is designed to work, the advantage of efficiency overcomes the disadvantage of higher false-negative.

captures Intents, Intent filters, Intent-related APIs, and finally the Intentresolution algorithm matching Intents and Intent filters. We define a set of key properties that guarantee a consistent and realistic Android state in our proposed semantics. We label the states satisfying such properties as "well-defined". Further, we prove that the transitions of the proposed semantic preserve the "well-defined" propriety of states. Then, we prove the effectiveness of the semantics in two ways: i) We express different aspects of ICC such as changing Intent types via its attributes; ii) We express and check a specific potential update for improving ICC security. The update includes inserting a caching element to semantic states so that processes that led to security breaches can be reported and avoided later on. We expressed and the model and verified all its lemmas and theorems with Coq proof assistant, a formal modeling tool [10]. We present the proof of one lemma in the paper and make proofs of all other lemmas and theorems available at our GitHub repository. 1 Based on our ICC formalization, we propose DLAIR, a security-aware algorithm for Intent resolution. To assist DLAIR, we propose a lightweight and heuristic tool (LekInt) that identifies suspicious execution paths. These are the paths that use Intents in a way that is suspicious of leaking sensitive data. On a set of 2, 000 realworld apps, we evaluated LekInt and compared it against Flowdroid [3], the stateof-the-art information leakage detection tool. The evaluation proves that LekInt is more effective and efficient than Flowdroid. LekInt and Flowdroid reported issues in 824 and 425 applications, respectively. The average running times per application for LekInt and Flowdroid are 47.8 and 74.6 seconds, respectively. Therefore LekInt has a better time complexity than Flowdroid. Efficiency is an important factor as LekInt is to run dynamically as part of Android. On a set of 100 apps, Flowdroid has higher false-negative rate (21 against 8) and lower false-positive rate (4 against 13) than LekInt. Bearing in mind the dynamic environment in which LekInt is designed to work, the advantages of efficiency and high true positives rate overcome the disadvantage of high false-negative rate (due to the approximation adopted in LekInt to boost its lightweight feature). Some of the issues reported by LekInt, which were not identified by the Flowdroid, are referred to in this paper. The metadata of the dataset and results of the experimental evaluation are available in our GitHub repository. 2 Contributions This paper has the following contributions: Paper Outline The paper is organized as follows. The most relevant state-of-the-art is critically evaluated and discussed in Sect. 2. Necessary background is presented in Sect. 3. The threat model that motivates the work in this paper is presented in Sect. 4. Section 5 presents our formal model for ICC framework. This model comprises the semantic states and key properties defining well-defined state. The main APIs of ICC have been discussed in this section as well. In Sect. 6, we present semantic rules for the framework APIs and prove that, semantic preserves the "well-defined" predicate of states. Section 7 utilizes the semantics presented in the paper to express basic and advanced ICC attributes. Section 8 presents DLAIR including the lightweight tool LekInt and its design, implementation, and evaluation.

Related work
Many studies have been published on intents and component communication using intents. This section reviews recent studies focused on these issues and also on Android formalization [5,28]. Potential future research is also discussed in this section.
Permissions are located in application manifest files. Permissions can be realized as requests to acquire access to delicate resources. Betarte et al. [5,6] presented a model for formalizing permission system of Android 6. They also formalized and proved some properties and security mechanisms for the permission model of Android using Coq. While our model targets the interesting behavior of intents and intent filters simply, the work in [5,6] is focused on the permission system in a complicated way. Chin et al. presented a tool, ComDroid [9], to check application interaction in Android. The tool is based on code analysis and detects security vulnerabilities related to data leakage in Android components. However, unlike our work, ComDroid is not supported by formal semantics to application interaction or its analysis steps.
Xu et al. presented a malware detection method, ICCDetector [29] which needs training with sets of benign applications and malware. This method focuses on the interactions among components of the same application. However, most other similar methods focus on resources claimed by malware such as permissions, system calls, and API calls. The work in our paper can be realized as a formal way to represent this interaction between components. Feizollah et al. [16] studied the effectiveness of including intent information in a characterizing feature for detecting malicious applications. They claimed that using intents reveals more precise malware behaviors than using only permission features. This emphasizes the need for a formal model to intents such as the one presented in our paper.
Building on the Android framework, Schmerl et al. presented a technique, Raindroid [25], that boosts security and preserves extendability. Raindroid relies on static analysis methods to recognize interaction among applications. The technique relies also on run-time methods that observe these interactions. Then the methods advise the system to reject interactions, require user permissions, or grant them. However, formal reasoning about the correctness of the advice is not presented in the paper. The model presented in our paper can be augmented with specific APIs to provide formal reasoning. Barros et al. presented static-analysis methods for Java reflection and intents in [4]. These methods are based on implicit control-flow. The methods also reveal control-flow points and data passed at these points. While our work is based on axiomatic semantics to precisely capture the Intent concept, the work in [4] uses type systems to treat intents.
Android has a mechanism by which an application can have private components. Such components are not accessible by other applications. Using next-intent vulnerability (NIV), this privacy can be bypassed by malicious applications. Hence private components become invocable by other applications. In [26], Tang et al. proposed an intent-flow static analysis NIVAnalyzer to investigate smali code and reveal NIV. The static detection is then followed by a dynamic verification via crafted exploit applications. However, the method is not supported with a formal model proving the correctness of the analysis. Some of the APIs used in NIVAnalyzer are given semantics in our model. Also remaining APIs (such as getIntent()) used in NIVAnalyzer can be added to our model easily. This can lead to formal reasoning about NIV.

Background
Android Concepts The building blocks for the Android app development framework are activities (UI tasks); broadcast receiver (system-wide broadcasts); content provider (data handling); and service (background services). A service is a group of background processes that do not have a user interface since they execute in the background. Broadcast receivers are background event observers that are commenced by other components. Content providers enable reaching and treating memory contents such as files, folders, and databases [11,20].
Intent 3 is a messaging object used for communication between the app components. Intents are either explicit or implicit. An explicit Intent determines the target component which is usually in the same app. Implicit Intents do not specify a certain component. Instead, they specify the needed action. This makes it possible for a component from another app to do the action. Listing 1 illustrates an example of an explicit Intent usage, ImpViewIntent also manifests implicit intent example. ImpViewIntent exhibits the action for viewing text. ImpViewIntent requests that another adequate app shows the text (announcement).
<activity android :name="ViewActivity"> <intent−filter > <category android :name ="android . intent . category . DEFAULT"/> <action android :name ="android . intent . action .VIEW"/> <data android :mimeType ="text / plain"/> </intent−filter > </activity> Intent Resolution Intent resolution [13] is the process of assigning a convenient component to a given implicit Intent. The assigned component must contain an Intent filter whose attributes match corresponding ones in the Intent. These attributes are action, category, and data. Therefore, Intent resolution includes three tests: action, category, and data tests. The tests are formalized n Table 2.

Threat model
This section presents the threat model which motivates us to formalize the intent resolution mechanism. The threat model visualized in Fig. 1 depicts main entities of the Android system; App1, App2, and Intent Resolution Algorithm (IRA). App1 has a component Comp1, that defines an implicit Intent, I , to start an activity. We assumes that I stores sensitive data in its Extra field. This is fair assumption as it common for Intents to store sensitive data [1]. Then I is passed to the API startActivity that asks Android to start an activity with characteristics determined in I . The Android system passes I to IRA to find a matching component. App2 has a component, Comp2.
The manifest file of App2 has an Intent filter, F, corresponding to Comp2. IRA uses F to check if Comp2 is a good match for I . If I and F match each other, I (with the wrapped sensitive data) is passed to App2 that initiates an instance of Comp2. The flow of I from App1 to App2 is an example of leaking sensitive data in the ICC framework.
The example above shows that there is a need for a lightweight and heuristic algorithm that identifies Intent-related sensitive data leakage. This need motivated our paper. The lightweight nature of the algorithm is justified by the fact that it is to be used dynamically while the app is running. Therefore the algorithm should not affect the performance significantly. The heuristic aspect of the algorithm is due to the fact that it should recognize cases where there is no need for security checks. Examples of these cases are when the checked Intent and the Intent filter are protected by permissions. In cases like these, the sensitive data passing is intended for some logical reasons related to the functions of the involved apps. The other motivation for this paper is the need to build the algorithm on formal semantics for the process of Inter-Component communication (ICC). It would be an advantage if the semantics is general enough to reason formally about ICC functional and security aspects [29].

Semantic states
In the following, we present the basis of our formal model for Android ICC. This section introduces the states of the model and axiomatic semantics [18,23] for Intent APIs. The semantics are formalized as state-transition maps that preserve a well-defined feature of states. The theoretical model is verified with the proof assistant Coq [10].
An Ù application, as described in Fig. 2, is a pair of an application id, AppID, and a manifest, Manifest. The Manifest component is a formalization of the Android manifest file. The Manifest is formalized as a pair: Comp * representing the application components and Compf representing Intent filters together with their hosting components. A component (Comp) is an element of the set {Activity, Service, BroadReceiver} which are uniquely specified using identifiers [11]. Moreover, the Service has a Boolean (ClientServer) that specifies whether the service is a client or server one. The sets AId, SId, BId denote sets of activity IDs, service IDs, and broadcast receiver IDs, respectively. The union of these sets forms the set of component IDs, CmpId. Since the Components are implemented as classes, the Android framework creates instances of the component classes at run-time. In the following, the instances will be referred to as component instances. As long as the instance exists, we call it an active or a running instance. We describe a component as installed (downloaded) means that the component and its app are included in the system under study [11].  The notation IComp denotes a component instance. The instance is identified via an ID, InstId.
The proposed semantics relies on the notion of well-defined system states. The notion captures system states satisfying realistic Android characteristics. These characteristics ensure states respecting the principles of Android OS. Formally, this notion is expressed as a predicate (WellDefined) on system states (SysState). Figure 4 shows the formalization of the predicate and its sub-predicates in the proof assistant Coq [10]. All the predicates assume a state variable s ∈ SysState. To precisely simulate semantics [18,23] of Intent APIs, we define some predicates and functions in Coq. These are presented and described in Table 1.
The following sub-predicates compose the WellDefined predicate:

IsService(c)
Holds if c is a service.

IsBroadCast(c)
Holds if c is a broadcast receiver.

ExpInt(i)
Holds if i is an explicit Intent.
Intent_hasA(i) Holds if the Intent i has a value (rather than None) in its Action field.

Intent_hasD(i)
Holds if the Intent i has a value (rather than None) in its Data field.

Intent_hasC(i)
Holds if the Intent i has a value (rather than None) in its Category field.

Intent_hasE(i)
Holds if the Intent i has a value (rather than None) in its Extra field.
Holds if the Intent i has the value (e, v) in its Extra field.
IntentF_hasA( f ) Holds if the Intent filter f has a value (rather than None) in its Action field.

IntentF_hasAa( f , a)
Holds if the Intent filter f includes the action a in its Action field.
IntentF_hasD( f ) Holds if the Intent filter f has a value rather than None in its Data field.

IntentF_hasDd( f , d)
Holds if the Intent filter f includes the data d in its Data field.

IntentF_hasC(f)
Holds if the Intent filter f has a value (rather than None) in its Category field.
holds if the Intent filter f includes the category c in its Category field.

CompInApp(c, a)
Holds if c is a component in the application a.
InFComp(c, f ) Holds if the Intent filter f belongs to the component c.

RetCmpId(c)
Returns the identifier CompId of the component c.

SerHasclntSerInt(c)
Holds if the component c is a service and the value of its attribute ClientServer is True.

CompDwnloaded(c, s)
Holds if the component c belongs to an application in the state s. Intent i and Intent filter f implies two conditions. The first condition is that i is an implicit Intent in an installed application, a1. The other condition is that f belongs to an installed application, a2.
We later prove that the predicate WellDefined is invariant concerning transition maps of the semantics [18,23]. Figure 5 presents APIs that are related to Intents. The formal semantics of the APIs is presented in the next section and their description is as follows: o startActivity(i) starts an activity that is determined by the Intent i. o startService(i) starts a service that is specified by the Intent i. o sendBroadcast(i) sends a broadcast that is fixed by the Intent i. o setComponent(i, option cmpId) explicitly sets the component that the Intent will target. o setAction (i, option act) sets the attribute Action of the given Intent. o setData(i, option dat) sets the attribute Data of the Intent i. o addCategory(i, cat) adds a category to the list attribute Category of the Intent i. o putExtra(i, ef, ev) sets the attributes ef and ev of the Intent i.
These APIs include ones that start a component via an Intent. The APIs also include ones that modify attributes of Intent objects. Therefore, the APIs are among the ones most used by Android programmers when using Intents. The behavior described above for the APIs is based on the official specification by Google [11,13].

Semantic rules
This section presents the semantics of the Android APIs (Fig. 5) most related to ICC. The semantics is captured by determining pre and post conditions. For each api ∈ API, a pre-condition expresses the conditions of a system state able to execute api. However, its post-condition describes the main characteristics of the system state resulting from executing api. The relationship denotes the execution of api. Figure 6 introduces the conditions pre(s) and post(s ) such that api : s s . We first provide a higher level of explanation for intent resolution and then present its formalization. We then use the formalization in the semantic rules. An Intent filter passes the action test if the Intent action is one of the filter actions. However, if the action list of filters is not empty and the Intent has no action included, the filter passes the test. To pass the category test, Intent categories have to be included in filter categories. The data element (of Intents and Intent filters) can have a MIME data type and a URI structure. The URI has four separate parts: scheme, host, port, and path. Although these parts are optional, their existence respects linear dependencies.
The action, category, and data tests of intent resolution are formalized in Table 2. Examples of applying rules of Table 2 are provided by the implicit Intent and the intent filter given in the Listings 1 and 2 of Sect. 3. We show some application cases. Rule 3 (L.H.S.) can be applied as follows: the condition category-default ∈ (Category) * f applies because the category DEFAULT belongs to the intent filter. Also the condition (Category) * i ⊆ (Category) * f applies because the intent is satisfied through the second part of the "OR" connector. This is so because both the intent and the intent filter have the action VIEW which is denoted in the rule by a.
In Fig. 6, the precondition of startActivity(i) requires the existence of a component c that resolves the Intent i. The component has to be an activity (IsActivity(c)) and installed in the state s (CompDwnloaded(c,s) IntentResol s = IntentResol s . 5. There is an instance ic of the activity c that is running in s . The instance was created as a result of executing the API. Therefore, ic does not belong to the state s. 6. Suppose that an ic is running in s . Then ic was running in s or ic = ic . 7. If i is implicit, then the process of intent resolution was carried on. Therefore an Intent filter f was found in c such that i matches f . This is recorded in IntentResol s .
The semantics of the APIs startService(i) and sendBroadcast(i) are similar to that of startActivity(i). However, for startService(i) and sendBroadcast(i), one of the changes is to replace IsActivity(c) with the convenient function: IsService c or IsBroadCast c. The descriptions of semantics for setComponent and setAction given in Fig. 6 are similar to that of startActivity. The semantics of APIs setData(i, dat), addCategory(i, cat) and putExtra(i, ef, ev) are similar to that of the API setAction (i, act).
In the following, we prove that the predicate WellDefined is preserved by onestep execution of any of the APIs of Fig. 5. This means that executing an API starting from a WellDefined state results in a WellDefined state. The proofs of all following lemmas and theorems were verified in Coq and their verification is available online. 4 Hence, we only show the proof of Lemma 1.
We need to show the same for the state s . Therefore we assume a : App, i : Intent, and (WaitImpInt s ) a i .
Now it is enough to show that ImpInt(i ). For i, i , we have i = i or i = i . We prove the required in both cases: By definition of implicit intent, this implies ImpInt(i), which implies ImpInt(i ). 2. The proof is by induction on the set API. We show only the case where API = startService(i). By assumption, for the state s we have: We need to prove the same for the state s . Hence we assume Now it is enough to show that By applying the postcondition of API (sub-condition 3) again, we get the required.

The proof is by induction on the set API.
We show only the case where API = putExtra(i,ef,ev). By assumption, for the state s we have: We need to prove the same for the state s . Hence we assume Now it is enough to show that a 1 = a 2 . By the postcondition of API

Semantics utilization
This section employs the semantics presented in the previous section. The semantics is a base towards formalizing basic and advanced aspects of the Android framework ICC. Here, we demonstrate the utility of proposed semantics towards developing a robust Android ICC framework. Modifying some fields (action, data, category, and extra) in an Intent does not change the Intent type. However, updating the attribute CmpId possibly change the Intent type. These facts and similar ones are formalized in the Lemmas 3 and 4 .    Our proposed semantics does not cache results of Intent resolution process. Hence, if two APIs use the same explicit Intent, the system will resolve the Intent twice. Therefore, the system does not benefit from the first resolution to the second one. This results in resource wastage which can be handled. Further, such instances have serious security implications. For example, if the first Intent resolution is responsible for sensitive data leakage, it will be repeated in the second Intent resolution.
Before running the Intent resolution process, it is convenient to check whether a matching component has been found recently. If this is the case, the system should check whether the component is responsible for a security breach. If there is no history of security breaches, then the system can declare the component to be a match. Otherwise, the system runs the Intent resolution process. The proposed updates can be implemented in our proposed semantics employing the following changes. The first change is to add the component BadIntResol : Intent × IntentFilter to the definition of semantic state (SysState). This augmentation, allows a state to store the history of Intent resolution that led to security breaches. The other change is to replace Rule 3 (R.H.S.) with the following three rules: With these changes, we can prove that executing Intent APIs such as startActivity(i) is secure as formalized in Theorem 2. The theorem guarantees that executing startActivity(i) for an implicit intent i does not lead to invoking activities having history of security breaches. Theorem 2 Suppose API ∈ {startActivity, startService, sendBroad cast}. Suppose also that ImpInt(i) ∧ API(i) : s s . Then there exists c ∈ Comp, ic ∈ IComp, and f ∈ IntentFilter such that: According to the theorem above the API execution results in an instance ic of a component c that has an Intent filter f such that the following conditions hold. The instance ic does not belong to s, but belongs to s . If f has recently been identified as a match to i, then c has no history of security breaches. This is formalized using the condition ¬(BadIntentResol s) i f . If there is no history of matching between i and f (¬(IntentResol s) i f ), then f has passed the action, category, and data tests.
Executing startActivity creates new instance. In a state s and for an explicit intent i, the execution of the startActivity(i) API results in an instance ic of a component c such that the following holds. c is an activity and ic does not belong to s, but belongs to and is running in s . The id of c coincides with that specified in attribute CmpId of i. This is formalized in the following lemma.

It is not possible to execute sendBroadcast(i) in a state s if i is an implicit intent that can not be resolved in s.
Suppose that in state s, i is an implicit intent that was not resolved recently. Additionally, suppose that a is the action value of i. Further, each intent filter in the system does not include a in its action list, it is not possible to execute the APIs {startActivity(i), startService(i), sendBroadcast(i)} in the state s. This is formalized in the following lemma, proof is available in the verification code.

It is not possible to execute startService(i) in a state s if, i is an explicit intent pointing to a component that is not installed in s.
We assume that in state s i is an explicit intent. We expect that CmpI d field of i does not coincide with that of any component in s. In such situations, it is not possible to execute the APIs {startActivity(i), startService(i), sendBroadcast(i)} in the state s. This is formalized in the following lemma.
Turning an implicit intent i into an explicit one and then executing startService(i) results in a new service instance in the final state. Suppose that in a state s, i is an implicit intent. Suppose that cid is the Id of the service c. Suppose that i is turned into explicit intent via assigning cid to the filed CmpI d of i.
Then executing startService(i) results in a new service instance of c in the final state. This is formalized in the following Theorem.
Executing sendBroadcast(i) with an implicit intent i results in a new Broadcast instance matching i. Suppose that in a state s, i is an implicit intent. Suppose that act is the value of the action property is i. We assume that i was not resolved recently. Then, executing sendBroadcast(i) results in a new a broadcast instance. The broadcast of the instance is installed in the initial state which includes a filter that matches i. This is formalized in the following theorem.
Then there exists c ∈ Comp, f ∈ IntentFilter, and ic ∈ IComp such that:

Data-leakage aware Intent resolution (DLAIR)
This section presents a new security-aware algorithm (DLAIR) for Intent resolution. The algorithm relies on the formal model presented in the previous sections of the paper in addition to LekInt, our lightweight tool that identifies suspicious paths related to Android app Intents. In this context, LekInt can be thought of as a security analysis tool for reporting execution paths with Intents that are suspicious of leaking sensitive user data in Android apps. DLAIR is outlined in Algorithm 1. DLAIR and the design, implementation, and evaluation of LekInt (as the main pillar of DLAIR) are presented in the following subsections. [γ, ω, β] ← LekInt( p, i); 5: if γ == 1 then 6: if ω == broadcast then 7: if β ∈ signature permissions then 8: Good_Filters else 10: Good_Filters if ω ∈ {activity, service} then 12: Good_Filters Good_Filters Good_Filters Recall that Android allows Intents targeting broadcasts to be protected by permissions. This is not the case for activities and services. Therefore, if ω is broadcast (Step 6), and if β is a signature permission (Step 7), then Step 8 uses our proposed algorithm of Intent resolution (IntMatchIntF mod ) to build the set Good_Filters. If β is not signature permission or the component type is not a broadcast, then the algorithm secures the matching process by accepting only filters protected by signature permissions. This is done in Steps 10 and 12. If γ = 0, then there is no need to care for permissions. This is implemented in Step 14. If i is not implicit, then in Step 16, the traditional algorithm of Intent resolution (outlined in Fig. 2) is used to find the set of Good_Filters. In all cases, Step 17 defines Suspicious_Filters as the set of all filters produced by the traditional algorithm of Intent resolution (outlined in Fig. 2

) minus Good_Filters.
It is necessary to note that DLAIR is not a taint analysis. While taint analysis is static and aims at fining data leaks, DLAIR is dynamic analysis. Taint analysis usually is applied once (on one app) at installation time. DLAIR can be realized as an enrichment of the process of Intent-resolutions. This enrichment aims at avoiding repetition of insecure Intent-resolutions. Hence DLAIR works on multiply applications simultaneously. While Taint analysis is typically applied as an extra layer above the Android OS, DLAIR can conveniently be integrated into the Android OS. Flowdroid [3] is built on the Soot tool [27] which replies on optimizing the Java byte code of apk files. This optimization increases significantly the rune time of the tool. Though disabling the optimization part of Soot is possible, the default configuration of Soot is still not fast enough as realized in many tools, such as Dare [22] and ded [14]. This fact has led researchers to utilize other tools (such as Androguard) as reviewed in [24]. Accuracy and soundness arguments [19] Fig. 7 Overview of LekInt solved yet [24]. This partially justifies that DLAIR gave better results than Flowdroid as explained later in detail.

Design of LekInt
LekInt is useful as a lightweight technique for testing the security of the execution path of a given Intent. In this context, an execution path is intent-suspicious if it contains the following three Dalvik instructions in the following specific order: o The first instruction defines an intent object, o The second instruction invokes a source API that reads sensitive data. o The third instruction invokes a sink API that takes the intent of the first instruction as an argument. terns on leaking data. This pattern was determined from analyzing results of state-of-the-art techniques reporting data leakage such as Flowdroid. In this case, the pattern is composed of two suspicious paths; the first path contains the first and second instructions of the definition of intent-suspicious paths. This path invokes another method that includes the second path which contains the third instruction of definition of intent-suspicious paths. Details specified for the suspicious path of the previous module are also collected for the two paths of this module.

Implementation of LekInt
The details of implementing modules of Fig. 7 are as follows: -The reverse engineering is done using Androguard and produces three objects a, d, dx. Our list of source and sink APIs were derived from ones used by state-of-the-art techniques such as Flowdroid. The list includes all common sources and sinks related to intents and bundles only. This list is available online with our result files. Among sink APIs in our list are the sends broadcast ones and the send service API. 5

Performance evaluation
This section presents the results of our experiments conducted for evaluating LekInt. We got the dataset from a reputable benchmark, namely Andro-Zoo [2]. We downloaded a random set of 2000 applications whose sha256 is available online with our result files. We limited the download to applications that Androzoo obtained from the Google Play Store. All experiments were done on a Dell (Vostro) device with processor: Intel(R) Core(TM) i7-3612 QM CPU @ 2.10 GHz, 8.00GB RAM, and Windows 10 (64-bits) operating system. All implementations were written in Python. Table 3 shows the statistics collected for comparing LekInt against Flowdroid [3] as one of the state-of-the-art techniques that are most common and related to LekInt. We make all our results and data files available online. 6 These files include 2000 text files produced by LekInt and 1999 text produced by Flowdroid for the applications of the dataset. The Coq files that include the proofs of our semantics are also available online.
Our experiments answer the following research questions: Applicability, Effectiveness, and Performance: The applicability of LekInt is proved by its results obtained for 2000 real-life Android applications. Moreover, we designed two Android applications that include different patterns of paths leaking sensitive data. These paths include Intents that target different types of components. To cover all possible cases in our applications, some of Intents and components were protected by permissions and others were not. LekInt succeeded in reporting all the leaking paths in the example applications. On the other hand, Flowdroid failed to report leaks in these two applications which we make available online along with their LekInt and Flowdroid results. Figure 8 (Right-hand-side) provides comparisons for leaks reported by LekInt and Flowdroid. The total number of leaks reported by LekInt and Flowdroid are 49015 and 4664, respectively. It is worth mentioning that Flowdroid reported more leaks than this number, but we considered only leaks related to our problem. For example, Flowdroid typically reports leaks in external components that are not among the native code of the app under analysis. Examples of  external components are com.facebook.CampaignTrackingReceiver and com.google.android.gms.ads.AdActivity. Such leaks were not considered in our evaluation. The reported number of leaks proves that LekInt is more effective than Flowdroid. Figure 8 (Left-hand-side) provides comparisons for running times of LekInt and Flowdroid. The average running times per application for LekInt and Flowdroid are 47.8 and 74.6 seconds, respectively. This proves that the performance and efficiency of LekInt are better than that of Flowdroid.
Accuracy: LekInt reported suspicious leaks in 824 apps, while the Flowdroid reported leaks in 425 apps. We manually checked the results reported for a random set of 100 apps for measuring the accuracy of LekInt against Flowdroid. Table 4 illustrates the results of our manual investigation.
Compared to LekInt, Flowdroid has higher false-negative and lower false positive. This is in line with the approximation adopted by LekInt. However, the efficiency and the high number of true positives reported by LekInt confirm its accuracy and usefulness.
Common Component for Leaking Data and Permissions Figure 9 answers research questions 3 and 4. The lower set of bars show that activity components collected from manifest files of the dataset are much more than service and broadcast-receiver components. However, a high percentage (21%) of these broadcast components are protected by permissions against 0.1% only for activity components. This is clear from the middle set of bars of the figure. The abbreviation MC in the y axis stands for manifest components. For some leaking paths, LekInt was able to determine the type of component targeted by the Intent of the path. The upper set of bars of Fig. 9 shows that 72% of these paths targeted activities. Therefore it is com- Fig. 9 Comparing statistics collected by LekInt for different types of Android components and for leaking paths protection by permissions mon to use activities rather than other types of components to leak data. Only 0.8% of the paths leaking data were protected by permissions. This supports the logic of our suggested algorithm for Intent resolution DLAIR. This is so because DLAIR tends to trust Intents protected by permissions.
Use Cases: For some apps of our data set Flowdroid did not report any leaks but our technique LekInt did. Some of these apps have the following details: 1. The first app has an execution path in the activity named "TiActivity". The path leaks data in a sequence of instructions that start another activity. The source API, in this case, is getIntent and the sink API is putExtra. 2. The second app has a leaking execution path that uses an Intent to start the activity "FuturePaymentConsentActivity". The source API in this case is getIntent and the sink API is putExtra. 3. The third app has a leaking path in its activity named "BaseFragmentActivity".
The path uses an Intent to start a service.
Also for our designed app (available online with results) LekInt discovered all the inserted patterns of leaks but Flowdroid did not.

Author Contributions All authors participated equally.
Funding Open access funding provided by The Science, Technology &; Innovation Funding Authority (STDF) in cooperation with The Egyptian Knowledge Bank (EKB).

Data availability
The details of the dataset and results of our experiments are available online on: https:// github.com/maelzawawy/LekInt.

Declarations
Animal research (Ethics) Not applicable.

Consent to participate (Ethics) Not applicable.
Consent to publish (Ethics) Consent to submit and publish has been received explicitly from all co-authors.

Plant reproducibility Not applicable.
Clinical Trials Registration Not applicable.

Conflict of interest
The authors declare that they have no conflict of interest.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.