Multi-dimensional android platform application behavior security evaluation method fusing user subjective evaluation

Abstract

The application discloses a kind of multi-dimensional Android platform application behavior security evaluation method of fusing user subjective evaluation, this method is combined with static detection based on permission correlation, dynamic monitoring based on historical confidence and user subjective expectation based on subjective correlation, and the application of Android platform is quantitatively evaluated to behavior security.This method includes application analysis method and application evaluation method.The former is based on the static detection of permission to apk source file, improve the fineness and objectivity;Dynamic monitoring is carried out to the real-time behavior of application, and the calling condition of each permission within a certain time is obtained;The result of static detection also provides guidance for dynamic monitoring, compensates its inefficiency.The latter is based on the two-dimensional result of application analysis method, and the subjective expectation of different users for different applications using different permissions is integrated, and the personalized application quantitative evaluation score is obtained according to the sensitivity of different users, which ensures the objectivity and science of detection analysis while considering the different attitudes of different users.

Description

Technical Field

[0001] This invention relates to the field of mobile application security, and more specifically to a multi-dimensional Android platform application behavior security assessment method that integrates user subjective evaluation. Background Technology

[0002] Mobile devices based on the Android platform have attracted a large number of users due to their ease of use, rich functionality, and expandability. With the widespread adoption of the Android operating system, a vast array of applications have been developed, providing end-users with a wealth of features. However, the increasing number of applications also brings serious security risks. Android software can easily obtain users' sensitive information, and inadequate protection can easily lead to privacy leaks. This risk has also attracted the interest of unscrupulous operators and even attackers, leading to the proliferation of malware in app stores, infiltrating legitimate software and threatening user privacy and security. For example, there are rogue software programs, such as spyware, that track user location and report to controllers; adware that collects user identity information for targeted marketing; and malware that steals bank passwords and other sensitive user information to commit crimes.

[0003] To prevent such applications, it's necessary to help users review them during installation. The Android system relies on permissions to help users understand the security and privacy risks of applications. Applications must request permissions to access sensitive resources. In other words, Android applications must present their expected behavior to the user. However, this is coarse-grained; even if permissions describe the resources an application attempts to access, they don't provide fine-grained information about how those resources are used. Suppose a user installs an application and allows it access to their contacts. It's difficult for the user to know whether the application is accessing the information as expected or is continuously accessing it without the user's explicit consent. Therefore, in addition to static analysis based on permissions, continuous dynamic analysis and understanding the user's level of concern regarding sensitive behaviors are also essential. On one hand, sensitive behaviors can be recorded in real-time by continuously tracking the application's calls during actual operation; on the other hand, monitoring priorities can be adjusted based on subjective expectations, with targeted marking. A comprehensive mechanism needs to build upon static analysis to guide the monitoring of installed applications, such as API calls during software runtime, and combine this with user expectations to inform users before malicious applications abuse their sensitive information.

[0004] In daily use, the appropriateness of a mobile application's behavior should be left to the user's risk assessment based on their personality and perspective. However, not everyone can accurately assess software security. Furthermore, users need to understand the application's behavior in different environments that will not pose a security threat. But such assessments are impractical for the average user. Therefore, an automated assessment mechanism is needed to evaluate applications and effectively alert users when their security expectations are violated. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a multi-dimensional Android platform application behavior security assessment method that integrates user subjective evaluations.

[0006] The present invention specifically adopts the following technical solution:

[0007] A multi-dimensional Android platform application behavior security assessment method integrating user subjective evaluation, characterized in that the method includes an application analysis method and an application evaluation method:

[0008] The application analysis method is used to perform static detection based on permissions on the application under test, and to perform real-time dynamic monitoring of the behavior of the application under test to obtain the application under test's call status for each permission; the results of the static detection provide guidance for the dynamic monitoring and compensate for the inefficiency of the dynamic monitoring.

[0009] The application evaluation method is used to quantify the results of static detection and dynamic monitoring to obtain feature vectors, incorporate users' subjective expectations of the software category to which the application under test belongs to call different permissions, and evaluate and score the software under test based on existing datasets of malicious and benign software according to the sensitivity of different users.

[0010] A further preferred embodiment of the present invention is:

[0011] The permission-based static testing of the application under test includes: obtaining the APK file of the application from the Huawei AppGallery; obtaining the application source code using decompilation technology; and analyzing the AndroidManifest.xml file obtained after decompilation using string matching technology to obtain the definitions in... <user-permission>Permission request status under the tag.

[0012] Real-time dynamic monitoring of the behavior of the application under test based on static detection results includes: installing the application under test in a rooted Android environment and using hook technology to control system service processes; increasing the number of monitored APIs for permissions requested frequently in static detection, and reducing the monitoring intensity for permissions not requested or requested sparingly in static detection; running the application under test and obtaining records of the application's calls to various privacy permissions and sensitive APIs within a certain period of time.

[0013] A further preferred embodiment of the present invention is:

[0014] The application evaluation method includes the following steps:

[0015] Step 1: Obtain the static indicator—permission relevance—based on the static detection data from the application analysis method;

[0016] Step 2: Obtain the dynamic indicator—historical confidence level—based on the dynamic monitoring data in the application analysis method;

[0017] Step 3: Based on the user's tolerance and sensitivity to different permissions requested by the software category to which the application under test belongs, obtain the subjective expectation index—subjective expectation value;

[0018] Step 4: Based on existing datasets of malicious and benign software, and combined with the three-dimensional indicators of static, dynamic, and subjective expectations of the application under test, an evaluation score is calculated.

[0019] A further preferred embodiment of the present invention is:

[0020] Step 1 includes:

[0021] Huawei's mobile app market categorizes software into 17 types, denoted as A. j For j∈{1,…,17}, according to the official Android documentation, permissions are divided into 9 groups, denoted as P. i , i∈{1,…,9}; Static detection yields the permission declaration vector, which is:

[0022] S MF ={p1, p2, ..., p g ,C} (1)

[0023]

[0024] C = j, if C ∈ A j (3)

[0025] Based on the permission declaration vector, the static metric permission relevance W(P) i A j The calculation formula is:

[0026]

[0027] Where N is the number of applications in the existing dataset that belong to the software category of the application to be tested, n(P) i A j ) indicates permission group P i In A j Frequency of occurrence in application categories, W(P) i A j ) represents the permission relevance of the i-th permission group in the j-th software category.

[0028] Step 2 includes:

[0029] Dynamic monitoring obtains the number of API function calls corresponding to each group of permissions for the application under test within a certain period of time, and calculates the historical confidence score H(API) of the dynamic indicator. i ):

[0030]

[0031] Where H(API) i ) represents the application being tested, A j Calling API group functions i Historical confidence level, call frequency t (API) i A j This indicates the likelihood of privacy being leaked through this permission, where β is the adjustment coefficient and σ is the growth coefficient, measuring the system's tolerance for the application accessing this permission as the likelihood of leakage increases.

[0032] Step 3 includes:

[0033] For A j For software of this type, users judge the categories of permissions or sensitive API functions they will use, with scores ranging from 5 to 1, from highly irrelevant to highly relevant. Higher scores are given for users who perceive a greater likelihood of security threats from using these permissions or API functions, and lower scores are given for others. The subjective evaluation vector is defined as E. user ,

[0034] E user (A j )={J(1,A j ),J(2,A j ),…,J(9,A j ),C) (6)

[0035] Where J(i,A) j () represents the user's subjective expectation.

[0036] Step 4 includes: weighting and summing the static, dynamic, and subjective expectation three-dimensional indicators of the application to be tested to obtain the indicator vector of the sample to be tested; using SVM soft margin to train the existing dataset to obtain the hyperplane and discriminant function Risk between malicious software and benign software; inputting the indicator vector of the sample to be tested; and evaluating and scoring it based on its distance from the hyperplane and the probability of being judged as benign software.

[0037] The beneficial effects of this invention are:

[0038] This invention obtains the permission request status of each group based on static detection, and obtains the permission relevance of each permission group corresponding to the software category of the application under test; it obtains the historical confidence of each group of permissions of the application under test based on dynamic monitoring of the access records of each group of permissions of the application under test within a certain period of time; it obtains the subjective prediction value of the application under test based on the user's tolerance and sensitivity to the use of each group of permissions of the software category to which the application under test belongs; finally, it combines the three-dimensional indicators of static, dynamic and subjective expectations of the application under test, and performs a quantitative evaluation of the behavioral security of the application on the Android platform based on existing malicious software and benign software datasets. Compared to traditional static and dynamic analysis methods, this invention introduces permission relevance into static detection and historical confidence into dynamic monitoring. This objectively reflects the objective permission requirements of the software category to which the application under test belongs, while simultaneously quantifying the actual usage of each permission group within a certain timeframe. Combining static and dynamic detection, and using static detection results to guide dynamic monitoring, it considers both code-level permission requests and the actual operation of the application. Furthermore, it performs specific real-time behavioral analysis of the application under test based on its category, compensating for the inefficiency of dynamic monitoring and improving its efficiency, ensuring a comprehensive and scientific assessment. Compared to traditional subjective judgments based on security experts' experience, this invention incorporates users' subjective expectations regarding the application's use of each permission group, reflecting the differences among users and providing differentiated assessment results for different attitudes and sensitivities. Compared to traditional tiered assessment results, the output of a percentage-based assessment score is more specific, allowing users to weigh and compare the security performance of different applications.

[0039] This method comprises application analysis and application evaluation. The application analysis method performs static permission-based detection on the application's APK source files, improving granularity and objectivity; it also dynamically monitors the application's real-time behavior, obtaining information on the application's access to various permissions over a specific time period. Simultaneously, the results of static detection provide guidance for dynamic monitoring, compensating for its inefficiency. The application evaluation method, building upon the two-dimensional results of the application analysis method, incorporates users' subjective expectations regarding the use of different permissions by different applications. It derives personalized quantitative evaluation scores based on different users' sensitivities, ensuring the objectivity and scientific rigor of the detection and analysis while considering the diverse attitudes of different users. Attached Figure Description

[0040] Figure 1 A flowchart illustrating a multi-dimensional Android platform application behavior security assessment method that incorporates user subjective evaluations;

[0041] Figure 2 A flowchart illustrating the specific implementation steps of permission-based static monitoring.

[0042] Figure 3 This is a flowchart illustrating the specific implementation steps for real-time dynamic monitoring of application behavior based on static detection.

[0043] Figure 4 Permission relevance for navigation and travel software used for testing;

[0044] Figure 5 Historical confidence levels for navigation and travel software used in testing;

[0045] Figure 6 The subjective expected values ​​of navigation and travel software for the experimental and control groups;

[0046] Figure 7 A comparison of location and sensor permission assessment values ​​between benign and malicious navigation services;

[0047] Figure 8 A comparison of location, phone number, and sensor permission assessment values ​​between benign and malicious navigation services;

[0048] Figure 9 Distance assessment scores under different levels of subjectivity;

[0049] Figure 10 These are probability assessment scores under different levels of subjectivity. Detailed Implementation

[0050] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0051] A multi-dimensional Android platform application behavior security assessment method that integrates user subjective evaluation includes application analysis methods and application evaluation methods.

[0052] The application analysis method consists of two steps: performing permission-based static detection on the application under test, and performing real-time dynamic monitoring of the behavior of the application under test based on the static detection results.

[0053] like Figure 2 As shown, the specific implementation method of permission-based static detection is as follows:

[0054] For static analysis, the APK file of the application to be tested is obtained from the official Huawei mobile app market, decompiled, and the permission request information is obtained by analyzing the AndroidManifest.xml file. The specific steps are as follows:

[0055] (1) First, obtain the apk file of the application to be tested from the Huawei mobile app market;

[0056] (2) Next, decompile the apk file to obtain the source code of the sample to be tested;

[0057] (3) Then, in the AndroidManifest.xml file in the source code... <user-permission>Perform string analysis on the permission declarations under the tags;

[0058] (4) Finally, the permission declarations are classified according to the permission categories to obtain the permission declaration vector.

[0059] like Figure 3 As shown, the specific implementation method for real-time dynamic monitoring of application behavior based on static detection results is as follows:

[0060] Install the application under test in a rooted Android environment, hook relevant system service processes, combine static detection results, selectively monitor relevant sensitive APIs, run the application under test, and obtain the application's access to various permissions within a certain period of time. The specific steps are as follows:

[0061] (1) First, redesign the app_process file to replace the original file in the Android system, load the pre-compiled jar package, and replace the program entry point;

[0062] (2) Secondly, the init process wakes up the incubation process Zygote, uses the fork function to start processes such as SystemServer, loads class libraries, and calls functions;

[0063] (3) Then, based on the analysis results of static detection, we should pay more attention to APIs that request more permissions and monitor related API behaviors more, and reduce the number of APIs monitored for those that do not request or request fewer permissions.

[0064] (4) Finally, install the application under test in the Android environment, run the application, and the hook module monitors the calls to system API functions and records them in the log;

[0065] like Figure 1 As shown, the application evaluation method consists of four steps: obtaining permission relevance based on static detection, obtaining historical confidence based on dynamic monitoring, obtaining subjective expectation value based on user subjectivity, and conducting quantitative evaluation based on three-dimensional indicators.

[0066] The specific steps for obtaining permission relevance based on static detection are as follows:

[0067] (1) According to Huawei's mobile app market, software is divided into 17 categories, denoted as A. j For j∈{1,…,17}, according to the official Android documentation, permissions are divided into 9 groups, denoted as P. i , i∈{1,…,9}; Static detection yields the permission declaration vector, which is:

[0068] S MF ={p1,p2,…,p9,C} (1)

[0069]

[0070] C = j, if C ∈ A j (3)

[0071] (2) For A j Application class, each of which has permissions P detected by static analysis i The relevance index, from largest to smallest, indicates the relationship between the permission and this type of application, from very weak to very strong; the frequency of use for each permission is F(P). i A j ), where n(P) i A j ) indicates permission group P i In A j The frequency of occurrence in the application category, where N represents the total number of applications analyzed in that category; as P... i The more times a permission group is requested, the higher the frequency of use of that permission will be, and the lower the weight value will be. This means that the risk of security threats is lower, and the safer the application under test is to use that permission.

[0072]

[0073] (3) The formula for calculating the permission relevance weight is:

[0074] F′(P i A j )=(1-F(P i A j )) 2 (8)

[0075]

[0076] The historical confidence level is obtained based on dynamic monitoring. The specific steps are as follows:

[0077] (1) API functions with a high relevance to privacy leaks are divided into 9 API groups corresponding to permission group categories, and defined as APIs. i ,i∈{1,2,…,9};

[0078] (2) The number of times the privacy API function is used within a certain time period, t(API i A j The relevance of this API group to the software functionality is used as an evaluation metric for historical confidence. Lower relevance and more frequent use will lead to an exponential decline in confidence in a particular API group. The historical confidence metric is defined as follows:

[0079]

[0080] Where H(API) i ) represents the application being tested, A j Call API group API i Historical confidence level, call frequency t (API) i A j This illustrates the possibility of privacy leaks through this permission, then H(API) i The slash α represents the trustworthiness of an application calling a specific set of APIs; β is the adjustment coefficient; σ is the growth coefficient, which measures the system's tolerance for the application accessing this permission as the possibility of leakage increases, and should be designed according to the actual situation.

[0081] (3) H(API) i Finally, the dynamic feature vector D is obtained. API ,

[0082] D API ={H(API1),H(API2),…,H(API9),C} (10)

[0083] The subjective expectation value is obtained based on the user's subjective opinion, and the specific method is as follows:

[0084] For A j For software of this type, users assess the categories of permissions or sensitive API functions they will use, with scores ranging from 5 (highest) to 1 (lowest), indicating a perception from highly irrelevant to highly relevant. Higher scores are given if the user believes using the permission or API function poses a security threat, and lower scores are given otherwise. The subjective evaluation vector is defined as E. user , where J(i,A) j This represents the user's subjective expectation.

[0085] E user (A j )={J(1,A j ),J(2,(A j ),…,J(9,A j ),C} (6)

[0086] The quantitative evaluation is based on three-dimensional indicators, and the specific steps are as follows:

[0087] (1) After normalizing the static, dynamic and subjective three-dimensional indicators of the application under test, the weighted sums are used to obtain the evaluation vector Risk of the application under test.

[0088] (2) Based on the existing dataset, the SupportVectorMachines (SVM) model is used to train the sample data. The SVM discriminates the input Risk evaluation vector and transforms it into a linear classification problem in a feature space of a certain dimension through nonlinear transformation. A linear SVM is then trained in the high-dimensional feature space. The kernel function K(risk) is used. i risk j To achieve nonlinear transformation, the inner product in the objective function and the classification decision function is replaced by a Gaussian kernel function.

[0089]

[0090] By selecting a suitable kernel function and a penalty parameter C>0, a nonlinear support vector machine is obtained to determine the separating hyperplane and the separating decision function between the two classes of samples, i.e., f. w (G), where G is the training set.

[0091]

[0092] Among them B i The result is a binary classification; the benign class is 1, and the malware class is -1. α i * ,b * This is the optimal solution to the convex quadratic programming problem.

[0093] (3) Based on the obtained separating hyperplane and separating decision function, there are two quantitative scoring methods; distance-based scoring: Let the distance function dist(A wait ,f w ), where A wait For the application to be discriminated; given a dataset G and the obtained hyperplane f w (G), defining the hyperplane about the sample point G i The geometric interval is γ i If the application is benign software γ i For positive, the γ of malware i If the distance is negative, train on the sample set. If the maximum distance in the training set is maxDist and the minimum distance is minDist, normalize the absolute values ​​of the distances from the hyperplane to the benign and malware class samples respectively, and invert the values ​​for the malware class samples; then map to the range of 1-100, and output the evaluation score Score(dist, A wait ,G), the range of 0-50 is defined as malware, and the range of 51-100 is defined as benign;

[0094] (4) Probability-based scoring: The probability of being classified as benign software is prob(A). wait The probability that the virus is of class A, G, 0 is prob(A, G, 0). wait ,G,1):

[0095] prob(A wait ,G,0)+prob(A wait ,G,1)=1 (13)

[0096] Calculate the probability distributions on both sides of the discriminant function to obtain Score(dist,A). wait ,G), the range of 0-50 indicates malware, and the range of 51-100 indicates benign.

[0097] The technical means disclosed in this invention are not limited to those disclosed in the above embodiments, but also include technical solutions composed of any combination of the above technical features.

[0098] Method Test Cases

[0099] Take travel navigation apps as an example.

[0100] Obtain the APK file of the application to be tested from Huawei's official mobile app store, and use a static analysis tool to test it, thus obtaining the permission relevance of navigation and travel applications. For example... Figure 4 As shown, the permissions for camera, location, phone, and storage have very low correlation, indicating that this type of software frequently requests these permissions. Therefore, when conducting security analysis on applications used by users, the request behavior of navigation and travel software for these permissions is tolerable.

[0101] The navigation app under test is installed in an Android environment equipped with a dynamic monitoring tool. The app is run, and the dynamic monitoring tool monitors and records the application's behavior to obtain historical confidence scores. The historical confidence scores of app X are shown below. Figure 5 As shown, by adjusting the values ​​of the growth coefficient and the adjustment coefficient, extreme cases of historical confidence levels are reduced, and the differences and intervals of each indicator are controlled within a suitable range. In this test, α=2 and β=3 were selected.

[0102] Two groups of users were assigned opposing subjective expectations. The experimental group was more sensitive to the use of various permissions and paid more attention to privacy protection, while the control group was relatively more tolerant and forgiving of the application's use of various permissions. Figure 6 As shown.

[0103] Figure 7 and Figure 8 The feature distribution of navigation and travel applications under test is shown. Figure 7 Two representative features, location and sensing, are selected to illustrate the two-dimensional feature distribution. Figure 8 The addition of telephone numbers allows for 3D feature visualization. It can be seen that the differences between the benign and malware classes are quite significant. Although the analytical values ​​of a few samples are relatively outliers, overall they are clearly binary separable, demonstrating the complementary role of the comprehensive framework.

[0104] Figure 9 and Figure 10 The evaluation schemes are distance-based and probability-based, with TN representing each software application. User A is the experimental group, and user B is the control group. It can be seen that in the distance-based evaluation scheme, for user A who prioritizes privacy, no application meets security expectations; the relatively secure TN4 only scores around 40. However, for user B, who is less concerned about geolocation and communication privacy, applications TN4 and TN5 meet security expectations and have higher evaluation scores. In the probability-based evaluation scheme, user B's software security situation is roughly the same as in scheme one. For user A, TN4 meets security expectations, and applications TN5 and TN1 show slight improvements in security. Overall, this user-oriented evaluation scheme has good usability. Different users show some differences in app classification results. The same behavior of the same category of software can lead to different subjective judgments, resulting in different evaluation results. This demonstrates that the model can highlight the differences between different software behaviors, quantifying them into significant numerical features that are easy for users to understand and perceive, providing a good reference for users. Furthermore, the figure also shows that among the two evaluation schemes, the probability-based evaluation scheme is more tolerant of user concerns and can balance the impact of overly extreme subjective scoring.

Claims

1. A method for evaluating the security of multi-dimensional Android platform application behaviors by fusing user subjective evaluation, characterized in that, The method comprises an application analysis method and an application evaluation method: The application analysis method is used for permission-based static detection of a to-be-tested application, real-time dynamic monitoring of to-be-tested application behavior, and obtaining the calling conditions of the to-be-tested application for each permission; the result of the static detection provides guidance for the dynamic monitoring and compensates for the inefficiency of the dynamic monitoring; for a permission that is applied more in the static detection, the number of monitored related APIs is increased, and for a permission that is not applied or is applied less in the static detection, the monitoring intensity is reduced; The application evaluation method is used for quantifying the static detection and dynamic monitoring results to obtain a feature vector, integrating subjective expectations of users on calling different permissions of a software category to which the application to be tested belongs, and weighting and adding three-dimensional indexes of static, dynamic and subjective expectations of the application to be tested to obtain a sample index vector; an existing data set is trained by using SVM soft interval to obtain a hyperplane and a discrimination function between malicious software and benign software , and the sample index vector is input to evaluate and score according to a distance of the sample index vector from the hyperplane and a probability of being judged as benign software. 2.The method of claim 1, wherein the method further comprises: The permission-based static detection on the to-be-tested application comprises the following steps: obtaining an APK file of the to-be-tested application from a Huawei mobile application market, obtaining application source code by using a decompilation technology, analyzing an AndroidManifest.xml file obtained after decompilation by using a string matching technology, obtaining definitions of <user-permission>The permission application conditions under the label.< / user-permission> 3.The method of claim 2, wherein the method further comprises: The real-time dynamic monitoring of the to-be-tested application behavior based on the static detection result comprises the following steps:

4. The method of claim 1, wherein the method of fusing user subjective evaluation for multi-dimensional Android platform application behavior security assessment is characterized by, The application evaluation method comprises the following steps: Step 1: obtaining a static index, i.e., a permission correlation degree, according to the static detection data in the application analysis method; Step 2: obtaining a dynamic index, i.e., a historical confidence degree, according to the dynamic monitoring data in the application analysis method; Step 3: obtaining a subjective expected index, i.e., a subjective expected value, according to the tolerance and sensitivity of a user to the calling of different permissions by the software category to which the to-be-tested application belongs; Step 4: performing evaluation scoring in combination with the three-dimensional indexes of the to-be-tested application, i.e., the static, dynamic and subjective expected indexes, according to existing malicious software and benign software data sets.

5. The method of claim 4, wherein the subjective evaluation of the fusion user is obtained by using a questionnaire. The step 1 comprises: According to Huawei mobile phone application market, the software is divided into 17 categories, denoted as , according to the Android official, the permissions are divided into 9 groups, denoted as , ; static detection gets the permission declaration vector, which has: According to the right declaration vector, the static index right correlation degree The calculation formula is: wherein is the number of applications in the existing dataset belonging to the software category of the application to be tested, denotes a permission group In the frequency of occurrence in the application category, denotes the th permission group in the th software category.

6. The method of claim 5, wherein the subjective evaluation of the fusion user is obtained by using a questionnaire. The step 2 comprises: The dynamic monitoring obtains the number of times of calling the API function corresponding to each group of permissions of the to-be-tested application in a certain time, and calculates the dynamic index historical confidence : wherein represents the detected application invokes API group functions the history confidence, the invocation frequency illustrates the possibility of leaking privacy through the permission, is a regulation coefficient; is a growth coefficient, which measures the tolerable degree of the system to invoke the permission of the application as the possibility of leakage increases.

7. The method of claim 5, wherein the subjective evaluation of the fusion user is obtained by using a questionnaire. The step 3 comprises: For software, the user judges the permission or sensitive API function category that will be used, and the scores from high to low are 5, 4, 3, 2, and 1, from very irrelevant to very relevant; the higher the score, the higher the possibility that the user thinks that the use of the permission or API function produces a security threat, otherwise the score is low; the subjective evaluation vector is defined as , wherein is the user's subjective expectation value.

Images