Sensitive api construction method for malware detection and computer program product

Abstract

This invention provides a method for constructing sensitive APIs for malware detection, comprising: collecting and labeling Android software samples to obtain multiple APK files; reverse-engineering static features from the multiple APK files; constructing a candidate sensitive API list; and constructing a simplified sensitive API set based on the candidate sensitive API list using a logistic regression classification model combined with an information gain ratio statistical method. This invention can solve the technical problem of the large number of sensitive APIs listed in the current Android official documentation, which is inconvenient to use. Experimental data verification shows that although the constructed simplified sensitive API set significantly reduces the number of sensitive APIs compared to the original set, it still retains the effectiveness in identifying malware, with an accuracy rate of over 90%.

Description

Technical Field

[0001] This invention relates to the field of computer information security detection technology, specifically to a method for constructing sensitive APIs and computer program products for malware detection. Background Technology

[0002] With the rapid development of mobile internet, Android has become the world's most widely used mobile operating system, widely applied to smartphones, tablets, and other mobile devices. However, Android's openness and widespread adoption make it a prime target for malware attacks. In recent years, malware has exhibited characteristics of surging numbers, constantly evolving technology, and a proliferation of variants, seriously threatening user privacy and data security. Traditional malware detection methods have limitations in dealing with these complex attacks, urgently requiring innovation and optimization.

[0003] Currently, malware detection primarily relies on two methods: dynamic behavior analysis and static signature analysis. Dynamic behavior analysis detects malicious activity by monitoring the actual runtime behavior of software. While this method has advantages in accuracy, it suffers from poor real-time performance and high computational cost. Therefore, static signature analysis is currently more widely used. Static signature analysis identifies malware by studying its code structure, API (Application Programming Interface) call frequency, and permission requests.

[0004] In static feature detection, the use of sensitive APIs plays a crucial role. Researchers often analyze the call frequency of sensitive APIs or simplify the function call graph into sensitive function subgraphs based on sensitive APIs. However, the large number of sensitive APIs listed in the Android official documentation poses challenges to subsequent use and analysis. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention proposes a method for constructing sensitive APIs for malware detection and a computer program product, thereby solving the technical problem of the large number of sensitive APIs listed in the current Android official documentation and their inconvenience in use.

[0006] The technical solution adopted in this invention is as follows:

[0007] Firstly, a method for constructing sensitive APIs for malware detection is provided, comprising: collecting and labeling Android software samples to obtain multiple APK files; reverse-engineering static features from the multiple APK files, wherein the static features include API call information; constructing a candidate sensitive API list based on the static features; and constructing a simplified sensitive API set based on the candidate sensitive API list, using a logistic regression classification model combined with an information gain ratio statistical method and the API call information.

[0008] Furthermore, static features are extracted from multiple APK files through reverse engineering, including: decompiling and parsing each APK file to extract API call information and function call relationships, thereby deriving static features.

[0009] Furthermore, a list of potential sensitive APIs is constructed, including: collecting the mapping relationship between sensitive permissions and official APIs, determining which APIs are related to sensitive permissions, and marking the APIs related to sensitive permissions as potential sensitive APIs.

[0010] Furthermore, a simplified sensitive API set is constructed using a logistic regression classification model combined with the information gain ratio statistical method. This includes: using the logistic regression classification model to filter the candidate sensitive APIs to obtain a logistic regression sensitive API subset; using the information gain ratio statistical method to filter the candidate sensitive APIs to obtain an information gain ratio API subset; and taking the intersection of the two API subsets to obtain the simplified sensitive API set.

[0011] Furthermore, a logistic regression classification model is used to screen the potential sensitive APIs, including:

[0012] The contribution value of the selected sensitive API is calculated using a logistic regression classification model. When calculating the contribution value, the weights and bias terms are optimized by minimizing the cross-entropy loss function, a positive class penalty factor is introduced to apply greater weight to malicious samples, and an elastic network regularization rule is added to modify the logistic regression classification model to prevent overfitting.

[0013] The calculated contribution value is converted into a sensitivity score; sensitive APIs are filtered based on the obtained sensitivity scores, and the first sensitive API list is selected from the candidate sensitive API list. The first sensitive API list and the corresponding first sensitivity score are saved to obtain the logistic regression sensitive API subset.

[0014] Furthermore, the information gain ratio statistical method is used to screen the potential sensitive APIs, including:

[0015] Calculate the target entropy and conditional entropy of the candidate sensitive APIs; calculate the information gain of the features based on the target entropy and conditional entropy; calculate the splitting information corresponding to the information gain; calculate the information gain ratio based on the information gain and splitting information; convert the calculated information gain ratio into a sensitivity score; filter sensitive APIs based on the obtained sensitivity scores, select a second sensitive API list from the candidate sensitive API list, save the obtained second sensitive API list and the corresponding second sensitivity score, and obtain the information gain ratio sensitive API subset.

[0016] Furthermore, the sensitivity scores obtained from logistic regression classification and information gain ratio statistics are normalized.

[0017] Furthermore, the sensitive API construction method for malware detection also includes validity verification of the streamlined sensitive API set, including: feature vector-based detection and function call graph-based detection.

[0018] In a second aspect, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the sensitive API construction method for malware detection described in the first aspect.

[0019] Thirdly, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs; and, when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the sensitive API construction method for malware detection as described in the first aspect.

[0020] As can be seen from the above technical solution, the beneficial technical effects of the present invention are as follows:

[0021] 1. The streamlined sensitive API set we built, although significantly reduced in number compared to the original sensitive API set, still retains its effectiveness in identifying malware, with an accuracy rate of over 90% in identifying malware.

[0022] 2. When constructing a simplified sensitive API set, the advantages of both logistic regression classification and information gain ratio statistics are combined. Features that are considered important in both methods are retained, which can improve the accuracy of screening and ensure that the selected sensitive APIs are not only statistically highly correlated, but also significantly improve the classification effect in model training. This can effectively avoid selecting features that only perform well under a certain method but may not be useful in the actual model, thereby reducing the risk of misselection. Attached Figure Description

[0023] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0024] Figure 1 This is a flowchart illustrating the sensitive API construction method and validity verification method according to an embodiment of the present invention. Detailed Implementation

[0025] The embodiments of the technical solution of the present invention will now be described in detail with reference to the accompanying drawings. These embodiments are merely illustrative of the technical solution of the present invention and are therefore intended to limit the scope of protection of the present invention.

[0026] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application should have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0027] Example

[0028] This embodiment provides a method for constructing sensitive APIs for malware detection, such as... Figure 1 As shown, it includes the following steps:

[0029] Step 1: Collect and label Android software samples to obtain multiple APK files.

[0030] Obtain a broad set of Android software samples from public data sources such as AndroZoo, Drebin, and Google Play, resulting in multiple APK files to ensure coverage of diverse sample types.

[0031] To facilitate subsequent testing and classification analysis, VirusTotal was used to assign accurate labels to each APK file. For example, the labels could be noted as "benign" or "malicious".

[0032] Step 2: Reverse engineer static features from multiple APK files

[0033] Each APK (Android application package) file is decompiled and parsed to extract API call information and function call relationships, thereby deriving static characteristics.

[0034] In specific implementations, the method of decompiling and parsing each APK file is not limited, and any feasible method in the existing technology can be used, such as using Androguard. Androguard can parse DEX files in Android applications and generate code structures corresponding to Smali files. By analyzing Smali files, Androguard can identify the definition, call relationship and basic opcode of each method, and then extract API call information and construct a function call graph (FCG).

[0035] In some embodiments, Androguard first loads the APK file and parses its DEX file. The DEX file contains bytecode information of the Android application, including all classes, methods, fields, and their call relationships. Androguard uses its internal DEX file parser to parse the classes and methods one by one, identifying the start and end structures of each method, thereby extracting which APIs are called in the APK and obtaining API call information.

[0036] During method body resolution, Androguard identifies and extracts opcode sequences, especially function call instructions (such as invoke-virtual, invoke-static, invoke-direct, etc.). These instructions are used to call other methods or functions and are crucial for establishing call relationships. When Androguard encounters an invoke-* instruction, it extracts information such as the class name, method name, and parameter types of the called method to determine the call relationship between the current method (caller) and the target method (callee).

[0037] After extracting the call relationships between all methods, Androguard treats each method as a node in a graph and the call relationship as a directed edge between nodes. Whenever one method calls another, a directed edge is created between the caller and the callee, representing the call path. By traversing the call relationships of all classes and methods in the application, Androguard generates the entire application's function call graph (FCG), thus completing the static feature extraction. The static features extracted in this step form the basis for subsequent analysis.

[0038] Step 3: Construct a list of potential sensitive APIs

[0039] Collect the mapping relationship between sensitive permissions and official APIs to determine which APIs are related to sensitive permissions; then mark these APIs related to sensitive permissions as candidate sensitive APIs.

[0040] In this embodiment, sensitive APIs are defined as system APIs related to sensitive permissions. In this step, sensitive permissions marked "Dangerous" are first collected from the Android official website. Then, the mapping relationships between multiple sensitive permissions and APIs (such as AXplore, PSCout, SuSi, etc.) are collected. By comprehensively analyzing these mapping relationships, a set of all APIs corresponding to sensitive permissions is extracted. In this embodiment, approximately 50,000 candidate sensitive APIs are obtained.

[0041] This step will provide you with a list of potential sensitive APIs.

[0042] Step 4: Construct a simplified set of sensitive APIs using a logistic regression classification model combined with the information gain ratio statistical method.

[0043] Because the number of potential sensitive APIs collected is large, further use is difficult. For example, using the frequency of sensitive API calls as a feature would result in a very large data dimensionality, leading to excessive consumption of computing resources. Considering that sensitive APIs are usually linked to sensitive behaviors, their call patterns should differ significantly between benign and malicious samples. Therefore, we can filter them based on existing samples to obtain a concise set of sensitive functions for easier subsequent processing.

[0044] In this embodiment, the logistic regression classification model and the information gain ratio statistical method are used in conjunction with the API call information in the static features obtained in step two to filter the potential sensitive APIs. After obtaining the respective API subsets, the intersection of the two API subsets is taken as the final simplified sensitive API set. Specifically:

[0045] 1. Use a logistic regression classification model to filter the potential sensitive APIs, obtaining a subset of logistic regression-sensitive APIs.

[0046] Logistic regression is a simple and efficient binary classification algorithm. After training, this model can quantify the contribution of each API to the classification. Sensitive APIs can be selected based on their contribution values. In this embodiment, the contribution value is the regression coefficient of logistic regression, i.e., the calculated weight information. In this embodiment, when using the logistic regression classification model to calculate the weight information of the selected sensitive APIs, the calculation formula is as follows:

[0047]

[0048] In the above formula, p = (y = 1 | X) is the probability that a sample belongs to the malicious category; X is an input matrix of shape equal to the total number of samples, with the number of sensitive APIs to be filtered out. Each row of the input matrix represents the API call frequency of a sample, and each column represents the call frequency of an API; w is the weight vector of each API, representing its influence on the classification result; b is the bias term, used to adjust the overall offset of the model output; σ(z) is the Sigmoid function, which converts the output of the linear model into probability values; e represents the natural constant. During calculation, the labels for benign and malicious samples are y = 0 and y = 1, respectively.

[0049] In some embodiments, the Logistic regression classification model optimizes the weights w and bias term b by minimizing the cross-entropy loss function, as calculated below:

[0050]

[0051] In the above formula, w is the optimization weight, b is the bias term, and y i Labels representing benign and malicious samples, p i This indicates the probability that a sample belongs to the malicious category.

[0052] When using the above formula to optimize the weights w and bias term b, considering that the number of malicious samples is significantly less than the number of benign samples among the samples used to screen for sensitive APIs, a positive class penalty factor is introduced to apply a larger weight to malicious samples in order to mitigate the impact of class imbalance. The class weights are automatically adjusted according to the number of samples. The formula for calculating the positive class penalty factor is as follows:

[0053]

[0054] In the above formula, N is the total number of samples, and c is the number of categories, which here takes the value of 2 or n. i Let be the number of samples in category i. After introducing the penalty factor, the loss function becomes:

[0055]

[0056] In the above formula, weight i The weight information calculated for sample i.

[0057] Meanwhile, in some embodiments, to control the complexity of the Logistic Regression classification model and prevent overfitting, regularization rules are added to the model to correct it. There are two types of regularization rules: L1 regularization directly compresses unimportant weight information to 0, retaining features that have a greater impact on classification, making it easier to select APIs that have a more significant impact on the classification results; L2 regularization can prevent excessive weights and improve the stability of the model. In this embodiment, elastic network regularization, which combines the advantages of L1 and L2 regularization, is used to correct the model. The calculation formula for elastic network regularization R(w) is as follows:

[0058]

[0059] In the above formula, λ = 1 / c represents the regularization strength, α represents the proportionality coefficient controlling L1 and L2; ||w||1 is the result of the L1 regularization rule, and ||w||2 is the result of the L1 regularization rule. 2 It is the result of L2 regularization rules, w j Indicates the weight.

[0060] Finally, the loss function combined with elastic network regularization is:

[0061]

[0062] In the above formula, N is the total number of samples, and weight i The weight information y is calculated for sample i. i Labels representing benign and malicious samples, p i Let λ represent the probability that a sample belongs to the malicious category, λ = 1 / c represent the regularization strength, and α represent the proportionality coefficient controlling L1 and L2 regularization; ||w||1 is the result of the L1 regularization rule, and ||w||2 is the result of the L1 regularization rule. 2 This is the result of L2 regularization. By using this loss function, combining the penalty factor and regularization, the impact of class imbalance in the sample data can be mitigated, while limiting the size of the weights to prevent the model from overfitting due to excessive focus on the minority class.

[0063] After obtaining the contribution value for each API, to facilitate further filtering and processing, the obtained contribution value is converted into a first sensitivity score between [0,1]. The formula for calculating the first sensitivity score is as follows:

[0064]

[0065] In the above formula, w max This represents the maximum contribution value.

[0066] Based on the obtained first sensitivity score, sensitive APIs are filtered out. Sensitive APIs with a first sensitivity score greater than 0 are filtered out from the candidate sensitive API list to obtain the first sensitive API list. The obtained first sensitive API list and the corresponding sensitivity score are saved to obtain the logistic regression sensitive API subset.

[0067] 2. Use the information gain ratio statistical method to filter the selected sensitive APIs and obtain a subset of APIs with high information gain ratio.

[0068] Information gain ratio (IGR) is an algorithm based on information entropy used to evaluate the relationship between features and target variables, and is particularly suitable for selecting discrete features. It measures the amount of information a feature provides to determine its contribution to classification, and further penalizes features with more values, thus obtaining a fairer evaluation metric. In this embodiment, when using the information gain ratio statistical method to screen sensitive APIs, the target entropy H(y) of the sample data is first calculated, as follows:

[0069]

[0070] In the above formula, pi represents the probability of each possible value of the target label y.

[0071] Next, we calculate the conditional entropy of the candidate sensitive APIs, which measures the uncertainty of the target label given the features. The formula for calculating the conditional entropy is:

[0072] H(y|X j )=∑P(X j =k)H(y|X j =k)

[0073] In the above formula, y represents the target label, and X... j Let k represent the feature, and k represent the possible values ​​of the feature.

[0074] After obtaining the target entropy and conditional entropy, the information gain (Gain) of the feature is calculated using the following formula:

[0075] Gain(X j )=H(y)-H(y|X j )

[0076] Information gain may favor features with a large number of values. Therefore, after obtaining the information gain, the split information corresponding to the information gain is calculated. The split information measures the complexity of the feature's own distribution and is used to penalize features with a large number of values, thus correcting for features biased by the information gain. The feature split information (Split) is calculated as follows:

[0077]

[0078] In the above formula, k represents the possible values ​​of the feature, P(X) j =k) ​​is the feature X j The probability of taking the value k.

[0079] After obtaining the information gain and splitting information, the corresponding information gain ratio is calculated. The information gain ratio (GainRatio) is used as the final screening metric to eliminate the bias of the number of feature values ​​on the screening results. The formula for calculating the information gain ratio is as follows:

[0080]

[0081] In the above formula, Gain represents information gain, Split represents split information, and X j Indicates characteristics.

[0082] After obtaining the information gain ratio for each API, it is also converted into the corresponding sensitivity score and calculated using the following formula:

[0083]

[0084] Based on the obtained second sensitivity score, sensitive APIs are filtered out. Sensitive APIs with a second sensitivity score greater than 0 are filtered out from the candidate sensitive API list to obtain the second sensitive API list. The obtained second sensitive API list and the corresponding sensitivity score are saved to obtain the information gain ratio sensitive API subset.

[0085] 3. Take the intersection of the two API subsets to obtain the final simplified sensitive API set.

[0086] After obtaining API subsets using two methods, the intersection of the two subsets is taken as the final simplified sensitive API set. The simplified sensitive API set constructed in step four combines the advantages of both logistic regression classification and information gain ratio (IVR) statistics. Specifically, IVR focuses more on global statistical characteristics and is more likely to select features with unique distributions or significant noise influence; logistic regression, through optimization during training, is better able to capture the interaction effects between features, but over-reliance on certain unstable features may lead to overfitting. By taking the intersection of the two API subsets, features considered important in both methods are retained, thus improving the accuracy of the selection. This ensures that the selected sensitive APIs are both statistically highly correlated and can significantly improve classification performance during model training. It effectively avoids selecting features that only perform well under one method but may not be useful in the actual model, thereby reducing the risk of misselection.

[0087] In this example, by combining logistic regression classification and information gain ratio statistics, the final simplified sensitive API set contains 3885 sensitive APIs, a significant reduction compared to the original set of over 50,000 sensitive APIs.

[0088] In some embodiments, to facilitate further API screening, the sensitivity scores obtained from logistic regression classification and information gain ratio statistics can be normalized, as calculated below:

[0089]

[0090] Step 5: Verify the effectiveness of the simplified sensitive API set

[0091] After constructing the streamlined sensitive API subset using the above steps, to verify that this subset can still effectively characterize the malicious behavior of malware while reducing the size of the set, we used current API-related static features to detect malware. These API-related static features include API call information and function call graphs. Then, we conducted experiments on different datasets, as follows:

[0092] Experiments were conducted on CICAndMal2017, AndroZoo_2016, and AndroZoo_2017. Each dataset was split into an 8:2 ratio, with the larger portion used as the training set and the smaller portion as the test set. First, the number of sensitive APIs was used as a feature. The detection results obtained based on the simplified sensitive API set are shown in Table 1.

[0093] Table 1 shows the detection results obtained using API statistics as a feature.

[0094]

[0095] Table 1 shows that each dataset was tested using different detectors to measure the performance of feature vectors obtained from the simplified sensitive API set on different classifiers, thus illustrating their effectiveness. An API may exhibit polymorphic usage within an APK; therefore, the count features of sensitive APIs can be used to construct corresponding API feature vectors. Table 1 shows that detection based on the obtained API feature vectors is still effective in detecting malware. Using Rf as the detector on CICAndMal2017 achieves 94% accuracy; using XGBoost as the detector on AndrZoo_2016 achieves 97% accuracy; and using both Rf and XGBoost on AndrZoo_2017 achieves 97% accuracy.

[0096] Then, using the function call graph as a feature, experiments were conducted on the same dataset. Since the directly obtained function call graph has too many nodes, direct use would incur a huge computational overhead. In this embodiment, the function call graph is processed in several ways, including the following steps: First, non-system API nodes in the call graph are uniformly abstracted as "SelfDefined" nodes to reduce interference from user-defined nodes. Then, based on the simplified sensitive API set, sensitive API nodes in each FCG are located. For multiple connected components in each function call graph, connected components that do not contain sensitive functions are not processed; for connected components that contain sensitive functions, the call relationships around the sensitive API node are preserved using a neighborhood expansion method, centered on the sensitive API node. Specifically, by traversing the sensitive API nodes, these nodes and their surrounding two-layer call relationships are preserved, while other nodes and edges outside this range are removed, thus obtaining the simplified sensitive function call graph (SFCG). If a connected component becomes multiple subgraphs before and after simplification, a "SelfDefined" node is used to connect the nodes with an in-degree of zero in these subgraphs to ensure the connectivity of the subgraphs.

[0097] To classify the topology graph, the call graph needs to be converted into a corresponding graph embedding vector. GraphSAGE combines the call graph and the node embedding information of the graph, using three hidden layers and an average pooling layer to transform topology graphs of different sizes into vectors of equal length. GraphSAGE uses locally sampled neighbors for information transfer, thus avoiding the limitation of processing the entire graph. Finally, different machine learning models are used for detection based on the obtained graph embedding vectors, and the detection results are shown in Table 2.

[0098] Table 2 shows the classification results using call graphs as features.

[0099]

[0100]

[0101] As shown in Table 2, simplifying the original call graph using a streamlined sensitive API set to obtain a sensitive function subgraph, and then using the graph embedding vector constructed from this subgraph for detection, still effectively identifies malware. On CICAndMal2017, using Rf as the detector achieves 92% accuracy; on AndrZoo_2016, using XGBoost as the detector achieves 91% accuracy; and on AndrZoo_2017, using both Rf and XGBoost achieves 92% accuracy.

[0102] As can be seen from the above experiments, the simplified sensitive API set constructed using this embodiment has an accuracy rate of over 90% in identifying malware. This demonstrates that although the number of simplified sensitive APIs is significantly reduced compared to the original set, the effectiveness in identifying malware is still preserved.

[0103] This embodiment also provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of the sensitive API construction method for malware detection described above.

[0104] This embodiment also provides an electronic device, including: one or more processors; a storage device for storing one or more programs; and when one or more programs are executed by one or more processors, causing the one or more processors to implement the steps of the sensitive API construction method for malware detection described above.

[0105] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.

Claims

1. A method for constructing sensitive APIs for malware detection, characterized in that, include: Android software samples were collected and labeled, resulting in multiple APK files; Static features are extracted from multiple APK files, including API call information; Construct a list of potential sensitive APIs based on static characteristics; Based on the list of potential sensitive APIs, a simplified set of sensitive APIs is constructed using a logistic regression classification model combined with information gain ratio statistics and the API call information; including: The contribution value of the candidate sensitive APIs is calculated using a logistic regression classification model. When calculating the contribution value, the weights and bias terms are optimized by minimizing the cross-entropy loss function. A positive class penalty factor is introduced to impose greater weight on malicious samples. An elastic network regularization rule is added to modify the logistic regression classification model to prevent overfitting. The calculated contribution value is converted into a sensitivity score. Sensitive APIs are then selected based on the obtained sensitivity scores. A first-sensitive API list is selected from the candidate sensitive API list, and the first-sensitive API list and its corresponding first-sensitive score are saved to obtain a subset of logistic regression sensitive APIs. The information gain ratio statistical method is used to screen potential sensitive APIs, and the target entropy and conditional entropy of the potential sensitive APIs are calculated. Based on the target entropy and conditional entropy, the information gain of the features is calculated. The splitting information corresponding to the information gain is calculated. The information gain ratio is calculated based on the information gain and splitting information. The calculated information gain ratio is converted into a sensitivity score. Sensitive APIs are screened based on the obtained sensitivity scores. A second sensitive API list is selected from the list of potential sensitive APIs. The obtained second sensitive API list and the corresponding second sensitivity score are saved to obtain the information gain ratio sensitive API subset. The simplified sensitive API set is obtained by taking the intersection of the logistic regression sensitive API subset and the information gain rate sensitive API subset.

2. The sensitive API construction method for malware detection according to claim 1, characterized in that, The process involves reverse engineering multiple APK files to extract static features, including decompiling and parsing each APK file to extract API call information and function call relationships, thereby deriving static features.

3. The sensitive API construction method for malware detection according to claim 1, characterized in that, Construct a list of potential sensitive APIs, including: Collect the mapping relationship between sensitive permissions and official APIs to determine which APIs are related to sensitive permissions; Mark APIs related to sensitive permissions as potential sensitive APIs.

4. The sensitive API construction method for malware detection according to claim 1, characterized in that, The sensitivity scores obtained from logistic regression classification and information gain ratio statistics are normalized.

5. The method for constructing sensitive APIs for malware detection according to claim 1, characterized in that, It also includes validity verification of the simplified sensitive API set, including: feature vector-based detection and function call graph-based detection.

6. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the sensitive API construction method for malware detection as described in any one of claims 1-5.

7. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the sensitive API construction method for malware detection as described in any one of claims 1-5.

Images