Mobile application security detection method and system based on multi-dimensional features and network behavior fingerprints

Abstract

The application provides a mobile application security detection method and system based on multi-dimensional features and network behavior fingerprints, and relates to the technical field of network security.The method comprises the following steps: running a mobile application in a controlled environment, capturing network traffic data generated during the running process of the mobile application, extracting dynamic behavior features including communication frequency, communication type and communication content from the network traffic data, constructing a network behavior fingerprint based on the dynamic behavior features, and performing normalization processing on the dynamic behavior features to obtain normalized dynamic behavior features; combining a risk classification threshold and the normalized dynamic behavior features, correcting a score result, and obtaining a final security score.The application determines the type of a mobile application and realizes efficient tracing by comprehensively analyzing static code layer features and dynamic traffic layer features.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a mobile application security detection method and system based on multi-dimensional features and network behavior fingerprints. Background Technology

[0002] With the rapid development of the mobile internet, the number and types of mobile applications have exploded. Among them, a number of potentially risky applications lurk. These applications are usually distributed through unofficial channels and exhibit diverse distribution characteristics. At the development level, they often exhibit specific visual interface designs and achieve their functions through unconventional naming conventions, reused signature certificates, requests for sensitive system permissions, and hiding communication domain names and network addresses. In addition to obvious characteristics at the code level, the network traffic generated by these applications during operation, including communication frequency, protocol type, and data content, also shows certain regularities. It is worth noting that some applications frequently change their communication domain names to evade detection, which poses a challenge to accurate identification and tracking, but their core communication patterns still maintain certain similarities.

[0003] Currently, most detection methods for such applications are limited to single-dimensional analysis of static code features or dynamic network traffic, resulting in problems such as low detection efficiency, inconsistent risk assessment standards, high false positive rates, and difficulty in achieving accurate source tracing. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a mobile application security detection method and system based on multi-dimensional features and network behavior fingerprints. By comprehensively analyzing static code layer features and dynamic traffic layer features, the mobile application type can be determined and efficient source tracing can be achieved.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows: Firstly, a mobile application security detection method based on multidimensional features and network behavior fingerprints, the method comprising: Step 1: Obtain a snapshot of the homepage of the mobile application, extract the visual features of the homepage snapshot using an image recognition model, and optimize the visual features to obtain key visual feature vectors. Step 2: Parse the installation file of the mobile application, extract various static features including the application package name, signing certificate, permission information, communication domain name record and communication IP address, and normalize the static features to obtain normalized static features. Step 3: Fuse the key visual feature vector and the normalized static features to form a comprehensive feature vector. Assign weights to each indicator in the comprehensive feature vector. Perform a security score based on the weighted comprehensive feature vector to obtain the score result. Determine the risk classification threshold through cluster analysis based on the score result. Step 4: Run the mobile application in a controlled environment, capture the network traffic data generated during its operation, extract dynamic behavioral features including communication frequency, communication type and communication content from the network traffic data, construct a network behavior fingerprint based on the dynamic behavioral features, and normalize the dynamic behavioral features to obtain normalized dynamic behavioral features. Step 5: Combine the risk classification threshold and normalized dynamic behavioral characteristics to revise the scoring results and obtain the final safety score.

[0006] Secondly, a mobile application security detection system based on multi-dimensional features and network behavior fingerprints includes: The acquisition module is used to acquire a snapshot of the homepage of the mobile application, extract the visual features of the homepage snapshot using an image recognition model, and optimize the visual features to obtain key visual feature vectors. The parsing module is used to parse the installation file of the mobile application, extract various static features including the application package name, signing certificate, permission information, communication domain name record and communication IP address, and normalize the static features to obtain normalized static features. The fusion module is used to fuse key visual feature vectors and normalized static features to form a comprehensive feature vector, assign weights to each indicator in the comprehensive feature vector, and perform a security score based on the weighted comprehensive feature vector to obtain the score result; based on the score result, the threshold for risk classification is determined through cluster analysis. The processing module is used to run mobile applications in a controlled environment, capture network traffic data generated during the operation of the applications, extract dynamic behavioral features including communication frequency, communication type and communication content from the network traffic data, construct network behavior fingerprints based on the dynamic behavioral features, and normalize the dynamic behavioral features to obtain normalized dynamic behavioral features. The correction module is used to correct the scoring results by combining the risk classification threshold and normalized dynamic behavioral characteristics to obtain the final safety score.

[0007] Thirdly, a computing device, comprising: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method.

[0008] Fourthly, a computer-readable storage medium storing a program that, when executed by a processor, implements the method.

[0009] The above-described solution of the present invention has at least the following beneficial effects: It effectively identifies mobile applications using random string names, extracts visual features of the application interface through image recognition models, and accurately classifies applications of various risk types, solving the challenge of identifying mobile applications with unknown content. By extracting static feature information from applications across multiple dimensions, it lays the foundation for comprehensive feature analysis. Combined with scientific weighting methods, it quantifies security assessment, effectively reducing biases caused by subjective judgment and single indicators. Using clustering analysis technology to dynamically update risk classification standards and thresholds, it can adaptively adjust detection strategies based on changes in application characteristics, providing timely and accurate risk warnings to user terminals. By constructing dynamic network behavior fingerprints, even if an application changes its communication domain name or modifies its underlying code, it can still accurately trace its origin based on core behavioral features, effectively identifying related versions and development organizations. The comprehensive use of static and dynamic behavioral features to refine the scoring model significantly improves the accuracy and reliability of risk identification. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating the mobile application security detection method based on multidimensional features and network behavior fingerprints provided in an embodiment of the present invention.

[0011] Figure 2 This is a schematic diagram of a mobile application security detection system based on multidimensional features and network behavior fingerprints provided by an embodiment of the present invention. Detailed Implementation

[0012] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0013] like Figure 1 As shown, embodiments of the present invention propose a mobile application security detection method based on multi-dimensional features and network behavior fingerprints. The method includes the following steps: Step 1: Obtain a snapshot of the homepage of the mobile application, extract the visual features of the homepage snapshot using an image recognition model, and optimize the visual features to obtain key visual feature vectors. Step 2: Parse the installation file of the mobile application, extract various static features including the application package name, signing certificate, permission information, communication domain name record and communication IP address, and normalize the static features to obtain normalized static features. Step 3: Fuse the key visual feature vector and the normalized static features to form a comprehensive feature vector. Assign weights to each indicator in the comprehensive feature vector. Perform a security score based on the weighted comprehensive feature vector to obtain the score result. Determine the risk classification threshold through cluster analysis based on the score result. Step 4: Run the mobile application in a controlled environment, capture the network traffic data generated during its operation, extract dynamic behavioral features including communication frequency, communication type and communication content from the network traffic data, construct a network behavior fingerprint based on the dynamic behavioral features, and normalize the dynamic behavioral features to obtain normalized dynamic behavioral features. Step 5: Combine the risk classification threshold and normalized dynamic behavioral characteristics to revise the scoring results and obtain the final safety score.

[0014] In this embodiment, by extracting and optimizing the visual features of the homepage through an image recognition model, mobile applications with irregular download names can be effectively processed, different types of applications can be accurately distinguished, and the problem of identifying applications with unknown content can be solved. Static features such as application package names and signature certificates are extracted from multiple dimensions and normalized to avoid the limitations of single static indicators, providing comprehensive and standardized data support for integrated risk assessment and reducing subjective judgment bias. Visual features and static features are fused to form a comprehensive feature vector, and a security score is calculated through objective weight allocation. Then, risk classification thresholds are determined in real time based on cluster analysis, making the scoring results more reasonable and the thresholds more adaptable, enabling proactive and accurate risk alerts. A network behavior fingerprint is constructed in a controlled environment to capture the dynamic behavior features of applications during operation. Even if the application undergoes domain name changes or code modifications, it can still be tracked through fingerprint association. Simultaneously, the normalization of dynamic features can adapt to the needs of multi-dimensional collaborative assessment. Combining risk thresholds and normalized dynamic features to correct the initial score can effectively identify applications with normal static features but abnormal dynamic behavior, avoiding misjudgments caused by relying solely on static features, and making the final security score more closely reflect the actual risk level of the application.

[0015] In a preferred embodiment of the present invention, step 1 involves obtaining a snapshot of the homepage of the mobile application, extracting visual features from the homepage snapshot using an image recognition model, and optimizing the visual features to obtain a key visual feature vector, including: Step 1.1: Install and launch the mobile application in a controlled environment and obtain a snapshot of its homepage. This includes: setting up a controlled hardware environment using a computer equipped with an Intel Core i7 processor, 16GB of RAM, and an NVIDIA RTX 3060 graphics card; installing an Android 11 emulator on this computer, allocating 4GB of RAM to the emulator, and setting a resolution of 1080×2340; then establishing a stable connection between the emulator and the computer through debug mode; after the installation file (.apk file) of the mobile application to be tested is uploaded, the system automatically executes the adbinstall command to install the application to the emulator, while setting a 30-second timeout mechanism to handle situations where the installation is unresponsive or fails; after installation, the application package is parsed from the mobile application's AndroidManifest.xml file. The system then launches the application using a command and records the launch time. To avoid interference from the initial loading screen during application startup, three snapshots of the homepage are captured at 1 second, 3 seconds, and 5 seconds after launch using the adbshellscreencap command. These snapshots are saved locally as .png files, named according to the APK's unique ID timestamp.png format. Finally, the OpenCV library is used to preprocess the three snapshots, scaling all images to 224×224 pixels (matching the input size of the models used later) and converting them to RGB three-channel format. If any unresponsiveness, crashes, or other abnormalities occur during application startup, the system will mark the APK as a startup exception and record detailed error logs (such as ActivityNotFoundException).

[0016] Step 1.2: Input the homepage snapshot into a pre-trained convolutional neural network model to extract original image features. Specifically, this includes: selecting a pre-trained ResNet34 model as the convolutional neural network model and performing adaptation adjustments: deleting the original fully connected layers and Softmax layers, retaining the first 33 convolutional layers to focus on image feature extraction, and replacing the last fully connected layer to adapt it to the semantic feature extraction requirements of mobile application homepage snapshots (such as improving the responsiveness to key elements in the application interface); during the model training phase, using a dataset containing 10,000 labeled samples (covering homepage snapshots of different types of applications). The samples were divided into training, validation, and test sets in a 7:2:1 ratio. The Adam optimizer was used to adjust the model parameters (the initial learning rate was set to 0.001, and it decayed to 1 / 10 of the original rate every 10 training cycles). The model performance was optimized using the cross-entropy loss function. The preprocessed homepage snapshot (224×224 pixels, RGB three-channel format) from step 1.1 was input into the adjusted ResNet34 model. The model's convolutional layers and other feature extraction layers processed the image, and finally output the original image features (such as the penultimate layer of the model, which can output a 512-dimensional feature vector to represent the core visual information of the homepage snapshot).

[0017] Step 1.3 involves filtering feature points with response values ​​higher than a preset threshold from the original image features to obtain the filtered feature points. Specifically, this includes processing the feature map corresponding to the original image features output in Step 1.2 for each channel of the feature map: First, calculate the mean value of feature values ​​for all spatial locations in the current channel. Using this mean value as a reference, filter out spatial locations in the channel with feature values ​​higher than the mean value and preliminarily determine these locations as high-response locations. Next, calculate the Euclidean distance between adjacent locations of these preliminarily high-response locations. Further filter based on the distance relationship to eliminate false high-response points caused by local noise. Finally, retain the high-response location with the largest feature value in each channel and determine these retained locations as the filtered feature points. This ensures that the filtering results accurately reflect the key visual information of the homepage snapshot and reduce interference from redundant features.

[0018] Step 1.4: Determine the minimum convex boundary surrounding all selected feature points in the feature space; identify the boundary feature points constituting the minimum convex boundary; connect the boundary feature points to form the minimum convex polygon. Specifically, this includes: mapping all feature points selected in Step 1.3 to the feature space, and applying the convex hull algorithm to process these feature points: the algorithm automatically finds the minimum convex boundary that can completely surround all feature points (i.e., ensures that the boundary contains all feature points and the boundary is a convex structure). This process can effectively eliminate noise points and outliers in the feature point set and retain the core feature points with strong stability; then, the algorithm identifies the boundary feature points constituting this minimum convex boundary, and connects them sequentially according to their relative positions in the feature space, finally forming the convex polygon that minimizes the area surrounding all selected feature points (i.e., the minimum convex polygon), making the distribution characteristics of the feature points clearer and more representative.

[0019] Step 1.5: Extract the vertex coordinates of the smallest convex polygon to form the optimized key visual feature vector. Specifically, this includes: extracting the vertices of the smallest convex polygon formed in Step 1.4 and recording the coordinate information of all vertices of the polygon in the feature space; sorting and organizing these vertex coordinates according to a preset unified order (such as clockwise or counterclockwise order); combining the sorted vertex coordinates into a vector form according to rules, which is the optimized key visual feature vector; this vector integrates the core visual features of the homepage snapshot and will subsequently be used as input in the static information analysis and security scoring of the mobile application, providing visual feature support for multi-dimensional feature collaborative analysis.

[0020] In a preferred embodiment of the present invention, step 2 involves parsing the installation file of the mobile application, extracting various static features including the application package name, signing certificate, permission information, communication domain name records, and communication IP address, and normalizing the static features to obtain normalized static features, including: Step 2.1: Parse the mobile application's installation file to extract various static features, including the application package name, signing certificate, permission information, communication domain name records, and communication IP address. Specifically, this includes: obtaining the mobile application's installation file (i.e., the .apk file), and using specialized tools to parse the file to extract the required static features. The APK class from the AndroGuard library is used to load the .apk file to be parsed. The `get_package` method within this class is then called to read the AndroidManifest.xml file from within the .apk file. <manifest>The `package` attribute value of the `<apk>` tag is used to determine the application package name; the signing file in the `META-INF` directory inside the `.apk` compressed file is located; this type of file is usually in `.RSA` or `.DSA` format; the `keytool` tool is used to execute a specified command to read detailed information from the signing file, including the certificate issuer, certificate validity period, signing algorithm, and certificate fingerprint (such as SHA256 fingerprint), forming the signature certificate's characteristics; the `pyaxmlparser` library is used to parse the `AndroidManifest.xml` file in the `.apk` file, focusing on identifying the contents of this file. <uses-permission>The content contained in the tags is used to extract the application permission requests recorded in all tags and organize them into an application permission list; the dns.resolver tool is used to scan the classes.dex file obtained after the .apk file is decompressed, as well as various resource files stored in the assets directory within the file, and hard-coded communication domain names are filtered out from these files and collected to form a communication domain name record; by scanning the binary file and related configuration files of the .apk file, hard-coded addresses that conform to the IP address format (such as IPv4 format) are identified and extracted, and summarized to form a communication IP address list.

[0021] Step 2.2 involves performing structural and random character analysis on the application package name to calculate its anomaly rate; analyzing the issuer and verifying the validity period of the signing certificate to determine its risk level; classifying and statistically analyzing the permission information to calculate the proportion of sensitive permissions; comparing the communication domain name records with a known risk domain name database to calculate the domain name risk rate; and comparing the communication IP addresses with a known risk IP database to calculate the IP risk rate. Specifically, this includes analyzing the various static features extracted in Step 2.1 and calculating the corresponding risk-related indicators. Calculate the package name anomality: Filter out characters in the package name that are not meaningful words such as company identifiers or application identifiers, and count the proportion of such meaningless characters to the total number of characters in the package name; verify whether the package name conforms to the common formal structure of com.company identifiers and application identifiers through rules. If the format fails to match, mark it as a format error; if the match is successful, mark it as a normal format.

[0022] Combining the two results above, the package name anomaly score is calculated, which reflects the degree of anomaly in the package name.

[0023] Determine the risk level of the certificate: Determine whether the certificate was issued by a legitimate CA (Certificate Authority) or signed by the application itself; check if the certificate is currently valid, and mark it as expired if it has expired; confirm whether the signature algorithm used by the certificate is compliant, and mark it as algorithmic risk if a weak algorithm with low security is used; check if the certificate has any signs of forgery, and mark it as a serious risk if forgery is confirmed; based on the above analysis results, classify the certificate into different risk levels, such as legitimate and valid, self-signed but compliant, self-signed with a weak algorithm, and expired or forged.

[0024] Calculate the percentage of sensitive permissions: The extracted permission list is categorized into sensitive permissions and ordinary permissions. Sensitive permissions include data access permissions (such as reading contacts, SMS messages, and location information), operation control permissions (such as sending SMS messages, making phone calls, and modifying system settings), and network interaction permissions (such as accessing the network and creating VPN connections). All other permissions are classified as ordinary permissions.

[0025] Count the number of sensitive permissions: Count the total number of permissions that are considered sensitive in the permission list.

[0026] Calculate the percentage of sensitive permissions: Divide the total number of sensitive permissions by the total number of permissions requested by the application to obtain the percentage of sensitive permissions.

[0027] Calculate the domain name risk rate: Prepare a database of known risky domains, which contains information on various domains that have been confirmed to be at risk; compare the communication domain records extracted in step 2.1 with the domains in the database of known risky domains one by one, and count the number of risky domains that are successfully matched; divide the number of risky domains that are successfully matched by the total number of communication domains extracted to obtain the domain risk rate.

[0028] Calculate IP risk rate: Prepare a known risk IP database, which contains information on various types of IP addresses that have been confirmed to be at risk; compare the communication IP addresses extracted in step 2.1 with the IP addresses in the known risk IP database one by one, and count the number of risk IPs that are successfully matched; divide the number of risk IPs that are successfully matched by the total number of extracted communication IP addresses to obtain the IP risk rate.

[0029] Step 2.3 involves normalizing the package name anomaly rate, certificate risk level, sensitive permission ratio, domain name risk rate, and IP risk rate to form a normalized static feature set. Specifically, this includes normalizing the five indicators obtained in Step 2.2—package name anomaly rate, certificate risk level, sensitive permission ratio, domain name risk rate, and IP risk rate—ensuring that all indicators' values ​​are uniformly within the range [0,1]. The specific processing method is as follows: Based on the original calculation results of package name anomaly, it is adjusted to the [0,1] range using mapping rules, where the closer the value is to 1, the higher the degree of package name anomaly, and the closer it is to 0, the more normal the package name. For different categories of certificate risk levels (e.g., legitimate and valid, self-signed but compliant, weak self-signed algorithm, and expired or forged), a corresponding mapping value is set for each level to ensure that the mapped value is within the [0,1] range; the higher the value, the higher the certificate risk. Since the percentage of sensitive permissions is itself the result of the number of sensitive permissions / the total number of permissions, its original value is already in the [0,1] range. Within this period, no additional adjustments are needed; simply retain the original calculation results. The domain risk rate is the result of the number of risky domains divided by the total number of domains, and the original value is also within the range of [0,1]. Directly use the original calculation results without further processing. The IP risk rate is the result of the number of risky IPs divided by the total number of IPs, and the original value is already within the range of [0,1]. Simply retain the original value. Integrate the above five indicators after normalization to form a normalized static feature set that includes package name anomaly degree, certificate risk level, sensitive permission ratio, domain risk rate, and IP risk rate.

[0030] In a preferred embodiment of the present invention, step 3, fusing the key visual feature vector and the normalized static features to form a comprehensive feature vector, includes: Step 3.1 involves concatenating the key visual feature vector with the packet name anomaly degree, certificate risk level, sensitive permission ratio, domain name risk rate, and IP risk rate from the normalized static feature set to form a comprehensive feature vector, specifically including: The source and shape of the key visual feature vector are confirmed. This vector is the optimized result obtained through step 1.5. It is composed of the vertex coordinates of the smallest convex polygon corresponding to the snapshot of the mobile application homepage arranged in a preset order (such as clockwise). Each vertex coordinate contains the corresponding spatial position value. The whole forms a numerical vector with a fixed dimension. All values ​​in the vector have been processed in the early stage (such as image scaling and feature filtering) to ensure their validity.

[0031] Secondly, retrieve the normalized static feature set, which is the output of step 2.3. It includes five indicators: package name anomaly degree, certificate risk level, sensitive permission ratio, domain name risk rate, and IP risk rate. The values ​​of each indicator have been normalized to the range of [0,1], and they are all numerical data reflecting the static risks of the application, without any format anomalies or missing data.

[0032] Check the numerical types of the key visual feature vectors and the indicators in the normalized static feature set to ensure that both are of a uniform numerical type such as floating-point numbers or integers, so as to avoid splicing errors due to type differences; if there are inconsistencies in types, use data conversion tools to unify the numerical types of the two types of features to floating-point numbers (to adapt to the subsequent weight allocation and scoring calculation requirements).

[0033] At the same time, the original dimensions of the key visual feature vectors are recorded (e.g., 2m dimensions if composed of m vertex coordinates, each vertex contains two coordinate values, x and y), and the fixed dimension of the normalized static feature set is specified as 5 dimensions (corresponding to five indicators), ensuring that the two types of features can be directly spliced ​​and combined in terms of dimensions without additional dimension compression or expansion operations (unless there are abnormalities in the feature dimensions in the previous steps, which need to be backtracked and corrected before adaptation).

[0034] The key visual feature vectors are concatenated in a fixed order: first the key visual feature vectors, then the normalized static features. The key visual feature vectors are used as the first half of the comprehensive feature vector, preserving the order of their internal vertex coordinates without changing the relative positions of the values ​​within the vector. Subsequently, the five indicators from the normalized static feature set are sequentially concatenated after the key visual feature vectors in the order of package name anomaly, certificate risk level, sensitive permission ratio, domain name risk rate, and IP risk rate, ensuring that the position of each indicator is fixed and non-repeating.

[0035] For example, if the key visual feature vector is a 20-dimensional vector (corresponding to 10 vertex coordinates), then the dimension of the concatenated comprehensive feature vector is 20 + 5 = 25 dimensions. The first 20 dimensions are the vertex coordinate values, and the last 5 dimensions are the normalized values ​​of package name anomaly degree, certificate risk level, sensitive permission ratio, domain name risk rate, and IP risk rate, respectively. After concatenation, first check whether the total dimension of the comprehensive feature vector is equal to the sum of the key visual feature vector dimension and 5 (normalized static feature dimension). If the dimensions do not match, backtrack to check the concatenation order or previous feature extraction steps to check for problems such as missing features or repeated concatenation.

[0036] Secondly, verify the values ​​of each part in the comprehensive feature vector: the key visual feature vector part must be consistent with the original vector values ​​output in step 1.5, without tampering or deviation; the normalized static feature part must completely correspond to the values ​​of the five indicators output in step 2.3, ensuring that the value of each indicator is within the range of [0,1] and without incorrect mapping; finally, store the verified comprehensive feature vector in the designated database, and label it with the unique identifier of the corresponding mobile application, so as to provide complete and accurate input data for the subsequent steps of weighting and security scoring of each indicator in the comprehensive feature vector.

[0037] In a preferred embodiment of the present invention, weights are assigned to each indicator in the comprehensive feature vector, and a security score is performed based on the weighted comprehensive feature vector to obtain a score result; based on the score result, a risk classification threshold is determined through cluster analysis, including: Step 3.2: Based on the information entropy theory, calculate the weights of each indicator in the comprehensive feature vector to determine the discriminative weight of each indicator. Specifically, this includes: selecting labeled samples to construct training and experimental sets: from the labeled mobile application samples, select 70% of the samples as the training set (e.g., 1260 samples) and the remaining 20% ​​of the new samples as the experimental set (e.g., 360 samples). All samples contain each indicator in the comprehensive feature vector (indicators corresponding to key visual feature vectors, package name anomaly, certificate risk level, sensitive permission ratio, domain name risk rate, IP risk rate), and each indicator has been normalized (value range [0,1]).

[0038] Next, the weight of each indicator in the training set is calculated: for each indicator in the comprehensive feature vector (let's call it the j-th indicator, where j starts from 1 and corresponds to each indicator in turn), the weight of the indicator value of each sample (let's call it the i-th sample) in the training set is calculated to be the proportion of the total value of the indicator of all samples, so as to reflect the relative importance of a single sample in the indicator.

[0039] Then, calculate the information entropy of each indicator: based on the indicator weights obtained above, combined with the normalization coefficient (ensuring that the information entropy value ranges from [0,1]), calculate the information entropy of each indicator; the smaller the information entropy, the greater the numerical difference of the indicator, and the stronger the ability to distinguish the risk attributes of mobile applications; conversely, the larger the information entropy, the weaker the ability to distinguish.

[0040] Finally, the discrimination weights of each indicator are determined. Based on the rule that discrimination weights are positively correlated with (1 - information entropy), the weight of each indicator is calculated. Specifically, (1 minus the information entropy of that indicator) is divided by the sum of (1 - information entropy) of all indicators; the result is the discrimination weight of that indicator. Simultaneously, the above calculation process of proportions, information entropy, and weights is repeated using an experimental set to verify the stability and objectivity of the weights, ultimately determining the weight values ​​that accurately reflect the discrimination ability of each indicator.

[0041] Step 3.3: Weight the comprehensive feature vector according to the discrimination weights and calculate the weighted comprehensive value. Specifically, this includes: determining the correspondence between the comprehensive feature vector and the discrimination weights, and matching the discrimination weights determined in Step 3.2 with each indicator in the comprehensive feature vector in sequence (for example, the first indicator in the comprehensive feature vector corresponds to the first weight, the second indicator corresponds to the second weight, and so on), to ensure that each indicator has its own exclusive discrimination weight.

[0042] Then, a weighted calculation is performed on each indicator in the comprehensive feature vector: for each indicator in the comprehensive feature vector, the value of the indicator is multiplied by its corresponding discrimination weight to obtain the weighted value of the indicator. For example, if the value of an indicator is 0.6 and the corresponding weight is 0.2, then the weighted value of the indicator is 0.6 × 0.2 = 0.12. Finally, the weighted values ​​of all indicators are summed, and the sum is the weighted comprehensive value of the mobile application's comprehensive feature vector. This value integrates the information of each indicator and its discrimination contribution, and can initially reflect the risk tendency of the application.

[0043] Step 3.4 calculates the initial security score based on the weighted composite value. Specifically, this includes: calculating the minimum enclosing cylinder volume of the composite feature vectors; treating the weighted composite feature vectors (all samples) as a set of points in a high-dimensional space; centering these points (subtracting the mean of each indicator dimension to eliminate the influence of data translation); then calculating the covariance matrix of the centered point set and performing eigenvalue decomposition on the covariance matrix, selecting the eigenvector corresponding to the largest eigenvalue as the principal axis direction in the high-dimensional space; based on the principal axis direction, calculating the projection values ​​of all points on the principal axis, taking the difference between the maximum and minimum projection values ​​as the height of the cylinder; then calculating the maximum perpendicular distance from all points to the principal axis as the radius of the cylinder; finally, calculating the minimum enclosing cylinder volume using the cylinder volume formula (adapted to high-dimensional space). This volume reflects the dispersion of the sample feature distribution; a larger volume indicates a more dispersed feature distribution and higher complexity or uncertainty in the application behavior.

[0044] Next, a volume adjustment factor is constructed: Since the calculated cylinder volume values ​​of different batches of mobile application samples vary greatly, directly using them for scoring will lead to uncontrolled results. Therefore, the volume needs to be normalized. The minimum and maximum volumes in the current batch of samples are selected, and the actual volumes are converted into volume adjustment factors with values ​​in the range of [0.5,2] through mapping rules (for example, the closer the volume is to the maximum volume, the closer the adjustment factor is to 2; the closer the volume is to the minimum volume, the closer the adjustment factor is to 0.5).

[0045] Finally, the weighted composite value obtained in step 3.3 is multiplied by the volume adjustment factor mentioned above, and the result is the initial security score. The higher the score, the higher the risk level of the mobile application; the lower the score, the higher the security level of the application.

[0046] Step 3.5 involves performing cluster analysis on the initial security scores of multiple mobile applications and determining the final number of clusters using the elbow rule. Specifically, this includes collecting the initial security scores of multiple mobile applications and various indicators from the comprehensive feature vectors of these applications, combining the two to form a seven-dimensional data vector (e.g., six-dimensional indicators and one-dimensional initial scores) as input data for cluster analysis.

[0047] Then, the K-means algorithm is used to attempt clustering: set the range of K (number of clusters) (e.g., from 2 to 10), and for each K value, use the K-means algorithm to cluster the input data, grouping applications with similar features and similar initial scores into the same cluster, and calculate the clustering error corresponding to each K value (usually expressed as the sum of squares within the cluster, i.e., the sum of squared distances from all samples within the cluster to the center of the cluster).

[0048] Next, plot the relationship curve between K value and clustering error with K value on the x-axis and clustering error on the y-axis. Observe the trend of the curve. When K value is small, the clustering error decreases significantly as K value increases. When K value increases to a certain value, the decrease in clustering error slows down significantly, and the curve shows an elbow (i.e., the turning point). The K value corresponding to this elbow is the optimal number of clusters. At this point, the clustering results can effectively distinguish the application of different risk characteristics without causing excessive refinement of clusters due to excessively large K value.

[0049] Step 3.6: Determine the classification thresholds for different risk levels based on the clustering results. Specifically, this includes: For the optimal number of clusters determined in Step 3.5, calculate the average of the initial security scores of all applications in each cluster. This average is the initial score center value of the cluster, representing the typical risk level of the applications in that cluster.

[0050] Then, the cluster center values ​​are sorted: all clusters are sorted in ascending order of the initial score center values, corresponding to different levels of risk from low to high (for example, the first-ranked cluster corresponds to low risk, the second-ranked cluster corresponds to medium risk, and the third-ranked cluster corresponds to high risk).

[0051] Finally, the risk classification threshold is determined: For two adjacent clusters after sorting, the median of their initial score centers (i.e., the sum of the two center values ​​divided by 2) is calculated. This median value is the classification threshold between the two risk levels. For example, if the center value of the low-risk cluster is 30 and the center value of the medium-risk cluster is 60, then the classification threshold between low and medium risk is (30+60) / 2=45. Applications with an initial score below 45 are classified as low-risk, applications with a score above 45 but below the high-risk threshold are classified as medium-risk, and so on. The threshold determined in this way can clearly distinguish mobile applications of different risk levels, providing a basis for subsequent risk assessment.

[0052] In a preferred embodiment of the present invention, step 4 involves running the mobile application in a controlled environment, capturing network traffic data generated during its operation, and extracting dynamic behavioral features, including communication frequency, communication type, and communication content, from the network traffic data, including: Step 4.1: Run the mobile application in the controlled environment and capture the network communication data it generates using a traffic monitoring tool. Specifically, this includes: selecting a computer equipped with an Intel Core i7 processor, 16GB of memory, and an NVIDIA RTX 3060 graphics card; installing an Android 11 emulator on the computer; allocating 4GB of memory to the emulator and setting a resolution of 1080×2340; establishing a stable connection between the emulator and the computer through debug mode to ensure that the application can run normally and that there is no external interference in the environment.

[0053] Secondly, deploy traffic monitoring configuration: deploy port mirroring between the emulator and the computer (testing terminal) to mirror the network traffic of the emulator to the specified listening port of the computer; select Wireshark as the traffic monitoring tool, open the tool, set the listening port to the above mirrored port, and configure basic filtering rules (only retain traffic related to the target application, and exclude traffic interference from the emulator system itself and other irrelevant applications).

[0054] Next, launch the application and capture traffic: Install the mobile application to be detected onto the emulator using the adb command, launch the application using the adbshell command, and simultaneously click the Start Capture button in Wireshark to record all network communication data generated by the application from startup to operation. Set the capture duration to 30 minutes after the application starts running, and use the pcapdroid tool to simulate normal user click operations (such as clicking interface buttons or switching pages) to trigger various network communication behaviors of the application as much as possible to ensure comprehensive capture of traffic data.

[0055] Finally, store the captured data: After the capture is complete, save the network communication data in Wireshark to a specified local directory on the computer in pcap format. The file name should be named according to the rule of application unique identifier-capture time.pcap. If an abnormality such as emulator disconnection or application crash occurs during the capture process, the current capture should be terminated, the abnormal log should be recorded, the environment should be rebuilt, and the capture process should be restarted.

[0056] Step 4.2: Extract DNS query records and communication IP addresses from the captured network communication data, and record the query domain name, resolution result, and time information. Specifically, this includes: opening the pcap format traffic data saved in Step 4.1, setting a DNS traffic-specific filtering rule (udpport53 or tcpport53) in Wireshark to filter out all DNS protocol-related packets; parsing each DNS packet to extract key information, including the query domain name (i.e., the target domain name of the DNS query initiated by the application), the resolution result (the IP address corresponding to the domain name), the resolution timestamp (the system time when the packet was captured), and the TTL (Time to Live) value; and organizing this information into a table according to the format of timestamp, query domain name, resolution IP, and TTL value to ensure that each DNS query record corresponds one-to-one with the corresponding time and result.

[0057] Secondly, in the Wireshark tool, switch the filter rule to IP to filter out all communication packets based on the IP protocol; extract the target IP address of the application initiating the communication from these packets (excluding irrelevant addresses such as the emulator's own IP and gateway IP), ensuring that the same IP address is not recorded repeatedly; use a WHOIS query tool (or call the WHOIS database interface) to query the organization information (such as the name of the operator or cloud service provider) of each target IP address, and record the time when the IP address first appears and the time when it last appears (reflecting the lifespan of the IP).

[0058] Finally, the extracted DNS query records and communication IP addresses are integrated and stored according to the association between time, domain name, IP address and IP-owning organization to form an original mapping table. This ensures that the corresponding IP can be traced through the domain name or the corresponding domain name usage record can be associated through the IP, providing data support for identifying the behavior of changing the domain name but keeping the IP unchanged.

[0059] Step 4.3: Count the number of data packets per unit time and calculate the communication frequency. Specifically, this includes: taking the 30 minutes after the application starts running continuously in Step 4.1 as a fixed statistical period. If the application becomes unresponsive within 30 minutes, the actual normal running time will be used as the statistical period (the actual time needs to be recorded and marked).

[0060] Secondly, filter target application data packets: In the Wireshark tool, further filter traffic data by application process ID or emulator IP address to ensure that only network data packets initiated by the mobile application to be detected are counted, excluding irrelevant data packets generated by emulator system processes and other background applications, and avoiding statistical bias.

[0061] Next, convert the data packet count to time: Use Wireshark's statistics and capture file properties to view the total number of packets (N) for the target application within the statistical period; convert the duration (T) of the statistical period from minutes to seconds (e.g., 30 minutes to 1800 seconds) to ensure that the time unit matches the statistical unit for the number of packets.

[0062] Finally, the accuracy of the total number of data packets (N) is confirmed by a counting tool. Combined with the converted statistical duration (T, unit: seconds), the number of data packets per unit time is counted and used as the communication frequency of the application. The calculation results are then compared with the communication frequency range of normal applications (e.g., 1-5 data packets per second on average for normal applications). The target application's communication frequency is recorded to determine whether it is within the normal range, providing a reference for subsequent risk analysis.

[0063] Step 4.4: Analyze the network communication protocol type and the port number used to identify communication type characteristics. Specifically, this includes: in the Wireshark tool, viewing the target application data packet list after filtering in Step 4.3, identifying the protocol type of each data packet through the protocol column, calculating the percentage of TCP and UDP protocol data packets (e.g., TCP protocol data packets account for 80%, UDP protocol data packets account for 20%), and recording the main communication protocol types used by the application.

[0064] Secondly, identify port number characteristics: extract the port number from the source port and destination port fields of each data packet, and distinguish between standard ports and non-standard ports (standard ports refer to industry-standard ports, such as port 443 commonly used for HTTPS communication and port 80 commonly used for HTTP communication; non-standard ports refer to other ports besides standard ports, such as 8081, 9000, etc.); count the proportion of non-standard port usage to total communication frequency, and record the non-standard port numbers preferred by the application and their corresponding communication frequency.

[0065] Finally, examine the information columns of the data packets or check the communication content using the tracing stream, TCP stream, or UDP stream functions to determine the application's communication encryption method: if the stream content displays ApplicationData and the protocol is marked as TLS / SSL, it is determined that a standard encryption method (such as HTTPS) is used; if the stream content is garbled and there is no TLS / SSL protocol identifier, or if the documentation confirms that the application uses a custom encryption algorithm, it is determined that a non-standard encryption method is used; integrate and record the proportion of protocol types, the proportion of non-standard ports, and the encryption method type to form a communication type characteristic table.

[0066] Step 4.5: parse the communication content and extract the density of specific keywords in the content. Specifically, in the Wireshark tool, prioritize unencrypted network streams (such as HTTP protocol streams) or encrypted streams that have been processed by decryption tools (such as application data after HTTPS decryption) as the analysis objects, and exclude encrypted garbled streams that cannot be parsed to ensure the effectiveness of content analysis.

[0067] Secondly, based on common business scenarios of mobile applications, select specific business keywords related to application functions (such as file transfer and data backup for utility applications, message sending and friend adding for social applications), and form a keyword list. Avoid using words without clear business meaning and ensure that keywords match the actual functions of the application.

[0068] Next, the frequency of keyword occurrences and content length were counted: using Wireshark's stream content viewing function, the parsable communication content was read line by line, and the total number of occurrences (K) of each keyword in the keyword list was counted using a text statistics tool; at the same time, the total number of characters (L) of the communication content was counted, excluding meaningless characters such as spaces and newlines, and only the length of valid text characters was calculated.

[0069] Finally, based on the total number of keyword occurrences (K) and the total content length (L) obtained from statistics, the ratio between the two is calculated to obtain the occurrence density of specific keywords in the communication content; if the total content length (L) is 0 (i.e. there is no effective text content), the keyword density is marked as 0 and the reason is recorded (e.g., the application only transmits binary data); the keyword density value is compared with the keyword density range of normal applications of the same type, and it is recorded whether the density of the target application is abnormal.

[0070] In a preferred embodiment of the present invention, a network behavior fingerprint is constructed based on the dynamic behavior features, and the dynamic behavior features are normalized to obtain normalized dynamic behavior features, including: Step 4.6 integrates the extracted communication frequency, communication type features, and communication content features to construct a network behavior fingerprint that includes a set of IP addresses, a set of domain names, average communication frequency, port distribution features, and keyword density. Specifically, this includes preparing the dynamic behavior feature data to be integrated. IP address set: Retrieve the communication IP addresses extracted in step 4.2, deduplicate all IP addresses (excluding duplicate IPs), and arrange the deduplicated IP addresses in order of their first appearance time to form an IP address set.

[0071] Domain set: Retrieve the DNS query records extracted in step 4.2, filter the queried domains, deduplicate all domains (excluding the same domain that is queried repeatedly), and arrange them in order of query time to form a domain set.

[0072] Average communication frequency: Retrieve the communication frequency (number of data packets per unit time) calculated in step 4.3. If there are multiple time segments of communication frequency data within the statistical period (e.g., statistics are collected every 5 minutes), calculate the average of the communication frequencies of all segments as the average communication frequency; if only one statistics are collected, directly use that communication frequency as the average communication frequency.

[0073] Port distribution characteristics: Retrieve the port number data analyzed in step 4.4, and count the proportion of communication times of non-standard ports to the total number of communication times (i.e., the proportion of non-standard ports). Use this proportion as the port distribution characteristics (for example, if the proportion of communication times of non-standard ports is 60%, then the port distribution characteristic value is 60%).

[0074] Keyword density: Directly retrieve the occurrence density of specific keywords in the communication content calculated in step 4.5, ensuring that the density value is the original calculation result (without normalization processing).

[0075] Then, the features are integrated to construct a network behavior fingerprint: the above IP address set, domain name set, average communication frequency, port distribution characteristics, and keyword density are integrated in a fixed order to form a network behavior fingerprint containing these five types of information; the fingerprint structure is recorded in the order of IP address set, domain name set, average communication frequency, port distribution characteristics, and keyword density, and the unique application identifier and fingerprint generation time corresponding to the fingerprint are marked to ensure that the network behavior fingerprint of each application can be uniquely traced.

[0076] Step 4.7 generates an organization identifier based on IP address characteristics and port distribution characteristics, specifically including: extracting the input features of the organization identifier: IP Prefix Set: Retrieve all IP addresses from the IP address set in step 4.6, process each IP address, and extract its first two segments (for example, if the IP address is 192.168.1.100, extract the first two segments 192.168). After removing duplicates from the extracted first two segments of the IP addresses, arrange them in alphabetical order to form the IP prefix set.

[0077] Port distribution characteristics: Directly retrieve the port distribution characteristics (i.e., the proportion of non-standard ports) determined in step 4.6, and ensure that the characteristic value is the original proportion data (e.g., 55%).

[0078] Encryption type: Retrieve the communication encryption method results analyzed in step 4.4 (such as standard TLS encryption, custom encryption, no encryption), and convert the encryption type into a unified text identifier (for example, standard TLS encryption is denoted as Standard-TLS, and custom encryption is denoted as Custom-Encryption).

[0079] Next, an organization identifier is generated: the IP prefix set (text format, with the first two segments separated by commas), port distribution characteristics (text format, retaining the percent sign), and encryption type identifier are concatenated into a complete string in the order of IP prefix set, port distribution characteristics, and encryption type (e.g., 192.168,10.0;55%;Standard-TLS). The SHA256 hash algorithm is used to calculate the hash value of this concatenated string, which is the organization identifier. If two applications have the same organization identifier, it is determined that they may be associated with the same operating organization, and the identifier is associated with and stored as a corresponding network behavior fingerprint.

[0080] Step 4.8: Normalize the communication frequency, the proportion of non-standard ports, and the keyword density to ensure that all feature values ​​are within a uniform range. Specifically, this includes normalizing the communication frequency, the proportion of non-standard ports, and the keyword density to ensure that all feature values ​​are within the [0,1] range after processing. Communication frequency normalization: First, determine the maximum average communication frequency of normal mobile applications through historical data statistics (i.e., the highest average communication frequency that normal applications may reach within the same statistical period, denoted as the maximum average frequency of normal applications); then, divide the average communication frequency of the target application in step 4.6 by the maximum average frequency of normal applications to obtain a preliminary normalization result; if the preliminary result is greater than 1, take 1 as the final normalized communication frequency; if the preliminary result is less than 0, take 0; if it is between 0 and 1, directly retain the preliminary result.

[0081] Non-standard port ratio normalization: The non-standard port ratio determined in step 4.6 is itself the ratio of the number of non-standard port communications to the total number of communications. Its original value is already in the range of [0,1], so no additional calculation is needed. This original ratio is directly used as the normalized non-standard port ratio.

[0082] Keyword density normalization: First, determine the maximum keyword density of normal mobile applications through historical data statistics (i.e., the highest keyword density that a normal application may achieve under the same communication content length, denoted as the maximum keyword density of the normal application); then, divide the keyword density of the target application in step 4.6 by the maximum keyword density of the normal application to obtain the preliminary normalization result; if the preliminary result is greater than 1, take 1 as the final normalized keyword density; if the preliminary result is less than 0, take 0; if it is between 0 and 1, directly retain the preliminary result.

[0083] Step 4.9: Combine the normalized dynamic behavior features to form a normalized dynamic behavior feature set. Specifically, this includes: retrieving the three features that were normalized in step 4.8, namely normalized communication frequency, normalized non-standard port ratio, and normalized keyword density; checking whether each feature value is within the range of [0,1]. If there are outliers outside the range, step 4.8 needs to be reprocessed to ensure that the feature values ​​are compliant.

[0084] Then, a normalized dynamic behavior feature set is formed: the three normalized features are integrated into a feature set in a fixed order of normalized communication frequency, normalized non-standard port ratio, and normalized keyword density; for example, if the normalized communication frequency is 0.6, the normalized non-standard port ratio is 0.55, and the normalized keyword density is 0.7, then the feature set is [0.6, 0.55, 0.7].

[0085] Finally, the normalized dynamic behavior feature set is associated with the corresponding application unique identifier, network behavior fingerprint, and organization identifier and stored in a designated database to ensure that the feature set can be quickly retrieved when the score is corrected in the future.

[0086] In a preferred embodiment of the present invention, step 5, combining the risk classification threshold and normalized dynamic behavioral characteristics, corrects the scoring result to obtain the final security score, including: Step 5.1: Based on the normalized values ​​of communication frequency, non-standard port ratio, and keyword density normalized values ​​from the normalized dynamic behavior feature set, calculate dynamic risk indicators. Specifically, this includes extracting three core indicators from the normalized dynamic behavior feature set formed in Step 4.9: the normalized value of communication frequency, the non-standard port ratio, and the keyword density normalized value. The normalized value of communication frequency reflects the frequency of application communication, the non-standard port ratio reflects the concealment of communication, and the normalized value of keyword density reflects the risk correlation of communication content. All three are positive risk indicators with values ​​in the range [0,1] (the higher the value, the more significant the corresponding risk characteristic).

[0087] Secondly, calculate the dynamic risk index: Integrate the three normalized indices mentioned above. Since all three contribute equally to dynamic risk, simply sum their values; the sum is the dynamic risk index. For example, if the normalized value of communication frequency is 0.6, the proportion of non-standard ports is 0.5, and the normalized value of keyword density is 0.7, then the dynamic risk index is 0.6 + 0.5 + 0.7 = 1.8. This index comprehensively reflects the overall risk level of the application's dynamic behavior during operation; the higher the value, the higher the dynamic risk of the application.

[0088] Step 5.2: Determine the correction coefficient of dynamic features based on the risk classification threshold. Specifically, this includes: retrieving the risk classification threshold determined by cluster analysis in step 3.6. Assume that the threshold for dividing low risk and medium risk is T1 and the threshold for dividing medium risk and high risk is T2 (T1 < T2) obtained by cluster analysis. These two thresholds are calculated based on the initial security score cluster centers of multiple applications and can accurately distinguish different static risk levels.

[0089] Secondly, the initial scoring interval is divided and a correction coefficient is matched: Based on the risk interval in which the initial safety score (output of step 3.4) falls, a corresponding correction coefficient α is set; the specific division logic is as follows: If the initial safety score is ≤ T1 (initially judged as low risk): At this time, we need to focus on the correction of the low risk judgment by dynamic risk. If the dynamic risk index is high, we need to appropriately increase the correction coefficient to amplify the impact of dynamic risk. The correction coefficient α is set to 0.3-0.5 (calibrated through historical training set to ensure that the corrected score in this range can accurately reflect the situation of static low risk but dynamic high risk). If T1 < initial safety score ≤ T2 (initially judged as medium risk): the initial score is already in the medium risk range, and the correction coefficient needs to balance static and dynamic risks, set to 0.2-0.4; If the initial safety score is greater than T2 (initially judged as high risk): the initial score already reflects a high static risk, and the dynamic risk is only used as a supplementary verification. The correction coefficient is set to 0.1-0.3 to avoid excessive correction that could lead to score distortion.

[0090] Finally, determine the final correction coefficient: Based on the range of the initial security score of the current application, select a value that is positively correlated with the dynamic risk index from the correction coefficient range of the corresponding range (the higher the dynamic risk index, the higher the value in the range should be selected). For example, when the initial score is ≤ T1 and the dynamic risk index is 1.8 (higher), the correction coefficient α is selected as 0.5.

[0091] Step 5.3: Construct a scoring correction term using the correction coefficient and dynamic risk index. Specifically, the scoring correction term is used to quantify the adjustment range of dynamic risk on the initial safety score. Since the higher the dynamic risk index and the larger the correction coefficient, the stronger the correction force on the initial score should be, the correction term is constructed by multiplying the dynamic risk index by the correction coefficient.

[0092] Secondly, calculate the scoring correction term: Multiply the dynamic risk index obtained in step 5.1 by the correction coefficient determined in step 5.2; the product is the scoring correction term. For example, if the dynamic risk index is 1.8 and the correction coefficient is 0.5, then the scoring correction term is 1.8 × 0.5 = 0.9. The magnitude of this correction term directly determines the extent to which the initial score needs to be lowered; the more significant the dynamic risk, the larger the correction term value, and the stronger the downward adjustment effect on the initial score.

[0093] Step 5.4: Apply the scoring correction item to the initial security score to obtain the corrected security score. Specifically, this includes: obtaining the initial security score output in step 3.4. This score is calculated based only on static and visual features and does not consider dynamic behavioral risks. There may be a bias where static features are normal but dynamic behavior is abnormal.

[0094] Secondly, subtract the score correction term obtained in step 5.3 from the initial safety score to obtain the preliminary corrected score. If the preliminary corrected score is less than 0, it is adjusted to 0 to avoid the score being meaningless. If the preliminary corrected score is greater than 100 (the initial score is at most 100), it remains unchanged at 100. For example, if the initial safety score is 65 (in the medium-risk range T1-T2) and the score correction term is 0.9, the corrected safety score is 65-0.9=64.1. If the initial score is 5 (low-risk range) and the correction term is 3, the preliminary corrected score is 5-3=2 (no adjustment required). If the initial score is 2 and the correction term is 3, it is adjusted to 0.

[0095] Finally, check whether the revised score is consistent with the dynamic risk characteristics. For example, for applications with high dynamic risk indicators, the revised score should be significantly lower than the initial score to ensure that the revised score is more in line with the actual static and dynamic comprehensive risk level of the application.

[0096] Step 5.5: Based on the risk classification thresholds, perform final risk level division on the corrected safety score to obtain the final safety score result. Specifically, this includes: retrieving the risk classification thresholds determined in step 3.6 (low-medium risk threshold T1, medium-high risk threshold T2). These thresholds have been verified by cluster analysis and can effectively distinguish applications with different risk levels.

[0097] Secondly, the final risk level is determined: based on the revised safety score obtained in step 5.4, the final risk level is determined by comparing it with the risk classification threshold. The specific classification rules are as follows: If the revised security score is ≤ T1: it is judged as low risk, indicating that the application shows low risk in both static features and dynamic behavior, and meets the security standards; If T1 < revised security score ≤ T2: it is judged as medium risk, indicating that the application has certain risk characteristics at the static or dynamic level, and its subsequent behavior needs to be further monitored. If the revised security score is greater than T2, it is considered high-risk, indicating that the application has significant risks in static features or dynamic behavior, and control measures need to be taken in a timely manner. The revised security score is associated with the corresponding risk level to form a result table of application unique identifier, revised score and final risk level, which is stored in the detection database and provided to the regulatory or review process at the same time to provide accurate basis for the security judgment of mobile applications.

[0098] like Figure 2 As shown, embodiments of the present invention also provide a mobile application security detection system based on multi-dimensional features and network behavior fingerprints, comprising: The acquisition module is used to acquire a snapshot of the homepage of the mobile application, extract the visual features of the homepage snapshot using an image recognition model, and optimize the visual features to obtain key visual feature vectors. The parsing module is used to parse the installation file of the mobile application, extract various static features including the application package name, signing certificate, permission information, communication domain name record and communication IP address, and normalize the static features to obtain normalized static features. The fusion module is used to fuse key visual feature vectors and normalized static features to form a comprehensive feature vector, assign weights to each indicator in the comprehensive feature vector, and perform a security score based on the weighted comprehensive feature vector to obtain the score result; based on the score result, the threshold for risk classification is determined through cluster analysis. The processing module is used to run mobile applications in a controlled environment, capture network traffic data generated during the operation of the applications, extract dynamic behavioral features including communication frequency, communication type and communication content from the network traffic data, construct network behavior fingerprints based on the dynamic behavioral features, and normalize the dynamic behavioral features to obtain normalized dynamic behavioral features. The correction module is used to correct the scoring results by combining the risk classification threshold and normalized dynamic behavioral characteristics to obtain the final safety score.

[0099] It should be noted that this system is a system corresponding to the above method. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0100] Embodiments of the present invention also provide a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method described above. All implementations in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0101] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention. < / manifest>

Claims

1. A mobile application security detection method based on multidimensional features and network behavior fingerprints, characterized in that, The method includes: Install and launch the mobile application in a controlled environment to obtain a snapshot of its homepage; input the homepage snapshot into a pre-trained convolutional neural network model to extract original image features; filter feature points with response values ​​higher than a preset threshold from the original image features to obtain the filtered feature points; determine the minimum convex boundary surrounding all the filtered feature points in the feature space; identify the boundary feature points that constitute the minimum convex boundary; connect the boundary feature points to form the minimum convex polygon; extract the vertex coordinates of the minimum convex polygon to form an optimized key visual feature vector; This process involves parsing the installation files of mobile applications to extract various static features, including the application package name, signing certificate, permission information, communication domain name records, and communication IP addresses. The application package name undergoes structural and random character analysis to calculate its anomaly level. The signing certificate is analyzed for its issuer and validity period to determine its risk level. Permission information is categorized and statistically analyzed to calculate the proportion of sensitive permissions. Communication domain name records are compared with a known risk domain name database to calculate the domain name risk rate. Communication IP addresses are compared with a known risk IP database to calculate the IP risk rate. Finally, the package name anomaly level, certificate risk level, proportion of sensitive permissions, domain name risk rate, and IP risk rate are normalized to form a normalized static feature set. Key visual feature vectors and normalized static features are fused to form a comprehensive feature vector. Based on information entropy theory, the weights of each indicator in the comprehensive feature vector are calculated to determine the discriminative weight of each indicator. The comprehensive feature vector is then weighted according to these discriminative weights to calculate a weighted comprehensive value. An initial security score is calculated based on the weighted comprehensive value. Cluster analysis is performed on the initial security scores of multiple mobile applications, and the final number of clusters is determined using the elbow rule. Classification thresholds for different risk levels are determined based on the clustering results. Running a mobile application in a controlled environment, network traffic data generated during its operation is captured. Dynamic behavioral features, including communication frequency, communication type, and communication content, are extracted from the network traffic data. The extracted communication frequency, communication type, and communication content features are integrated to construct a network behavioral fingerprint containing a set of IP addresses, a set of domain names, average communication frequency, port distribution features, and keyword density. An organization identifier is generated based on the IP address and port distribution features. The communication frequency, non-standard port ratio, and keyword density are normalized to ensure that each feature value is within a uniform numerical range. The normalized dynamic behavioral features are combined to form a normalized dynamic behavioral feature set. Based on the normalized values ​​of communication frequency, non-standard port ratio, and keyword density in the normalized dynamic behavior feature set, a dynamic risk index is calculated. Correction coefficients for the dynamic features are determined according to the risk classification threshold. A scoring correction term is constructed using the correction coefficients and the dynamic risk index. The scoring correction term is applied to the initial security score to obtain a corrected security score. Finally, the corrected security score is used to classify the risk level according to the risk classification threshold to obtain the final security score result.

2. The mobile application security detection method based on multidimensional features and network behavior fingerprints according to claim 1, characterized in that, The key visual feature vectors and normalized static features are fused to form a comprehensive feature vector, including: The key visual feature vector is combined with the package name anomaly degree, certificate risk level, sensitive permission ratio, domain name risk rate and IP risk rate from the normalized static feature set to form a comprehensive feature vector.

3. The mobile application security detection method based on multidimensional features and network behavior fingerprints according to claim 2, characterized in that, Running a mobile application in a controlled environment, capturing network traffic data generated during its operation, and extracting dynamic behavioral characteristics from the network traffic data, including communication frequency, communication type, and communication content, including: The mobile application runs in the controlled environment, and the network communication data it generates is captured using a traffic monitoring tool. Extract DNS query records and communication IP addresses from captured network communication data, and record the queried domain name, resolution result, and time information; Count the number of data packets per unit time and calculate the communication frequency; Analyze the network communication protocol type and the port number used to identify communication type characteristics; The communication content is parsed to extract the density of specific keywords.

4. A mobile application security detection system based on multidimensional features and network behavior fingerprints, wherein the system implements the method as described in any one of claims 1 to 3, characterized in that, include: The acquisition module is used to acquire a snapshot of the homepage of the mobile application, extract the visual features of the homepage snapshot using an image recognition model, and optimize the visual features to obtain key visual feature vectors. The parsing module is used to parse the installation file of the mobile application, extract various static features including the application package name, signing certificate, permission information, communication domain name record and communication IP address, and normalize the static features to obtain normalized static features. The fusion module is used to fuse key visual feature vectors and normalized static features to form a comprehensive feature vector, assign weights to each indicator in the comprehensive feature vector, and perform a security score based on the weighted comprehensive feature vector to obtain the score result; based on the score result, the threshold for risk classification is determined through cluster analysis. The processing module is used to run mobile applications in a controlled environment, capture network traffic data generated during the operation of the applications, extract dynamic behavioral features including communication frequency, communication type and communication content from the network traffic data, construct network behavior fingerprints based on the dynamic behavioral features, and normalize the dynamic behavioral features to obtain normalized dynamic behavioral features. The correction module is used to correct the scoring results by combining the risk classification threshold and normalized dynamic behavioral characteristics to obtain the final safety score.

5. A computing device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method as described in any one of claims 1 to 3.

Images