Risk Measurement Method for Privilege Escalation Attacks on Android Apps Based on Process Algebra

: On the Android platform, information leakage can use an application-layer privilege escalation attack composed of multi-app collusion. However, the detection effect of a single app that can construct privilege escalation attacks is not good. Furthermore, the existing software and app measurement methods are not applicable to the measurement of collusion privilege escalation attacks. We propose a method for measuring the risk of a single app by using process algebra to model and determine the attack behavior, and we construct a measurement function based on sensitive data transitions and the feature set of attack behavior. Through the analysis of the privilege escalation attack model, the feature set of attack behavior is obtained. Then, based on the extracted behavior feature set, process algebra is used to model the dangerous behavior of an app. The dangerous behavior of the app is determined by weak equivalence and non-equivalence, and finally the risk of the app is measured based on the measurement function. Three known applications are used to verify the attack, and the risk measurement values are above 0.98. Based on the classification of applications on the market, we select typical apps in each category to build the test set. Benchmark tests and test set experiments show that the risk measurement results are consistent with the actual detection results, verifying the feasibility and effectiveness of this method.


Introduction
With the rapid development of the mobile internet and the Internet of Things(IoT), the Android system, which accounts for 40.39% of operation system (OS) market share, has become an important application platform [1]. Therefore, Android apps are widely used in smart homes, smart healthcare, online education, transportation, tourism, and other aspects closely related to people's lives. From the perspective of trends in mobile threats, security problems related to the mobile internet and the IoT are highlighted in the 5G era [2][3][4]. There are also more and more threats to Android apps that carry a large amount of users' privacy data [5,6]. The Nokia Thread Intelligence Report2019 points out that, in 2018, the average monthly infection rate in mobile networks was 0.31%, and Android devices were responsible for 47.15% of the observed malware infections [7].
Based on the report in [8], it was found that 98.7% of the devices in the security analysis results of the system vulnerability. Compared with 89.7% in 2018, the percentage of privilege escalation vulnerabilities has increased, and the threat by privilege escalation attacks has increased. However, application-layer collusion privilege escalation attacks composed of multi-app collusion is based on multiple independent and secure app collusions. Such attacks can complete the theft of user's privacy data and destructive operation through the collusion of multiple apps. The attack behavior of collusion privilege escalation attacks is more covert and more threatening. Therefore, more and more researchers are focusing on collusion privilege escalation attacks on Android apps.
At present, researchers have made remarkable detection and prevention methods for collusion privilege escalation attacks on Android apps. However, for the current permission granting mechanism, most existing detection and prevention methods become costly or rigid in the recent Android dynamic permission environment [9]. Risk measurement method can avoid the detection of communication between applications and reduce the cost of the method, so it is a feasible solution to measure the risk of the app which can constitute the collusion privilege escalation attacks. At the same time, researchers have put forward many classical methods for the security measurement of software and apps. Therefore, it has a solid research foundation and technical feasibility.
However, due to the strong concealment of collusion privilege escalation attacks, the use of existing methods to measure a single app is not effective. The main problems are as follows: (1) the measurement is mainly based on the overall behavior, performance, or development process of the software, without considering the attack behavior features of collusion privilege escalation attacks; (2) the risk measurement of the app is only based on one feature, such as permission or application programming interface (API) calls, without considering the multi-feature nature of collusion privilege escalation attacks. There is a lack of research on the security measurement of collusion privilege escalation attacks on a single app. Therefore, this paper proposes a method to measure collusion privilege escalation attacks on Android apps based on process algebra. The specific method is described as follows: (1) Extraction of the attack behavior feature set and the number of transitions. Based on an analysis of the model of collusion privilege escalation attacks, six features of the app, namely dangerous permissions of the app, dangerous permissions of the components, component intent communication, sensitive API calls, sensitive data flow acquisition, and dissemination of sensitive data, are obtained as the feature set of attack behavior, and the number of transitions is extracted by using static technology. (2) Attack behavior modeling and determination. Based on the extraction of the attack behavior features set, process algebra is used to model app behavior and attack behavior, and weak equivalence is used to determine app behavior. (3) Risk measurement. According to the result of the behavior determination, the number of behavior features and the number of transitions, a measurement function is constructed to measure the risk of the single app.
The contributions of this paper are as follows: (1) Construction and extraction of the feature set of collusion privilege escalation attacks. After obtaining the attack behavior feature set, the static extraction method is used to extract the behavior feature set and the number of transitions of sensitive data. This is done in order to make up for the lack of collusion privilege escalation attack features in the existing app measurement methods.
(2) Modeling and determination of app behavior using process algebra. The behavior of the app is modeled and determined based on semantics and the equivalence concept of process algebra, and any app that is weakly equivalent to attack behavior is measured. In view of the particularity of collusion attacks, this makes up for the inaccurate measurement results caused by the existing measurement methods that do not distinguish the equivalence relationship of test objects.
(3) Construction of the measurement function and test set experiment. Based on the number of features in the feature set and the number of transitions, the measurement function is constructed. The case, benchmarks test and test set experiments are completed by using the measurement function. The experimental results show that the method is feasible and effective.

Related Work
For the detection of and protection against malware in Android systems, researchers have put forward many classical solutions, from the initial signature-based detection method to the behavior-based dynamic and static detection methods, and then to the data mining and machine learning-based detection methods [10][11][12][13]. However, due to their lack of analysis of the features of collusion privilege escalation attacks, these detection methods have a poor detection effect on a single app that can construct collusion privilege escalation attacks. Based on these previous achievements, researchers have carried out in-depth analysis on privilege escalation attacks on Android apps, and produced remarkable research results. Kernel-level privilege escalation attacks are detected by stain tracking and monitoring permission information [14,15], while for application-level privilege escalation attacks, references [16,17] respectively detect and protect against application-level privilege escalation attacks that function by Android security modules (ASM) access control and monitoring of important system calls. However, application-layer collusion privilege escalation attacks occur on the basis of the collusion of multiple independent and secure apps, so it is particularly important to detect the dangerous path between apps [9,16]. However, the existing detection methods have shortcomings in the following two aspects: (1) their lack of detection of inter-application communication that can construct privilege escalation attacks; (2) their lack of analysis and detection of the features of collusion privilege escalation attacks. With the continuous improvement of Android security mechanisms, the cost of inter-application communication detection and multi-feature detection is increasing. Therefore, the measurement of application-layer collusion privilege escalation attacks has attracted the attention of researchers.
Meanwhile, researchers have made many achievements in the field of software and app security trust measurement. Zhao Qian et al. [18] used pi-calculus, an important branch of process algebra,to measure software dependability by comparing real running results with expected results, so as to conduct quantitative research on software credibility. Although this method uses runtime in behavior modeling, it can reflect the credibility of real-time software changes. However, for collusion privilege escalation attacks, it can disguise the attack result as the expected target and rationalize the attack behavior. Based on the trust theory in the field of human sociology, a measurable software trust framework (social to software, S2S) is proposed in reference [19]. From the point of view of software capability, it gives an overall measurement solution for software trustworthiness. However, as for a single app that constitutes collusion privilege escalation attacks, the app is secure and non-threatening when it alone running, which will make the measurement method invalid. In reference [20], evidence is considered as the basic element for establishing software trustworthiness and supporting a trustworthiness evaluation, and a software process trustworthiness model is proposed based on process assurance. Although the establishment of this method runs through the whole development process, and its considerations are more comprehensive, it is difficult to measure collusion privilege escalation attack by this method in cases where developers have designed an app as part of a collusion privilege escalation attack from the beginning. Reference [21] introduces a risk assessment method based on an analysis of the relationship between permission and function, and it is found that standardizing permission application by Android developers can provide reasonable permission configuration to users in real time and reduce the risk of permission abuse. However, this method only considers the risk of using permissions in the implementation of functions, but fails to consider other attack features. Xu Junfeng et al. [22] proposed a credit index measurement method for Android app security based on analytic hierarchy process (AHP) combined with the Android software certification strength and the violation records in the third-party application market. This method considers the violation records of third-parties. Therefore, the credibility evaluation is more objective. However, the concealment of the attack associated with collusion privilege escalation attacks makes it difficult for the third-party's violation record to mark the app's violation in time. Li Danjun et al. [23] proposed an application risk assessment method based on behavioral analysis by using a sandbox approach to dynamically monitor and record the behavior of applications on Android. However, this method only considers the system's API calls, not other attack features. Reference [24] proposed a criterion to measure the security risks of the apps based on analyzing requested permissions of large numbers of malwares and benign apps. This method used the concepts of entropy given that more informative permissions have higher impacts on the computed risk values. Although this method considers the scale of information in permissions, the permissions for collusion attack may not have more information.
Therefore, previous research results on software and app credibility measurement have been achieved. However, due to the strong concealment and camouflage of application-layer collusion privilege escalation attacks, the detection effect of existing software measurement methods for collusion privilege escalation attacks is not good. The main problems are as follows: (1) Up to now, there has been no method to measure the credibility of a single app that constructs collusion privilege escalation attacks.
(2) The existing methods do not consider the feature set of attack behavior when measuring the credibility of a single app, and they only focus on one feature.
Therefore, it is very important to measure the risk of a single app that constructs collusion privilege escalation attacks. In view of this, the present paper proposes a method for app risk measurement using process algebra.

Background Information
In order to better describe and understand this measurement method, some background concepts are explained.
(1) Definition and classification of privilege escalation attacks on android app.
Privilege escalation attacks means that an application with lower (less) permissions can access components with higher (more) permissions without being restricted by tasks. That is, a malicious program without any permission can obtain the required permission through a third-party app.
This attack can be divided into two categories: kernel-level and application-level. There are two kinds of application-layer privilege escalation attacks: confused deputy attacks and collusion privilege escalation attacks. Our study is focused on the application-layer collusion privilege escalation attack.
The privilege escalation attack occurs in the application-layer of Android architecture. Android apps access components with more permissions than themselves through third-party apps and intent communication.
(3) Definition of confused deputy attacks. This is a kind of application-layer privilege escalation attack. It exploits privileged app interface vulnerability and exploits the interface vulnerability. One component of the app has applied for dangerous permissions that it does not need, and there are interfaces that allow other apps to access through intent. By scanning the interface, malware can use its implementation to confuse agent attacks.
(4) Definition of collusion privilege escalation attacks. This is a kind of application-layer privilege escalation attack. It takes place on the basic of collusion of multiple apps, and completes the attack by gradually upgrading permission. App A obtains sensitive information but does not apply for permission P, but component comA of A has the ability to access the component comB of App B. At this time, B applies for P. ComB has the ability to access the component comC of App C, and comC has applies for P. Therefore, from comA does not apply for P to comA completes access to comC with using comB and P, which constitutes collusion privilege escalation attacks, and completing sensitive information leaks and other attacks.  Figure 1 describes a privilege escalation attack based on multi-app collusion [25]. AppA and AppC do not apply for permission P1, while AppB applies for P1, and component ComC1 applies for P1; therefore, componentComA1 is not protected by P1, while components ComB1 and ComC1 are protected by P1. As can be seen in Figure   Therefore, based on the analysis of Figure 1, we can obtain the behavior feature set F of the privilege escalation attack as

Construction of the Attack Behavior Feature Set
where: (1) F1 indicates the dangerous permissions of the application.
(2) F2 indicates the dangerous permissions of the components.

Extraction of the Attack Behavior Feature Set
For Android application package (APK), APKTool is used to convert APK into a Smali file for analysis. The AndroidManifest.xml file is the information description file of the application, which defines the permissions, components, intent filter and other information contained in the application. The behavior feature set is extracted from Smali and AndroidManifest.xml.
The latest dangerous permissions list is obtained from Google official documents, and permissions disabled after version 5.0. PScout [26] summarizes the relationship between the permissions and API calls of multiple versions of Android, and builds sensitive API sets based on the dangerous permissions list.

Permissions of the application
The application permissions are extracted according to the <uses-permission> tag in the AndroidManifest.xml file.

Permissions of components
(1) The component information is extracted according to the <activity></activity> tag in the AndroidManifest.xml file.
(2) The permissions of components are extracted on the basis of (1).

Component Intent communication
Based on the extraction of the component information, the special function calls (getExtra, putExtra, etc.) in the Smali file are used to extract the information on Intent communication.

Sensitive API calls
The system call sequence is extracted by the Android Software Development Kit's(SDK's) strace, and the sensitive API calls are obtained by combining the sensitive API set.

Sensitive data flow acquisition
FlowDroid [27] is used to extract sensitive data flow pairs, that is, < source, sink >, where source is the information's source and sink is the leakage point. 6. Dissemination of sensitive data FlowDroid [27] is used to detect the data dissemination path from source to sink. 7. Applying for the dangerous permissions of the application and components On the basis of 1 and 2, the dangerous permissions applied by the app are obtained according to the dangerous permissions list.

Attack Case
According to the attack model in Section 4.1, we designed three apps to constitute aprivilege escalation attack [28], and the key code is shown in Figure 2. According to the above code: 1) comAppA does not apply for any dangerous permission. Its component inputInfromShowActivity obtains the user's private information (username and password) through edittext, and sends it to the component whose <intent-filter > is sensitiveInfo through the intentAppA. 2) comAppB has applied for the dangerous permission android.permission.SEND_SMS, and its component sendNewsToFriend has <intent-filter> as sensitiveInfo. The user's private information (username and password) is obtained by bundleB and is sent to the component whose <intent-filter> is sensitiveInfoSend through intentAppB. 3) comAppC has not applied for any dangerous permission, but its component sendMessage has applied for android.permission.SEND_SMS dangerous permission and has <intent-filter > as sensitiveInfoSend. Using bundleC, the username and password are obtained and sent to the mobile phone number by SMS.

Process Algebra Based on Behavior Features
Process algebra [29] can effectively describe the Android architecture and message communication characteristics, and it can be used in the creation of an application attack behavior model according to the attack behavior feature set. The following is the syntactic and semantic specification of process algebra based on behavior features. appComBehavior ∷ = P . a |Feature |Feature ∈ ⋯ |Feature | X < y , y , ⋯ , y > X(y , y , ⋯ , y ) (action)P where: is a summation, where I and K are any finite indexing set. a is protected byP , because a must start activities after the action represented by P occurs. It represents a collection of behaviors of a component of an app under permission. 2) Feature |Feature | ⋯ |Feature represents that the component has w features at the same time.

3)
X < y , y , ⋯ , y > | (y , y , ⋯ , y ) ,where X < y , y , ⋯ , y > represents the action of message transmission; X(y , y , ⋯ , y ) represents the action of message receipt; y , y , ⋯ , y represents n sensitive data. 4) (action)P represents that the action is under the protection of permission P.

Attack Behavior Modeling
In the Android architecture, apps are made up of several services and components. A component is the basic unit of an app. In the case of a privilege escalation attack, a component with dangerous behavior must complete the collection, transmission and sending of sensitive information under the protection of dangerous permission. The four components of Android are as follows: 1) Activity, which is used to express the function. 2) Service, which runs in the background and does not provide interface presentation.
3) BroadcastReceiver, which is used to receive broadcast information. 4) ContentProvider, which supports data storage and reading across multiple applications and is equivalent to a database.
Therefore, the dangerous behavior of a privilege escalation attack must be carried out by a component, and the behavior of the application components constitutes the behavior of the application. According to Formulas (1) and (2), the definition of component attack behavior under P1 can be obtained, as shown in Formula (3).
3) X < y , y , ⋯ , y > X(y , y , ⋯ , y ) , where X < y , y , ⋯ , y >represents the action of message transmission and X(y , y , ⋯ , y )represents the action of message receipt.y , y , ⋯ , y represents n sensitive data. 4) (χ)P represents the behaviorχofan application is protected by permission P.

Behavior Determination and Risk Measurement Based on Process Algebra
According to the state relations of strong equivalence, weak equivalence and non-equivalence defined in process algebra, we use the concept of weak equivalence to determine the dangerous behavior and then combine the risk measurement function to measure the risk.   f (x, y).
where x represents the number of dangerous features in F(0 ≤ ≤ 6), and y represents the number of transitions (0 ≤ ≤ ∞).
(1) When x tends to be 6 and Y tends to be infinite, then

Feature Set Extraction of Attack Behavior
Using Equation (1), the behavior feature sets of comAppA, comAppB, and comAppC can be obtained respectively, as shown in Table 1. Because the code is tedious, in order to save space, the behavior feature is not represented directly by code,but it is represented by T and F, where T means that the feature exists, and F means that the feature does not exist. Table 1. Feature sets of comAppA, comAppB and comAppC. Table 1, it is shown that the number of Fs for comAppA, comAppB, and comAppCis 3, 6, and 5, respectively.

Attack Behavior Modeling
For the case of the privilege escalation attack given in Section 4.3, the attack behavior models of comAppA, comAppB, and comAppC can be obtained according to Table 1 and Equation (3).
(1) The attack behavior of comAppA is modeled as shown in Equation (5).

AppBehavior Modeling
The behavior models of comAppA, comAppB, and comAppC can be obtained according to Table 1 and Equation (2).
(1) The behavior of comAppA is modeled as shown in Equation (8).

BehaviorDetermination
App has a feature then it has a state when the feature exists. For example, App has permission P, and then its component is protected by P. The privilege escalation attacks must be a part of the action set of the application itself. Therefore, according to the Definition (1), the status and behavior of app can build LTS, and the status of Equations (6) and (9)    Construct the state transition diagram of Equations (6) and (9), as shown in Figure 3a,b. According to the Definition (2), suppose that S = {(q , p ), (q , p ), (q , p ), (q , p ), (q , p ), (q , p )}. (1) p weak simulation q verification. ∀(q, p) ∈ S , each migration of the first element q, q → q , 0 ≤ i, j ≤ 4 can be migrated p → p , 0 ≤ i, j ≤ 4 by a second element p matching (or a series of migration, or even no migration). For example, for(q , p ),q has q → q ，so ∃(q , p ) ∈ S ，using p → p matching. Therefore, s is a weak simulation, that is, p weak simulation q .
(2) In the same manner, the weak simulation relationship of each state in two state graphs can be verified. (3) According to the concept of weak equivalence Definition 3, S -1 can be verified as a weak simulation in the way of (1). (4) Therefore, the weak equivalence between the states in Figure 3a,b can be verified. Then, the weak equivalence between the Equations (6) and (9)  To make the verification more automated, the mobility workbench (MWB) was chosen as the verification tool. Standardize Equations (6) and (9) according to MWB syntax [30].For example, the output a in process algebra should be converted to 'a. Therefore, x < y > in Equation (6) is convert to MWB syntax is ′x < y >. In order to better distinguish the input and output, we use ′y < y > to represent the output. The comAppBBehavior in Equation (9) is represented by agent BB when it is encoded by MWB, and the comAppBAttack in Equation (6) is represented by agent BA when it is encoded by MWB. Agent BB1X and BA1X represent the components of BB and BA respectively. Weq and eq are used to verify the weak equivalence and strong equivalence of the two models. Therefore, the weak equivalence relationship between the component behavior model (BB) and the component attack behavior model (BA) can be verified, as shown in Figure 4a. At the same time, the comAppAChange in Equation (11) is represented by AC when it is encoded by MWB, and the comAppAAttack in Equation (5)   As can be seen from Figure 4, MWB can be used to verify the weak equivalence relations of Equations (5) and (8), as well as Equations (7) and (10) respectively, that is, it can be verified that comAppA, comAppB, and comAppC are weakly equivalent to the attack model.

Risk Measurement
According to Definition 5, the number of sensitive data transitions of comAppA, comAppB, and comAppC can be obtained,as shown in Table 4. Using Equation (4) and the risk measurement algorithm 1 based on process algebra, measurement values for the three apps can be obtained, as shown in Table 5. From the measurement results in Table 5, we can see that the measurement values of comAppA, comAppB and comAppC are close to 1. The measurement values of comAppAChange, for which the relevant features have been changed, is 0. Theseresults are consistent with the actual app's dangerous behaviors, so this shows the effectiveness of our method.

Method Evaluation
In this paper, APKTool and FlowDroid are used to extract the attack behavior feature set. MWB is used to verify the equivalence of behavior. Java language is used to implement the risk measurement algorithm. All experiments were carried out on a machine with 8G memory and Intel (R) core (TM) i5-2520M CPU.
The key steps in this method are attack behavior feature set extraction and transition detection, and the time complexity of the dangerous behavior determination and measurement algorithm is O(n). In the experiment on the test set, due to the different of feature set and the number and path of transition, the costs of time and space are discretely distributed, as shown in Figure 5. This method is discussed in two cases: weak equivalence and non-equivalence. According to measurement algorithms and measurement function, weak equivalence APKs must be risk measured, but non-equivalence APKs risk measurement value is 0. The size of the APK, the number of components, the number of sensitive data transitions and the number of features in the attack behavior feature set affect the time cost and space cost of this method. There are three situations as follows: (1) Some of the APKs have some features as small size, fewer components, or fewer sensitive data transitions and attack features. In general, those APKs are non-equivalent to attacks behavior. Those APKs have less time cost and space cost.
(2) Another part of APKs have the following features as larger size, more components, or a greater number of sensitive data transitions and attack features. In general, those APKs will be weak equivalent to the attack behavior. Those APKs has more time cost and space cost for this method. (3) There will be some special APKs. For example, two APKs have similar size, but because the number of components, transitions and features of first APK is far greater than second APK, the time cost and space cost of first APK are also far greater than second APK. However, it will follow the principle that with more components, or the greater number of transitions and features there, the more this method will cost in terms of time and space.
Therefore, according to the analysis of (1) and (2) on the above, the time cost and space cost of this method are prone to the phenomenon of two groups separated, as shown in Figure 5b. According to (3) on the above, due to special circumstances, those two groups are not necessarily completely separated, as shown in Figure 5a.

BenchmarksTest and Analysis
DroidBench [31] is a set of open source real-life Android applications to be used as a testing ground for static and dynamic security and measurement methods. FieldAndObjectSensitivity, InterAppCommunication, and InterComponentCommunication test sets in DroidBeach are measured by the method in this paper. Three test sets cover sensitive data acquisition and propagation, inter-application communication and component communication, which have the attack features of collusion privilege escalation attacks. The methods, shown in Sections 4, 5, and 6, and Equation (4), are used to verify the behavior equivalence and measure the risk. Table 6 shows the F sets, equivalence relations, and measurement results of each test object, where T represents the existence of feature and F represents the no-existence of feature.  FieldSensitivity1  T  T  F  T  T  T  1  Weak  0.997521248  FieldSensitivity2  T  T  F  T  T  T  1  Weak  0.997521248  FieldSensitivity3  T  T  F  T  T  T  1  Weak  0.997521248  FieldSensitivity4  T  T  F  T  T  T  1  Weak  0.997521248  ObjectSensitivity1  T  T  F  T  T  T  1  Weak  0.997521248  ObjectSensitivity2  T  T  F  T  T  T  2  Weak  0.999088118  IntentSource1  T  T  T  T  F  T  1  Weak  0.997521248  ServiceCommunicati  on1  T  T  F  T  T  T  1  Weak  0.997521248   SharedPreferences1  T  T  F  T  T  T  1  Weak  0.997521248 The relationship between the sum of the number of behavior features and transition of the test object and the measurement results is shown in the Figure 6. (1) The measurement value in Table 6 is between 0.9975-0.9999, which verifies the effectiveness of this method. The three test sets have information leak of sensitive data, communication between apps and communication between components respectively. From the measurement results, it can be seen that app with the risk of such an information leak has a higher risk of privilege escalation attacks, which is consistent with the actual situation.
(2) Figure 6 shows that the sum of the number of behavior features and transition is directly proportional to the measurement results. The necessity of building F and extracting migration times is verified.

Composition of the Test Set
The test set is composed of 51 apps from the Android application market such as Google Play and 3 apps developed by the research team [32]. In order to enrich the test set, 22 categories are selected; and one to three typical apps are selected for each category. The specific classification and number of apps are shown in Table 7.  number  3  1  3  3  3  3  3  1  2  2  3 The selection of each typical application is as follows: (1) among the same type of app, it should be ranked as high as possible; (2) the APK should be as small as possible. Following the secondary principle, the size of APKs in the test set is shown in Figure 7. The smallest APK's size is 0.4 M, the largest APK's size is 22.5 M, and the average size is 5.33 M. Meanwhile, apps from the same developer have the convenience of having collusion privilege escalation attacks deliberately created for them, and the same developer is prone to generate the same software vulnerabilities in the process of app development. Therefore, in the selection of samples, six developers and 16 apps are selected, as shown in Table 8. For the test set, the detection method in reference [33] by our research group is used for detection, which is divided into three categories: constituent attack apps, hidden danger apps, and non-dangerous apps. The specific detection results are shown in Table9. According to Table 9, unsafe apps account for 74.1% of the test set.

Measurement Results and Analysis
We use the method in Section 4 to extract the feature set F of the test set, and part of the extracted data is shown in Table 10. Using the methods in Sections 5 and 6, the test set can be divided into weak equivalent app and non-equivalent app, as shown in Table 11. According to the data in Tables9 and11, the attack behavior determination result by our method is consistent with the detection result by reference [33].
To measure the test set, the measurement algorithm is used, and the app determination results and measurement values from Table 10 are shown in Table 12. The measurement values of test set are shown in Figure 8a, and the curve values of 40 weakly equivalent apps are shown in Figure 8b. In Table 8, 13 apps developed by the same developer were verified as a weak equivalent with the attack model. The measurement results are shown in Figure 9. From the measurement results in Figures 8 and 9, the following three conclusions are obtained: (1) The measurement results clearly show the risk degree of the attack. From Figure 8b, it can be seen that the measurement values of weakly equivalent apps with the collusion privilege escalation attack model are all above 0.86, which is consistent with the actual danger level of the app.
(2) The measurement value is proportional to the number of features in the feature set and the number of transitions of sensitive data. As can be seen from Figures 8b and 9, the more features and sensitive data transition times, the greater the risk measurement. However, in Figure 8a, there are some particularities, so we need to further strengthen the analysis and refine the feature set and the measurement function. (3) The risk of collusion privilege escalation attacks is higher in an app developed by the same developer. From Figure 9, it can be seen that the measurement values of weakly equivalent apps with the attack model are all above 0.95, which proves that the risk of collusion privilege escalation attacks is high.

Conclusions
Process algebra was used to model a component's behavior and attack behavior based on the extracted behavior feature set and the number of transitions. Then, weak equivalence was used for decision making. Finally, a risk measurement was carried out based on the measurement function. Through the case, benchmarks and test set experiments, it is verified that the measurement results of this method can clearly show the risk degree of collusion privilege escalation attacks for an app. From the research in this paper, it can be seen that if an app has more attack features and sensitive data transition times, then the app has a higher risk measurement value. Furthermore, the risk of collusion privilege escalation attacks for apps that were developed by the same developer is significantly higher than that of other apps. Future work will be carried out in relation to the following two aspects: 1) Because there are many apps with measurement values in the range of 0.86-0.99, it is necessary to refine the measurement function and privilege escalation attacks behavior feature set to ensure that the measurement value is more reasonable. 2) We used the same weight of features in the feature set, and different weights can be calculated using a correlation method to improve the accuracy of the measurement.