Abnormality detection method and device, electronic equipment, medium and program product

Abstract

The invention provides an anomaly detection method and device, electronic equipment, a medium and a program product, and can be applied to the technical field of artificial intelligence. The method comprises the following steps: disassembling a to-be-analyzed program to obtain an assembly instruction set; performing sequential traversal on the assembly instruction set, and dividing the assembly instruction set based on a control transfer instruction to obtain a plurality of nodes for representing program execution path fragments; directed connection between the corresponding nodes is established on the basis of the control transfer relation between the multiple nodes so as to construct a directed graph used for representing the program control process, and nodes containing release operation calling are marked as release nodes in the process of constructing the directed graph; and executing path search in the directed graph based on the release node, and performing secondary release risk detection based on a path search result.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and more specifically to an anomaly detection method, apparatus, device, medium, and program product. Background Technology

[0002] In programming languages ​​that employ manual memory management, memory allocation and deallocation are entirely under the developer's control. Oversights in the logic can lead to the same memory being deallocated repeatedly, resulting in a double-free security vulnerability. This type of problem is highly insidious, often caused by complex conditions, multi-path execution, and cross-function management behaviors that fragment the memory lifecycle, making it difficult for manual review to accurately determine the number and order of deallocations.

[0003] Currently, double-free issues primarily rely on manual static checks, which are costly and inefficient in large codebases. To improve detection capabilities, there are solutions for automatically monitoring memory behavior through instrumentation, dynamic simulation, and path constraints; however, these methods are limited by path coverage and struggle to fully uncover deeper risks. Furthermore, while some research has attempted to use graph modeling to identify issues such as the use of freed memory or unreleased resources, a systematic graph model and global analysis method for double-free scenarios are still lacking. This prevents the achievement of high-coverage, accurate automatic identification of double-free risks in complex software environments. Summary of the Invention

[0004] In view of the above problems, this application provides anomaly detection methods, apparatus, equipment, media and program products.

[0005] According to a first aspect of this application, an anomaly detection method is provided, the method comprising: disassembling a program to be analyzed to obtain an assembly instruction set; sequentially traversing the assembly instruction set and dividing the assembly instruction set based on control transfer instructions to obtain multiple nodes representing program execution path segments; establishing directed connections between corresponding nodes based on the control transfer relationships between the multiple nodes to construct a directed graph representing the program control flow, wherein, during the construction of the directed graph, nodes containing release operation calls are marked as release nodes; and performing path search in the directed graph based on the release nodes, and detecting secondary release risks based on the results of the path search.

[0006] According to an embodiment of this application, disassembling the program to be analyzed to obtain an assembly instruction set includes: scanning the executable instructions of the program to be analyzed to obtain corresponding address information; extracting the corresponding machine code based on the address information and disassembling it to obtain assembly instructions arranged in address order; and forming the assembly instruction set based on the assembly instructions and the corresponding address information.

[0007] According to an embodiment of this application, the step of sequentially traversing the assembly instruction set and dividing the assembly instruction set based on control transfer instructions to obtain multiple nodes representing program execution path segments includes: taking the program entry address as the current traversal starting point, sequentially reading the assembly instructions in the assembly instruction set based on the address order; in response to detecting the control transfer instruction, dividing the assembly instructions from the current traversal starting point to the control transfer instruction into a node; and continuing sequential traversal based on the updated traversal starting point until all assembly instructions are divided into the multiple nodes, wherein, in the case of a jump by the control transfer instruction, the target address of the control transfer instruction is used as the updated traversal starting point; in the case of no jump, the address of the assembly instruction following the control transfer instruction is used as the updated traversal starting point.

[0008] According to embodiments of this application, the control transfer instruction includes at least one of an unconditional jump instruction, a conditional jump instruction, a loop jump instruction, and a function call instruction.

[0009] According to an embodiment of this application, establishing a directed connection between corresponding nodes based on the control transfer relationship between the plurality of nodes includes: for each node containing the control transfer instruction, determining a corresponding target node using the target address; establishing a directed connection between the node containing the control transfer instruction and the target node pointing to the target node; and for nodes not containing the control transfer instruction, establishing a directed connection with the node immediately adjacent in the address order.

[0010] According to an embodiment of this application, the step of performing path search in the directed graph based on the release node and detecting the risk of secondary release based on the path search results includes: taking any release node as the search starting point, performing a depth-first search or breadth-first search in the directed graph, and marking visited nodes during the search process; and filtering out target paths from the starting release node to at least one other release node from the path search results, using the target paths as candidate secondary release paths, and detecting the risk of secondary release based on the candidate secondary release paths.

[0011] According to an embodiment of this application, the detection of secondary release risk based on the candidate secondary release path includes: sequentially analyzing the parameter sources of release operation calls in each release node along the control flow order of the nodes in the candidate secondary release path to establish a correspondence between release operations and memory addresses; comparing whether the memory addresses acted upon by the release operations of adjacent release nodes are the same based on the correspondence; and determining the candidate secondary release path as a path with secondary release risk when the comparison result shows that the release operations of any adjacent release node act upon the same memory address, and no reallocation, reset, or overwrite operation of the memory address is detected between the release operations.

[0012] According to an embodiment of this application, the method further includes: when multiple release operation call instructions are detected in the same node, extracting the memory address of each release operation; and in response to multiple release operation calls targeting the same memory address in the same node, identifying the corresponding node as a node with a risk of secondary release.

[0013] A second aspect of this application provides an anomaly detection device, comprising: a disassembly module for: disassembling a program to be analyzed to obtain a set of assembly instructions; a sequential traversal module for: sequentially traversing the set of assembly instructions, dividing the set of assembly instructions based on control transfer instructions to obtain multiple nodes representing program execution path segments; a directed graph construction module for: establishing directed connections between corresponding nodes based on the control transfer relationships between the multiple nodes to construct a directed graph representing the program control flow, wherein, during the construction of the directed graph, nodes containing release operation calls are marked as release nodes; and an anomaly detection module for: performing path search in the directed graph based on the release nodes, and detecting secondary release risks based on the results of the path search.

[0014] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0017] According to embodiments of this application, by dividing assembly instructions into multiple nodes representing execution path segments and constructing a directed graph based on control transfer relationships, the control flow structure of the program can be fully depicted. During graph construction, nodes containing release operation calls are automatically identified and marked, making the release behavior traceable at the control flow level. This allows for path searching on the graph structure, identifying execution paths that may lead to secondary release risks. Embodiments of this application are highly automated and versatile, independent of specific compilation environments and language frameworks, and can cover all executable paths of the program. This effectively overcomes the problems of low efficiency and insufficient coverage in manual auditing, thereby improving the detection accuracy and coverage of memory management anomalies while reducing detection costs. It is suitable for security analysis and quality assurance of large and complex software systems. Attached Figure Description

[0018] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0019] Figure 1 The illustrations depict application scenarios of anomaly detection methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0020] Figure 2 A flowchart illustrating an anomaly detection method according to an embodiment of this application is shown schematically.

[0021] Figure 3 The flowchart schematically illustrates a method for sequentially traversing a set of assembly instructions according to some exemplary embodiments of this application;

[0022] Figure 4 The flowchart illustrates a method for detecting secondary release risk according to some exemplary embodiments of this application;

[0023] Figure 5 A schematic diagram illustrating the structure of an anomaly detection device according to an embodiment of this application is shown; and

[0024] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing an anomaly detection method according to an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0027] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0028] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0029] In programming languages ​​employing manual memory management mechanisms, the allocation and release of memory resources rely entirely on the developer's control. Oversights during complex logic processing can lead to the same memory block being repeatedly freed, creating a double-free security vulnerability. This type of vulnerability is a high-risk issue in memory management; if maliciously exploited, it can not only cause abnormal program crashes during runtime but also corrupt the underlying memory structure, giving attackers the ability to execute instructions without authorization, potentially leading to remote system control or data tampering. For enterprise servers and critical business systems, this type of security vulnerability is extremely destructive, potentially causing significant economic losses and business risks.

[0030] Double-free issues are often deeply hidden, and their causes are frequently related to complex conditional judgments, multi-path execution chains, and cross-function memory management behaviors. In large-scale software engineering, memory resource allocation and deallocation may occur in different modules, different threads, or different call paths, resulting in fragmented and overlapping lifecycles for the same memory address, increasing the difficulty of manual judgment. Developers or security auditors often find it difficult to fully grasp the number and order of memory deallocations across all execution paths. Therefore, in large-scale software systems, it is necessary to develop detection technologies that can automatically identify double-free risks.

[0031] In current technical practices, the most common approach still relies on manual static code review. While manual review offers some flexibility, it often requires significant manpower for codebases with hundreds of thousands or even millions of lines of code, and suffers from time-consuming nature and insufficient coverage. To improve efficiency, some research has proposed automated or semi-automated solutions, such as monitoring memory allocation and deallocation behavior through program instrumentation, dynamic simulator execution, and path constraint execution, aiming to automatically detect double deallocation risks. However, these methods are generally limited by path coverage. In complex business scenarios, the combination of execution paths can grow exponentially, while dynamic simulation or instrumentation can often only explore a limited number of paths, making it difficult to cover all potential risk points and prone to incomplete detection.

[0032] In addition to the above, there are some graph-based modeling methods in the field of memory safety analysis. For example, by constructing variable association graphs, pointer propagation graphs, or memory lifecycle graphs, typical memory management problems such as using freed memory or failing to release resources can be identified. These methods identify abnormal behavior by structuring program behavior into a graph model and using graph search, path analysis, and other techniques. However, current research mostly focuses on other types of memory management defects, and a systematic graph model construction method for double-free scenarios has not yet been developed, nor has a mature solution been found that utilizes graph theory principles for global detection. This leaves a gap in the methodological framework of this field.

[0033] Based on this, embodiments of this application provide an anomaly detection method, the method comprising: disassembling the program to be analyzed to obtain an assembly instruction set; sequentially traversing the assembly instruction set, dividing the assembly instruction set based on control transfer instructions to obtain multiple nodes representing program execution path segments; establishing directed connections between corresponding nodes based on the control transfer relationships between the multiple nodes to construct a directed graph representing the program control flow, wherein, during the construction of the directed graph, nodes containing release operation calls are marked as release nodes; and performing path search based on the release nodes in the directed graph, and detecting secondary release risks based on the path search results. According to embodiments of this application, by dividing the assembly instructions into multiple nodes representing execution path segments and constructing a directed graph based on control transfer relationships, the control flow structure of the program can be completely depicted; during the graph construction process, nodes containing release operation calls are automatically identified and marked, making the release behavior traceable at the control flow level, thereby enabling path search to be performed on the graph structure to identify execution paths that may lead to secondary release risks. The embodiments of this application are highly automated and versatile, do not depend on specific compilation environments and language frameworks, can cover all executable paths of a program, effectively overcome the problems of low efficiency and insufficient coverage of manual auditing, thereby improving the detection accuracy and coverage of memory management anomalies, while reducing detection costs, and are suitable for security analysis and quality assurance of large and complex software systems.

[0034] It should be noted that the anomaly detection methods, apparatus, devices, media, and program products defined in this application can be used in the fields of artificial intelligence technology and fintech, and can also be used in a variety of other fields besides artificial intelligence technology and fintech. The application fields of the anomaly detection methods, apparatus, devices, media, and program products provided in the embodiments of this application are not limited.

[0035] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0036] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all offer users corresponding operation entry points, allowing them to choose to agree to or reject the automated decision results; if the user chooses to reject, the process proceeds to expert decision-making. Here, "expert decision-making" refers to the decision-making activities of personnel who specialize in a particular field, possess specialized experience, knowledge, and skills, and have reached a certain level of professional expertise.

[0037] Figure 1 The illustration shows an application scenario of the anomaly detection method, apparatus, device, medium, and program product according to embodiments of this application.

[0038] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0039] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0040] In the embodiments of this application, the first terminal device 101 can be an example of the first device, and the second terminal device 102 and / or the third terminal device 103 can be an example of at least one second device. The first device and the second device can communicate collaboratively through an internal client mechanism to implement the data distribution and rendering logic described in the anomaly detection method.

[0041] In some embodiments, the first device and at least one second device may be different display modules, windows or screens on the same computing terminal (such as a host), or multiple physical devices that work together through a network, such as different client instances deployed on a desktop computer, tablet terminal or mobile device respectively.

[0042] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smart mobile terminals, tablet computers, laptop computers, and desktop computers.

[0043] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0044] It should be noted that the anomaly detection method provided in this application embodiment can generally be executed by server 105. Correspondingly, the anomaly detection device provided in this application embodiment can generally be located in server 105. The anomaly detection method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the anomaly detection device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0045] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0046] The following will be based on Figure 1 The described scene, through Figures 2-4 The anomaly detection method of the disclosed embodiments is described in detail.

[0047] Figure 2 A flowchart illustrating an anomaly detection method according to an embodiment of this application is shown schematically.

[0048] like Figure 2 As shown, the anomaly detection method 200 of this embodiment includes operations S210 to S240.

[0049] During operation of S210, the program to be analyzed is disassembled to obtain the set of assembly instructions. The disassembly process converts the program to be analyzed from binary form into an assembly-level representation that can be used for static analysis, thereby providing basic information for subsequent node partitioning and control flow graph construction.

[0050] In the embodiments of this application, the system can first read the executable instruction area of ​​the program to be analyzed, and determine the starting address, length, and loading method of the instruction segment by scanning the file header information and instruction segment description. Subsequently, the system uses an instruction parsing component to parse the binary content of the program byte by byte, translating the machine instructions into assembly statements with clear semantics, and arranging them sequentially according to their physical location and logical address in the executable file.

[0051] In some embodiments, the disassembly process can achieve adaptive parsing by combining instruction set characteristics and architecture information. For example, instruction lengths, addressing modes, and register call methods differ across processor architectures. The system can automatically determine the instruction set architecture used by the target program by recognizing the executable file's format header information (such as file identifiers and segment descriptor tables) and select the corresponding instruction translation template for disassembly. For architectures using variable-length instruction encoding, the disassembler can dynamically determine instruction boundaries based on opcode characteristics and immediate value identifiers, ensuring the accuracy and readability of the disassembly results. In some embodiments, by combining symbol table information or debugging information, function names, global variable names, and local labels can be recovered, thereby adding semantic comments to the assembly instruction set and further improving analyzability.

[0052] In another embodiment, the disassembly process can be executed not only on a single target program but also in batch processing in scenarios involving multiple modules or files. For complex programs containing multiple dynamically linked units, the system can build a global assembly instruction index table by loading and parsing the code segments of each target module one by one. This index table records the load base address, instruction offset, and call relationships between modules, thereby supporting cross-module control flow analysis. For example, in a scenario where a main program calls multiple external library files, the system can identify module boundaries and function jump addresses during the disassembly stage, avoiding path interruption problems caused by unclear module divisions in subsequent path search stages.

[0053] In some embodiments, disassembly operations can also be combined with instruction-level simulation techniques to improve the parsing accuracy of dynamic code segments or self-modifying code. When the system detects indirect jumps, delayed bindings, or dynamically generated machine instructions in the instruction set, the simulation engine can be temporarily started to run the specified code segment in a controlled environment, collect the actual instruction sequence during its execution, and supplement the assembly instruction set with these dynamically generated instructions.

[0054] In the embodiments of this application, in order to ensure the traceability of the disassembly results, the system can also establish a unique identifier for each assembly instruction. The unique identifier information includes the program file name, segment number, logical address and machine code check value, so that the subsequent node division and path search stages can accurately locate the corresponding position in the original program, and support the reverse mapping from address to file offset when the risk detection result is output.

[0055] In some embodiments, the system can also employ multi-mode disassembly strategies for programs with different compilation optimization levels. For example, in programs with higher optimization levels, there are numerous instruction rearrangements and inline functions, resulting in a complex control flow structure. In this case, the system can use a control flow recovery-based disassembly mode, combined with algorithms such as jump table identification and function boundary inference, to perform structured disassembly. For programs with lower optimization levels, a sequential parsing mode can be used to quickly generate instruction sets.

[0056] In some embodiments, to improve the processing power of large-scale programs, the disassembly process can employ a segmented parallel strategy. The system can divide the program code segment into multiple partitions according to a fixed length or function boundaries, and allocate them to different computing threads or processing units for disassembly operations. After each partition is completed, the system automatically merges the results and unifies the assembly instruction numbers and address mappings.

[0057] In the embodiments of this application, to enhance the robustness of anomaly detection, the disassembly module can also be configured with an instruction integrity verification function. The system can perform hash verification on the machine code segments of the target program before and after disassembly to ensure that no file corruption or code tampering occurs during the analysis process. In addition, the system can also record additional information such as instruction length, operand type, and calling convention in the disassembly results to assist in subsequent memory operation identification and call semantic analysis, thereby improving the overall detection accuracy.

[0058] In operation S220, the assembly instruction set is sequentially traversed, and the assembly instruction set is divided based on control transfer instructions to obtain multiple nodes used to represent program execution path segments.

[0059] In the embodiments of this application, the sequential traversal of the assembly instruction set is used to transform the disassembly results into structured execution units, enabling the identification of logical boundaries and execution paths in the program. The system can start from the program entry address and read the assembly instructions one by one according to their order in memory. When a control transfer instruction is detected, it is used as a demarcation point, dividing the continuous instructions since the last demarcation point into a node. Each node corresponds to a continuous execution segment that does not involve jumps during execution, thereby discretizing the entire program's execution flow into multiple node units, laying the foundation for subsequent control flow analysis.

[0060] In the embodiments of this application, sequential traversal is applicable not only to single-threaded execution logic but also to multi-branch and loop structures. For instruction segments containing loop jumps, the system can automatically identify the loop body range by recording the correspondence between the loop entry address and the jump target, and mark it as a special type of node. In this way, when constructing the control flow graph later, the loop structure can be accurately modeled, representing both the self-jump relationship of the loop body and distinguishing the external execution path after the loop ends.

[0061] In some embodiments, the system can introduce a stack-based recording mechanism during traversal to manage the nesting relationships between function calls and returns. For example, when a function call instruction is encountered, the system can push the current address onto the call stack and jump to the entry point of the called function to continue traversal; when a return instruction is detected, the upper-level call address can be popped from the stack, and the first instruction after the return can be used as the new traversal starting point. This allows the control path under complex call hierarchies to be recovered at the static analysis level, making node partitioning more accurate.

[0062] In the embodiments of this application, the sequential traversal operation can also be combined with a code block boundary identification algorithm to address instruction reordering issues caused by compiler optimizations. The system can automatically identify the start and end positions of code blocks using features such as control flow characteristics, jump table patterns, and function preorder identifiers, ensuring that node partitioning maintains logical continuity even when instructions are optimized across regions. For example, for delayed jump structures generated by compiler optimization, the system can infer the execution order from the target address, thereby restoring the true control boundary.

[0063] In some embodiments, to improve the traversal efficiency of large programs, the system can adopt a segmented traversal and parallel recognition approach. The assembly instruction set can be divided into several consecutive segments, each segment is assigned an independent thread to execute the node division, and the results are merged through address indexing to establish a unified jump mapping between nodes.

[0064] In the embodiments of this application, the sequential traversal process can also be combined with the detection of an exception handling mechanism. When the system identifies an abnormal jump or interrupt call instruction, it can mark it separately as a special control transfer point and establish a logical connection with the exception handling entry point.

[0065] In some embodiments, the system can also extract internal feature information of nodes during the traversal phase, such as memory access instructions, call parameters, and register changes, and store them as node attributes. This attribute information can be directly used in the subsequent risk analysis phase to determine the source of parameters and the memory address of the release operation. By embedding attribute collection during the node partitioning phase, the system can reduce the overhead of subsequent multiple scans of instruction sets and improve overall analysis efficiency.

[0066] In operation S230, directed connections between corresponding nodes are established based on the control transfer relationship between the multiple nodes to construct a directed graph for representing the program control flow. In the process of constructing the directed graph, nodes containing release operation calls are marked as release nodes.

[0067] In the embodiments of this application, directed connections are established between corresponding nodes based on the control transfer relationships between multiple nodes, which are used to form a complete control flow diagram at the program's structural level. The system has obtained the boundary and content information of each node in the previous stage. At this point, the possible flow of the program during execution can be determined based on the control transfer instructions at the end of each node. For example, when the node ends with an unconditional jump instruction, a directed connection can be directly established between that node and the node corresponding to the jump target; when the node ends with a conditional jump instruction, the system can simultaneously establish two connections: one pointing to the jump target node, and the other pointing to the next node in address order, to represent the two execution states: the branch condition is true and the condition is false.

[0068] In some embodiments, to further improve the accuracy of graph construction, the system may incorporate semantic information of function calls and returns when establishing node connections. When a function call instruction is detected, the system can establish a directed connection between the current node and the entry node of the called function, and when a return instruction is detected, establish a back connection from the function node back to the first instruction after the calling node.

[0069] In the embodiments of this application, for loop structures, the system can establish self-looping connections between nodes to represent repeatedly executed logical paths. When a loop jump instruction is detected, the system can point the current node to the starting node of the loop body, forming a self-looping relationship. To prevent the loop relationship from causing the path in the graph to expand infinitely, the system can also set a marker or depth limit for the loop connection, so that subsequent path searches can identify and reasonably prune the repeatedly traversed parts.

[0070] In some embodiments, the system may employ a multi-level index structure to organize the connections between nodes. For example, in large programs, the control flow graph may contain tens of thousands of nodes, and directly storing all connections would incur significant storage overhead. The system may first establish local subgraphs at the function or module level, and then establish higher-level connections between the subgraphs, thereby forming a hierarchical control flow representation.

[0071] In the embodiments of this application, directed connections between nodes can be accompanied by various attribute information to enhance the semantic expressiveness of the graph structure. When establishing a connection, the system can record metadata such as jump type, condition flag, target offset address, and call return characteristics. For example, conditional jumps can be accompanied by condition identifiers and register state descriptions, and function call connections can be accompanied by parameter passing methods or call stack depth information.

[0072] In some embodiments, the system can simultaneously perform node type identification during the graph construction process to mark nodes with specific functions. Nodes containing release operation calls can be identified as critical nodes and marked as release nodes. The system can identify memory release-related call instructions, such as calling specific memory management functions or performing register release operations, by scanning the assembly instructions within the nodes.

[0073] In the embodiments of this application, to ensure the accuracy of the marking, the system can perform cross-validation on the release nodes by combining contextual semantic information. When a release call is detected in a node, the system can further check whether there are corresponding memory allocation or address assignment operations in the instructions before and after the node, and confirm that the node has indeed performed the release behavior.

[0074] In some embodiments, the system can establish special directed connections for abnormal jump paths in a program. Some programs may execute specific recovery code segments through interruption or error jumps under the exception handling mechanism. The system can identify such jump instructions during graph construction and establish connections with the exception handling entry node.

[0075] In the embodiments of this application, the control flow graph construction process can employ an incremental update strategy. During the traversal, whenever a new node or control transfer relationship is identified, the system can update the graph structure in real time, without needing to rebuild it uniformly after the traversal is complete. Furthermore, when the program changes or is incrementally compiled, only the connections of the affected nodes need to be rebuilt, thereby quickly completing the graph update.

[0076] In some embodiments, the system can also perform structural optimization and redundancy elimination on the constructed directed graph. By analyzing the in-degree and connection patterns of nodes, the system can merge nodes with the same structure and logical equivalence, or remove isolated nodes that cannot be reached, thereby simplifying the size of the control flow graph. The optimized graph structure maintains logical integrity while improving the operational efficiency of the path search and risk detection phases.

[0077] In operation S240, a path search is performed on the directed graph based on the release node, and the risk of secondary release is detected based on the result of the path search.

[0078] In the embodiments of this application, the operation of performing path search in a directed graph based on the release node aims to identify path relationships that may result in repeated releases during program execution through a graph traversal algorithm. The system can select any release node as the search starting point and traverse the directed connections to obtain all reachable paths from the starting release node to other release nodes.

[0079] In some embodiments, to improve the efficiency of path search, the system can mark visited nodes to prevent repeated traversal in loop structures. During the search process, if a loop edge or back edge is detected, the system can add a loop identifier to the path record and terminate excessively deep traversals according to preset depth limits or path pruning rules to avoid exponential path expansion in the graph structure.

[0080] In the embodiments of this application, path search is not only used to discover the connection relationships between nodes, but also to filter target paths by combining node attribute information. For example, during the search process, the system can retain only branches of the path that contain multiple release nodes, or limit local paths within the scope of certain functions or modules, thereby focusing on critical paths where repeated resource releases may occur. For cross-function or cross-module call relationships, the system can also generate hierarchical path records based on the hierarchical information of the function call edges to describe the transmission of the release operation between different call layers.

[0081] In some embodiments, to enhance the interpretability of path search, the system can simultaneously generate an intermediate representation of the path structure during the traversal process. Each path can record auxiliary data such as the sequence of nodes traversed, control transition types, conditional jump information, and the number of loops. This path representation can be saved in the result cache for subsequent path comparison, similar path merging, or risk verification.

[0082] In embodiments of this application, the system can also integrate static and dynamic information during the path search phase. For example, if actual execution trajectory information exists in the disassembly phase or external debug logs, the system can map these dynamic trajectories onto directed graph nodes, limiting the search scope to actually reachable paths, thereby reducing the number of redundant theoretical paths. In the absence of runtime data, the system can also perform path pruning based on call constraints, conditional decisions, and register states to approximate the control flow of actual execution.

[0083] In some embodiments, after path search is completed, the system can perform feature clustering on the obtained path set, merging paths with similar structures or shared nodes into one category. This significantly reduces redundant results and facilitates subsequent risk assessment and visualization. For example, if multiple paths differ only slightly in their conditional branches, the system can group them into a single representative path, thus presenting the key relationships of the control flow in a more compact form in the output.

[0084] In embodiments of this application, path searching can also be associated with node attributes to extract context information of the release operation. When the system traverses to a release node, it can record the source of the parameters corresponding to its release call, the register state, and the value passing path of related variables. Subsequently, the system can trace back along the path to find the allocation operation or address assignment instruction related to the parameter, in order to determine whether the two release operations act on the same memory region.

[0085] In some embodiments, the system may employ a multi-strategy fusion path search mechanism. In addition to conventional depth-first and breadth-first approaches, heuristic search algorithms can be combined to prioritize paths more likely to contain high-risk release nodes. For example, the system can assign weights to each node based on the density of release nodes, function level, or call frequency, and prioritize branches with higher weights during the search process. This adaptive search strategy can discover potentially risky paths more quickly with limited computing resources.

[0086] In the embodiments of this application, to facilitate result analysis and verification, the system can output the path search results in a graphical form. Each candidate path can be represented by a visual diagram consisting of a sequence of nodes and directed edges, with nodes marked with special colors or shapes. When a potentially risky path is detected, the system can highlight key nodes in the path and their corresponding assembly instruction locations on the graph, assisting analysts in quickly locating the source of the problem.

[0087] In some embodiments, the system can also combine path search with automated verification. Once a candidate path is identified, the system can generate a corresponding verification script or simulation input. By simulating the instruction execution sequence on the path in a virtual execution environment, it observes whether the release operation repeatedly acts on the same memory address. If the simulation results are consistent with the path analysis, the existence of the risk can be further confirmed, improving the reliability of the detection conclusions.

[0088] According to embodiments of this application, an assembly instruction set is obtained by disassembling the executable file, enabling the analysis of the program's underlying execution logic. Based on control transfer instructions, the assembly instruction set is divided into multiple nodes, clearly depicting the program's execution path structure. Directed connections are established based on the control transfer relationships between nodes, constructing a directed graph reflecting the global control flow. During graph construction, nodes containing release operation calls are automatically marked, making key behaviors visually represented in the graph. The system performs path searching starting from release nodes, automatically identifying paths that may lead to duplicate releases and performing risk detection. Embodiments of this application logically form a closed-loop process of disassembly, node partitioning, graph construction, and detection, capable of covering all execution paths of complex programs and achieving automatic analysis of resource release behavior. Compared with traditional manual auditing and dynamic instrumentation methods, it features strong versatility, high coverage, and high detection accuracy, and can be widely applied to static security analysis and quality assurance of large-scale industrial software.

[0089] The anomaly detection method of this application will be specifically described below by way of preferred embodiments.

[0090] In the embodiments of this application, the disassembly process of the program to be analyzed aims to convert the binary executable file into a set of assembly instructions with a logical structure, so as to facilitate subsequent control flow analysis and path detection. Specifically, the system can first scan the executable instruction region of the program to be analyzed, read the file header, segment description, and load address information, thereby determining the starting address of the code segment and the instruction distribution range.

[0091] In some embodiments, the system extracts the corresponding machine code based on the address information and uses a disassembly module to convert the machine instructions into readable assembly instructions. During disassembly, the meaning of each instruction can be analyzed according to the target processor's instruction set architecture, opcode format, and addressing mode to generate assembly statements with opcodes, operands, and target addresses. In this way, the original machine code is structured into a sequence of assembly instructions arranged in address order, preserving the integrity of program execution while eliminating unreadable binary code.

[0092] In the embodiments of this application, to further improve disassembly accuracy, the system can combine the debug symbol table, export table, and function boundary information to recover some function names, call entry points, and local variable identifiers. This allows for the reconstruction of the program logic hierarchy at the assembly instruction level, facilitating subsequent identification of control transfer relationships and resource management behaviors. For programs without symbolic information, the system can also identify common function pre-sequence features through pattern matching algorithms to infer function boundaries and achieve higher-precision disassembly.

[0093] After disassembling, the system can associate and store the assembly instructions with their corresponding address information, forming an assembly instruction set. This set records not only the assembly text of each instruction but also its logical address, segment number, machine code, and length. Through this structured set format, the system can quickly locate any instruction in subsequent analysis phases, track control transfer targets, and provide direct indexing for establishing nodes and directed connections.

[0094] Through the above process, the embodiments of this application can restore an executable file into a set of assembly instructions with a logical structure without requiring source code. This process is platform-adaptive and scalable, and can automatically select the appropriate disassembly strategy for programs with different architectures, thereby providing a unified data foundation for subsequent control flow modeling and risk detection, and improving the automation and accuracy of the analysis.

[0095] In the embodiments of this application, the assembly instructions obtained from disassembly can also be divided into multiple nodes with independent execution semantics by identifying control transfer instructions, thereby providing structured input for subsequent control flow modeling.

[0096] Figure 3 The flowchart illustrates a method for sequentially traversing a set of assembly instructions according to some exemplary embodiments of this application.

[0097] like Figure 3 As shown, the method for sequentially traversing the assembly instruction set includes operations S310 to S330.

[0098] In operation S310, the program entry address is used as the current traversal starting point, and the assembly instructions in the assembly instruction set are read sequentially based on the address order.

[0099] Specifically, after disassembling, the system first parses the executable file's header information, such as the main entry point, load base address, code segment offset, and segment table structure, to determine the logical address of the program's first executable instruction, i.e., the program entry address. The program entry address corresponds to the starting position of the program's startup function or initialization routine and is the first control flow node during program execution. After determining the starting point, the system sequentially reads each instruction in the assembly instruction set according to its logical address order. During the reading process, the system simultaneously records the address, opcode, and operand information of each instruction to ensure that the traversal order matches the actual execution order of the program, thereby avoiding logical deviations caused by instruction jumps or reordering.

[0100] In operation S320, in response to detecting the control transfer instruction, a node is formed from the assembly instruction corresponding to the current traversal starting point to the control transfer instruction.

[0101] When the system detects a control transfer instruction while sequentially reading assembly instructions, it determines that the location represents a boundary point in the program logic. At this point, the system defines a node as the instruction range from the assembly instruction corresponding to the current traversal starting point to the instruction covered by the control transfer instruction. This node represents a linear sequence of instructions that executes continuously without branching or jumping. Its internal execution order is unique and predictable, thus forming the basic execution unit of program control flow.

[0102] In operation S330, sequential traversal continues based on the update traversal starting point until all assembly instructions are divided into the multiple nodes. In the case of a control transfer instruction executing a jump, the target address of the control transfer instruction is used as the update traversal starting point; in the case of no jump, the address of the assembly instruction following the control transfer instruction is used as the update traversal starting point.

[0103] Specifically, the system updates the traversal starting point based on different control transfer types and continues sequential traversal. When a control transfer instruction is detected, the system uses the target address of that instruction as the new traversal starting point and continues analysis along the target path; when no control transfer occurs, the address of the next assembly instruction is used as the new traversal starting point, and reading continues downwards. This cyclical traversal process continues until all assembly instructions have been assigned to their corresponding nodes. Through this mechanism, the system can fully cover all possible execution paths of the program and ensure that each path has a unique mapping in the control graph.

[0104] In some embodiments, to improve traversal efficiency, the system can mark processed address ranges to avoid redundant partitioning. In programs with multiple branch jumps, the system can employ a queue-based traversal strategy, simultaneously maintaining multiple unprocessed target addresses, thereby achieving synchronous analysis of multi-path execution scenarios. Furthermore, for nested function calls or loop jump structures, the system can also utilize recursive backtracking or a stack structure to save the traversal state, ensuring accurate identification of the start and end ranges of each node even under complex call hierarchies.

[0105] In some embodiments, the system can collect characteristic information within nodes, such as register state changes, call parameters, and memory access instructions, while partitioning nodes, to support subsequent release operation detection. This characteristic information can be stored as node attributes for direct retrieval during subsequent graph construction and risk analysis phases. By combining traversal with information extraction, the system achieves unified modeling of program logic and resource behavior.

[0106] According to embodiments of this application, automated structured analysis of programs can be performed at the assembly level, decomposing complex binary execution logic into a computable set of nodes. This allows for precise division of program control units without source code, significantly improving the automation and versatility of the analysis.

[0107] In the embodiments of this application, control transfer instructions are key instruction types used to change the execution order of programs, and their detection results directly determine the boundaries of node partitioning and the connection method of control flow. Control transfer instructions may include unconditional jump instructions, conditional jump instructions, loop jump instructions, and function call instructions, etc.

[0108] In the embodiments of this application, unconditional jump instructions are used to directly change the execution address of the program. When the system recognizes this type of instruction, it will immediately end the division of the current node and continue the analysis with the jump target address as the new traversal starting point. Conditional jump instructions are used to determine whether the program jumps to the target address based on a specific logical judgment result. When the system detects this type of instruction, it will simultaneously establish two potential execution paths: one jump path corresponding to the condition being true, and the other sequential path corresponding to the condition not being true, thereby realizing a complete representation of the branch structure. Loop jump instructions reflect the logical structure of repeated execution in the program. When the system detects a loop jump, it will establish a self-closing loop connection for the current node to describe the repeated execution relationship of the loop body, and establish identifiers for the loop entry and exit in the graph structure to control the depth of loop expansion in the subsequent path search phase. Function call instructions are a special form of control transfer, characterized in that the jump target is the entry point of another code segment, and the program needs to return to the calling position to continue running after the execution of that segment is completed. When the system detects a function call instruction, it establishes a directed connection between the calling node and the entry node of the called function, and re-establishes the connection with subsequent instructions of the calling node when a return instruction is detected, in order to maintain the closed loop of the control flow.

[0109] The embodiments of this application, by recognizing various types of control transfer instructions, can fully express the control changes of a program at the assembly level. This mechanism provides a precise basis for node partitioning and control flow graph construction, enabling the system to achieve stable and high-precision logic reconfiguration under complex program structures.

[0110] In the embodiments of this application, directed connections are established between corresponding nodes based on the control transfer relationships between multiple nodes, which is used to fully express the execution flow of the program at the structured level. In the above embodiments, the system has already identified the start and end addresses and type information of each node. At this point, by analyzing the control transfer instructions at the end of each node, the path direction for the program to jump from that node to the next node can be determined. For nodes containing control transfer instructions, the system can read the target address corresponding to the instruction and determine the target node matching that address in the graph structure, thereby establishing a directed connection between the two pointing to the target node. This connection reflects the possible jump relationships of the program at the control flow level and is a key step in constructing the overall control flow diagram.

[0111] In some embodiments, to ensure the accuracy of the connection relationship, the system can perform target node matching and verification before establishing a directed connection. When multiple nodes are detected to have the same starting address as the target address, the system can select the most accurate matching node based on the address range and hierarchical relationship of the nodes, thereby avoiding connection errors caused by overlapping intervals or multi-level calls. Furthermore, in the presence of function call instructions, the system can establish a connection between the calling node and the entry node of the called function, and re-establish a return connection at the function return location to maintain the closure of the program control flow.

[0112] In the embodiments of this application, for nodes that do not contain control transfer instructions, the system assumes that their execution paths are consecutive in address order. Therefore, directed connections can be established between this node and its immediate address-adjacent node. By simultaneously handling both explicit jumps and sequential execution connections, the system can cover all execution paths in the program, thereby achieving complete modeling of the control structure.

[0113] In some embodiments, while establishing node connections, the system can also assign attribute information to the connection edges to identify the jump type, jump conditions, and call relationships. For example, conditional jumps can be accompanied by branch condition flags, unconditional jumps can be accompanied by target offset information, and function call connections can record parameter passing methods or call stack depths. Attribute information can assist in determining the program's execution logic during the subsequent path search phase, improving the accuracy of detection.

[0114] According to the embodiments of this application, by establishing directed connections between nodes, a structured reconstruction of the program control logic is achieved. This not only reflects various control relationships such as sequential execution, branch jumps, loops and function calls, but also supports attribute-based modeling, ensuring the integrity and accuracy of the control flow graph.

[0115] In the embodiments of this application, a path search operation can be performed on the directed graph based on the release node to determine the reachability relationship between different release behaviors in the program and discover execution paths that may have the risk of duplicate releases. Specifically, the system can arbitrarily select a release node as the search starting point and perform path traversal in the graph structure. The traversal can use depth-first search or breadth-first search algorithms to explore all possible paths from the starting release node to other release nodes. During the search process, the system can mark visited nodes to prevent repeated traversal or infinite search caused by loops or recursive structures, thereby ensuring the convergence and accuracy of the search results.

[0116] In some embodiments, the system can select different search strategies based on program structure and resource call characteristics. For programs with complex structures and deep function hierarchies, depth-first search can prioritize obtaining complete function call chains; while for programs with frequent control transfers and many branches, breadth-first search can cover more potential paths in a shorter time. The system can also combine heuristic priority strategies to weight the connection density, call frequency, or resource type of released nodes to improve search efficiency and the hit rate of critical paths.

[0117] In the embodiments of this application, after the path search is completed, the system can filter out target paths from the starting release node to at least one other release node. This path reflects the logical chain where continuous release behavior may occur during program execution. The system can record these paths as candidate secondary release paths and further determine in subsequent analysis stages whether the release operations in the path act on the same memory address, thereby determining whether the risk actually exists.

[0118] In some embodiments, the system can also incorporate path constraint analysis during the path search phase to improve the reliability of the detection results. For example, when filtering target paths, the system can detect whether there are reallocation or memory reset operations between the released nodes in the path. If relevant instructions are detected, the path can be automatically excluded to avoid misjudging it as a risky path. In addition, the system can perform logical reasoning on the branch conditions in the path to verify whether the two releases are executed in the same conditional context, thereby further improving the accuracy of the results.

[0119] In the embodiments of this application, to enhance visualization analysis and result tracing, the system can display the searched candidate paths graphically. In the graph structure, release nodes can be distinguished by specific identifiers, and paths are represented by directed line segments, along with control transfer information between nodes. Users can intuitively view the execution order, conditional branches, and function call relationships of the release operation in the interface, thereby quickly locating the source of risk and triggering conditions.

[0120] Through the embodiments of this application, path search and filtering can identify potential double-release risks in complex programs during the static analysis stage, without relying on dynamic execution or manual auditing. Compared with traditional methods based on symbolic execution or manual detection, it has a wider coverage, higher detection accuracy, and can be extended to complex software environments with multiple modules and multiple threads.

[0121] Figure 4 The flowchart illustrates a method for detecting secondary release risk according to some exemplary embodiments of this application.

[0122] like Figure 4 As shown, the method for detecting the risk of secondary release may include operations S410 to S430.

[0123] In operation S410, the source of parameters for release operation calls in each release node is analyzed sequentially along the control flow order of the nodes in the candidate secondary release path to establish the correspondence between release operations and memory addresses.

[0124] The system can determine the target memory address corresponding to each free operation by tracing register values ​​at the instruction level, parameter pass chains, and memory operation records. To ensure the accuracy of the analysis results, the system can also establish a correspondence between free operations and actual memory addresses by combining variable assignment instructions, pointer pass operations, or function return values ​​of preceding nodes in the path. Through this mapping relationship, the system can clearly characterize the target of each free operation in the path.

[0125] In operation S420, based on the correspondence, it is compared whether the memory addresses acted upon by the release operations of adjacent release nodes are the same.

[0126] When multiple release nodes exist in the path, the system can analyze adjacent node pairs sequentially to determine if the released memory addresses are consistent. If the release operations of adjacent nodes operate on different addresses, the two releases can be considered independent operations with no risk association. If they operate on the same address, further checks are needed to see if the memory address has been reallocated or the variable reset between the two releases. The system can verify whether memory resources have been reinitialized by detecting memory allocation, assignment, or pointer update instructions in intermediate nodes of the path, thus distinguishing between normal releases and abnormal duplicate releases.

[0127] In operation S430, when the comparison result shows that the release operation of any adjacent release node acts on the same memory address, and no reallocation, reset or overwrite operation of the memory address is detected between the release operations, the candidate secondary release path is determined as a path with secondary release risk.

[0128] In some embodiments, to further improve the accuracy and robustness of detection, the system may also introduce a cross-path verification mechanism. When the same memory address is released multiple times in different paths, the system can confirm the global nature of the risk through path merging and cross-analysis, thereby identifying repeated release scenarios hidden in multi-branch or exception handling logic.

[0129] The embodiments of this application enable the automatic identification of reachable paths for resource release behavior at the control flow level, and achieve high-precision risk assessment through parameter tracing and address comparison. This method avoids dependence on dynamic program execution and has the advantages of high detection efficiency, strong scalability, and adaptability to multi-language compilation environments.

[0130] In the embodiments of this application, when multiple release operation call instructions are detected in the same node, the system can further analyze the target objects of these release operations to determine whether there is a duplicate release of the same memory address. Since a node typically represents a sequence of continuously executed instructions, if multiple release operations exist in the same node, it may mean that the program has repeatedly released the same resource within the same logical interval, thus posing a high risk of anomalies. The system can independently parse each release instruction within the node, extracting its applied memory address or related parameter values ​​to establish a correspondence between instructions and memory addresses.

[0131] In some embodiments, when extracting the address of a release operation, the system can perform tracing and analysis by combining register states, parameter passing methods, and memory access records. For parameters passed via registers or the stack, the system can trace back to the upstream assignment instruction to determine the actual memory pointer corresponding to the release call; for indirect addressing, the system can parse the address offset or pointer relationship to identify the target memory region to be released. Through multi-level tracing, the system can accurately locate the memory object acted upon by each release instruction at the assembly level.

[0132] In the embodiments of this application, when the system determines that multiple free calls targeting the same memory address exist within the same node, the node can be identified as a node with a risk of duplicate free. At this time, the system records the node's starting address, the relevant assembly instruction sequence, and memory address identification information, and can mark the node as a high-priority risk point in the detection results. To improve the interpretability of the results, the system can also highlight the node and its corresponding free call location in the visualization output, enabling analysts to intuitively understand the region and logical context in which the duplicate free occurs.

[0133] In some embodiments, the system can also perform cross-validation by combining path-level detection results. When certain candidate risky paths have been identified during the path search phase, if a node traversed by that path is simultaneously identified as a multiple release node, the system can raise the risk level of that node and further confirm its contribution to the path risk. Through this multi-dimensional validation mechanism, the system can distinguish between local repeated releases and cross-path repeated releases, thereby improving the accuracy and reliability of the detection results.

[0134] Through the above embodiments, this application introduces a multi-release detection mechanism at the node level, which can independently identify repeated release behavior in local logic without relying on path traversal, and form a complementary relationship with path analysis. This enables the system to discover risky paths across functions and modules, as well as capture abnormal resource releases within the same logical segment, thereby improving the overall detection coverage and analysis depth.

[0135] Corresponding to the above-described anomaly detection method, embodiments of this application also provide an anomaly detection device.

[0136] Figure 5 A schematic block diagram of an anomaly detection device according to an embodiment of this application is shown.

[0137] like Figure 5 As shown, the anomaly detection device 500 of this embodiment includes a disassembly module 510, a sequential traversal module 520, a directed graph construction module 530, and an anomaly detection module 540.

[0138] The disassembler module 510 can be used to disassemble the program to be analyzed to obtain a set of assembly instructions. In one embodiment, the disassembler module 510 can be used to perform the operation S210 described above, which will not be repeated here.

[0139] The sequential traversal module 520 can be used to sequentially traverse the assembly instruction set, dividing the assembly instruction set based on control transfer instructions to obtain multiple nodes representing program execution path segments. In one embodiment, the sequential traversal module 520 can be used to execute the operation S220 described above, which will not be repeated here.

[0140] The directed graph construction module 530 can be used to establish directed connections between corresponding nodes based on the control transfer relationships between the plurality of nodes, so as to construct a directed graph for representing the program control flow. During the construction of the directed graph, nodes containing release operation calls are marked as release nodes. In one embodiment, the directed graph construction module 530 can be used to execute the operation S230 described above, which will not be repeated here.

[0141] The anomaly detection module 540 can be used to perform path search in the directed graph based on the release node, and to detect the risk of secondary release based on the path search results. In one embodiment, the anomaly detection module 540 can be used to perform the operation S240 described above, which will not be repeated here.

[0142] According to an embodiment of this application, the disassembly module 510 can also be used to scan the executable instructions of the program to be analyzed to obtain the corresponding address information; extract the corresponding machine code based on the address information and disassemble it to obtain assembly instructions arranged in address order; and form the assembly instruction set based on the assembly instructions and the corresponding address information.

[0143] According to an embodiment of this application, the sequential traversal module 520 can also be used to take the program entry address as the current traversal starting point, and sequentially read the assembly instructions in the assembly instruction set based on the address order; in response to detecting the control transfer instruction, divide the assembly instructions from the current traversal starting point to the control transfer instruction into a node; and continue sequential traversal based on the updated traversal starting point until all assembly instructions are divided into the multiple nodes, wherein, in the case of a jump by the control transfer instruction, the target address of the control transfer instruction is used as the updated traversal starting point; in the case of no jump, the address of the assembly instruction following the control transfer instruction is used as the updated traversal starting point. The control transfer instruction includes at least one of unconditional jump instructions, conditional jump instructions, loop jump instructions, and function call instructions.

[0144] According to an embodiment of this application, the directed graph construction module 530 can also be used to determine the corresponding target node for each node containing the control transfer instruction using the target address; establish a directed connection between the node containing the control transfer instruction and the target node; and establish a directed connection between a node that does not contain the control transfer instruction and the node that is immediately adjacent in the address order.

[0145] According to an embodiment of this application, the anomaly detection module 540 can also be used to perform a depth-first search or a breadth-first search in the directed graph with any release node as the search starting point, and to mark the visited nodes during the search process; and to filter out the target path from the starting release node to at least one other release node in the path search results, and to use the target path as a candidate secondary release path, and to detect the risk of secondary release based on the candidate secondary release path.

[0146] According to an embodiment of this application, the anomaly detection module 540 can also be used to sequentially analyze the source of parameters of the release operation call in each release node along the control flow order of the nodes in the candidate secondary release path, so as to establish a correspondence between the release operation and the memory address; based on the correspondence, compare whether the memory address acted on by the release operation of adjacent release nodes is the same; and when the comparison result shows that the release operation of any adjacent release node acts on the same memory address, and no reallocation, reset or overwrite operation of the memory address is detected between the release operations, the candidate secondary release path is determined as a path with secondary release risk.

[0147] According to an embodiment of this application, the anomaly detection module 540 can also be used to extract the memory address of each release operation when multiple release operation call instructions are detected in the same node; and to determine the corresponding node as a node with a risk of secondary release in response to multiple release operation calls for the same memory address in the same node.

[0148] According to embodiments of this application, any multiple modules among the disassembly module 510, sequential traversal module 520, directed graph construction module 530, and anomaly detection module 540 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the disassembly module 510, sequential traversal module 520, directed graph construction module 530, and anomaly detection module 540 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the disassembly module 510, sequential traversal module 520, directed graph construction module 530, and anomaly detection module 540 may be implemented at least partially as a computer program module that can perform corresponding functions when the computer program module is run.

[0149] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing an anomaly detection method according to an embodiment of this application.

[0150] like Figure 6 As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage portion 608 into a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0151] RAM 603 stores various programs and data required for the operation of electronic device 600. Processor 601, ROM 602, and RAM 603 are interconnected via bus 604. Processor 601 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 602 and / or RAM 603. It should be noted that the programs may also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0152] According to embodiments of this application, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output (I / O) interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0153] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0154] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 602 and / or RAM 603 and / or one or more memories other than ROM 602 and RAM 603 described above.

[0155] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the anomaly detection method provided in the embodiments of this application.

[0156] When the computer program is executed by the processor 601, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0157] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0158] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0159] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0160] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0161] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0162] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. Without departing from the scope of this application, those skilled in the art can make various substitutions and modifications, all of which should fall within the scope of this application.

Claims

1. An anomaly detection method, characterized in that, The method includes: Disassemble the program to be analyzed to obtain the set of assembly instructions; The assembly instruction set is sequentially traversed, and the assembly instruction set is divided based on control transfer instructions to obtain multiple nodes that represent program execution path segments; Based on the control transfer relationships among the multiple nodes, directed connections are established between corresponding nodes to construct a directed graph representing the program control flow. During the construction of the directed graph, nodes containing release operation calls are marked as release nodes. Based on the release node, a path search is performed in the directed graph, and the risk of secondary release is detected based on the path search results.

2. The method according to claim 1, characterized in that, The disassembly of the program to be analyzed yields a set of assembly instructions, including: The executable instructions of the program to be analyzed are scanned to obtain the corresponding address information; Based on the address information, the corresponding machine code is extracted and disassembled to obtain assembly instructions arranged in address order; and Based on the assembly instructions and their corresponding address information, the assembly instruction set is formed.

3. The method according to claim 2, characterized in that, The step of sequentially traversing the assembly instruction set, dividing the assembly instruction set based on control transfer instructions, and obtaining multiple nodes to represent program execution path segments includes: Using the program entry address as the current traversal starting point, the assembly instructions in the assembly instruction set are read sequentially based on the address order. In response to the detection of the control transfer instruction, a node is formed from the assembly instruction corresponding to the current traversal starting point to the control transfer instruction; and The sequential traversal continues from the update traversal starting point until all assembly instructions are divided into the multiple nodes. In the case of a control transfer instruction causing a jump, the target address of the control transfer instruction is used as the update traversal starting point; in the case of no jump, the address of the assembly instruction following the control transfer instruction is used as the update traversal starting point.

4. The method according to claim 3, characterized in that, The control transfer instructions include at least one of the following: unconditional jump instructions, conditional jump instructions, loop jump instructions, and function call instructions.

5. The method according to claim 3, characterized in that, The establishment of directed connections between corresponding nodes based on the control transfer relationships between the multiple nodes includes: For each node containing the control transfer instruction, the corresponding target node is determined by the target address; a directed connection is established between the node containing the control transfer instruction and the target node, pointing to the target node; For nodes that do not contain the control transfer instruction, a directed connection is established with the node immediately adjacent in the address order.

6. The method according to claim 1, characterized in that, The process of performing a path search in the directed graph based on the released node, and detecting the risk of secondary release based on the path search results, includes: Starting from any release node, perform a depth-first search or breadth-first search in the directed graph, and mark visited nodes during the search process. as well as The target path from the starting release node to at least one other release node is selected from the path search results. The target path is used as a candidate secondary release path, and the risk of secondary release is detected based on the candidate secondary release path.

7. The method according to claim 6, characterized in that, The detection of secondary release risk based on the candidate secondary release path includes: Following the control flow order of the nodes in the candidate secondary release path, the source of parameters for the release operation call in each release node is analyzed in turn to establish the correspondence between the release operation and the memory address; Based on the aforementioned correspondence, compare whether the memory addresses affected by the release operations of adjacent release nodes are the same; as well as When the comparison results show that the release operation of any adjacent release node acts on the same memory address, and no reallocation, reset or overwrite operation of the memory address is detected between the release operations, the candidate secondary release path is determined as a path with secondary release risk.

8. The method according to claim 6 or 7, characterized in that, The method further includes: When multiple release operation call instructions are detected in the same node, the memory address of each release operation is extracted. as well as If multiple free operation calls are made to the same memory address within the same node, the corresponding node will be identified as a node with a risk of double free.

9. An anomaly detection device, characterized in that, The device includes: The disassembler module is used to: disassemble the program to be analyzed to obtain the set of assembly instructions; The sequential traversal module is used to: sequentially traverse the assembly instruction set, divide the assembly instruction set based on control transfer instructions, and obtain multiple nodes to represent program execution path segments; A directed graph construction module is used to: establish directed connections between corresponding nodes based on the control transfer relationships between the plurality of nodes, so as to construct a directed graph representing the program control flow, wherein, during the construction of the directed graph, nodes containing release operation calls are marked as release nodes; and The anomaly detection module is used to: perform path search in the directed graph based on the release node, and detect the risk of secondary release based on the result of the path search.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images