Application file security analysis method and system, medium and electronic equipment

Abstract

The invention provides an application file security analysis method and system, a medium and electronic equipment. The application program file security analysis method comprises the steps of obtaining a first application program file and risk data; obtaining a second application program file according to the first application program file and the hash value thereof, wherein the hash value of the second application program file is the same as that of the first application program file; performing static analysis on the second application program file to obtain file feature data; dynamically analyzing the second application program file to obtain file operation data; the file feature data and the file operation data are classified through a machine learning algorithm to obtain a classification result of the second application program file, and the classification result is used for representing whether the second application program file is malicious software or not; and comparing the analysis data with the risk data to obtain a comparison result.

Description

Technical Field

[0001] The present application belongs to the technical field of security analysis, and relates to an application file security analysis method, system, medium and electronic device. Background Art

[0002] APK is the application package file format of the Android operating system, which contains all components of an Android application, such as code, resources, configuration files, etc. With the popularity of Android devices, the security analysis of APK files has become increasingly important, as malware and application vulnerabilities may pose a threat to user data security and privacy.

[0003] Existing APK analysis tools and methods include manually decompressing APK files, reading and analyzing code, checking permissions and components, etc. This method is not only time-consuming and error-prone, but also unable to cope with the needs of efficient analysis of large numbers of APK files. In addition, as malware authors use more advanced techniques to hide malicious code, traditional analysis tools have limitations in detecting these complex threats. Summary of the invention

[0004] The purpose of this application is to provide an application file security analysis method, system, medium and electronic device for improving the efficiency and accuracy of application file security analysis.

[0005] In a first aspect, the present application provides an application file security analysis method, the application file security analysis method comprising: obtaining a first application file and risk data; obtaining a second application file based on the first application file and its hash value, the second application file having the same hash value as the first application file; statically analyzing the second application file to obtain file feature data; dynamically analyzing the second application file to obtain file operation data; classifying the file feature data and the file operation data using a machine learning algorithm to obtain a classification result for the second application file, the classification result being used to indicate whether the second application file is malware; comparing the analysis data with the risk data to obtain a comparison result, the analysis data comprising the file feature data, the file operation data, and the classification result.

[0006] In an implementation of the first aspect, the process of obtaining the second application file based on the first application file and its hash value includes: searching whether there is an application file with the same hash value as the first application file on the back end; if so, using the application file as the second application file; otherwise, transmitting the first application file to the back end; performing hash value verification on the received first application file on the back end, and obtaining the second application file based on the verification result.

[0007] In an implementation of the first aspect, the process of obtaining the second application file according to the verification result includes: if the verification is successful, using the first application file received by the back end as the second application file.

[0008] In an implementation of the first aspect, the process of statically analyzing the second application file to obtain file feature data includes: decompressing the second application file to obtain a metadata file; and parsing and decompiling the metadata file to obtain the file feature data.

[0009] In an implementation of the first aspect, the application file security analysis method further includes: updating the analysis data and the risk data into a database.

[0010] In an implementation of the first aspect, the process of using a machine learning algorithm to classify the file feature data and the file operation data to obtain a classification result of the second application file includes: obtaining a malicious identification model; using the malicious identification model to match and classify the file feature data and the file operation data to obtain the classification result; wherein the training method of the malicious identification model includes: obtaining training data, the training data including: file feature data and file operation data of malicious software, file feature data and file operation data of normal software; using the training data to train a convolutional neural network to obtain the malicious identification model.

[0011] In an implementation of the first aspect, the analysis data and the risk data are compared to obtain a comparison result, comprising: updating an analysis rule using the risk data; and comparing the analysis data and the risk data based on the analysis rule to obtain the comparison result.

[0012] In a second aspect, the present application provides an application file security analysis system, the application file security analysis system comprising: a first application file acquisition module, used to acquire a first application file and risk data; a second application file acquisition module, used to acquire a second application file based on the first application file and its hash value, the second application file having the same hash value as the first application file; a static analysis module, used to perform static analysis on the second application file to acquire file feature data; a dynamic analysis module, used to perform dynamic analysis on the second application file to acquire file operation data; a classification result acquisition module, used to classify the file feature data and the file operation data using a machine learning algorithm to acquire a classification result of the second application file, the classification result being used to indicate whether the second application file is malware; a comparison result acquisition module, used to compare the analysis data with the risk data to acquire a comparison result, the analysis data including the file feature data, the file operation data, and the classification result.

[0013] In a third aspect, the present application provides an electronic device, comprising: a memory on which a computer program is stored; and a processor, communicatively connected to the memory, for executing the computer program to implement the above-mentioned application file security analysis method.

[0014] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by an electronic device, implements the above-mentioned application file security analysis method.

[0015] As described above, the application file security analysis method, system, medium and electronic device described in this application have the following beneficial effects:

[0016] The application file security analysis method provided in this application can perform a comprehensive analysis on application files, obtain file feature data through static analysis and obtain file operation data through dynamic analysis, and can meet the needs of efficient analysis of a large number of application files. It can classify and judge whether the application file is malware, and obtain the comparison result between the application file and the malware by comparing it with the risk data, so as to realize the identification and detection of malware with more advanced and complex threats. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 Shown is a schematic diagram of an application scenario of the application file security analysis method described in an embodiment of the present application.

[0018] Figure 2 Shown is a process diagram of the application file security analysis method described in an embodiment of the present application.

[0019] Figure 3 Shown is a schematic diagram of the process of obtaining the second application file described in an embodiment of the present application.

[0020] Figure 4 Shown is a schematic diagram of the process of obtaining file feature data described in an embodiment of the present application.

[0021] Figure 5 Shown is a schematic diagram of the process of obtaining the classification result of the second application file described in an embodiment of the present application.

[0022] Figure 6 Shown is a schematic diagram of the process of obtaining comparison results described in an embodiment of the present application.

[0023] Figure 7 Shown is a flow chart of the application file security analysis method described in an embodiment of the present application.

[0024] Figure 8 Shown is a structural diagram of the application file security analysis system described in an embodiment of the present application.

[0025] Fig. 9 Shown is a schematic diagram of the structure of an electronic device described in an embodiment of the present application.

[0026] Component number description

[0027] 10. Software System

[0028] 101 Frontend

[0029] 102 Backend

[0030] 1 Application File Security Analysis System

[0031] 11. First application file acquisition module

[0032] 12. Second application file acquisition module

[0033] 13 Static Analysis Module

[0034] 14 Dynamic Analysis Module

[0035] 15 Classification result acquisition module

[0036] 16 Comparison results module

[0037] 2 Electronic devices

[0038] 21 Memory

[0039] 22 Processor

[0040] 23 Display

[0041] Steps S11 to S16

[0042] Steps S21 to S24

[0043] Steps S31 to S32

[0044] Steps S41 to S42

[0045] Steps S51 to S52 DETAILED DESCRIPTION

[0046] The following describes the embodiments of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0047] It should be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present application, and thus the drawings only show components related to the present application rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed at will, and the component layout may also be more complicated.

[0048] APK is the application package file format of the Android operating system, which contains all components of an Android application, such as code, resources, configuration files, etc. With the popularity of Android devices, the security analysis of APK files has become increasingly important, as malware and application vulnerabilities may pose a threat to user data security and privacy.

[0049] Existing APK analysis tools and methods mainly rely on manual operations, including manually decompressing APK files, reading and analyzing codes, checking permissions and components, etc. This method is not only time-consuming and error-prone, but also unable to cope with the needs of efficient analysis of large numbers of APK files. In addition, as malware authors use more advanced techniques to hide malicious code, traditional static and dynamic analysis tools have limitations in detecting these complex threats.

[0050] In order to improve the efficiency and accuracy of APK file analysis, some technical solutions have proposed some automated analysis tools. These tools usually include functions such as parsing APK files, extracting features, analyzing code and resources, etc. However, these tools often only focus on specific analysis aspects, such as permission abuse, malicious behavior detection, etc., and lack a comprehensive analysis framework to comprehensively evaluate the security of APK files.

[0051] In addition, automated analysis tools, such as APKtool, dex2jar, and JD-GUI, can help analysts parse APK files and decompile codes, but they still have shortcomings in automation and comprehensive analysis. For example, they may not be able to automatically identify and analyze the latest malware techniques, or provide a user-friendly visual interface to display the analysis results.

[0052] In summary, APK file analysis has the following problems:

[0053] 1) Manual analysis is inefficient and cannot cope with the analysis needs of a large number of APK files.

[0054] 2) Existing tools lack a comprehensive analysis framework and cannot comprehensively evaluate the security of APK files.

[0055] 3) It is difficult to detect malware that uses advanced techniques such as code obfuscation, encryption, and anti-debugging techniques.

[0056] 4) The lack of a user-friendly visual interface makes the analysis results difficult for non-professionals to understand and use.

[0057] At least to address the above problems, the following embodiments of the present application provide an application file security analysis method, which can be applied to Figure 1 The software system shown.

[0058] The software system 10 includes a front end 101 and a back end 102. The front end 101 includes a user interface and a user experience, and is the part that the user directly interacts with. The back end 102 is responsible for processing the data and business logic of the application, and communicating with the front end, database, server, etc. In this application, the user uploads the APK file through the front end 101, and the back end 102 receives the APK file and judges and analyzes whether it is malware and malicious features, and sends the judgment and analysis results to the front end.

[0059] The technical solutions in the embodiments of the present application will be described in detail below in conjunction with the drawings in the embodiments of the present application.

[0060] Figure 2 The diagram is a process diagram of an application file security analysis method in one embodiment of the present application. Figure 2 As shown, the application file security analysis method includes:

[0061] S11, obtaining a first application file and risk data. The first application file is an APK (Android Package) file uploaded by a user, and the first application file is stored in temporary data.

[0062] S12: Obtain a second application file according to the first application file and its hash value, where the second application file has the same hash value as the first application file.

[0063] Specifically, the second application file is verified using a file verification mechanism to ensure that the hash value of the second application file is the same as that of the first application file. The same hash value of the second application file and the first application file represents that the second application file has not been tampered with during the acquisition process and is a complete application file.

[0064] S13: Perform static analysis on the second application file to obtain file feature data.

[0065] Specifically, static analysis refers to the security analysis of an application without running it. Static analysis usually involves in-depth inspection and analysis of the application's code, configuration files, resource files, etc. The main advantage of static analysis is that it can perform a comprehensive inspection of the application and will not be affected by any external factors that the application may encounter during runtime. The source code of the application file is obtained by decompiling the application file, and then the source code is analyzed to obtain relevant feature data.

[0066] S14, dynamically analyzing the second application file to obtain file operation data.

[0067] Specifically, dynamic analysis refers to the security analysis of an application while it is running. Dynamic analysis methods can discover security issues that an application may encounter while running, such as network communication anomalies, file system operation anomalies, etc. The main advantage of dynamic analysis is that it can discover security issues that cannot be discovered in static analysis.

[0068] Exemplarily, the process of dynamically analyzing application files includes: installing and running the application on a real device or simulator. Using various tools and techniques to monitor the behavior of the application at runtime, such as network communications, file system operations, system API calls, etc. Recording abnormal behaviors of the application at runtime, such as abnormal network requests, file operations, etc. Analyzing the captured abnormal behaviors to determine whether the application has security issues.

[0069] By combining static analysis and dynamic analysis to conduct a comprehensive analysis of application files, we can have a more comprehensive understanding of the security of application files and discover potential security issues in a timely manner.

[0070] S15, classifying the file feature data and the file operation data using a machine learning algorithm to obtain a classification result of the second application file. The classification result is used to indicate whether the second application file is malware.

[0071] S16, comparing the analysis data with the risk data to obtain a comparison result. The analysis data includes the file feature data, the file operation data, and the classification result. The analysis data of the application file is compared with the latest risk data to determine whether there are malicious features in the application file.

[0072] Exemplarily, malicious feature data is built into the backend database, and application file features are generated based on the built-in malicious feature data. The second application file is parsed to obtain the malicious feature data of the second application file, and the malicious feature data of the second application file is compared with the malicious feature data already existing in the database. If the second application file has the same malicious feature data existing in the database, it is marked as risk data.

[0073] According to the above description, the application file security analysis method provided by the present application can perform a comprehensive analysis on the application file, obtain file feature data through static analysis and obtain file operation data through dynamic analysis, and can meet the needs of efficient analysis of a large number of application files. It can classify and judge whether the application file is malware, and obtain the comparison result between the application file and the malware by comparing it with the risk data, so as to realize the identification and detection of malware with more advanced and complex threats.

[0074] Figure 3 The diagram shows a process diagram of obtaining a second application file in an embodiment of the present application. Figure 3 As shown, the process of obtaining the second application file according to the first application file and its hash value includes:

[0075] S21, searching whether there is an application file with the same hash value as the first application file in the backend.

[0076] S22: If yes, use the application file as the second application file.

[0077] S23: Otherwise, the first application file is transmitted to the backend.

[0078] S24, performing hash value verification on the received first application file at the back end, and obtaining the second application file according to the verification result.

[0079] Specifically, when transferring files between the web front-end and the web back-end, the MD5 hash algorithm is used to verify the integrity and consistency of the files during the transmission process. The MD5 hash algorithm is a widely used hash function that can convert data of any length into a fixed-length summary, usually 128 bits. The summary is called the MD5 hash value, which is unique and irreversible, that is, different data inputs will produce different hash values.

[0080] Preferably, the web front end uses the md5 algorithm to calculate the hash value of the first application file, and the hash value calculated by the web front end is sent to the web back end. The web back end receives the hash value sent by the front end and searches whether there is an application file with the same hash value locally. If it exists, it means that the application file has been uploaded and it is used as the second application file to avoid repeated uploading and analysis. If the hash value received by the web back end does not exist locally, the web back end receives the first application file. After receiving, the back end will perform a hash value check on the received first application file again to confirm whether the file has been tampered with or damaged during the transmission process. If the hash values ​​of the front end and the back end are the same, the first application file received by the back end is used as the second application file. If the hash values ​​calculated by the front end and the back end are the same, it means that the file has not been tampered with during the transmission process and can be used as the second application file. If the hash values ​​are different, it means that the file may be tampered with or damaged during the transmission process. At this time, the file will not be analyzed further to avoid analyzing the wrong conclusion. If the hash value check passes, the back end will perform further static analysis and dynamic analysis on the application file to evaluate its security. After the analysis is completed, the back end will store and record the new hash value for quick matching in future analysis to improve analysis efficiency. In this way, file transfer between the web front-end and the web back-end becomes more secure and reliable, and can effectively prevent files from being tampered with or damaged during transmission, thereby ensuring the accuracy and effectiveness of the analysis results.

[0081] The process of obtaining the second application file according to the verification result includes: if the verification is successful, taking the first application file received by the back end as the second application file; if the verification fails, deleting the first application file received by the back end.

[0082] Figure 4 The following is a schematic diagram of the process of obtaining file feature data in one embodiment of the present application. Figure 4 As shown, the process of statically analyzing the second application file to obtain file feature data includes:

[0083] S31, decompress the second application file to obtain a metadata file.

[0084] Specifically, the second application file is stored in a compressed package format, including multiple files and directories. The second application is decompressed to obtain a metadata file, which is related to the structure and content of the application file.

[0085] Preferably, the metadata file includes an AndroidManifest.xml file and a classes.dex file. Among them, the AndroidManifest.xml file defines the metadata and configuration of the application, and the AndroidManifest.xml file includes the basic information of the application, application components (such as activities, services, broadcast receivers, etc.), requested permissions, used SDK versions, configurations of application components, etc. The AndroidManifest.xml file defines the package name, version information, permission requests, intent filters, application icons, etc. of the application. The classes.dex file contains the actual code of the application and is the core of the application runtime execution. The classes.dex file is a bytecode file used by the Dalvik virtual machine, which contains the compressed format of the Java class files (.class files) of the application and the dependencies between them. These class files are compiled into bytecode and can be run on the Dalvik virtual machine. During the build process, the Java class files are compiled into DEX files and packaged in the final APK file. The AndroidManifest.xml file and the classes.dex file constitute a complete Android application, which determines the functions and behaviors of the application.

[0086] S32, parsing and decompiling the metadata file to obtain the file feature data.

[0087] Exemplarily, the file feature data includes version information of the application file, the size of the application file, the package name of the application, the version code and version name of the application, the permission request list of the application, the component information of the application (such as activities, services, broadcast receivers, content providers), the application's usage permissions and required functions, certificate signatures, integrated third-party service SDKs and libraries, network behavior, code behavior characteristics, packaging service providers and other information.

[0088] Exemplarily, the process of statically analyzing the second application file to obtain file feature data also includes repairing and correcting the second application file in advance.

[0089] Specifically, the process of repairing and correcting the second application file is as follows:

[0090] 1) Obtain the file data of the second application file, read it cyclically from the end of the file data until the end mark of the central directory is obtained, and parse the information of the central directory.

[0091] 2) Extract and cache the signature block data of the second application file.

[0092] 3) Loop through the central directory file header information starting from the offset position at the beginning of the central directory until the central directory data is read, and record the number of files while looping through the reading.

[0093] 4) Read the local file header through the central directory and correct the encryption flags of the central directory and the local file header.

[0094] 5) Read the file content through the local file header and decompress the file content.

[0095] 6) If the decompression is correct, the decompression method is written into the file data to complete the repair of the compression method; if it is not compressed, the uncompressed size in the file header and the compressed file size are determined. When the two sizes are not equal, the compressed file size is corrected to the uncompressed file size.

[0096] 7) Repair the content of the end segment of the central directory, write the number of recorded files, append the signature block data to the end of the repaired data, and append the content of the end segment of the central directory to the end of the file.

[0097] 8) Read the repaired second application file in ZIP format, and read the AndroidManifest.xml file in the second application file.

[0098] 9) Traverse each data block in the AndroidManifest.xml file, correct the number of strings in the data block, and obtain the correct string. Compared with the application file before repair, the repaired file makes up for the defects of missing nodes, tampered attributes and replaced strings in the application file.

[0099] In one embodiment of the present application, dynamically analyzing the second application file to obtain file operation data includes:

[0100] Step 1: prepare the operating environment and install the second application file.

[0101] Exemplarily, the second application file is installed on a real Android device to more accurately simulate the user's usage environment, and communicates with the connected Android device through adb (Android Debug Bridge) commands to remotely control the device to perform various operations, such as installing and uninstalling applications, obtaining device information, and executing shell commands.

[0102] Step 2: Run the second application file to obtain file running data.

[0103] Preferably, uiautomator (User Interface Automator) automated testing tool is used to simulate the interactive behavior of the user to trigger different functions and code paths of the second application file. Among them, uiautomator is an automated testing tool that can automatically perform various user operations, such as clicking a button, inputting text, sliding the screen, etc. Through uiautomator, automatic clicks and other operations are performed to detect whether the application has been shelled. Shelling refers to encrypting or obfuscating the application code, which increases the difficulty of reverse engineering. If shelling is detected, a shelling tool (such as Xposed framework) can be used to decrypt or restore the shelled code to perform detailed code logic analysis. And a packet capture tool (such as Wireshark, Charles, mitmproxy, etc.) is used to capture and analyze the network requests initiated by the application at runtime and the network responses received. Through the packet capture tool, the network behavior of the application can be understood, including the requested URL, request method, request header, request body, data and status code of the response, etc., which helps to discover the network communication mode, data transmission mode and potential security issues of the application. The Frida dynamic analysis tool can be used to monitor and modify the code of the application at runtime, such as capturing sensitive API calls, modifying data, etc., which helps to gain a deeper understanding of the internal logic of the application and potential security threats.

[0104] By dynamically analyzing the second application file to extract sensitive information from the application file, we can fully understand the runtime behavior of the application, including user interaction, network communication, and code execution. This information is crucial for evaluating the security and performance of the application and can help discover potential security vulnerabilities and abuse.

[0105] Exemplarily, the file execution data includes screenshots, network information, code files, code behavior characteristics and other information.

[0106] Figure 5 The diagram shows a process of obtaining the classification result of the second application file in one embodiment of the present application. Figure 5As shown, the process of classifying the file feature data and the file operation data by using a machine learning algorithm to obtain the classification result of the second application file includes:

[0107] S41, obtaining a malicious identification model.

[0108] The training method of the malicious identification model includes:

[0109] a. Obtain training data. The training data includes: file feature data and file operation data of malware, and file feature data and file operation data of normal software.

[0110] b. Train the convolutional neural network using the training data to obtain the malicious identification model. Train the convolutional neural network using the training data and the labels corresponding to the data to obtain the malicious identification model. The malicious identification model can predict the corresponding labels based on the characteristics of the training data.

[0111] S42, using the malicious identification model to match and classify the file feature data and the file operation data to obtain the classification result, wherein the classification result is whether the second application file is malware.

[0112] In one embodiment of the present application, the application file security analysis method further includes: updating the analysis data and the risk data into a database.

[0113] Exemplarily, the database is, for example, a MySQL database. The MySQL database is a relational database capable of storing structured data.

[0114] Exemplarily, the latest risk data is obtained from an external data source, the risk data is parsed, and the parsed data is updated to the database. The risk data can be obtained by crawling data using a crawler technology or by using an API interface.

[0115] Preferably, the external data sources include malware databases, security vulnerability databases, permission abuse databases, code behavior feature databases, and network request feature databases. Among them, malware databases include VirusTotal, MalwareBazaar, etc., and malware databases collect and analyze a large number of malware samples and provide relevant feature information. Security vulnerability databases include CVE, NVD, etc., and security vulnerability databases record known software vulnerability information and provide detailed descriptions and solutions for vulnerabilities. The permission abuse database can record the potential risks of different permissions, such as which permissions are prone to abuse and the consequences of abuse of permissions. The code behavior feature database can record the behavioral characteristics of normal and malicious code, such as function call patterns, data flow analysis, etc. The network request feature database can record common network request features of malware, such as domain names, IP addresses, ports, request parameters, etc. Updating risk data can keep the system's security detection capabilities always up to date, improve the detection rate of malware and vulnerabilities, and reduce the false alarm rate to avoid misjudging normal applications as malware.

[0116] Figure 6 The following is a schematic diagram of the process of obtaining the comparison result in one embodiment of the present application. Figure 6 As shown, the process of comparing the analysis data with the risk data and obtaining the comparison result includes:

[0117] S51, using the risk data to update the analysis rules. The analysis rules are updated according to the collected vulnerabilities and malicious code blocks to generate new analysis rules.

[0118] S52, comparing the analysis data with the risk data based on the analysis rule to obtain the comparison result. The comparison result is the malicious features and malicious types in the application file that are the same as the risk data.

[0119] For example, the permissions requested by the application file are compared with the permission abuse information library to determine whether there is permission abuse. The code behavior of the application file is compared with the code behavior feature library to determine whether there is abnormal behavior. The network request of the application file is compared with the malware feature library to determine whether there is malicious network behavior.

[0120] In one embodiment of the present application, an analysis report of the application file is automatically generated based on the classification results and the comparison results. The analysis report includes the overall security results of the application file, potential security issues, recommended measures for repair, etc. The analysis report can be sent to the user through a web interface or email.

[0121] This application uses comprehensive automated analysis technology to detect and judge the security of application files. This application combines dynamic analysis with static analysis to conduct a comprehensive analysis of application files, using static analysis to extract source code decompilation features and dynamic analysis to automatically click and simulate human operations, and to capture packets, take screenshots, and process frida hooks. It can conduct a comprehensive analysis of the security of application files from various dimensions. Compared with a single dimension that can only perform specific analysis on application files, using a combination of dynamic and static analysis to analyze application files from multiple dimensions can more easily detect malware that uses advanced technologies (such as code obfuscation, encryption, and anti-debugging technology), and can meet the processing and analysis needs of a large number of application files.

[0122] In order to better analyze and detect the malicious features of applications, this application provides an application file security analysis method. There are still deficiencies in the detection of complex malicious threats of malware, so a new comprehensive analysis method is designed to perform malicious analysis and preliminary malicious screening of application files through comprehensive analysis and collaborative comprehensive methods, which can more effectively detect the types and features of malicious files, thereby realizing security detection and analysis of application files.

[0123] The general embodiment will be described in detail below through a specific example of the application file security analysis method provided by the embodiment of the present application. It should be noted that the content in this example is only used to explain and illustrate the application file security analysis method provided by the embodiment of the present application, and is not used to limit the scope of protection of the present application. In specific applications, corresponding steps can be added or deleted based on the example according to actual needs. Figure 7 The flowchart of the application file security analysis method in this example is shown. Figure 7 As shown, the application file security analysis method in this example includes the following steps.

[0124] In the first step, the user uploads the application file to the server through the web interface. The hash values ​​of the application file received by the web front-end and the web back-end are calculated. If the hash value of the application file received by the back-end is the same as the hash value of the web front-end, the application file has not been tampered with during the upload process.

[0125] The second step is to perform static analysis on the application files received by the web backend. First, the application files are decompressed to obtain the metadata file AndroidManifest.xml, and classes.dex is decompiled to obtain the smali file, which is then extracted according to the specified opcodes of the smali file to obtain the file feature data of the application file.

[0126] The third step is to dynamically analyze the application files received by the web backend. Run the application files on the real device through adb, and capture the packets to obtain network behavior. Use uiautomator to automatically click to determine whether the application is packed, and unpack it when it is detected. Use frida to capture specific nodes (such as SMS, contact access, etc.) to obtain the corresponding code behavior characteristics. Through a series of dynamic analysis, the file operation data of the application file is finally obtained.

[0127] The fourth step is to use the pre-trained malicious identification model to classify the file feature data and file operation data to identify possible malicious behaviors. For example, the onnxruntime inference framework is used to train and infer a set of pornographic images, and to perform image recognition and classification on static resource images in application files and screenshots of dynamic analysis.

[0128] In the fifth step, the multiple analysis data obtained from the second to fourth steps are updated into the database, and malicious vulnerabilities and malware features are regularly collected from the cloud server to update the MySQL database, and the collected features are compared with the analysis data to obtain the final security analysis results, potential problems, and recommended repair measures.

[0129] In the sixth step, users can generate a report in the required format based on the analysis results and download it through the web interface.

[0130] In summary, the application file security analysis method provided by the present application can quickly process a large number of APK files in an automated manner, which shortens the analysis time by at least 50% compared with the manual analysis method and improves the analysis efficiency of application files. Through machine learning algorithms and advanced rule sets, known and unknown security vulnerabilities, malicious code and other security threats in APK files are more accurately identified, and the test accuracy reaches more than 95%, which is much higher than the average accuracy of existing tools. By combining comprehensive analysis technologies such as static analysis and dynamic analysis, the false alarm rate of application files is effectively reduced. At the same time, new analysis rules and algorithms can be continuously updated and added from the cloud server to cope with the evolving security threats. The application file security analysis method provided by the present application can not only analyze the code and permissions of the APK file, but also consider the behavioral characteristics and operation characteristics of the application, provide a comprehensive security assessment for the APK file, and comprehensively reveal the possible risks of the application through comprehensive analysis. At the same time, an intuitive visual interface is also provided, so that non-professionals can easily understand the analysis results of the application file, reduce the dependence of enterprises on professional security analysts, and save labor costs. Comprehensive analysis of application files is performed, and file feature data is obtained through static analysis and file operation data is obtained through dynamic analysis. The application file is classified and judged whether it is malware, and the comparison result between the application file and the malware is obtained by comparing it with the risk data. The security analysis result of the application is finally obtained based on the analysis result and the comparison result.

[0131] The protection scope of the application file security analysis method described in the embodiment of the present application is not limited to the execution order of the steps listed in this embodiment. All solutions implemented by adding, reducing or replacing steps in the prior art based on the principles of the present application are included in the protection scope of the present application.

[0132] An embodiment of the present application also provides an application file security analysis system, which can implement the application file security analysis method described in the present application. However, the implementation device of the application file security analysis method described in the present application includes but is not limited to the structure of the application file security analysis system listed in the present embodiment. All structural deformations and replacements of the prior art made according to the principles of the present application are included in the protection scope of the present application.

[0133] Figure 8 The diagram shows a schematic diagram of the structure of an application file security analysis system in one embodiment of the present application. Figure 8As shown, the application file security analysis system 1 includes: a first application file acquisition module 11, a second application file acquisition module 12, a static analysis module 13, a dynamic analysis module 14, a classification result acquisition module 15, and a comparison result acquisition module 16. Among them, the first application file acquisition module 11 is used to acquire the first application file and risk data. The second application file acquisition module 12 is used to acquire the second application file according to the first application file and its hash value, and the second application file has the same hash value as the first application file. The static analysis module 13 is used to perform static analysis on the second application file to obtain file feature data. The dynamic analysis module 14 is used to perform dynamic analysis on the second application file to obtain file operation data. The classification result acquisition module 15 is used to classify the file feature data and the file operation data using a machine learning algorithm to obtain a classification result of the second application file, and the classification result is used to indicate whether the second application file is malware. The comparison result acquisition module 16 is used to compare the analysis data with the risk data to obtain a comparison result, and the analysis data includes the file feature data, the file operation data, and the classification result.

[0134] It should be noted that Figure 8 The modules in the application file security analysis system 1 are Figure 2 The steps in the application file security analysis method correspond to each other and are not described in detail here.

[0135] In the several embodiments provided in the present application, it should be understood that the disclosed system, device or method can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules / units is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or units can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules or units, which can be electrical, mechanical or other forms.

[0136] The modules / units described as separate components may or may not be physically separated, and the components displayed as modules / units may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules / units may be selected according to actual needs to achieve the purpose of the embodiments of the present application. For example, the functional modules / units in the various embodiments of the present application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0137] Those of ordinary skill in the art should further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0138] The present application embodiment also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by the processor, the application file security analysis method provided by the present application embodiment is implemented. A person of ordinary skill in the art can understand that all or part of the steps in the method for implementing the above embodiment can be completed by instructing the processor through a program, and the program can be stored in a computer-readable storage medium, and the storage medium is a non-transitory medium, such as a random access memory, a read-only memory, a flash memory, a hard disk, a solid-state hard disk, a magnetic tape, a floppy disk, an optical disc, and any combination thereof. The above storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disc (DVD)), or a semiconductor medium (e.g., a solid-state hard disk (SSD)), etc.

[0139] The embodiment of the present application may also provide an electronic device. Fig. 9 The diagram shows a schematic diagram of the structure of an electronic device 2 in an embodiment of the present application. Fig. 9 As shown, in this embodiment, the electronic device 2 includes a memory 21 and a processor 22 .

[0140] The memory 21 is used to store computer programs. In some possible implementations, the memory 21 may include: ROM, RAM, a disk, a USB flash drive, a memory card, or an optical disk, etc., various media that can store program codes.

[0141] In the embodiment of the present application, the memory 21 may include a computer system readable medium in the form of a volatile memory, such as a RAM and / or a cache memory. The electronic device 2 may further include other removable / non-removable, volatile / non-volatile computer system storage media. The memory 21 may include at least one program product having a set (e.g., at least one) of program modules, which are configured to perform the functions of the various embodiments of the present application.

[0142] The processor 22 is connected to the memory 21 and is used to execute the computer program stored in the memory 21 so that the electronic device 2 executes the application file security analysis method.

[0143] Exemplarily, the processor 22 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc. In other embodiments, the processor 22 may also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0144] In some implementations, the electronic device 2 provided in the embodiment of the present application may further include a display 23. The display 23 is communicatively connected to the memory 21 and the processor 22, and is used to display a graphical user interface (GUI) related to the application file security analysis method.

[0145] In the embodiment of the present application, the display 23 may include a display screen (display panel). In some implementations, the display panel may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. In addition, the display 23 may also be a touch panel (touch screen, touch screen), and the touch panel may include a display screen and a touch-sensitive surface. When the touch-sensitive surface detects a touch operation on or near it, it is transmitted to the processor 22 to determine the type of touch event, and then the processor 22 provides a corresponding visual output on the display device according to the type of touch event.

[0146] The descriptions of the processes or structures corresponding to the above-mentioned figures have different emphases. For parts that are not described in detail in a certain process or structure, please refer to the relevant descriptions of other processes or structures.

[0147] The above embodiments are merely illustrative of the principles and effects of the present application and are not intended to limit the present application. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present application. Therefore, all equivalent modifications or changes made by a person of ordinary skill in the art without departing from the spirit and technical ideas disclosed in the present application shall still be covered by the claims of the present application.

Claims

1. A method for analyzing application file security, characterized in that: The application file security analysis method comprises: obtaining first application files and risk data; Acquire a second application file according to the first application file and its hash value, wherein the second application file has the same hash value as the first application file; Performing static analysis on the second application file to obtain file feature data; Dynamically analyzing the second application file to obtain file operation data; classifying the file feature data and the file operation data using a machine learning algorithm to obtain a classification result of the second application file, wherein the classification result is used to indicate whether the second application file is malware; The analysis data is compared with the risk data to obtain a comparison result, wherein the analysis data includes the file feature data, the file operation data, and the classification result.

2. The application file security analysis method according to claim 1, characterized in that: The process of obtaining the second application file according to the first application file and its hash value includes: Searching whether there is an application file with the same hash value as the first application file on the back end, and if so, using the application file as the second application file; otherwise, transmitting the first application file to the back end; A hash value check is performed on the received first application file at the back end, and the second application file is obtained according to the check result.

3. The application file security analysis method according to claim 2, characterized in that: The process of obtaining the second application file according to the verification result includes: if the verification is successful, using the first application file received by the back end as the second application file.

4. The application file security analysis method according to claim 1, characterized in that: The process of statically analyzing the second application file to obtain file feature data includes: decompressing the second application file to obtain a metadata file; The metadata file is parsed and decompiled to obtain the file characteristic data.

5. The application file security analysis method according to claim 1, characterized in that: The application file security analysis method further includes: updating the analysis data and the risk data into a database.

6. The application file security analysis method according to claim 1, characterized in that: The process of classifying the file feature data and the file operation data by using a machine learning algorithm to obtain a classification result of the second application file includes: Obtain a malicious identification model; Using the malicious identification model to match and classify the file feature data and the file operation data, and obtain the classification result; The training method of the malicious identification model includes: Acquire training data, the training data including: file feature data and file operation data of malware, and file feature data and file operation data of normal software; The convolutional neural network is trained using the training data to obtain the malicious identification model.

7. The application file security analysis method according to claim 1, characterized in that: The process of comparing the analysis data with the risk data and obtaining the comparison result includes: updating analysis rules using the risk data; The analysis data and the risk data are compared based on the analysis rule to obtain the comparison result.

8. An application file security analysis system, characterized in that: The application file security analysis system comprises: A first application file acquisition module, used to acquire a first application file and risk data; A second application file acquisition module, configured to acquire a second application file according to the first application file and its hash value, wherein the second application file has the same hash value as the first application file; A static analysis module, used for performing static analysis on the second application file to obtain file feature data; A dynamic analysis module, used for dynamically analyzing the second application file to obtain file operation data; a classification result acquisition module, used to classify the file feature data and the file operation data using a machine learning algorithm to obtain a classification result of the second application file, wherein the classification result is used to indicate whether the second application file is malware; The comparison result acquisition module is used to compare the analysis data with the risk data to obtain the comparison result, wherein the analysis data includes the file feature data, the file operation data, and the classification result.

9. An electronic device, characterized in that: The electronic device comprises: a memory having a computer program stored thereon; A processor is communicatively connected to the memory, and is used to execute the computer program to implement the application file security analysis method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by an electronic device, the application file security analysis method described in any one of claims 1 to 7 is implemented.

Images