Application risk detection method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a risk detection method and device of an application program, an electronic device and a storage medium. The present disclosure relates to the technical field of computers, in particular to the technical field of software testing, and can be used in diversified scenarios such as query and detection of black production application programs, security detection of application programs, etc. The specific implementation scheme is: receiving an application program to be detected; performing static code detection on the application program to obtain a static detection result; performing dynamic behavior monitoring on the application program to obtain a dynamic detection result; and generating a risk detection result based on the static detection result and the dynamic detection result. According to the disclosure of the present scheme, the efficiency and accuracy of risk analysis can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the field of software testing technology. It can be used for various scenarios such as querying and detecting black market applications and security testing of applications. Specifically, it relates to a method, device, electronic device and storage medium for risk detection of applications. Background Technology

[0002] Traditional risk analysis typically relies on multiple independent analysis tools. The installation and configuration of each tool increases operational complexity, and compatibility issues may exist between different tools, affecting the efficiency and accuracy of the overall analysis. Summary of the Invention

[0003] This disclosure provides a method, apparatus, electronic device, and storage medium for risk detection of an application.

[0004] According to one aspect of this disclosure, a risk detection method for an application is provided, comprising:

[0005] Receive the application to be tested;

[0006] Perform static code analysis on the application and obtain the static analysis results;

[0007] Dynamic behavior monitoring of the application is performed to obtain dynamic detection results;

[0008] Risk detection results are generated based on static and dynamic detection results.

[0009] According to another aspect of this disclosure, a risk detection device for an application is provided, comprising:

[0010] The receiving module is used to receive the application to be detected;

[0011] The static code analysis module is used to perform static code analysis on the application and obtain the static code analysis results.

[0012] The dynamic detection module is used to monitor the dynamic behavior of the application and obtain dynamic detection results;

[0013] The first generation module is used to generate risk detection results based on static and dynamic detection results.

[0014] According to another aspect of this disclosure, an electronic device is provided, comprising:

[0015] At least one processor; and

[0016] The memory is communicatively connected to the at least one processor; wherein,

[0017] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0018] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0019] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0020] The solution disclosed herein can solve the problems of complex operation, low efficiency and inaccurate judgment in the existing software risk analysis process, thereby improving the efficiency and accuracy of risk analysis.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0022] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0023] Figure 1 This is a schematic flowchart of a risk detection method for an application according to an embodiment of this disclosure;

[0024] Figure 2 This is a framework diagram of a risk detection tool according to an embodiment of this disclosure;

[0025] Figure 3 This is an architecture diagram of the dynamic search process according to an embodiment of the present disclosure;

[0026] Figure 4 This is a schematic diagram of the call chain tracing and network request analysis process according to an embodiment of this disclosure;

[0027] Figure 5 This is a schematic diagram of the structure of a risk detection device for an application according to an embodiment of the present disclosure;

[0028] Figure 6 This is a schematic diagram of a risk detection scenario according to an embodiment of this disclosure;

[0029] Figure 7 This is a block diagram of an electronic device used to implement a risk detection method for an application according to embodiments of the present disclosure. Detailed Implementation

[0030] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0031] In this document, the term "and / or" merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The term "at least one" in this document indicates any combination of at least two of a plurality of elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C. The terms "first" and "second" in this document refer to and distinguish between multiple similar technical terms, not to restrict the order or to limit there to only two. For example, "first feature" and "second feature" refer to two categories / two features; the first feature can be one or more, and the second feature can also be one or more.

[0032] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0033] Before introducing the technical solutions of the embodiments of this disclosure, the technical terms that may be used in this disclosure will be further explained:

[0034] Static code analysis: Analyzing source code to discover potential security vulnerabilities and code defects without running the application.

[0035] Dynamic behavior monitoring: Real-time monitoring and analysis of the application's behavior during operation to detect abnormal behavior and security threats.

[0036] Risk score: A quantitative metric used to represent the magnitude of an application's potential security risks.

[0037] Risk Detection Report: This report details all security issues, vulnerabilities, and anomalous behaviors discovered during static and dynamic detection, and provides corresponding remediation recommendations and improvement measures.

[0038] In related technologies, detecting whether an application (APP) contains risky or malicious activities requires the use of multiple tools. However, in practice, there are still many limitations and shortcomings, specifically in the following aspects:

[0039] (1) Fragmented tools and low integration: Current risk analysis processes typically rely on multiple independent tools, such as packet capture tools, hook injection tools, and kernel monitoring tools. The lack of a unified integration platform between these tools leads to complex operations, low compatibility between different tools, and low data transfer efficiency, which affects the overall smoothness of the analysis process.

[0040] (2) Complex operation and high threshold: Many analysis tools require professional configuration and usage experience, especially kernel monitoring, unpacking, and dynamic analysis, which involve cumbersome operation steps and high technical requirements. Non-professionals find it difficult to complete the entire risk analysis process smoothly, which limits the widespread application of the technology.

[0041] (3) Low analysis efficiency and long time consumption: Multi-tool collaboration often requires a long time for data processing and analysis, especially when facing large or complex applications, the analysis efficiency is obviously insufficient and it is difficult to meet the needs of rapid evaluation in actual business.

[0042] (4) Inaccurate risk assessment: The black market feature database is outdated and cannot identify new or variant malicious behaviors in a timely manner. In addition, the risk scoring mechanism is relatively crude and it is difficult to accurately distinguish between different types of risky behaviors, which may lead to missed or false reports.

[0043] (5) Lack of dynamic behavior analysis: Although static analysis can provide some basis for risk judgment, it lacks effective monitoring and analysis of the dynamic behavior of the application during runtime. In particular, the detection capability of complex dynamic loading or self-modifying code is limited, resulting in blind spots in the analysis results.

[0044] In order to at least partially solve one or more of the above-mentioned problems and other potential problems, this disclosure proposes a risk detection method for an application, which can solve the problems of operational complexity, inefficiency and inaccurate judgment in the existing risk analysis process, and improve the efficiency and accuracy of risk analysis.

[0045] This disclosure provides a method for detecting the risk of an application. Figure 1 This is a flowchart illustrating a risk detection method for an application according to an embodiment of this disclosure. This risk detection method can be applied to a risk detection device located on a personal computer terminal. In some possible implementations, the risk detection method can also be implemented by the processor calling computer-readable instructions stored in memory. Figure 1 As shown, the risk detection methods of this application include:

[0046] S101, Receive the application to be tested;

[0047] S102. Perform static code analysis on the application and obtain the static analysis results;

[0048] S103. Perform dynamic behavior monitoring on the application and obtain dynamic detection results;

[0049] S104. Generate risk detection results based on the static detection results and the dynamic detection results.

[0050] In this embodiment of the disclosure, the application received in S101 is assumed to be a black market app. Black market apps typically refer to applications used for illegal activities, fraud, malicious advertising, data theft, etc.

[0051] In this embodiment of the disclosure, static code analysis involves analyzing source code without running the program to discover potential security vulnerabilities and code defects. Static code analysis typically involves a thorough examination of the code's syntax, semantics, structure, and other aspects.

[0052] In this embodiment of the disclosure, dynamic behavior monitoring involves real-time monitoring and analysis of a program's behavior during runtime. Dynamic behavior monitoring typically involves capturing an application's network activity, file operations, process behavior, etc., during runtime and comparing them with known security threat patterns. In this embodiment of the disclosure, the results of dynamic behavior monitoring will be used as dynamic detection results.

[0053] It should be noted that this disclosure does not limit the execution order of S102 and S103. S102 can be performed before S103, S102 can be performed after S103, and S102 and S103 can be performed simultaneously.

[0054] For example, suppose there's a malicious app called "Malicious Mining" that uses system resources to mine cryptocurrency without the user's knowledge. A risk detection webpage is opened on a personal computer (PC). After detecting the malicious app and dragging it to a preset area, static code analysis and dynamic behavior monitoring are performed. During the static analysis phase, suspicious code snippets and encryption algorithms might be found in the app. During the dynamic analysis phase, abnormal behaviors such as communicating with mining pools on the network and consuming large amounts of CPU and memory resources might be detected. Finally, a risk score and risk detection report are generated based on the detection results, alerting the user or security team that the malicious app poses a serious security risk and recommending immediate uninstallation or repair.

[0055] The technical solution of this disclosure, by combining static code analysis and dynamic behavior monitoring, can comprehensively and quickly discover potential security issues in applications, improving the efficiency and accuracy of risk analysis. Risk detection helps to promptly identify and remediate security problems, reducing the risk of application attacks or misuse and enhancing security.

[0056] In some embodiments, risk detection results include risk scores and risk detection reports; the risk detection methods used in this application include:

[0057] S105. In response to receiving a risk score query request for the application, output the risk score of the application;

[0058] S106. In response to receiving a risk detection report query request for the application, output the risk detection report for the application.

[0059] This disclosure does not restrict the execution order of S105 and S106. S105 can be performed before S106, S105 can be performed after S106, and S105 and S106 can be performed simultaneously.

[0060] In some implementations, when users or security teams need to know an application's risk score, they can obtain that score through a query interface. This helps in quickly assessing the application's security and determining whether further investigation or remediation is needed.

[0061] In some implementations, when users or security teams need detailed information about the security issues of an application, they can obtain a complete risk detection report through a query interface. The report will provide detailed detection results, problem descriptions, remediation suggestions, and other information to help users or security teams develop targeted remediation plans.

[0062] Thus, by outputting risk scores, users or security teams can quickly understand the security level of an application. Because risk detection reports provide detailed detection results and remediation suggestions, they help users or security teams develop targeted remediation plans and security strategies to reduce potential security risks.

[0063] In some embodiments, before performing dynamic behavior monitoring or static code detection, the method further includes: detecting whether the application is protected by a packer; and if the application is protected by a packer, performing an unpacking operation on the application to extract the original file cluster of the application, which is used for static or dynamic analysis.

[0064] In this embodiment of the disclosure, the packing protection is a code protection technology that prevents reverse engineering and tampering by compressing, encrypting or obfuscating the code.

[0065] In this embodiment of the disclosure, the unpacking operation is the process of restoring a packed application to its original, unpacked code or file cluster.

[0066] In this embodiment of the disclosure, the original file cluster refers to the original code or file set of the application extracted after the unpacking operation, which is used for subsequent static code detection or dynamic behavior monitoring.

[0067] In some implementations, before performing dynamic behavior monitoring or static code analysis, it is first determined whether the application under test is protected by a packer. For example, packer protection can be identified by analyzing the application's binary structure, entry points, and code segment characteristics.

[0068] In some implementations, if the application is detected to be protected by a packer, an unpacking operation is performed. Upon successful unpacking, the original file clusters of the application are extracted, which will be used for subsequent static code analysis or dynamic behavior monitoring.

[0069] For example, suppose there's a malicious app called "Malicious Ad Plugin" that uses a code-breaking tool to hide its malicious behavior. After detecting the code-breaking, a professional unpacking tool is used to unpack it. Once unpacked, the app's original file cluster is extracted and subjected to static code analysis and dynamic behavior monitoring. The static analysis reveals suspicious ad code and malicious behavior triggering logic within the app; the dynamic analysis detects abnormal behavior such as the app frequently sending ad requests in the background and consuming system resources. Finally, based on the detection results, a risk score and risk detection report are generated, alerting users or the security team that the app poses a serious security risk and recommending immediate uninstallation or repair.

[0070] Thus, by unpacking the application, its original code can be restored, avoiding interference from the packer's protection on static code detection and dynamic behavior monitoring, thereby improving the accuracy and reliability of detection. Adding unpacking functionality expands the applicability of the detection method, enhances its ability to detect applications with packers, and allows for the timely discovery and handling of potential security issues in such applications. This helps reduce the risk of application attacks or misuse, improving overall security.

[0071] In some embodiments, performing static code analysis on an application to obtain static analysis results may include: unpacking the application's compressed package to obtain multiple component files included in the application; analyzing the multiple component files to obtain the application's static analysis results; wherein, the static analysis results are the first type of security vulnerability detection results obtained by analyzing without running the application.

[0072] In this embodiment of the disclosure, a compressed file is a technique for packaging multiple files or folders into a single file. Compressed files are commonly used to save storage space, facilitate file transfer, or protect files from easy modification.

[0073] In this embodiment of the disclosure, component files are files that constitute the various independent parts or modules of the application. These files may include source code, configuration files, resource files, etc.

[0074] In this embodiment of the disclosure, the first type of security vulnerability detection results are factors or conditions discovered during static code analysis that may lead to security problems in the application. These results typically include information such as a description of the problem, its severity, its potential impact, and remediation suggestions.

[0075] In some implementations, unpacking can be performed using specialized decompression tools or scripts, ensuring accurate extraction of all component files contained within the application. This step is a prerequisite for static code analysis; only with access to the application's source code or analyzable component files can subsequent analysis be performed more effectively. Through unpacking, component file analysis, and the generation of static code analysis results, development teams can identify and fix potential security vulnerabilities early in the software development lifecycle, improving application security and code quality.

[0076] In some implementations, automated tools are used to perform in-depth analysis of the source code to uncover potential security vulnerabilities, programming errors, and poor coding practices. This step does not require running the application; instead, it identifies potential problems by analyzing the code's structure, syntax, and semantics. During the analysis, a focus can be placed on security vulnerabilities, performance bottlenecks, logical errors, and whether relevant programming standards and best practices are followed.

[0077] In some implementations, static detection results include the detection of Category 1 security vulnerabilities found without parsing and running the application. Static detection results are typically presented in the form of a report, which includes a list of identified issues, the severity of the issues, their potential impact, and remediation recommendations.

[0078] For example, suppose there's an application called "Secure Payment App," and the development team decides to perform static code analysis on it. First, the team opens a risk detection webpage on their PC, drags the app to a preset area, and the webpage unpacks the app's compressed file, obtaining multiple component files including source code, configuration files, and resource files. Then, they perform in-depth analysis of these component files. During the analysis, several potential security vulnerabilities were discovered, such as uninitialized variables, resource leaks, and a possible Structured Query Language (SQL) injection vulnerability. The development team promptly fixed these vulnerabilities based on the detection results and retested the app. Ultimately, the app's security was significantly improved, and the code quality was optimized.

[0079] In this way, static code analysis can identify logical errors, performance bottlenecks, and poor coding practices in the code, and provide suggestions for improvement. This helps the development team improve code quality and reduce the workload of later debugging and fixing. Static code analysis helps the development team identify and correct problems during the coding phase, thereby avoiding the need to invest more time and resources in the later testing and maintenance phases, and helping to reduce the maintenance cost of the application.

[0080] In some embodiments, dynamic behavior monitoring of the application is performed to obtain dynamic detection results, including: sending the application to a terminal in a preset detection environment for the terminal to install the application; in response to receiving a test instruction for a target task, forwarding the test instruction to the terminal with the application installed to instruct the terminal to execute a test task for the application; analyzing the task execution data returned by the terminal to generate dynamic detection results, which include detection results of a second type of security vulnerability that occurs when the application is running.

[0081] In this embodiment of the disclosure, dynamic behavior monitoring is a technical means to monitor the behavior of an application in real time during operation. By simulating a real user environment, dynamic behavior monitoring can discover potential security risks of the application in different scenarios.

[0082] In this embodiment of the disclosure, the detection environment is a specific environment set up for dynamic behavior monitoring. This environment typically simulates the usage scenarios and conditions of real users to ensure the accuracy of the detection results.

[0083] In this embodiment of the disclosure, a test instruction is an instruction used to instruct the terminal to perform a specific test task. A test instruction typically includes the specific test task to be performed and related parameters.

[0084] In this embodiment of the disclosure, the task execution data is data collected during the execution of test tasks on the terminal. This data may include the application's running status, resource usage, network requests and responses, etc., for subsequent analysis and detection.

[0085] In this embodiment of the disclosure, the second type of security risk is different from the first type of security risk found in static code detection. The second type of security risk occurs during the operation of the application and may involve the abuse of application permissions, data leakage, malicious behavior, etc.

[0086] In some implementations, to simulate a real user environment, the application under test is sent to a terminal in a preset testing environment, ensuring the accuracy of the test results. For example, multiple test scenarios are designed according to testing requirements, each representing a specific usage environment or condition; corresponding test scenario instructions are generated for each terminal under test. These instructions detail which test scenario the terminal should run the application under test in and how to configure relevant parameters to simulate that scenario. The test scenario instructions are sent to multiple terminals under test via a network or other communication methods. After receiving the test scenario instructions, each terminal under test configures and runs the application under test in the specified test scenario according to the requirements in the instructions.

[0087] In some implementations, when a test instruction for a target task is received, the instruction is forwarded to the terminal with the installed application. The test instruction typically includes the specific test task to be performed and related parameters. Upon receiving the test instruction, the terminal will execute the test task for the application as required by the instruction.

[0088] In some implementations, task execution data is collected in real time during the execution of test tasks on the terminal. This data may include the application's running status, resource usage, network requests and responses, etc. The collected task execution data is analyzed to identify potential Category II security vulnerabilities that may arise during application runtime. These vulnerabilities may involve application privilege abuse, data leakage, malicious behavior, etc.

[0089] In some implementations, dynamic detection results are generated based on the analysis findings. These results are typically presented in the form of a report, which includes a list of identified security vulnerabilities, the severity of the issues, their potential impact, and remediation recommendations.

[0090] For example, suppose there's an application called "Smart Social App," and the development team decides to monitor its dynamic behavior. First, the "Smart Social App" to be tested is sent to a terminal in a pre-defined testing environment, and the application is installed on that terminal. Then, scenarios such as user login, sending messages, and browsing activity feeds are simulated, generating corresponding test commands, which are then sent to the terminal with the application installed. During the execution of the test tasks on the terminal, task execution data is collected in real time, such as application memory usage, CPU usage, network requests and responses, etc. Analysis reveals that the application poses a data leakage risk when sending messages, specifically because sensitive data is not encrypted. Based on the dynamic monitoring results, the development team promptly fixed the issue and retested the application. Ultimately, the application's security was significantly improved.

[0091] In this way, dynamic behavior monitoring can monitor the behavior of applications in real time during operation and promptly identify potential security vulnerabilities. By simulating real user environments, dynamic behavior monitoring can comprehensively detect the behavior of applications in different scenarios, ensuring the accuracy of the detection results. Once a security vulnerability is detected, dynamic behavior monitoring can quickly generate detection results and provide remediation suggestions, helping the development team quickly locate and fix the problem. Dynamic behavior monitoring can effectively improve application security and reduce the risks caused by security vulnerabilities.

[0092] In some embodiments, analyzing the task execution data returned by the terminal includes at least one of the following:

[0093] Analyze the various data packets generated by the application during data transmission to identify hidden abnormal data packets, malicious traffic, and suspicious interactive behaviors;

[0094] Analyze the application's behavior in modifying system environment variables and the file system;

[0095] Analyze the application's behavior at the kernel level.

[0096] In this embodiment of the disclosure, a data packet is the basic unit of data in network communication. It contains header information and data content, and is used for transmission and exchange within the network.

[0097] In this embodiment of the disclosure, system environment variables refer to variables in the operating system used to store global data such as system configuration information, user information, and path information. These variables can be read and modified by applications.

[0098] In this embodiment of the disclosure, the file system is a structure in the operating system used to store and manage data. It provides interfaces for creating, deleting, modifying, and accessing files, and serves as an important bridge for interaction between applications and data.

[0099] In this embodiment of the disclosure, the kernel level refers to the core part of the operating system, which is responsible for core functions such as system resource management, process scheduling, and interrupt handling. Application behavior at the kernel level typically involves direct access to and manipulation of system resources.

[0100] In some implementations, the analysis involves various data packets generated by the application during data transmission, including: First, capturing all network data packets generated by the application during runtime. This can be achieved by installing a network packet capture tool on the terminal or by remotely capturing packets using professional network analysis tools. Then, the captured data packets are parsed to extract key information such as header information, data content, source address, and destination address. Finally, in-depth analysis of the data packets is performed to identify hidden abnormal data packets, malicious traffic, and suspicious interactions. For example, by examining characteristics such as the packet signature, encryption method, and data length, it is possible to identify malicious activities such as forgery, tampering, or injection attacks.

[0101] In some implementations, analyzing an application's behavior regarding system environment variables and the file system includes: monitoring the application's access to and modification of system environment variables during runtime. This can be achieved by setting system hooks or access control lists to record all application operations on system environment variables. Monitoring the application's read and write behavior to the file system, including file creation, deletion, modification, and access. These behaviors can be captured using file system monitoring tools or logging functions. The captured changes are then analyzed to determine their legality or potential security risks. For example, if an application modifies critical system configuration files or deletes user data without user authorization, it may be considered malicious behavior.

[0102] In some implementations, analyzing application behavior at the kernel level includes using kernel debuggers or performance analysis tools to monitor application behavior at the kernel level. This includes the application's usage of system resources, calls to kernel modules, and execution of system calls. Deep analysis of the captured kernel behavior is then performed to identify any abnormal or malicious activity. For example, if an application frequently makes system calls to obtain sensitive information or perform illegal operations, this may be considered malicious behavior at the kernel level.

[0103] For example, suppose there is an application called "Financial Assistant". During security testing, the following steps were taken to analyze its task execution data: By capturing all data packets generated by the application during data transmission, one packet was found to have a forged signature and was identified as malicious traffic. By monitoring the application's modifications to system environment variables and the file system, it was found that the application modified system configuration files without user authorization, which was identified as a potential security risk. By monitoring the application's behavior at the kernel level using a kernel debugger, it was found that the application frequently made system calls to obtain sensitive user information, which was identified as malicious behavior at the kernel level. Based on the above analysis results, the "Financial Assistant" application was deemed to have a high risk level.

[0104] Therefore, by comprehensively analyzing application behavior in areas such as data transfer, system environment variable and file system modifications, and kernel-level behavior, potential security threats can be detected and prevented in a timely manner, improving application security. Monitoring and analyzing application behavior helps to promptly identify and fix problems that may lead to system crashes or data corruption, thereby enhancing system stability.

[0105] In some embodiments, during the dynamic monitoring and analysis process, the risk detection method further includes: generating a network request list containing all captured network requests based on task execution data; and in response to receiving a modification operation on target network data in the network request list, reconstructing the network request based on the modification operation and displaying the modified network data details.

[0106] In this embodiment of the disclosure, the network request list records a detailed list of all network requests generated by the application.

[0107] In this embodiment of the disclosure, the modification operation is an action to modify the target network data in the network request list, such as modifying request parameters, request headers, request bodies, etc.

[0108] In some implementations, when analyzing task execution data, all network requests generated by the application are first captured. This can be achieved by installing a network monitoring tool on the terminal or using a proxy server. The captured network requests are then compiled into a network request list, which contains detailed information for each request, such as the request Uniform Resource Locator (URL), request method, request headers, and request body.

[0109] In some specific implementations, when a modification operation is received targeting network data in the network request list, the network request is reconstructed based on the specific content of the modification operation (such as modifying request parameters, request headers, request body, etc.). The modification operation can be triggered through a user interface (such as button clicks, text input, etc.) or executed by an automated script or tool.

[0110] In some implementations, after reconstructing the network request, the modified network data details are displayed.

[0111] For example, suppose there's an application called "Online Shopping App." During a security check, the following steps were taken to analyze and modify network requests: All network requests generated by the application were captured, and a list of network requests was generated. A request for the transmission of sensitive data was found in the network request list, and it was decided to modify it. The network request was reconstructed by modifying the sensitive data value in the request parameters. Details of the modified network data, including a list of call chains, were displayed. In the call chain list, an anomalous function call was found that invoked an external Application Programming Interface (API) and transmitted sensitive data. By examining the complete call process of the target call chain, the cause of the sensitive data leak was determined, and it was remedied.

[0112] In this way, by capturing and analyzing network requests, potential malicious network activities, such as data breaches and man-in-the-middle attacks, can be detected and prevented in a timely manner. Furthermore, by modifying and reconstructing network requests, different attack scenarios can be simulated to test the application's defense capabilities.

[0113] In some embodiments, displaying modified network data details includes: outputting a list of call chains that can be viewed; and, in response to receiving a request to view a target call chain in the call chain list, outputting the complete call process of the target call chain.

[0114] In this embodiment of the disclosure, the call chain records the sequence of all function or method calls from the time the application initiates a network request until the request is finally completed.

[0115] In this embodiment of the disclosure, the call chain list contains a list of multiple call chains, each of which records a complete path from when the application initiates a network request to when the request is completed.

[0116] In this embodiment of the disclosure, the complete call process includes detailed information about each call point in the target call chain, including function name, parameters, return value, etc., to demonstrate the complete execution process of the call chain.

[0117] In some implementations, when a request to view a target call chain in the call chain list is received, the complete call process of the target call chain is output. This can be achieved by displaying the hierarchical structure of the call chain and detailed information about each call point (such as function name, parameters, return value, etc.).

[0118] Thus, by providing an intuitive user interface and detailed call chain information, developers can more easily understand and analyze network request behavior, thereby improving the user experience. Displaying modified network data details and call chain lists helps developers quickly locate and fix network request-related issues. This can significantly improve debugging efficiency and shorten problem-solving time. By analyzing and modifying network requests, and displaying modified network data details and call chain information, application security, debugging capabilities, and user experience can be greatly improved.

[0119] Figure 2 A framework diagram of a risk detection tool is shown, such as... Figure 2 As shown, this risk detection tool comprises a user layer, a business function layer, a core capability layer, and an underlying service layer. The user layer supports Android application package (APK) files, Android library project binary archive (AAR) files, and files in preset compressed file formats. In practice, users can directly drag the APK file, AAR file, or core code of the application to be detected into the preset detection box. The business function layer includes functions such as decompilation, APK unpacking, code viewing, static search, call chain tracing, call chain analysis, dynamic search, hooking classes / methods, artificial intelligence (AI) analysis, network interface packet capture, network interface analysis, network interface call chain tracing, and network interface replay. In practice, users can view and select specific business functions individually, or they can have the system automatically execute all functions in the business function layer without individual selection. The core capability layer includes capabilities such as decompilation, unpacking, dynamic debugging, and network packet capture. The underlying service layer includes services such as decompilation services, unpacking services for various vendors, hooking services, and network services. It should be noted that... Figure 2 The architecture diagram of the risk detection tool shown is merely illustrative. In actual applications, the file types supported by the user layer can be adjusted according to requirements, business functions can be added or removed, core functions can be added or removed, and underlying services can be added or removed. These details will not be elaborated here.

[0120] Figure 3 An architecture diagram of the dynamic search process is shown, such as... Figure 3As shown in the diagram, the architecture includes a user operation layer, a functional module layer, and a foundation capability layer. The user operation layer supports the following operations: automatically generating hook code for specified classes and methods; selecting classes and methods for hooking; searching data generated during app execution and associating it with specific methods; and searching for page data and network data. The functional modules support the following functions: generating hook code; executing hooks for specified classes and methods; data search; and AI analysis. The foundation capabilities include hooking key system APIs; dynamic library hooking; page data monitoring; and network data monitoring. It should be noted that... Figure 3 The architecture diagram shown is merely illustrative. In actual applications, the user operation layer can be adjusted to support various functions and their corresponding functional modules and base capabilities as needed, which will not be elaborated here.

[0121] Figure 4 This illustrates the call chain tracing and network request analysis process, such as... Figure 4 As shown, the process includes:

[0122] S401: Network packet capture;

[0123] Risk detection tools capture data packets transmitted over the network.

[0124] S402: Packet capture list, select any network request;

[0125] After successfully capturing network packets, the risk detection tool generates a list containing all captured network requests. Users can then select one or more network requests of interest from this list for further analysis.

[0126] S403: Display network data details;

[0127] After a user selects a network request, the risk detection tool will display detailed information about the request, including but not limited to request headers, response headers, request body, response body, and transmitted metadata.

[0128] S404: Do you want to modify network data? If yes, proceed to S405; otherwise, proceed to S408.

[0129] When analyzing network data, users may need to simulate certain modifications to test the response of applications or services. This step asks the user if they need to modify the captured network data.

[0130] S405: Should the network request be replayed? If no, proceed to S406; if yes, proceed to S407.

[0131] If the user chooses to modify the network data, then the next step is to decide whether to resend (or "replay") the modified network request.

[0132] S406: Other operations;

[0133] If a user chooses not to replay the network request, it means that the user may want to perform other operations, such as saving the modified data, generating a report, or performing further static analysis.

[0134] S407: Request the network data to be displayed again based on the modified content, and then execute S408;

[0135] If the user chooses to replay the network request, the risk detection tool will reconstruct and resend the request based on the user's modifications, and then display the modified network data details.

[0136] S408: Trace method call;

[0137] This step allows users to trace and view the methods that triggered the network requests, and to understand the backend code or method call chain that triggered these requests.

[0138] S409: View the call chain;

[0139] Users can choose to view the entire call chain to understand all the steps and processes from the initial method call to the final network request.

[0140] S410: View any method in the call chain;

[0141] This step allows users to select and view any method in the call chain, enabling a more in-depth analysis of a specific method or node.

[0142] S411: AI analyzes the selected method.

[0143] To provide deeper analysis and insights, risk detection tools can integrate AI capabilities to automatically analyze user-selected methods. AI can provide information about the method's behavior, performance, potential problems, and interactions with other methods.

[0144] Thus, risk detection tools, starting with network packet capture, provide users with a comprehensive and in-depth network data analysis and debugging environment through detailed data display and modification, and then through call chain tracing and AI analysis.

[0145] In some embodiments, generating risk detection results based on static and dynamic detection results includes: inputting the static and dynamic detection results into a pre-trained risk assessment model to obtain a risk detection report output by the risk assessment model, wherein the risk assessment model is used to perform a comprehensive risk assessment based on multi-dimensional static and multi-dimensional dynamic detection results to generate risk detection results, which include a risk score and a risk detection report.

[0146] In this embodiment of the disclosure, the static detection result is obtained by scanning the source code using a static code analysis tool, including information on code quality, potential defects, security vulnerabilities, etc.

[0147] In this embodiment of the disclosure, the dynamic detection results are behavioral data captured by dynamic testing tools or actual running applications, including performance data, anomaly data, user interaction data, etc.

[0148] In this embodiment of the disclosure, the risk assessment model is a model used to comprehensively process and analyze static and dynamic detection results to evaluate the security and stability of an application. This model can output a risk score and a risk detection report.

[0149] In this embodiment of the disclosure, the risk score is a quantitative indicator calculated by the risk assessment model based on static and dynamic detection results, which is used to reflect the security risk and stability level of the application.

[0150] In this embodiment of the disclosure, the risk detection report is a detailed report generated by the risk assessment model, which includes a detailed description of the risk, its possible impact, and suggested remedial measures.

[0151] In some specific implementations, professional static code analysis tools are used to scan the source code to obtain static detection results regarding code quality, potential defects, security vulnerabilities, etc. Dynamic detection results are obtained by capturing runtime behavioral data of the application, including performance data, anomaly data, and user interaction data, through dynamic testing tools or by actually running the application.

[0152] In some specific implementations, a suitable risk assessment model is selected or constructed based on the assessment objectives and business needs. This model should be capable of processing multi-dimensional static and dynamic detection results and outputting risk scores and risk detection reports. Historical data and expert knowledge are used to train the risk assessment model, enabling it to accurately assess the risk level reflected by static and dynamic detection results.

[0153] In some implementations, collected static and dynamic detection results are input into a pre-trained risk assessment model. The model comprehensively processes and analyzes the input results, calculating a risk score based on preset assessment criteria and algorithms. Simultaneously, the model generates a risk detection report containing a detailed description of the risk, its potential impact, and recommended remedial measures. The development team or security experts interpret the generated risk report to understand the risk points and recommended actions. Based on the risk score and the recommendations in the report, corresponding remediation plans and security measures are developed to reduce or eliminate potential risks.

[0154] For example, suppose there's an application called "Financial App," and the development team decides to conduct a risk assessment. The team drags the application to a risk detection webpage on a PC. This webpage first scans the source code using static code analysis tools, obtaining static detection results regarding code quality, potential defects, etc. Then, it captures the application's runtime behavior data using dynamic testing tools, obtaining dynamic detection results. Next, the static and dynamic detection results are input into a pre-trained risk assessment model, resulting in a risk score and a risk detection report. The report indicates that the application has a high-risk SQL injection vulnerability and provides detailed remediation recommendations. Based on the report's recommendations, the development team fixes the application and re-assesses the risk, ensuring the application's security.

[0155] Thus, by combining static and dynamic detection results, the risk assessment model can more comprehensively reflect the security and stability of the application, improving the accuracy of the assessment. Using a pre-trained risk assessment model can significantly shorten assessment time and improve efficiency. The detailed information and recommended actions in the risk detection report can provide targeted guidance to the development team, helping them quickly locate and fix potential security vulnerabilities and defects. Through continuous risk assessment and remediation efforts, the application's security capabilities can be continuously improved, reducing security risks.

[0156] It should be understood that Figures 2 to 4 The schematic diagrams shown are merely illustrative and not limiting, and are scalable; those skilled in the art can use them as a basis. Figures 2 to 4 Even with various obvious changes and / or substitutions to the examples, the resulting technical solutions still fall within the scope of this disclosure.

[0157] This disclosure provides a risk detection device for an application, such as... Figure 5 As shown, the risk detection device may include: a receiving module 501 for receiving the application to be detected; a static detection module 502 for performing static code detection on the application to obtain static detection results; a dynamic detection module 503 for performing dynamic behavior monitoring on the application to obtain dynamic detection results; and a first generation module 504 for generating risk detection results based on the static detection results and the dynamic detection results.

[0158] In some embodiments, the risk detection result includes a risk score and a risk detection report; the risk detection device further includes: a first output module ( Figure 5 (Not shown in the image), used to output the application's risk score in response to receiving a risk score query request for the application; second output module ( Figure 5 (Not shown in the image), used to output the application's risk detection report in response to receiving a request for a risk detection report query for the application.

[0159] In some embodiments, the risk detection device further includes: a casing detection module ( Figure 5 (Not shown in the image), used to detect whether an application is protected by a packer before performing dynamic behavior monitoring or static code analysis; unpacking module ( Figure 5 (Not shown in the image) is used to unpack the application when it is detected that the application is protected by a packer, in order to extract the original file cluster of the application, which is used for static or dynamic analysis.

[0160] In some embodiments, the static detection module 502 is configured to: unpack the compressed package of the application to obtain multiple component files included in the application; analyze the multiple component files to obtain the static detection results of the application; wherein the static detection results are the first type of security vulnerability detection results obtained by analyzing without running the application.

[0161] In some embodiments, the dynamic detection module 503 is configured to: send the application to a terminal in a preset detection environment for the terminal to install the application; in response to receiving a test instruction for a target task, forward the test instruction to the terminal with the application installed, so as to instruct the terminal to execute a test task for the application; analyze the task execution data returned by the terminal, and generate a dynamic detection result, which includes a second type of security vulnerability detection result that occurs when the application is running.

[0162] In some embodiments, the dynamic detection module 503 is used to: analyze various data packets generated by the application during data transmission to identify hidden abnormal data packets, malicious traffic, and suspicious interactive behaviors; analyze the application's modification behavior of system environment variables and file system; and analyze the application's behavior at the kernel level.

[0163] In some embodiments, the risk detection device further includes: a second generation module ( Figure 5 (Not shown in the image), used to generate a list of network requests containing all captured network requests based on task execution data; Refactoring module ( Figure 5 (Not shown in the image), used to reconstruct the network request based on the modification operation received for the target network data in the network request list; the third output module ( Figure 5 (Not shown in the image) is used to display the modified network data details.

[0164] In some embodiments, the third output module ( Figure 5(Not shown in the image), used to: output a list of call chains that can be viewed; and in response to receiving a request to view a target call chain in the call chain list, output the complete call process of the target call chain.

[0165] In some embodiments, the first generation module 504 is used to: input static detection results and dynamic detection results into a pre-trained risk assessment model to obtain a risk detection report output by the risk assessment model, wherein the risk assessment model is used to perform a comprehensive risk assessment based on multi-dimensional static detection results and multi-dimensional dynamic detection results, and generate a risk score and a risk detection report.

[0166] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0167] The application risk detection device of this disclosure can solve the problems of complex operation, low efficiency and inaccurate judgment in the existing software risk analysis process, and improve the efficiency and accuracy of risk analysis.

[0168] This disclosure provides a schematic diagram of a risk detection scenario, such as... Figure 6 As shown.

[0169] As previously described, the testing methods provided in this disclosure are applied to electronic devices. Electronic devices are intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0170] Specifically, the electronic device may perform the following operations:

[0171] Receive the application to be tested;

[0172] Perform static code analysis on the application and obtain the static analysis results;

[0173] Dynamic behavior monitoring of the application is performed to obtain dynamic detection results;

[0174] Risk scores and risk detection reports are generated based on static and dynamic detection results.

[0175] In response to receiving a risk score query request for the application, output the application's risk score;

[0176] In response to receiving a request for a risk detection report of the application, output the risk detection report of the application.

[0177] It should be understood that Figure 6 The scene diagrams shown are merely illustrative and not restrictive; those skilled in the art can interpret them based on... Figure 6 Even with various obvious changes and / or substitutions to the examples, the resulting technical solutions still fall within the scope of this disclosure.

[0178] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0179] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0180] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0181] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from storage unit 708 into random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. An input / output (I / O) interface 705 is also connected to bus 704.

[0182] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0183] The computing unit 701 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, CPUs, graphics processing units (GPUs), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processors, controllers, microcontrollers, etc. The computing unit 701 performs the various methods and processes described above, such as application risk detection methods. For example, in some embodiments, the application risk detection method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the application risk detection method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform a risk detection method for an application by any other suitable means (e.g., by means of firmware).

[0184] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0185] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0186] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM), flash memory, optical fiber, compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0187] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0188] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0189] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0190] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0191] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A risk detection method for an application, comprising: Receive the application to be tested; Static code analysis was performed on the application to obtain the static analysis results; Dynamic behavior monitoring is performed on the application to obtain dynamic detection results; The dynamic detection results correspond one-to-one with multiple test scenarios, and each test scenario corresponds to a specific usage environment or condition. Risk detection results are generated based on the static detection results and the dynamic detection results; The dynamic behavior monitoring of the application to obtain dynamic detection results includes: The application is sent to a terminal in a preset detection environment so that the terminal can install the application. In response to receiving a test instruction for a target task, the test instruction is forwarded to the terminal on which the application is installed, so as to instruct the terminal to perform a test task for the application; The task execution data returned by the terminal is analyzed to generate dynamic detection results, which include the detection results of the second type of security risks that occur when the application is running. Generate a network request list containing all captured network requests based on the task execution data; In response to receiving a modification operation for target network data in the network request list, the network request is reconstructed according to the modification operation, and the modified network data details are displayed.

2. The method according to claim 1, wherein, The risk detection results include a risk score and a risk detection report, and the method further includes: In response to receiving a risk score query request for the application, the risk score of the application is output; and In response to receiving a request for a risk detection report of the application, the risk detection report of the application is output.

3. The method according to claim 1, wherein, Before performing dynamic behavior monitoring or static code analysis, the following is also included: Detect whether the application is protected by a protective shell; If the application is detected to be protected by a packer, the application is unpacked to extract the original file cluster, which is used for static or dynamic analysis.

4. The method according to claim 1 or 3, wherein, The static code analysis of the application to obtain static analysis results includes: The compressed package of the application is unpacked to obtain multiple component files included in the application; The static detection results of the application are obtained by analyzing the multiple component files; wherein the static detection results are the first type of security vulnerability detection results obtained by analyzing without running the application.

5. The method according to claim 1, wherein, The analysis of the task execution data returned by the terminal includes at least one of the following: Analyze the various data packets generated by the application during data transmission to identify hidden abnormal data packets, malicious traffic, and suspicious interactive behaviors; Analyze the application's behavior regarding modifications to system environment variables and the file system; Analyze the behavior of the application at the kernel level.

6. The method according to claim 1, wherein, The description of displaying the modified network data details includes: The output includes a list of call chains that can be viewed; In response to receiving a view request for a target call chain in the call chain list, the complete call process of the target call chain is output.

7. The method according to claim 1, wherein, The process of generating risk detection results based on the static detection results and the dynamic detection results includes: The static detection results and the dynamic detection results are input into a pre-trained risk assessment model to obtain a risk detection report output by the risk assessment model. The risk assessment model is used to perform a comprehensive risk assessment based on the multi-dimensional static detection results and the multi-dimensional dynamic detection results to generate the risk detection results.

8. A risk detection device for an application, comprising: The receiving module is used to receive the application to be detected; The static code detection module is used to perform static code detection on the application and obtain static code detection results. The dynamic detection module is used to monitor the dynamic behavior of the application and obtain dynamic detection results; The dynamic detection results correspond one-to-one with multiple test scenarios, and each test scenario corresponds to a specific usage environment or condition. The first generation module is used to generate risk detection results based on the static detection results and the dynamic detection results; The dynamic detection module is used for: The application is sent to a terminal in a preset detection environment so that the terminal can install the application. In response to receiving a test instruction for a target task, the test instruction is forwarded to the terminal on which the application is installed, so as to instruct the terminal to perform a test task for the application; The task execution data returned by the terminal is analyzed to generate dynamic detection results, which include the detection results of the second type of security risks that occur when the application is running. The second generation module is used to generate a network request list containing all captured network requests based on the task execution data. The reconstruction module is configured to reconstruct the network request based on the modification operation received for the target network data in the network request list. The third output module is used to display the modified network data details.

9. The apparatus according to claim 8, wherein, The risk detection results include a risk score and a risk detection report, and the device further includes: A first output module is configured to output the risk score of the application in response to receiving a risk score query request for the application; and The second output module is used to output the risk detection report of the application in response to receiving a risk detection report query request for the application.

10. The apparatus according to claim 8, further comprising: The packer detection module is used to detect whether the application is protected by a packer before performing dynamic behavior monitoring or static code detection; The unpacking module is used to unpack the application when it is detected that the application is protected by a packer, so as to extract the original file cluster of the application, which is used for static or dynamic analysis.

11. The apparatus according to claim 8 or 10, wherein, The static detection module is used for: The compressed package of the application is unpacked to obtain multiple component files included in the application; The static detection results of the application are obtained by analyzing the multiple component files; wherein the static detection results are the first type of security vulnerability detection results obtained by analyzing without running the application.

12. The apparatus according to claim 8, wherein, The dynamic detection module is also used for: Analyze the various data packets generated by the application during data transmission to identify hidden abnormal data packets, malicious traffic, and suspicious interactive behaviors; Analyze the application's behavior regarding modifications to system environment variables and the file system; Analyze the behavior of the application at the kernel level.

13. The apparatus according to claim 8, wherein, The third output module is also used for: The output includes a list of call chains that can be viewed; In response to receiving a view request for a target call chain in the call chain list, the complete call process of the target call chain is output.

14. The apparatus according to claim 8, wherein, The first generation module is further configured to: The static detection results and the dynamic detection results are input into a pre-trained risk assessment model to obtain a risk detection report output by the risk assessment model. The risk assessment model is used to perform a comprehensive risk assessment based on the multi-dimensional static detection results and the multi-dimensional dynamic detection results to generate the risk detection results.

15. An electronic device comprising: At least one processor; as well as A memory that is communicatively connected to at least one processor; wherein, The memory stores instructions that can be executed by at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

16. A non-transitory computer-readable storage medium storing computer instructions, wherein, Computer instructions are used to cause a computer to perform the method according to any one of claims 1-7.

17. A computer program product comprising a computer program stored on a storage medium, wherein the computer program, when executed by a processor, implements the method according to any one of claims 1-7.

Images