related to the external intent.Our inter-procedural data-flow RQ 1:What is the accuracy of path's intent conditions is mainly based on the reaching definition technique [10]. we generate? which focuses on statically determining which definitions RQ 2:Can our tool be applied to practical apps and may reach a given point in the code.But we do not find capability leaks Can exploits help devel- remove intent-irrelevant condition statements if their branch opers find bugs? statements contain intent-relevant statements.For example RQ 3:Our tool uses symbolic execution,what is run- as shown in Listing 1,the statement if(z 5)can not time efficiency of our work? be removed because the true branch of if(5)has intent-relevant statements.But we can remove if(y<6) and if(z>7).We also reserve statements that intent- APK Size APK SLOC relevant statements depend.For example,the statement Distribution Distribution String key ="pid"will not be removed in listing 100,00 1000.00 90.00 8 900.00 92137 1.Since most statements are not related to intent,it is 0.00 800.00 76,33 possible to substantially reduce the CFG.Thus,our method 70.00 700.00 is efficient.As shown in Listing 1,there are 6 branches 60.00 600.00 50.0 500.00 in total 6 paths in the doTask/method.But none of the 40.00 400.00 5 branches have any statements related to intent data,so 30.00 300.00 20.00 we can simplify doTaskI method into doTask2 method and 200.00 10.00 100.00 doTask2 method only has 3 branches in total 3 paths. 0.00 0.00 247 C.Compute Path's Intent Constraints Z3 is a state-of-the-art theorem prover from Microsoft Fig.2.APK Size and SLOC Distribution Research.It can be used to check the satisfiability of logical formulas over one or more theories.We uti- The following experiment results are collected on Ubuntu lize Z3 to solve intent conditions.At first,we get 18.04 with a 3.6GHz Intel Core i7 CPU and 32GB RAM all statements of a path.Then we will process state- Our dataset consists of 18 categories of applications from ments separately to generate intent constraints in for- Wandoujia in 2017.We select 45 most popular apps for each mat of SMT2 language.These statements mainly in- category and in total 810 apps,then remove hardened apps clude intent.get Action,intent.hasCategory,intent.get [11]and apps that soot can not analyze [12].Finally,we Extra,equals,if,variable definition and other operation get 439 apps.These apps size and SLOC(source lines of statements about value of intent attribute.For example. code)are shown in figure 2.What we need to explain is if statement is if(str.equals("success")),the SMT2 lan- that the use of harden technology is becoming more and guage is(assert(=str”success'”)）.Z3 will return more popular,which causes that we can not get the real the value of str is"success".Our tool can get correct string source code of app.Fortunately,our tool is proposed for and primitive values in most cases when compute path's developers,and developers can use our tool to detect the app intent constraints. before it is hardened,so our tool is still useful.To answer D.Test-app Test Instrumented App RQ1,we divide 439 apps into five categories (0-9M,9M- 18M,18M-27M,27M-36M,36M-)according to app size.We The intent test cases that we generate satisfy the intent select 5 apps randomly from each category in total 25 apps conditions of paths,but there are some other conditions of to evaluate our tool. paths that we can not control.So we need use dynamic way to test whether paths are reachable.We insert log statements before tgtAPIs in detected app and repackage A.ROl:Accuracy of Path's Intent Conditions detected app as a new app (named instrumented app).And the log statement mainly records these information:test case We run our tool for these 25 apps and record the number,exported-component's name,package name,tgtAPI statements that we can not handle (named unhandledSer). and etc.Then we develop test-app which do not have any At the same time,we manually check each statement we permissions and it utilizes test cases to test instrumented can handle and record the statements that we can not app.If the tgtAPI can be triggered,the log will be generated, get correct value (named incorrectSer).For example,a indicating that the app occurs a capability leak.Then our tool string value from network.allStatementsSet is a set of all reads the test log to generate a detection report for detected intent-relevant statements.We use the following correctness app.The exploits of capability leaks in detection report can metric to access the accuracy of intent conditions that we trigger the corresponding capability leak,and they can help generate: size(allStatementsSet)-size(unhandledSet)-size(incorrectSet) developers analyse bugs. size(allstatementsSet) The accuracy results are shown in figure 3.The accuracy of III.EVALUATION path's intent conditions is high and no app has a rate lower To assess our work,we study the following research than 90%.This indicates that for the overwhelming majority questions: of cases,our tool can generate correct intent conditions. 293related to the external intent. Our inter-procedural data-flow is mainly based on the reaching definition technique [10], which focuses on statically determining which definitions may reach a given point in the code. But we do not remove intent-irrelevant condition statements if their branch statements contain intent-relevant statements. For example, as shown in Listing 1, the statement if(x > 5) can not be removed because the true branch of if(x > 5) has intent-relevant statements. But we can remove if(y < 6) and if(z > 7). We also reserve statements that intent￾relevant statements depend. For example, the statement String key = ”pid” will not be removed in listing 1. Since most statements are not related to intent, it is possible to substantially reduce the CFG. Thus, our method is efficient. As shown in Listing 1, there are 6 branches in total 6 paths in the doTask1 method. But none of the 5 branches have any statements related to intent data, so we can simplify doTask1 method into doTask2 method and doTask2 method only has 3 branches in total 3 paths. C. Compute Path’s Intent Constraints Z3 is a state-of-the-art theorem prover from Microsoft Research. It can be used to check the satisfiability of logical formulas over one or more theories. We uti￾lize Z3 to solve intent conditions. At first, we get all statements of a path. Then we will process state￾ments separately to generate intent constraints in for￾mat of SMT2 language. These statements mainly in￾clude intent.getAction,intent.hasCategory, intent.get ∗ Extra, equals, if, variable definition and other operation statements about value of intent attribute. For example, if statement is if(str.equals(”success”)), the SMT2 lan￾guage is (assert (= str ”success”)). Z3 will return the value of str is ”success”. Our tool can get correct string and primitive values in most cases when compute path’s intent constraints. D. Test-app Test Instrumented App The intent test cases that we generate satisfy the intent conditions of paths, but there are some other conditions of paths that we can not control. So we need use dynamic way to test whether paths are reachable. We insert log statements before tgtAPIs in detected app and repackage detected app as a new app (named instrumented app). And the log statement mainly records these information: test case number, exported-component’s name, package name, tgtAPI and etc. Then we develop test-app which do not have any permissions and it utilizes test cases to test instrumented app. If the tgtAPI can be triggered, the log will be generated, indicating that the app occurs a capability leak. Then our tool reads the test log to generate a detection report for detected app. The exploits of capability leaks in detection report can trigger the corresponding capability leak, and they can help developers analyse bugs. III. EVALUATION To assess our work, we study the following research questions: RQ 1: What is the accuracy of path’s intent conditions we generate? RQ 2: Can our tool be applied to practical apps and find capability leaks ? Can exploits help devel￾opers find bugs? RQ 3: Our tool uses symbolic execution, what is run￾time efficiency of our work? Fig. 2. APK Size and SLOC Distribution The following experiment results are collected on Ubuntu 18.04 with a 3.6GHz Intel Core i7 CPU and 32GB RAM. Our dataset consists of 18 categories of applications from Wandoujia in 2017. We select 45 most popular apps for each category and in total 810 apps, then remove hardened apps [11] and apps that soot can not analyze [12]. Finally, we get 439 apps. These apps size and SLOC(source lines of code) are shown in figure 2. What we need to explain is that the use of harden technology is becoming more and more popular, which causes that we can not get the real source code of app. Fortunately, our tool is proposed for developers, and developers can use our tool to detect the app before it is hardened, so our tool is still useful. To answer RQ1, we divide 439 apps into five categories (0-9M,9M- 18M,18M-27M,27M-36M,36M-) according to app size. We select 5 apps randomly from each category in total 25 apps to evaluate our tool. A. RQ1: Accuracy of Path’s Intent Conditions We run our tool for these 25 apps and record the statements that we can not handle (named unhandledSet). At the same time, we manually check each statement we can handle and record the statements that we can not get correct value (named incorrectSet). For example, a string value from network. allStatementsSet is a set of all intent-relevant statements. We use the following correctness metric to access the accuracy of intent conditions that we generate: size(allStatementsSet)−size(unhandledSet)−size(incorrectSet) size(allstatementsSet) The accuracy results are shown in figure 3. The accuracy of path’s intent conditions is high and no app has a rate lower than 90%. This indicates that for the overwhelming majority of cases, our tool can generate correct intent conditions. 293