White list generation method and related equipment

Abstract

The embodiment of the invention discloses a white list generation method and device, a storage medium and electronic equipment, and relates to the technical field of computers. In the embodiment of the specification, in order to obtain a white list for only allowing some calling modes to call the application, an application data packet which represents the complete application compiling process and is packaged is decompiled to obtain a multi-line code, and the multi-line code corresponds to a plurality of calling behaviors; the multiple calling behaviors are further scanned to conduct credible behavior matching on all the calling behaviors, at least one target calling behavior matched through the credible behaviors in the multiple calling behaviors is extracted, at least one white list is finally generated, and all the white lists comprise at least one target calling behavior.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a whitelist generation method and related devices. Background Art

[0002] As enterprises deepen their governance and control of application security risks, they will gradually switch the control of application calling behavior from blacklist mode to whitelist mode, thereby greatly reducing the possibility of attacks being bypassed.

[0003] However, the whitelist model inevitably increases operational workload. To prevent uninterrupted application calls, a whitelist must be generated before the application is officially launched. This whitelist should include as many trusted behaviors as possible for the application. This way, when the application is officially used, only the trusted behaviors on the whitelist are allowed.

[0004] However, the existing whitelist generation method is to enable observation mode for the application, collect call behaviors over a period of time, determine whether the call behaviors are trustworthy, and then configure them into the whitelist. This whitelist generation method has the disadvantages of high omission rate and large workload. Summary of the Invention

[0005] The embodiments of this specification provide a whitelist generation method and related devices that can solve the above problems. The technical solution is as follows:

[0006] In a first aspect, an embodiment of this specification provides a whitelist generation method, the method comprising:

[0007] Obtaining an application data packet representing an application compilation process, and decompiling the application data packet to obtain multiple lines of code;

[0008] Scanning multiple call behaviors corresponding to the multiple lines of code, and extracting target call behaviors matched by trusted behaviors from the multiple call behaviors; wherein the number of the target call behaviors is at least one;

[0009] A whitelist is generated according to at least one of the target calling behaviors; wherein the whitelist is used to only allow the application to be called according to a calling method corresponding to the target calling behavior.

[0010] In a second aspect, an embodiment of this specification provides a whitelist generation device, the device comprising:

[0011] A data acquisition module, configured to acquire an application data packet representing an application compilation process, and decompile the application data packet to obtain multiple lines of code;

[0012] a trusted matching module, configured to scan a plurality of call behaviors corresponding to the plurality of lines of code and extract a target call behavior matched by a trusted behavior from the plurality of call behaviors; wherein the number of the target call behaviors is at least one;

[0013] A list generation module is used to generate a whitelist according to at least one of the target calling behaviors; wherein the whitelist is used to only allow the application to be called according to the calling method corresponding to the target calling behavior.

[0014] In a third aspect, an embodiment of this specification provides a computer storage medium, wherein the computer storage medium stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the above-mentioned method steps.

[0015] In a fourth aspect, an embodiment of this specification provides a computer program product, wherein the computer program product stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the above-mentioned method steps.

[0016] In a fifth aspect, an embodiment of this specification provides an electronic device, which may include: a processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the above-mentioned method steps.

[0017] The beneficial effects of the technical solutions provided by some embodiments of this specification include at least:

[0018] In an embodiment of this specification, to obtain a whitelist that only allows certain calling methods to call an application, a packaged application data packet representing the complete application compilation process is decompiled to obtain multiple lines of code, each of which corresponds to multiple calling behaviors. By obtaining multiple calling behaviors from an application data packet representing the complete compilation process, this embodiment of this specification can better cover various calling methods for the application, such as covering the calling logic corresponding to dependent packages introduced during the compilation process. This greatly reduces the possibility that the whitelist will miss certain calling behaviors and improves the reliability of the whitelist.

[0019] Furthermore, multiple call behaviors are scanned to perform trusted behavior matching on each call behavior, and at least one target call behavior that passes the trusted behavior matching is extracted from the multiple call behaviors. In other words, the target call behavior can be understood as a call behavior that meets the trusted behavior criteria among the call behaviors.

[0020] Generate at least one whitelist, each of which includes at least one target call behavior. Compared to collecting target investigation behaviors and building a whitelist by observing a large number of call behaviors against the application after the application is released, the embodiments of this specification extract multiple call behaviors through multiple lines of code in the application data packet, and scan and match the target investigation behaviors as trusted behaviors. This not only effectively avoids the problem of missing target call behaviors caused by the observation method and reduces the high labor costs associated with the observation method, but also the whitelist generated based on the embodiments of this specification is highly accurate and can effectively intercept non-target call behaviors against the application in actual use, protecting the security of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0022] Figure 1 This is a schematic diagram of the architecture of a whitelist generation method provided in an embodiment of this specification;

[0023] Figure 2 This is a flowchart of a whitelist generation method provided in an embodiment of this specification;

[0024] Figure 3 This is a flowchart of a whitelist generation method provided in an embodiment of this specification;

[0025] Figure 4 This is a schematic diagram of a process for obtaining a whitelist provided in an embodiment of this specification;

[0026] Figure 5 This is a flowchart of a method for generating a whitelist provided in an embodiment of this specification;

[0027] Figure 6 This is a flowchart of obtaining a target calling behavior provided by an embodiment of this specification;

[0028] Figure 7 This is a flowchart of a whitelist generation method provided in an embodiment of this specification;

[0029] Figure 8 This is a schematic diagram of a multi-system interaction provided by an embodiment of this specification;

[0030] Figure 9 This is a schematic diagram of the structure of a whitelist generation device provided in an embodiment of this specification;

[0031] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0032] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this specification.

[0033] In the description of this specification, it should be understood that the terms "first", "second", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units inherent to these processes, methods, products or devices. For those of ordinary skill in the art, the specific meanings of the above terms in this specification can be understood according to the specific circumstances. In addition, in the description of this specification, unless otherwise specified, "multiple" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.

[0034] The present specification is described in detail below with reference to specific embodiments.

[0035] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, storage, and display, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the features, information, and data involved in this specification are all obtained with full authorization.

[0036] like Figure 1 As shown, Figure 1 This is a flowchart of a whitelist generation method provided in an embodiment of this specification. Figure 1The system includes at least a server 101 for executing a whitelist generation method, and also includes a plurality of electronic devices for uploading application data packets or calling requests for a certain application. The plurality of electronic devices include at least an electronic device 1021, an electronic device 1022, and an electronic device 1023. It is understood that Figure 1 The number of servers and electronic devices shown in the figure is for illustration only and is not limited in this embodiment of the present specification.

[0037] The above-mentioned server 101 can be a separate server device, such as: a rack-mounted, blade, tower, or cabinet-mounted server device, or a hardware device with strong computing power such as a workstation or a mainframe computer; it can also be a server cluster composed of multiple servers. The servers in the service cluster can be composed in a symmetrical manner, wherein each server has equivalent functions and status in the transaction link, and each server can provide services to the outside world independently. Providing services independently can be understood as not requiring the assistance of other servers.

[0038] For example, the server may be multiple physical servers that are independent in hardware. Alternatively, the server may be multiple virtual servers that are deployed in the same hardware resource pool. Virtual server deployment methods include, but are not limited to, VMware, Virtual Box, and Virtual PC.

[0039] It is understood that the server 101 also has other service capabilities and functions to complete the tasks in the following embodiments. For example, the server 101 also provides portal services, resource management services, and CI / CD services.

[0040] Electronic devices include, but are not limited to, wearable devices, handheld devices, personal computers, tablets, in-vehicle devices, smartphones, computing devices, or other processing devices connected to a wireless modem. Electronic devices may be referred to by different names in different networks, such as user equipment, access terminals, subscriber units, subscriber stations, mobile stations, mobile stations, remote stations, remote terminals, mobile devices, user terminals, terminals, wireless communication devices, user agents or user devices, cellular phones, cordless phones, personal digital assistants (PDAs), and electronic devices in 5G networks or future evolution networks.

[0041] In the embodiments of the present specification, electronic devices such as electronic device 1021, electronic device 1022, and electronic device 1023 may also be equipped with a display device. The display device may be any device capable of realizing a display function, for example, a cathode ray tube display (CR), a light-emitting diode display (LED), an electronic ink screen, a liquid crystal display (LCD), a plasma display panel (PDP), etc. For example, a user may use the display device on electronic device 1021 to send a call request for a certain application to server 101. The call request corresponds to a certain call behavior. In other words, the user requests to call the application using the call method corresponding to the call behavior.

[0042] Multiple electronic devices and multiple servers can communicate with each other through communication links established by a communication protocol, for example: wherein the network can be a wireless network or a wired network, the wireless network includes but is not limited to a cellular network, a wireless local area network, an infrared network or a Bluetooth network, and the wired network includes but is not limited to an Ethernet, a universal serial bus (USB) or a controller area network. In one or more embodiments of the specification, technologies and / or formats including Hypertext Markup Language (HTML), Extensible Markup Language (XML), etc. are used to represent data (such as a target compressed package) exchanged through the network. In addition, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), Internet Protocol Security (IPsec), etc. can also be used to encrypt all or some links. In other embodiments, customized and / or dedicated data communication technologies can also be used to replace or supplement the above-mentioned data communication technologies.

[0043] In one embodiment, Figure 2 The figure below is a flow chart of a whitelist generation method provided in an embodiment of this specification. This method can be implemented by a computer program and can be run on a whitelist generation device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone tool application.

[0044] Specifically, the whitelist generation method includes:

[0045] S102: Obtain an application data packet representing an application compilation process, and decompile the application data packet to obtain multiple lines of code.

[0046] The application compilation process describes the entire process from source code to executable files. This process typically includes the following steps: preprocessing, which handles macro definitions and conditional compilation in the source code; compilation, which converts the source code into assembly code or intermediate code; assembly, which converts the assembly code into machine code; and linking, which combines multiple object files and library files to generate the final executable file.

[0047] An application data package can be understood as a packaged unit that contains information such as the application's executable file. This data package is the final product of the compilation process and can be run directly on the target platform or syntax environment. For example, in mobile applications, common application data packages include APK (Android apps) and IPA (iOS apps). Desktop applications also have similar data packages, such as exe files or dmg files.

[0048] Decompiling an application data package can be understood as the process of converting a compiled binary file back into high-level language code. The decompilation method can be to use a decompilation tool corresponding to the format of the application data package. For example, for Android applications (.apk files), common decompilation tools are JADX and APKTool, which can be used to restore the original multiple lines of Java code. In other embodiments, other decompilation methods are also included, and this specification does not limit this.

[0049] S104: Scan multiple call behaviors corresponding to multiple lines of code, and extract target call behaviors matched by trusted behaviors from the multiple call behaviors.

[0050] First, determine the multiple call behaviors corresponding to multiple lines of code. Call behaviors can be understood as the actual execution or triggering of methods, functions, system services, etc. within multiple lines of code. Analyzing which call behaviors correspond to multiple lines of code can be a combination of static and dynamic analysis. Specifically, static analysis refers to analyzing the source code to identify the relationships between method and function calls and infer the application's call path; dynamic analysis refers to analyzing the application's runtime behavior and tracking method calls by executing the application. Call behavior is typically obtained through debugging tools, logging, or code injection.

[0051] Scan multiple call behaviors corresponding to multiple lines of code and detect whether each call behavior matches a preset trusted behavior, or whether each call behavior can be matched by a trusted behavior. If a call behavior matches a trusted behavior, the call behavior is considered trusted. Further, extract other call behaviors that match the trusted behavior from the multiple call behaviors as target call behaviors, with at least one target call behavior.

[0052] The trusted behavior used to match the calling behavior can be a behavior template, a matching policy, or a matching condition, that is, a pattern or specification used to describe an application, system, or operation, defining the expected and compliant behavior.

[0053] A calling behavior may include the following items: behavior type (including method calls, state changes, network requests, file reading and writing, system resource usage, etc.), parameter requirements (parameters passed in the behavior can be key fields, such as user input, network request parameters, etc.), return value and side effects (the return value of the method and its impact on the system state, such as whether to generate logs, file output or database updates), calling sequence (some behaviors depend on a specific calling sequence. For example, the authentication process must first verify the user's identity and then allow access to resources), etc. Therefore, based on the content included in the calling behavior, the multiple entries included in the trusted behavior and the specific content corresponding to each entry are defined. Based on the preset trusted behavior, multiple calling behaviors obtained from the application data packet are scanned and matched, and other calling behaviors matched by the trusted behavior in the multiple calling behaviors are extracted as target calling behaviors.

[0054] like Figure 3 As shown, Figure 3 The whitelist generation method of the embodiment of the present invention is a flowchart of obtaining an application data packet 201 of an application, decompiling the application data packet 201 to obtain multiple lines of code, and analyzing the multiple lines of code to obtain multiple calling behaviors. Figure 3 The multiple call behaviors shown include at least call behavior 2021, call behavior 2022, call behavior 2023, call behavior 2024, and call behavior 2025. The multiple call behaviors are scanned to determine that the target call behaviors matched by the trusted behavior in the multiple call behaviors are call behavior 2022 and call behavior 2024.

[0055] S106: Generate a whitelist according to at least one target calling behavior.

[0056] A whitelist is used to restrict application invocations to the target call behavior. A specific application may have one or more whitelists. For example, a whitelist may contain all target call behaviors associated with that application. Another example might include a whitelist for each target call behavior associated with that application.

[0057] like Figure 3 As shown, whitelist 2031 is determined based on call behavior 2022 as the target call behavior, and whitelist 2032 is determined based on call behavior 2024 of the target call behavior. For example, if the application is a photography application, call behavior 222 is to call the camera when shooting, and call behavior 223 is to store the photo in a preset location when storing the photo.

[0058] Based on the target call methods included in the whitelist, users are only allowed to call the application using the call method corresponding to the target call behavior. In other words, users are only allowed to initiate call requests corresponding to the target call behavior to the platform running the application. For example, if a user requests to use the microphone while shooting in a photography application, this call method is not in the whitelist 2031 and will be blocked.

[0059] In an embodiment of this specification, to obtain a whitelist that only allows certain calling methods to call an application, a packaged application data packet representing the complete application compilation process is decompiled to obtain multiple lines of code, each of which corresponds to multiple calling behaviors. By obtaining multiple calling behaviors from an application data packet representing the complete compilation process, this embodiment of this specification can better cover various calling methods for the application, such as covering the calling logic corresponding to dependent packages introduced during the compilation process. This greatly reduces the possibility that the whitelist will miss certain calling behaviors and improves the reliability of the whitelist.

[0060] Furthermore, multiple call behaviors are scanned to perform trusted behavior matching on each call behavior, and at least one target call behavior that passes the trusted behavior matching is extracted from the multiple call behaviors. In other words, the target call behavior can be understood as a call behavior that meets the trusted behavior criteria among the call behaviors.

[0061] Generate at least one whitelist, each of which includes at least one target call behavior. Compared to collecting target investigation behaviors and building a whitelist by observing a large number of call behaviors against the application after the application is released, the embodiments of this specification extract multiple call behaviors through multiple lines of code in the application data packet, and scan and match the target investigation behaviors as trusted behaviors. This not only effectively avoids the problem of missing target call behaviors caused by the observation method and reduces the high labor costs associated with the observation method, but also the whitelist generated based on the embodiments of this specification is highly accurate and can effectively intercept non-target call behaviors against the application in actual use, protecting the security of the application.

[0062] based on Figure 2-Figure 3 Please refer to the embodiment shown in Figure 4 The embodiment shown. Figure 4This is a schematic diagram of a process for obtaining a whitelist provided in an embodiment of this specification. S106 includes the following steps:

[0063] S202: Determine a call link of the target call behavior according to at least one step included in the target call behavior.

[0064] A call chain consists of at least one node corresponding to each step and the corresponding parameters of each node. Specifically, a call chain represents the interaction sequence and dependency relationships between multiple components, modules, or services to complete the target call behavior.

[0065] In a call chain, each function or method call is called a node. Each node represents a specific operation or event during execution. Node parameters include: method name (the name of the function or method being called); call type (synchronous or asynchronous); timestamp (the time the node started executing); execution status (whether the node executed successfully or threw an exception); and return value (the result returned after the node executed).

[0066] S204: Generate a whitelist corresponding to the target calling behavior according to the calling link of the target calling behavior.

[0067] The number of whitelists is at least one. Figure 3 As shown, a whitelist 2031 is determined based on the call behavior 2022 as the target call behavior, a whitelist 2032 is determined based on the call behavior 2024 as the target call behavior, and for each whitelist, the call link is stored in the form of a link graph through graph technology.

[0068] In this embodiment, the call link corresponding to the target call behavior and the nodes constituting the call link are stored to obtain a whitelist. The execution status of the entire call link can be traced through multiple nodes, and the target call behavior can be more clearly reflected through the call link.

[0069] In one embodiment, after generating a whitelist corresponding to the target calling behavior according to the calling link of the target calling behavior, the method further includes: visualizing the calling link included in the whitelist to obtain a whitelist report.

[0070] Visualization can be understood as abstracting the call chain into a graphical form that is easy to understand and analyze. Charts, graphs, flowcharts, and other forms help users intuitively view, understand, analyze, and make decisions. Specifically, the call chain is visualized to form a call chain graph, which is included in the whitelist report. The call chain graph shows the call relationships between the various functions or services involved in the target call behavior. Each node in the call chain graph represents a function or service, and each edge represents a call between functions or services. Different elements such as color, size, and shape can be used to represent different attributes.

[0071] In this embodiment, by visualizing the call links included in the whitelist to obtain a call link graph, the efficiency and accuracy of the target call behavior analysis are greatly improved.

[0072] In one embodiment, Figure 5 The figure below is a flow chart of a whitelist generation method provided in an embodiment of this specification. This method can be implemented by a computer program and can be run on a whitelist generation device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone tool application.

[0073] Specifically, the whitelist generation method includes:

[0074] S302: Obtain an application data packet representing an application compilation process, and decompile the application data packet to obtain multiple lines of code.

[0075] See the above S102, which will not be repeated here.

[0076] S304: Determine multiple calling behaviors according to the multiple lines of code.

[0077] Determine the multiple call behaviors corresponding to multiple lines of code. Call behaviors can be understood as the actual execution or triggering of methods, functions, system services, etc. within multiple lines of code. Analyzing which call behaviors correspond to multiple lines of code can be a combination of static and dynamic analysis. Specifically, static analysis refers to analyzing the source code to identify the relationship between method calls and function calls to infer the application's call path; dynamic analysis refers to analyzing the application's runtime behavior and tracking method calls by executing the application. Specifically, call behaviors are obtained through debugging tools, logging, or code injection.

[0078] S306: Scan multiple call behaviors according to the trusted behavior matching policy, and extract target call behaviors that are matched by the trusted behavior from the multiple call behaviors.

[0079] The trusted behavior matching strategy used to match call behaviors can integrate information such as matching conditions and matching steps to obtain a trusted behavior that can describe a pattern or specification of an application, system, or operation.

[0080] Specifically, the trusted behavior matching strategy includes at least two trusted behavior matches and the matching conditions required for the trusted behavior matching process. The at least two trusted behavior matches can be understood as performing a preliminary match on multiple call behaviors to obtain at least one call behavior as a matching result, and then further matching the at least one call behavior as a matching result to obtain at least one call behavior as a second matching result. The at least one call behavior from the second matching result can also be further matched until the target call behavior is obtained. Furthermore, each time multiple call behaviors are matched, at least one call behavior that meets the matching conditions is extracted based on the matching conditions corresponding to that round, and then the next matching round is entered and matched according to the matching conditions corresponding to that round.

[0081] Scan multiple call behaviors multiple times. During each matching process, each call behavior is compared with the preset matching conditions required for that round of matching. When a call behavior passes the trusted behavior match, it is marked as trusted. Furthermore, after extracting the call behaviors that pass the trusted behavior match from the multiple call behaviors at least twice, a target call behavior is obtained. There must be at least one target call behavior.

[0082] In this embodiment, multiple call behaviors are scanned through a trusted behavior matching strategy, and the trusted behavior matching strategy includes at least two trusted behavior matches and the matching conditions required for the trusted behavior matching process. Multiple rounds of screening can improve the accuracy of screening out target call behaviors from multiple call behaviors and improve the credibility of the target call behavior.

[0083] In one embodiment, multiple call behaviors and call links corresponding to the call behaviors are determined based on multiple lines of code; the call links corresponding to the multiple call behaviors are scanned according to the trusted behavior matching strategy, and the target call behaviors matched by the trusted behavior are extracted from the multiple call behaviors.

[0084] Based on the steps corresponding to the call behavior, the call chain corresponding to the call behavior can be determined. That is, the call chain includes at least one node corresponding to each step and the parameters corresponding to each node. The trusted behavior matching strategy includes the steps corresponding to the trusted behavior, the trusted behavior matching strategy also includes the call chain corresponding to the trusted behavior, and the parameters corresponding to each of the multiple nodes included in the call chain.

[0085] The trusted behavior matching strategy includes multiple call links, scans the call links corresponding to the multiple call behaviors, and matches the call links corresponding to the trusted behaviors with the call links corresponding to the call behaviors. Specifically, the multiple nodes included in each call link and the parameters corresponding to the nodes are matched, thereby extracting the target call behavior that matches the trusted behavior from the multiple call behaviors. This embodiment can improve the accuracy of screening the target call behavior from multiple call behaviors.

[0086] S308: Generate a whitelist according to at least one target calling behavior.

[0087] Refer to the above S106 and will not be repeated here.

[0088] The embodiments of this specification can better cover various calling methods for an application by obtaining multiple calling behaviors from an application data packet that represents a complete compilation process. For example, it can cover the calling logic corresponding to the dependency package introduced during the compilation process, thereby greatly reducing the possibility that the whitelist will miss certain calling behaviors and improving the reliability of the whitelist. Compared with collecting target investigation behaviors and building a whitelist by observing a large number of calling behaviors for an application after the application is released, the embodiments of this specification extract multiple calling behaviors through multiple lines of code in the application data packet, and scan and match the target investigation behaviors as trusted behaviors. This can not only effectively avoid the problem of missing target calling behaviors caused by the observation method and reduce the high labor costs brought by the observation method, but also the whitelist generated based on the embodiments of this specification has high accuracy and can effectively intercept non-target calling behaviors for the application in actual use to protect the security of the application.

[0089] based on Figure 5 Please refer to the embodiment shown in Figure 6 The embodiment shown. Figure 6 This is a flowchart of obtaining a target calling behavior provided by an embodiment of this specification. S304 includes the following steps:

[0090] S402: Obtain at least one step corresponding to each of the multiple calling behaviors.

[0091] Based on the multiple lines of code corresponding to each call behavior, determine at least one step corresponding to the call behavior. For example, in the call chain corresponding to the call behavior, each function or method call location is called a node. Each node can represent a step in the execution process.

[0092] S404: During the first trusted behavior matching, multiple steps are scanned according to the first matching condition, and at least one target step that meets the first matching condition is extracted from the multiple steps.

[0093] The trusted behavior matching strategy includes a first matching condition. It is understandable that the first matching condition in S404 and the second matching condition in S408 only represent that the matching process in S404 precedes the matching process in S408.

[0094] The first matching condition required for the first trusted behavior match is set based on certain specific steps. The trusted steps can be understood as the steps included in the trusted behavior. The trusted behavior can include one or more trusted steps, and the trusted steps can be located at any position in the process corresponding to the trusted behavior.

[0095] For example, the first matching condition includes that the trusted step is to generate log data. During the first trusted behavior match, multiple steps are scanned according to the first matching condition, and at least one step containing the content of generating log data is extracted from the multiple steps as the target step.

[0096] S406: According to at least one target step, determine a calling behavior including the target step as a calling behavior to be matched.

[0097] The number of call behaviors to be matched is at least one. The call behavior to be matched that includes the target step enters the next round of matching. The call behavior to be matched can include one or more target steps.

[0098] S408. During the second trusted behavior matching, scan at least one to-be-matched calling behavior according to the second matching condition, and extract a target calling behavior that meets the second matching condition from the at least one to-be-matched calling behavior.

[0099] The trusted behavior matching strategy includes a second matching condition. The second matching condition required for the second trusted behavior matching is set based on other contents included in the trusted behavior.

[0100] For example, during the second trusted behavior matching, the call links corresponding to at least one call behavior to be matched are scanned according to multiple preset graph query statements, and the target call behavior corresponding to the call link that meets the graph query statement in at least one call behavior to be matched is extracted.

[0101] A graph query statement can be understood as a query method for multiple call links. This query method uses a graph structure to represent the relationship between different matching call behaviors and call links. Specifically, based on the multiple nodes and node parameters included in the call link corresponding to the preset trusted behavior, multiple graph query statements are configured. The graph query statements are then used to search for a target call link that satisfies the call link corresponding to the trusted behavior, and the target call behavior corresponding to the target call link is determined based on the target call link.

[0102] For example, the second matching condition is that the trusted behavior includes calling a preset address to store log data and returning the stored results. The graph query statement requires querying the call link corresponding to the call to the preset address to store logs and returning the stored results. During the second trusted behavior matching, the call links corresponding to at least one call behavior to be matched are scanned according to the preset graph query statement, and the target call behavior corresponding to the call link that meets the graph query statement in at least one call behavior to be matched is extracted.

[0103] In one embodiment, Figure 7 The figure below is a flow chart of a whitelist generation method provided in an embodiment of this specification. This method can be implemented by a computer program and can be run on a whitelist generation device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone tool application.

[0104] Specifically, the whitelist generation method includes:

[0105] S502: Check whether the R&D status of the application is stable.

[0106] The application's R&D status is stable, which can be understood as meaning that during the application development process, the current version has reached a relatively stable stage, that is, the application functions have been completed or basically realized, the system runs stably without major problems, and can be put into use or launched normally. It can also be understood as the compilation process of the application at the current stage has been completed, and there will be no major additions or deletions to the multiple lines of code corresponding to the application.

[0107] In one embodiment, the stability of an application's development status is determined by detecting whether multiple lines of code corresponding to the application are merged from a branch to the main branch during the application compilation process. In other words, in this embodiment, the stability of an application's development status is detected by detecting the code merge status. When application code branches and the main branch are frequently merged, it usually means that developers are actively developing features and fixing bugs, and the application's development status is unstable.

[0108] In one embodiment, whether the application's development status is stable is determined by detecting whether the application is deployed to the release environment. In other words, in this embodiment, when it is detected that the application is deployed to the release environment or the grammar environment, or when it is detected that the application is online, it is determined that the application's development status is stable.

[0109] S504: When the development status of the application is stable, obtain an application data packet representing the application compilation process, and decompile the application data packet to obtain multiple lines of code.

[0110] In this embodiment, a whitelist for an application is generated only when the development status of the application is stable. The whitelist can improve the coverage of target calling behaviors allowed by the application, avoid the inconvenience caused by omissions and possible security risks for the application.

[0111] S506: Scan multiple call behaviors corresponding to multiple lines of code, and extract target call behaviors matched by trusted behaviors from the multiple call behaviors.

[0112] See the above S104, which will not be repeated here.

[0113] S508: Generate a whitelist according to at least one target calling behavior.

[0114] See the above S106, which will not be repeated here.

[0115] In one embodiment, when an application code update is detected, particularly a large-scale update, such as a major version update, the application data package corresponding to the updated application is retrieved again and a new whitelist is extracted. The new whitelist can be a modification of the existing whitelist, for example, the call links included in the new whitelist are modifications of the call links on the existing whitelist. The new whitelist can also be a whitelist generated based on newly added target call behaviors.

[0116] like Figure 8 As shown, Figure 8 This is a schematic diagram of a multi-system interaction provided in an embodiment of this specification. The execution subject of the whitelist generation method provided in an embodiment of this specification includes multiple systems, and the whitelist generation method is completed through the interaction between the multiple systems.

[0117] Specifically, the application change perception system 401 detects the code merging status of the R&D platform 402 , and the R&D platform 402 sends the packaged application data packet to the application compilation system 403 .

[0118] When the application change perception system 401 detects that a code branch is merged into the trunk, it determines that the application development is stable and sends a change perception callback to the code decompilation system 404 .

[0119] Based on the change-aware callback, code decompilation system 404 obtains the application data packet through application compilation system 403, decompiles the application data packet to obtain multiple lines of code, and obtains multiple call behaviors corresponding to the multiple lines of code. Further, code decompilation system 404 sends the multiple call behaviors to trusted behavior scanning system 405.

[0120] The trusted behavior scanning system 405 scans multiple call behaviors corresponding to multiple lines of code, extracts target call behaviors that match the trusted behavior from the multiple call behaviors, and generates at least one whitelist. The trusted behavior scanning system 405 sends the at least one whitelist to the trusted behavior operation system 406.

[0121] Trusted behavior operation system 406 reports the at least one whitelist to trusted behavior management system 407, so that trusted behavior management system 407, running in the application runtime environment, only allows the application to be called using the calling method corresponding to the target calling behavior based on the whitelist. Trusted behavior operation system 406 also stores the at least one whitelist in trusted behavior storage system 408, so that trusted behavior storage system 408 stores the at least one whitelist.

[0122] The embodiments of this specification can better cover various calling methods for an application by obtaining multiple calling behaviors from an application data packet that represents a complete compilation process. For example, it can cover the calling logic corresponding to the dependency package introduced during the compilation process, thereby greatly reducing the possibility that the whitelist will miss certain calling behaviors and improving the reliability of the whitelist. Compared with collecting target investigation behaviors and building a whitelist by observing a large number of calling behaviors for an application after the application is released, the embodiments of this specification extract multiple calling behaviors through multiple lines of code in the application data packet, and scan and match the target investigation behaviors as trusted behaviors. This can not only effectively avoid the problem of missing target calling behaviors caused by the observation method and reduce the high labor costs brought by the observation method, but also the whitelist generated based on the embodiments of this specification has high accuracy and can effectively intercept non-target calling behaviors for the application in actual use to protect the security of the application.

[0123] The following are device embodiments of this specification, which can be used to implement the method embodiments of this specification. For details not disclosed in the device embodiments of this specification, please refer to the method embodiments of this specification.

[0124] See Figure 9 , which shows a schematic diagram of the structure of a whitelist generation device provided by an exemplary embodiment of this specification. The whitelist generation device can be implemented as all or part of the device through software, hardware, or a combination of both. The device includes a data acquisition module 601, a trusted matching module 602, and a list generation module 603.

[0125] A data acquisition module 601 is used to acquire an application data packet representing an application compilation process, and decompile the application data packet to obtain multiple lines of code;

[0126] A trusted matching module 602 is configured to scan multiple call behaviors corresponding to the multiple lines of code and extract target call behaviors matched by trusted behaviors from the multiple call behaviors; wherein the number of the target call behaviors is at least one;

[0127] The list generation module 603 is used to generate a whitelist according to at least one target calling behavior; wherein the whitelist is used to only allow the application to be called according to the calling method corresponding to the target calling behavior.

[0128] In one embodiment, the trusted matching module 602 includes:

[0129] a behavior analysis unit, configured to determine a plurality of calling behaviors according to the plurality of lines of code;

[0130] A policy matching unit is used to scan the multiple call behaviors according to the trusted behavior matching policy and extract the target call behaviors that pass the trusted behavior matching from the multiple call behaviors; wherein the trusted behavior matching policy includes at least two trusted behavior matches and the matching conditions required for the trusted behavior matching process.

[0131] In one embodiment, the policy matching unit includes:

[0132] A first matching subunit is configured to obtain at least one step corresponding to each of the plurality of calling behaviors;

[0133] a second matching subunit, configured to scan the plurality of steps according to a first matching condition during a first trusted behavior match, and extract at least one target step from the plurality of steps that meets the first matching condition; wherein the trusted behavior matching strategy includes the first matching condition;

[0134] a third matching subunit, configured to determine, based on the at least one target step, a call behavior including the target step as a call behavior to be matched; wherein the number of the call behaviors to be matched is at least one;

[0135] The fourth matching sub-unit is used to scan at least one of the call behaviors to be matched according to the second matching condition during the second trusted behavior matching, and extract the target call behavior that meets the second matching condition from at least one of the call behaviors to be matched; wherein the trusted behavior matching strategy includes the second matching condition.

[0136] In one embodiment, the fourth matching sub-unit is specifically used to scan the call links corresponding to at least one of the call behaviors to be matched according to a plurality of preset graph query statements during the second trusted behavior matching, and extract the target call behavior corresponding to the call link that meets the graph query statement in at least one of the call behaviors to be matched.

[0137] In one embodiment, the behavior analysis unit includes:

[0138] A behavior analysis subunit, configured to determine a plurality of call behaviors and call links corresponding to the call behaviors based on the plurality of lines of code;

[0139] In one embodiment, the policy matching unit includes:

[0140] The policy matching subunit is used to scan the call links corresponding to the multiple call behaviors according to the trusted behavior matching policy, and extract the target call behaviors that are matched by the trusted behavior from the multiple call behaviors.

[0141] In one embodiment, the whitelist generating apparatus further includes:

[0142] A R&D stability module is used to detect whether the R&D status of the application is stable;

[0143] The data acquisition module 601 includes:

[0144] The stable acquisition unit is used to acquire an application data packet representing the application compilation process when the development status of the application is stable, and decompile the application data packet to obtain multiple lines of code.

[0145] In one embodiment, the stable acquisition unit includes:

[0146] The first acquisition subunit is used to determine whether the development status of the application is stable by detecting whether multiple lines of code corresponding to the application are merged from the branch to the trunk during the application compilation process.

[0147] In one embodiment, the stable acquisition unit includes:

[0148] The second acquisition subunit is configured to determine whether the development status of the application is stable by detecting whether the application is deployed to a release environment.

[0149] In one embodiment, the list generation module 603 includes:

[0150] A first generating unit is configured to determine a call link corresponding to the target call behavior based on at least one step included in the target call behavior; wherein the call link includes nodes corresponding to the at least one step and parameters corresponding to the nodes;

[0151] The second generating unit is configured to generate a whitelist corresponding to the target calling behavior according to the calling link corresponding to the target calling behavior; wherein the number of the whitelist is at least one.

[0152] In one embodiment, the list generation module 603 further includes:

[0153] The third generating unit is used to visualize the call links included in the whitelist to obtain a whitelist report.

[0154] The embodiments of this specification can better cover various calling methods for an application by obtaining multiple calling behaviors from an application data packet that represents a complete compilation process. For example, it can cover the calling logic corresponding to the dependency package introduced during the compilation process, thereby greatly reducing the possibility that the whitelist will miss certain calling behaviors and improving the reliability of the whitelist. Compared with collecting target investigation behaviors and building a whitelist by observing a large number of calling behaviors for an application after the application is released, the embodiments of this specification extract multiple calling behaviors through multiple lines of code in the application data packet, and scan and match the target investigation behaviors as trusted behaviors. This can not only effectively avoid the problem of missing target calling behaviors caused by the observation method and reduce the high labor costs brought by the observation method, but also the whitelist generated based on the embodiments of this specification has high accuracy and can effectively intercept non-target calling behaviors for the application in actual use to protect the security of the application.

[0155] It should be noted that the whitelist generation device provided in the above embodiment only uses the division of the above-mentioned functional modules as an example when executing the whitelist generation method. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the whitelist generation device provided in the above embodiment and the whitelist generation method embodiment are based on the same concept. The implementation process is detailed in the method embodiment and will not be repeated here.

[0156] The serial numbers of the embodiments in the present specification are for description only and do not represent the advantages or disadvantages of the embodiments.

[0157] The embodiment of this specification also provides a computer storage medium that can store multiple instructions, which are suitable for being loaded and executed by a processor as described above. Figure 1 - Figure 8 The whitelist generation method of the embodiment shown, the specific execution process can be found in Figure 1 - Figure 8 The detailed description of the illustrated embodiment will not be repeated here.

[0158] This specification also provides a computer program product, which stores at least one instruction, and the at least one instruction is loaded and executed by a processor as described above. Figure 1 - Figure 8 The whitelist generation method of the embodiment shown, the specific execution process can be found in Figure 1 - Figure 8 The detailed description of the illustrated embodiment will not be repeated here.

[0159] See Figure 10 , is a schematic diagram of the structure of an electronic device provided in the embodiment of this specification. Figure 10 As shown, the electronic device 700 may include: at least one processor 701 , at least one network interface 704 , a user interface 703 , a memory 705 , and at least one communication bus 702 .

[0160] The communication bus 702 is used to implement the connection and communication between these components.

[0161] The user interface 703 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 703 may also include a standard wired interface and a wireless interface.

[0162] The network interface 704 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0163] The processor 701 may include one or more processing cores. The processor 701 utilizes various interfaces and lines to connect the various components within the server 700. By running or executing instructions, programs, code sets, or instruction sets stored in the memory 705, and calling data stored in the memory 705, the processor 701 performs various functions of the server 700 and processes data. Optionally, the processor 701 may be implemented in at least one hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 701 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display; and the modem is used to handle wireless communications. It is understood that the modem may not be integrated into the processor 701 and may be implemented separately on a single chip.

[0164] Among them, the memory 705 may include a random access memory (RAM) or a read-only memory (Read-Only Memory). Optionally, the memory 705 includes a non-transitory computer-readable storage medium. The memory 705 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 705 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 705 may also be optionally at least one storage device located away from the aforementioned processor 701. As Figure 10 As shown, the memory 705 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a whitelist generation application.

[0165] exist Figure 10 In the electronic device 700 shown, the user interface 703 is mainly used to provide an input interface for the user and obtain data input by the user; and the processor 701 can be used to call the whitelist generation application stored in the memory 705 and specifically perform the following operations:

[0166] Obtaining an application data packet representing an application compilation process, and decompiling the application data packet to obtain multiple lines of code;

[0167] Scanning multiple call behaviors corresponding to the multiple lines of code, and extracting target call behaviors matched by trusted behaviors from the multiple call behaviors; wherein the number of the target call behaviors is at least one;

[0168] A whitelist is generated according to at least one of the target calling behaviors; wherein the whitelist is used to only allow the application to be called according to a calling method corresponding to the target calling behavior.

[0169] In one embodiment, the processor 701 performs the scanning of multiple call behaviors corresponding to the multiple lines of code, extracting a target call behavior matched by a trusted behavior from the multiple call behaviors, and specifically performs:

[0170] Determine multiple calling behaviors according to the multiple lines of code;

[0171] The multiple call behaviors are scanned according to a trusted behavior matching strategy, and target call behaviors that pass the trusted behavior matching are extracted from the multiple call behaviors; wherein the trusted behavior matching strategy includes at least two trusted behavior matches and matching conditions required for the trusted behavior matching process.

[0172] In one embodiment, the processor 701 scans the multiple call behaviors according to the trusted behavior matching policy and extracts a target call behavior from the multiple call behaviors that matches the trusted behavior, specifically performing:

[0173] Obtain at least one step corresponding to each of the multiple calling behaviors;

[0174] During the first trusted behavior matching, scanning the plurality of steps according to the first matching condition, and extracting at least one target step that meets the first matching condition from the plurality of steps; wherein the trusted behavior matching strategy includes the first matching condition;

[0175] According to the at least one target step, determining a call behavior including the target step as a call behavior to be matched; wherein the number of the call behaviors to be matched is at least one;

[0176] During the second trusted behavior matching, at least one of the to-be-matched call behaviors is scanned according to the second matching condition, and a target call behavior that meets the second matching condition is extracted from the at least one to-be-matched call behavior; wherein the trusted behavior matching strategy includes the second matching condition.

[0177] In one embodiment, the processor 701 performs the following steps: scanning at least one of the to-be-matched call behaviors according to the second matching condition during the second trusted behavior matching, extracting a target call behavior that meets the second matching condition from the at least one to-be-matched call behavior, and specifically performing the following steps:

[0178] During the second trusted behavior matching, the call links corresponding to at least one of the call behaviors to be matched are scanned according to the preset multiple graph query statements, and the target call behavior corresponding to the call link that meets the graph query statement in at least one of the call behaviors to be matched is extracted.

[0179] In one embodiment, the processor 701 performs the step of determining the multiple calling behaviors according to the multiple lines of code, specifically performing:

[0180] Determining a plurality of calling behaviors and calling links corresponding to the calling behaviors according to the plurality of lines of code;

[0181] Scanning the multiple call behaviors according to the trusted behavior matching policy and extracting target call behaviors from the multiple call behaviors that are matched by the trusted behavior includes:

[0182] The call links corresponding to the multiple call behaviors are scanned according to the trusted behavior matching strategy, and target call behaviors that are matched by the trusted behavior are extracted from the multiple call behaviors.

[0183] In one embodiment, before the processor 701 executes the step of obtaining the application data packet representing the application compilation process and decompiling the application data packet to obtain the multiple lines of code, it further executes:

[0184] Check whether the development status of the application is stable;

[0185] The processor 701 executes the process of obtaining an application data packet representing the application compilation process, decompiles the application data packet to obtain multiple lines of code, and specifically performs the following steps:

[0186] When the development state of the application is stable, an application data packet representing the application compilation process is obtained, and the application data packet is decompiled to obtain multiple lines of code.

[0187] In one embodiment, the processor 701 performs the detection of whether the development status of the application is stable by specifically performing:

[0188] Whether the development status of the application is stable is determined by detecting whether multiple lines of code corresponding to the application are merged from the branch to the trunk during the application compilation process.

[0189] In one embodiment, the processor 701 performs the detection of whether the development status of the application is stable by specifically performing:

[0190] By detecting whether the application is deployed to the release environment, it is determined whether the development status of the application is stable.

[0191] In one embodiment, the processor 701 generates a whitelist based on at least one target calling behavior by specifically performing:

[0192] Determining a call link corresponding to the target call behavior according to at least one step included in the target call behavior; wherein the call link includes nodes corresponding to the at least one step, and parameters corresponding to the nodes;

[0193] A whitelist corresponding to the target call behavior is generated according to the call link corresponding to the target call behavior; wherein the number of the whitelist is at least one.

[0194] In one embodiment, after executing the call link according to the target call behavior and generating a whitelist corresponding to the target call behavior, the processor 701 further executes:

[0195] The call links included in the whitelist are visualized to obtain a whitelist report.

[0196] The embodiments of this specification can better cover various calling methods for an application by obtaining multiple calling behaviors from an application data packet that represents a complete compilation process. For example, it can cover the calling logic corresponding to the dependency package introduced during the compilation process, thereby greatly reducing the possibility that the whitelist will miss certain calling behaviors and improving the reliability of the whitelist. Compared with collecting target investigation behaviors and building a whitelist by observing a large number of calling behaviors for an application after the application is released, the embodiments of this specification extract multiple calling behaviors through multiple lines of code in the application data packet, and scan and match the target investigation behaviors as trusted behaviors. This can not only effectively avoid the problem of missing target calling behaviors caused by the observation method and reduce the high labor costs brought by the observation method, but also the whitelist generated based on the embodiments of this specification has high accuracy and can effectively intercept non-target calling behaviors for the application in actual use to protect the security of the application.

[0197] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory, or a random access memory.

[0198] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0199] The above disclosure is only a preferred embodiment of this specification, and certainly cannot be used to limit the scope of rights of this specification. Therefore, equivalent changes made according to the claims of this specification are still within the scope covered by this specification.

Claims

1. A whitelist generation method, the method comprising: Obtaining an application data packet representing an application compilation process, and decompiling the application data packet to obtain multiple lines of code; Scanning multiple call behaviors corresponding to the multiple lines of code, and extracting target call behaviors matched by trusted behaviors from the multiple call behaviors; wherein the number of the target call behaviors is at least one; A whitelist is generated according to at least one of the target calling behaviors; wherein the whitelist is used to only allow the application to be called according to a calling method corresponding to the target calling behavior.

2. The whitelist generation method according to claim 1, wherein scanning the plurality of call behaviors corresponding to the plurality of lines of code and extracting target call behaviors matched by trusted behaviors from the plurality of call behaviors comprises: Determine multiple calling behaviors according to the multiple lines of code; The multiple call behaviors are scanned according to a trusted behavior matching strategy, and target call behaviors that pass the trusted behavior matching are extracted from the multiple call behaviors; wherein the trusted behavior matching strategy includes at least two trusted behavior matches and matching conditions required for the trusted behavior matching process.

3. The whitelist generation method according to claim 2, wherein scanning the plurality of call behaviors according to the trusted behavior matching strategy and extracting target call behaviors that match the trusted behavior from the plurality of call behaviors comprises: Obtain at least one step corresponding to each of the multiple calling behaviors; During the first trusted behavior matching, scanning the plurality of steps according to the first matching condition, and extracting at least one target step that meets the first matching condition from the plurality of steps; wherein the trusted behavior matching strategy includes the first matching condition; According to the at least one target step, determining a call behavior including the target step as a call behavior to be matched; wherein the number of the call behaviors to be matched is at least one; During the second trusted behavior matching, at least one of the to-be-matched call behaviors is scanned according to the second matching condition, and a target call behavior that meets the second matching condition is extracted from the at least one to-be-matched call behavior; wherein the trusted behavior matching strategy includes the second matching condition.

4. The whitelist generation method according to claim 3, wherein during the second trusted behavior matching, scanning at least one of the to-be-matched call behaviors according to the second matching condition and extracting a target call behavior that meets the second matching condition from the at least one to-be-matched call behavior comprises: During the second trusted behavior matching, the call links corresponding to at least one of the call behaviors to be matched are scanned according to the preset multiple graph query statements, and the target call behavior corresponding to the call link that meets the graph query statement in at least one of the call behaviors to be matched is extracted.

5. The whitelist generation method according to claim 2, wherein determining a plurality of call behaviors based on the plurality of lines of code comprises: Determining a plurality of calling behaviors and calling links corresponding to the calling behaviors according to the plurality of lines of code; Scanning the multiple call behaviors according to the trusted behavior matching policy and extracting target call behaviors from the multiple call behaviors that are matched by the trusted behavior includes: The call links corresponding to the multiple call behaviors are scanned according to the trusted behavior matching strategy, and target call behaviors that are matched by the trusted behavior are extracted from the multiple call behaviors.

6. The whitelist generation method according to claim 1, before obtaining an application data packet representing an application compilation process and decompiling the application data packet to obtain a plurality of lines of code, further comprising: Check whether the development status of the application is stable; The obtaining of an application data packet representing an application compilation process and decompiling the application data packet to obtain multiple lines of code include: When the development state of the application is stable, an application data packet representing the application compilation process is obtained, and the application data packet is decompiled to obtain multiple lines of code.

7. The whitelist generation method according to claim 6, wherein the detecting whether the development status of the application is stable comprises: Whether the development status of the application is stable is determined by detecting whether multiple lines of code corresponding to the application are merged from the branch to the trunk during the application compilation process.

8. The whitelist generation method according to claim 6, wherein the detecting whether the development status of the application is stable comprises: By detecting whether the application is deployed to the release environment, it is determined whether the development status of the application is stable.

9. The whitelist generation method according to claim 1, wherein generating the whitelist according to at least one target calling behavior comprises: Determining a call link corresponding to the target call behavior according to at least one step included in the target call behavior; wherein the call link includes nodes corresponding to the at least one step, and parameters corresponding to the nodes; A whitelist corresponding to the target call behavior is generated according to the call link corresponding to the target call behavior; wherein the number of the whitelist is at least one.

10. The whitelist generation method according to claim 9, after generating the whitelist corresponding to the target call behavior according to the call link of the target call behavior, further comprising: The call links included in the whitelist are visualized to obtain a whitelist report.

11. A whitelist generation device, comprising: A data acquisition module, configured to acquire an application data packet representing an application compilation process, and decompile the application data packet to obtain multiple lines of code; a trusted matching module, configured to scan a plurality of call behaviors corresponding to the plurality of lines of code and extract a target call behavior matched by a trusted behavior from the plurality of call behaviors; wherein the number of the target call behaviors is at least one; A list generation module is used to generate a whitelist according to at least one of the target calling behaviors; wherein the whitelist is used to only allow the application to be called according to the calling method corresponding to the target calling behavior.

12. A computer program product, wherein the computer program product stores a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the method steps according to any one of claims 1 to 10.

13. A computer storage medium storing a plurality of instructions, wherein the instructions are suitable for being loaded by a processor and executing the method steps according to any one of claims 1 to 10.

14. An electronic device comprising: A processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the method steps according to any one of claims 1 to 10.

Images