Multifeature-Based Behavior of Privilege Escalation Attack Detection Method for Android Applications

*is study proposed an application behavior-detection method based on multifeature and process algebra for detecting privilege escalation attacks in Android applications. *e five features of application that constituted the attack were determined through an analysis of the privilege escalation attack model. On the basis of the extraction of multiple features, process algebra was used to build the application-behavior model and the attack model. Strong equivalence relation was used to verify the application behavior. Finally, dataflow path detection is conducted among the applications that can constitute privilege escalation attacks to determine those apps constituted a privilege escalation attack. *e accuracy and effectiveness of the proposed method were verified using the DroidBench benchmark test and the test set that includes 55 APKs of 22 types.


Introduction
With the development of Mobile Internet and the popularization of smartphones, the number of downloads of applications has also increased significantly [1]. e Android system with open-source applications has become popular among smart device manufacturers and developers. It is widely used in finance, government, transportation, education, military, automobile, home, energy, and other important fields, and it has a large user base [2,3]. According to statistics obtained by Strategy Analytics, Android accounted for 88% of the global smartphone market in the third quarter of 2016 [4]. Android system is widely used in the industrial Internet of ings (IIoT) [5]. Although there are classical solutions from the nonrepudiation record of the network to the access control of the Internet of ings (IoT) [6][7][8][9], the security of the android operating system has been a subject of concern, specifically in the mobile Internet privacy leak issue. e Nokia reat Intelligence Report-2019 indicates that, in 2018, the average monthly infection rate in mobile networks was 0.31%, with Android devices being responsible for 47.15% of the observed malware infections [10]. According to the data collected in the Android Security Eco-Environment Research in 2018, the China Mobile Security Eco-Research Report in 2018, and the Android Malware Annual Special Report, 360 Internet Security Centers intercepted about 4.342 million new samples of malware on mobile terminals, and known security vulnerabilities have been found in 99.3% of Android applications in the last year, with 89.6% of them having high-risk security vulnerabilities. e cross-border behavior of app permissions shows an increasing integral trend. Moreover, 98.8% of the apps that applied for privacy permissions abused the permission to write call records [11][12][13]. Usually, the permissions applied for apps involve users' privacy and even threaten users' information security. erefore, access to users' privacy information through collusion attacks of privilege escalation has become a research hotspot.
Currently, behavior-based detection is mainly used to detect privilege escalation attacks in Android applications. ose include some features which are extracted statically, for example, permission, component, and other behavior characteristics' detection and dynamic system operation process application behavior information collection and detection. However, two shortcomings exist in the detection of multiapplication collusion for privilege escalation attack: (1) a single application is detected, and the dataflow path between multiapplications is not detected, so the detection effect of multiapplication collusion is not good. (2) e current detection methods are based on 1-3 features, but do not consider the joint detection of more than 4 features, and without knowing the hidden dangerous factors that constitute the privilege escalation attack.
In view of the serious threat and strong concealment of collusion attacks and not good detection effect of single application, we proposed a detection method based on multifeature and process algebra modeling. e method is described as follows: (1) Extraction feature of attack behavior: based on the analysis of the attack model, five kinds of features are extracted, including apply dangerous permission, Intent-filter, sensitive API calls, sensitive dataflow pairs, and component Intent communication.
(2) Application behavior and attack behavior modeling: process algebra was used to build the application behavior and attack behavior model. Strong equivalence was used to verification. en, it can determine whether the application can constitute a privilege escalation attack.
(3) e dataflow path was detected between attack applications. Path detection algorithm was used to detect the dataflow path between the apps that can constitute the privilege escalation attack. So, the apps that have the path between applications constituted the privilege escalation attacks.
e main contributions of this paper are as follows: (1) Five features of attack behavior were extracted. e static feature extraction method is used to extract dangerous permission application, sensitive dataflow pairs, sensitive API calls, component Intent communication, and Intent-filter, which make up for the limitation that a single feature can be detected but attack behavior cannot be highly restored. (2) Behavior modeling and path detection between applications: process algebra is used to model the application behavior and attack behavior, and strong equivalence is used to confirm the equivalence relationship between the behavior model and the attack model of the app. Path detection makes up for the limitation that traditional methods only detect a single app but do not consider the collusion behavior between applications. (3) Explanation of hidden factors of privilege escalation attacks: based on the experiments of the case, benchmarks, and test sets, the accuracy and effectiveness of the method are confirmed, and the hidden factors that constitute the privilege escalation attack are explained.

Related Work
e wide use of smartphones and Mobile Internet has resulted in the year-by-year increase in the number of malicious Android apps, thus making the detection of malicious apps a research hotspot. is subject has research value due to the particularity of the privilege escalation attack with multiapplication collusion. e following will be from the malware detection, and the privilege escalation detection methods are described.

Malware Detection Method.
e malware detection method for Android has changed from the signature-based method to the application-based behavior feature method and then to the feature classification and detection based on machine learning and data mining theory. Androguard [14], a well-known malicious code early detection tool for Android, uses a signature-based method to detect a malicious code; however, it cannot detect unknown malicious applications.
us, many researchers are focusing on the detection method based on app behavior features. In [15][16][17][18][19][20], the researchers detected the behavior of Android malware by analyzing, extracting, and comparing the behavior features of the app such as permission, control flow, dataflow, and sensitive API calls. Furthermore, the probabilistic confidence value framework proposed in [20] can effectively reduce the detection cost. Although the detection method based on the application of behavioral features has achieved good results, it can still be strengthened for extracting and combining behavioral features.
Moreover, because of the maturity of machine learning and data mining theory, researchers are now introducing them to malicious application detection methods. In [21][22][23][24][25][26], the researchers used machine learning and data mining theory to extract, classify, evaluate, and detect known malicious features, and they provided a direction for further research on permission and API for detecting malicious applications. DroidCat [27] and SafeDroid v2.0 [28] contributed to query strategy, active learning, and simplifying malicious features, while DroidDeep [29] contributed to static feature collection and selection. Androdect [30] constructed the dataset of the component, key function call, and system call based on the feature extraction of the component, function call, and system call; moreover, it used the three-layer hybrid ensemble algorithm for detection. e system performed well for detection accuracy and execution efficiency but only considered three types of features. Unlike the previous studies, Amin et al. [31] proposed an antimalware system based on a self-defined learning model that detects the end-to-end deep learning system of Android malware by extracting the operation code from the application bytecode; however, the system focused on using different deep learning models to improve the detection rate.

Privilege Escalation Detection Method.
Because of the complexity of privilege escalation attacks, the aforementioned detection methods for malicious software are relatively weak in detecting privilege escalation attacks. Some researchers have therefore conducted more in-depth research on privilege escalation attacks. In [32,33], tracking tainted information and monitoring permission information were used to protect and detect the kernel-level privilege escalation attack. Two types of attacks on the application layer are confused deputy attacks and collusion attacks.
Researchers have proposed some good solutions for detection and prevention of confused deputy attacks. Bugiel et al. [34] proposed extending Android middleware and deploying a security framework of mandatory access control in the kernel, thus aiming to detect and prevent the application-level confused deputy attacks and focusing on the binder IPC, Internet sockets, and the file system of the kernel. Lee et al. [35] proposed protecting Android from privilege escalation attacks by monitoring important system calls of application processes. is method can detect and prevent new unknown malware; however, it only considers the feature of system calls. Xu et al. [36,37] proposed a flexible and efficient security extension scheme for Android middleware. is security framework is used to prevent the expansion of permission lead vulnerabilities of third-party applications via confused deputy attacks. In this framework, the main consideration is how to restrict risky interapplication communications.
For the collusion attacks that we have studied, researchers have made in-depth exploration from data information and behavior features. Youn et al. [38] proposed a method for preventing privilege escalation attacks by verifying the usefulness of the protocol for requesting services, reviewing the applicability of requesting services, transmitting information to the system, and communicating risks to users. However, the primary consideration is the metadata and the context manager metadata. DroidAuditor [39] is a solution for application behavior analysis using interactive behavior graphs; it can detect application-layer privilege escalation attacks such as confused deputy and collusion attacks. Furthermore, it primarily uses the Android security module (ASM) access control architecture to analyze application behavior. Wang et al. [40] proposed a method for detecting privileged escalation attacks based on the component, application layer, and the defects of package management. For the component-based detection method, the researcher considered three features: permission, exported attribute, and Intent-filter. For the applicationlayer-based detection method, the component and permission information are considered. In the system update or package management-based detection method, the researcher considered three features: permission, UID sharing, and tainted data. To summarize, this study provided a good research for collusion attack detection; however, the number of features used in each method can still be strengthened.
us, for the application-layer collusion attacks, using the aforementioned detection method to detect a single application, the detection results must not be good. However, for the existing detection methods, only 1-3 types of behavior features are considered, and the detection of the dangerous information path between applications is insufficient. At the same time, Bhandari et al. [41] also proposed the importance of interapp communication detection. In fact, in addition to considering multiple features, it is necessary to detect the dangerous path between applications to effectively detect the multiple application collusion privilege escalation attacks in the application layer.

Extraction of Behavior Features
e behavior of applications can be expressed by their features [30]. Static methods are adopted to extract the behavior features on the basis of an analysis of attack-behavior features.

Analysis of Attack-Behavior
Features. Android applications are composed of activity, service, broadcast receiver, and content provider, which communicate through Intent [2,42]. e security architecture of Android allows an application with fewer (or no) permissions to access application components with more permission [2]. erefore, malicious programs without any permission obtain the required privileges through third-party programs, thus constituting a multiapplication collusion privilege escalation attack, as shown in Figure 1 [43][44][45].
As can be seen from Figure 1, (1) ree applications (A, B, and C) run independently and do not interfere with each other. Application A has components ComA 1 and ComA 2 and no permission. Application B has permission P 1 and components ComB 1 and ComB 2 . Application C has no permissions, but component ComC 1 has permission P 1 and ComC 2 has permission P 2 . (2) ComA 1 without permission can access ComB 1 with P 1 ; ComB 1 can access ComC 1 with P 1 that is applied for component ComC 1 but cannot access ComC 2 with P 2 . (3) ComA 1 has P 1 without being applied for P 1 . ree applications (A, B, and C) can constitute a privilege escalation attack based on P 1 .
According to the attacking principle, the app that constitutes an attack must have the following behavioral features: (1) Applied dangerous permission: privilege escalation attack occurs in the process of continuously refined permissions; dangerous permissions are an important factor of the privilege escalation attack. Moreover, it is necessary to detect the interapplication path for the applications that can constitute the privilege attack. e permission mechanism of the Android platform has a feature that once the permission is granted, it will be permanently protected by the permission [42], and it can realize the call of components between applications, which is the best camouflage for privilege escalation attacks.

Privilege Escalation Attack Case.
A privilege escalation attack case is presented, consisting of three normally independent apps (App1, App2, and App3) based on the permission of SEND_SMS. e key code for the three applications is shown in Table 1.
e key code is as follows: ( ComB of App2 has the same permission as ComC, so ComB communicates with ComC. (4) e three applications in SEND_SMS are refined and enhanced step by step. e three conspired applications constitute the privilege escalation attack. ey use SMS to send the bank code to the specified phone number. Figure 2 shows a diagram of a constituted privilege escalation attack.

Application-Behavior Feature Extraction.
Feature extraction was performed to construct an application feature tree (AFT). AFT is a tree that has three depths. e root node stands for the name of the application, the root node of each subtree stands for the component of the application, and the leaf node of the subtree stands for the features of the corresponding component. Features include dangerous permissions, component Intent communication, sensitive dataflow pairs, Intent-filter, and sensitive API calls.

Component and Dangerous Component Permission
Extraction. Permission and component information were extracted from an AndroidManifest.XML file. A dangerous permissions' list was built based on Google's official documents, as shown in Figure 3.

Dangerous Application Permission Extraction.
According to the permission mechanism of the Android system, each component is protected by an application's permissions, as shown in Figure 4.
Several random APKs were used to extract permissions and components. e statistical data are shown in Table 2.

Component Intent Communication Extraction.
Based on the conversion of the APK to the Smali file, it is combined with the Intent tag of the component in the AndroidManifest.XML for analysis, and then the information of application components was extracted, as shown in Figure 5.
In the attack case in Section 3.2, ComB of App2 was extracted, and its Intent communication information is shown in Table 3.

Sensitive API Call Extraction.
Au et al. [46] studied the corresponding relationship between the permissions of multiple versions of the Android system and API correspondence. With the help of their findings, sensitive API calls are obtained by using the strace tool to extract the sequence of system calls, as shown in Figure 6. [47] was used to extract sensitive data stream pairs, that is, <source, sink>. Source is the source of sensitive information acquisition, and sink is the source of sensitive information transmission.

Sensitive Dataflow Pair Extraction. FlowDroid
e extracted sensitive dataflow pairs are added to AFT.
In the attack case in Section 3.2, the component ComC of App3 was extracted, and its sensitive dataflow pairs are shown in Table 4.   Application: C Permission:- Figure 1: Principle of the privilege escalation attack.    two systems and determine the equivalence in their behavior [48]. In process algebra, the behavior of a system is defined using actions or events that it can perform. Actions represent abstract activity or behavior. erefore, process algebra is used to define interactions between processes based on actions. It describes the behavior of a system in a combinatorial way. e Android application is built on components. e action set of all the components constitutes the overall behavior of the app [49]. Process algebra can be used to effectively describe the Android architecture and features of message communication. erefore, we propose that process algebra must be used to model the behavior and attack behavior of the app. e syntax and semantic specifications of the process algebra are given as follows:

Application-Behavior
P∷ � A y 1 , y 2 , . . . , y n iεI a i .P i P 1 P 2 · X〈y 1 , y 2 , . . . , y n 〉 X y 1 , y 2 , . . . , y n (]χ)P|!P|0. (1) In the formula, (1) A(y 1 , y 2 , . . . , y n ), represents that each process P has a unique process identifier, where y i represents the free name in P. (2) i∈I a i .P i � a 1 P 1 + a 2 P 2 + · · · + a n P n ; it is a summation, where I is any finite indexing set. If I � ∅, then i∈I a i .P i is the empty summation, written as 0, indicating that the process is successfully terminated. P i is protected by a i because P i must start activities after the action represented by a i occurs.

Application-Behavior Model.
We used process algebra to create an application-behavior model based on AFT. e syntax and semantic specifications of the definitions are given as follows.
Definition 1 (application behavior). In the Android architecture, applications are composed of components. On the basis of the permission mechanism of Android, component action is a set of information sending, receiving, and executing operations under permission protection. e sensitive behavior of a component is under permission protection. erefore, app behavior can be obtained by the actions of all components. Application behavior is defined as follows: where n represents the total number of components in the app and m represents the total number of actions of the current component. e behavior model of any component is as follows. e application behavior model is created by using the process algebra based on AFT. Each composition part of formula (1) is expressed using the key features of the Android architecture. For example, y 1 , y 2 , . . . , y n in X〈y 1 , y 2 , . . . , y n 〉 is expressed using sensitive data. erefore, the behavior model of any component is constructed by using formulas (1) and (2) as follows: In the formula, (1) Com(id) represents that ComAction has a unique id, and it can be omitted.  Mobile Information Systems 7 (2) iεv jεw P i .Feature j , where, w represents the number of features in AFT, v represents the number of permissions, and P represents permissions. P i .Feature j represents Feature j is protected by P i and the order in which they occur; Feature j must occur before P i can start the activity. (3) Feature 1 |Feature 2 |Feature w represents an application has w features at the same time. (4) (X〈data〉 | X(data)), where X〈data〉 represents the action of message sending, and X(data) represents the action of message receiving. (5) (Feature)P represents the behavior in which an application is protected by permission P. (6) !Feature j represents Feature j being replicated.

Formula (3) describes the set of behaviors of any component of the app.
is includes the following: any single component can have a unique identity, actions of the components can be performed under the permission protection, and these actions must be performed after the permission is granted; each component can have multiple features, the components can have the ability to send and receive information, and any feature of the component can be reused.
Definition 2 (privilege escalation attack model). According to the analysis of the attacking principle in Section 3.1, the application that constitutes the privilege escalation attack (PEApp) must have dangerous permissions, sensitive API calls, component Intent communication, and sensitive information flow sending. According to formula (2), attack behavior must be completed by a component in the application, that is, ∃Com k (k ∈ n), and the component must have AFT. According to formulas (1) and (3), the model of privilege escalation attacks is as follows: ese actions must be performed after permission is granted, after which the component can send and receive information, where any feature of the component can be reused. erefore, by using formulas (3) and (4), we can complete the modeling of app and attack behaviors.

Behavior Equivalence and Interapplication
Path Detection e strong equivalence of process algebra is used to determine the equivalence relationship between the behavior and attack models of the app. erefore, according to the concept of labelled transition system, strong simulation, and strong equivalence in process algebra, the following are defined: behavior-labelled transition system, behavior-strong simulation, and behavior-strong equivalence based on AFT.

Related Concepts of Behavior Equivalence
Definition 3 (behavior-labelled transition system (LTS)). Suppose the application action is under the protection of P permission; the app action set Act � a 1 , a 2 , . . . , a t , a 1 ′ , a 2 ′ , . . . , a t ′ } is a pair (Q, T) which is LTS, where Q � (a 1 , P), (a 2 , P), . . . , (a t , P), (a 1 ′ , P), (a 2 ′ , P), . . . , (a t ′ , P)} is a state set; T⊆(Q × Act × Q) is a ternary relation known as a transition relation. If ∀(a i , P) ∈ Q, ∀(a i ′ , P) ∈ Q,∃a i ∈ Act(or ∃a i ′ ∈ Act), and ((a i , P), a i , (a i ′ , P)) ∈ T(or((a i , P), a i ′ , , P)). erefore, LTS for app component behavior and attack behavior can be constructed to determine the equivalent relationship between component behavior and attack behavior.
Based on formulas (3) and (4), the attack behavior of an app's component must be included in the overall behavior of the component; therefore, the simulation relationship between the attack behavior of the component and the behavior of the component belongs to the same LTS. erefore, based on the concept of strong simulation in process algebra, the concept of behavior-strong simulation is given.

Definition 4 (behavior-strong simulation). Based on Definition 3, let (Q, T) be an LTS, and let
S � ((a 1 , P), (a 1 ′ , P)), ((a 2 , P), (a 2 ′ , P)), . . . , ((a t , P), (a t ′ , P)) be a binary relation over Q. en, S is called a strong simulation over (Q, It can verify whether the LTS consisting attack behavior and component behavior has strong simulation S. S includes attack behavior and part of the component behavior. Definition 5 (behavior-strong equivalence). Based on Definitions 3 and 4, a binary relation S over Q is said to be a strong bisimulation over the LTS (Q, T) if both S and its converse are simulations. We say that (a i , P) and (a i ′ , P) are strongly equivalent, written as (a i , P) ∼ (a i ′ , P), if a strong bisimulation S exists such that (a i , P)S(a i ′ , P), where (a i , P) ∈ ComAction， (a i ′ , P) ∈ PEApp. Definition 5 is used to verify that the strong simulation S with attack 8 Mobile Information Systems behavior and part of component behavior is strong mutual simulation. ere are two states, namely, (a i , P) ∈ ComAction, (a i ′ , P) ∈ PEApp and ((a 1 , P), (a 1 ′ , P)) ∈ S, which are strong equivalences. erefore, the definition can verify the equivalence between the application component behavior and attack behavior models.

Interapplication Path Detection
Definition 6 (dangerous information flow path between applications (DIPA)). Since the application-layer collusion privilege escalation attack occurs between multiple applications, it is necessary to detect the dangerous data flowing between multiple applications. erefore, on the basis of applying for dangerous permissions, sensitive information transmission paths exist between multiple apps, which are composed of "applicationName.componentName⟶ applicationName.componentName⟶· · ·⟶application Name.componentName." Based on Definition 6, we construct an algorithm of the interapplication dangerous information flow path.

Application Feature Extraction.
According to the discussion in Section 3.3, the features of App1, App2, and App3 are obtained as shown in Table 5. Text in italics indicates the abbreviations of features, and text in boldface denotes the storage of feature (Intent) value.
According to Table 5, AFT is constituted for ComA, ComB, and ComC, as shown in Figures 8(a)-8(c), respectively.

Attack Behavior Model.
For the AFT of the privilege escalation attack case given in Section 6.1, the application's attack behavior models were modeled by formula (4).

App Behavior Model. Formula (3) is used to model the app behavior of the case as follows:
(1) e behavior model of AppModel1 is shown in the following formula: AppModel1∷ � (X(data1) | X〈data1〉). (8) (2) e behavior model of AppModel2 is shown in the following formula: (3) e behavior model of AppModel3 is shown in the following formula:

Equivalence Relation Verification and Path Detection.
MWB (Mobility Workbench) is a tool used for manipulating, analyzing, and verifying mobile concurrent systems described in process algebra. According to Definition 5, MWB is used to normalize the app behavior model and the attack model. en, the equivalence relationship between them is verified. Table 6 is the basic syntax transformation of normalization. For example, (X〈y 1 〉 | X(y 1 )) in formula (5) is converted according to MWB grammar, and the conversion result is X(y 1 ). ′ X〈y 1 〉.
e attack behavior models of App1 and App2 (representation in MWB with APP2), and the app behavior models of AppModel1 and AppModel2 were validated to have a strong equivalence relationship, as shown in Figure 9.
Similarly, we can verify the strong equivalence between App3 and AppModel3. According to Algorithm 1, we can see that (1) App1, App2, and App3 can constitute a privilege escalation attack. (2) e attacking path of the constituted privilege escalation attack is

Experiment Evaluation.
e key steps of our detection method are sensitive dataflow detection and dangerous path detection. In the worst case, the search time complexity of the algorithm is O ((n − m + 1)m). Fifty-five Android APK samples were tested, and two APKs failed. e time and space cost analysis data are shown in Table 7.

Benchmark Test and Comparison Analysis.
is method was used to examine some test sets of the DroidBench benchmark [50] and comparisons with [40]. e detection method that is proposed in [40] is used to detect the components, dangerous permissions, component communication, sensitive API calls, and the Intent-filter in the benchmark test. However, this method does not detect the flow of sensitive data. Table 8 summarizes the obtained data of the benchmark test and comparison results. e expression was as follows: the test result of "this method/the test result of [40]." e test results show that a threat was expressed by T, no threat was expressed by NT, a false alarm was expressed by F, a missed alarm was expressed by L, a security call (registration) was expressed by A, insecurity was expressed by NA, and nondetection was expressed by N, as shown in Table 8.
e benchmark test showed that this method can accurately detect the security risks of the privilege escalation attack such as sensitive information and component communication. Compared with [40], two points were shown:

FilterApp3:
Intent.ActionName � "IntentApp2";  ① We proposed the method detected sensitive API calls and sensitive dataflow pairs and considered more comprehensive dangerous factors than [40] ② Two methods have high accuracy in components, dangerous permissions, component communication, and Intent-filter Table 9 shows the accuracy rate, false positive rate, and missing rate of our method in benchmark test.

Composition of the Test Set.
Fifty-two APKs were selected from an Android application market such as Google Play, and three APKs were developed by our research team to build the test sample set [51]. According to the classification of APK in major application markets, 22 classes of APK were selected in sample extraction, and 1 to 3 typical APKs were selected for each type. e specific Insert into PEAppString+"/"//Use/to split application which constituted privilege escalation attack (6) temp j � Split(PEAppString,"/") (7) for j � 0 to w//w represents the number of applications that can constituted privilege escalation attack (8) Construction AFT j (9) for j � 0 to w (10) Construction AFF//Construct Application Feature Forest (AFF) of suspicious application based on AFT (11) Intent k points to leaf-AFF k (12) postorder-traversal save as forestString (13) n � forestString.length, m � Intent k .length (14) for s � 0 to n − m (15)    classification and the number of APKs are shown in Table 10.
For Android users, they want the app to be powerful but smaller; therefore, two rules should be followed when selecting a typical APK: (1) app is at the top of this kind of app; (2) the app takes up less space. However, the small size of an app does not mean that it has fewer components, which is the smallest unit for launching an attack. erefore, the statistical figure of the app size and the number of components is shown in Figure 10.
Because collusion attacks easily occur in the combination form of multiple apps of the same company and the same developer, the test set selection considers the situation of the same company or the same developer. Furthermore, there are 13 apps developed by four companies and one developer; the detail is shown in Table 11.

Analysis of Experiment Validity.
e validity of this method was verified by the test sample set. e test results showed that 5.5% of the applications constitute the privilege escalation attack. Some applications are equivalent to the attack model, which can be used as part of the collusion attack. No dataflow path with multiple applications is detected; thus, it is called the application that can constitute the privilege escalation attack, accounting for 32.7%. However, APK encryption or code obfuscation hinders the detection of our method. us, 3.6% of the APKs were failed, and 96.4% is the efficiency. e component-based detection method that is proposed in [40] is used to detect the test set. Both test set detection results and comparison of the test set are shown in Table 12. e expression method is the test results of this method/the test results of [40].
From Table 12, it can be observed that the componentbased detection method proposed in [40] lacks the detection of dataflow between the applications. e detection result of collusion constitutes that a privilege escalation attack is invalid. e method of Wang et al. [40] does not distinguish between the apps that can constitute the privilege escalation attack and the ones that have hidden dangerous. erefore, 54.6% of the apps can be detected as privilege escalation attacks, but using our method, there are 71.0% of them which can be detected as privilege escalation attacks and hidden dangerous. Since Wang et al.'s [40] method only detects activities and service components, there is a 16.4% missing rate. Compared with the component-based detection method proposed in [40], the test results in Tables 8  and 12 indicate that the method proposed in this paper has the following advantages: (1) it detects sensitive dataflow pairs, making the detection of attack behavior features more effective; (2) it detects the dataflow path between applications, making the method more conducive to detect collusion attacks; (3) it can distinguish between an app that can constitute a privilege escalation attack and an app that is hidden dangerous, which makes the detection results more accurate; and (4) it detects the four components that lead to reduction in the missing rate.
As shown in Figure 10, components are the basic units of detection, while 1,679 components are detected in this study.
Among them, 272 components have Intent communication.
e components of the app use Intent to send sensitive data; however, no components receiving sensitive information can be detected in the app. In this case, there may be a vulnerability in passing sensitive information or encoding, which is termed a dangerous component, represented by a total number of 88 components. In the encoding process, some components are registered in the AndroidManifest.XML file, but in the app, these components have never been used. It is called a registered but unused component, with 53 components in total. e detailed statistical results are shown in Table 13.
For example, in the APK with the package name "com.example.healthmonitor," it is detected that there are 12 components registered, such as ".Uploadimage,.Ecgdactivity,.Ecgdatactivity, and.Shakeactivity," but they are not used. In the APK with the package name of "com.yuntongxun.ecdemo1," there is a dangerous component ".Main.index." In this component, the sending action with Intent name of "SendTo" is detected, but the receiving component of the Intent data cannot be found in the APK.
As per Table 11, there are 13 apps of the same company or developer in the test set. Among them, there are three apps that constitute privilege escalation attacks, two apps  Intentfilter  ActivityCommunication1  T/T  T/T  NT/NT  T/N  NT/N  A/A  ActivityCommunication2  T/T  T/T  T/T  T     Mobile Information Systems 13 that can constitute privilege escalation attacks, and five apps that have hidden dangers, as shown in Table 14. e statistics in Table 14 show that the percentage of the applications of the same developer that can constitute the privilege escalation attacks and carry security risks is relatively high. is is because (1) e same developer's ideas and methods are the same, which makes it easy to produce the same software vulnerabilities and coding irregularities (2) e same developers have the convenience of using the application developed by them to constitute privilege escalation attacks erefore, the joint detection of multiapp in the same development is particularly important.
Our test results show that the dangerous factors in the app that can constitute the privilege escalation attack included dangerous permission abuse and inaccurate use of component Intent methods, as shown in Table 15.
For example, in the APK with the package name "com.example.healthmonitor," 36 components that repeatedly applied for permissions were detected. Among them, "android.permission.WRITE_EXTERNAL_STORAGE" was applied for a dangerous permission six times, "android.permission.READ_PHONE_STATE" five times, and "android.permission.ACCESS_FINE_LOCATION" four times, with more examples occurring but not listed herein.

Conclusion
On the basis of feature extraction of applications, our method proposes that application behavior and attack behavior can be modeled through process algebra and combined with a strong simulation to detect a single application and then uses interapplication dangerous information flow path algorithm to detect the interapplication calls so as to determine the multiapps that constituted the privilege escalation attacks. In our method, we fully consider the different roles of multifeatures in the application-layer collusion attacks. e proposed approach was tested by using the DroidBench benchmark; the results show its good accuracy. rough the detection of the test set, 32.7% of the APK can constitute privilege escalation attacks, 32.7% of the APK have security risks, and the efficiency of the method is 96.4%. Based on the test results of this study, the improper use of permission, intent communication, and the intentional design of the same developer are the biggest factors that cause the collusion attack of the application layer. In the future work, we will continue to study the privilege escalation attack model and dynamic feature extraction technology to refine attack behavior features and improve the attack model.

Data Availability
e measurement data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare no conflicts of interest.
Acknowledgments is work was partly financially supported through grants from the National Natural Science Foundation of China (no.