Method for identifying compiled binary codes based on graph network

Abstract

The invention discloses a compiled binary code recognition method based on a graph network. The method comprises the following steps: acquiring a compiled binary code to be identified in a control system, performing decompilation to obtain a decompiled pseudo code and inheritance relationships of various types in the decompiled pseudo code, and constructing a member function table; constructing a software variable relation table based on the relation between the software variables of the classes; based on the software variable relation table, constructing a directed subgraph of the member function; aggregating the directed sub-graphs into a class level general graph according to the calling relationship; and performing variable semantic inference based on the class hierarchy general graph, and identifying the type and semantics of the compiled binary code so as to determine the function of the compiled binary code in the control system. According to the method, the directed subgraph and the class level general graph of the decompilation pseudo-code can be automatically constructed, then variable type semantic inference is carried out based on a graph network structure, the decompilation pseudo-code recognition problem can be systematically solved, and therefore more efficient and accurate technical support is provided for robot reverse engineering and software analysis.

Description

Technical Field

[0001] This invention relates to a method for identifying compiled binary code, which falls under the field of software reverse engineering technology, and specifically to a method for identifying compiled binary code based on graph networks. Background Technology

[0002] As control software becomes increasingly complex, object-oriented programming has become the mainstream development method. However, in practical applications, it is necessary to analyze and understand the compiled binary code through decompilation. This is especially true in robot control systems, where reconstructing and analyzing the class structure and interrelationships of the control software is crucial for gaining a deep understanding of its internal state transitions, data transmission, and data processing mechanisms.

[0003] In software reverse engineering, when faced with compiled binary code, disassemblers are typically used to generate decompiled pseudocode to understand the code logic. However, object-oriented features such as classes, inheritance, and polymorphism in high-level languages ​​are often lost after compilation, resulting in missing class structure information and ambiguous variable semantics in the decompiled pseudocode, significantly increasing the difficulty of reverse engineering. Existing techniques largely rely on manual experience or simple pattern matching, making it difficult to systematically reconstruct complex class hierarchies and variable semantic relationships.

[0004] Existing class refactoring techniques primarily rely on static analysis of decompiled code, attempting to infer class structure through class functions, disassembled code, and other functions' usage of class members. However, this approach has the following limitations: First, the parsing of virtual function tables and the reconstruction of virtual function call relationships lack systematicity and accuracy; second, the types, meanings, and functions of class member variables are difficult to obtain directly from decompiled code, leading to insufficient reliability in variable refactoring; finally, there is a lack of effective tools and methods to integrate scattered class information, making it difficult to form a complete class hierarchy and variable relationship diagram.

[0005] Furthermore, while existing reverse engineering tools can provide decompiled code, the variable names they output are usually automatically generated temporary names, resulting in extremely poor readability and further increasing the difficulty of analysis and understanding. Especially when dealing with complex scenarios such as multiple inheritance and virtual function overloading, existing technologies often fail to accurately reconstruct the original design intent of the class, and thus cannot infer the precise function of the compiled binary code in the robot control system. Summary of the Invention

[0006] To address the problems existing in the background art, the present invention provides a method for identifying compiled binary code based on graph networks.

[0007] The technical solution adopted in this invention is: The graph network-based method for identifying compiled binary code of the present invention includes: Step 10: Obtain the compiled binary code to be identified in the control system, decompile the compiled binary code to obtain the decompiled pseudocode and the inheritance relationship of each class to be reconstructed, and then construct the member function table of each class, which includes several member functions.

[0008] Step 20: Based on the decompiled pseudocode, obtain the software variables of each class, and construct a software variable relationship table based on the relationships between the software variables of each class; based on the software variable relationship table, traverse the member function tables of each class and construct a directed subgraph for each member function.

[0009] Step 30: Based on the calling relationships of each member function, aggregate all directed subgraphs into a class hierarchy graph.

[0010] Step 40: Perform variable semantic inference and class variable reconstruction based on the class hierarchy diagram to identify the type and semantics of the compiled binary code, thereby determining the function of the compiled binary code in the control system. The identified compiled binary code can be modified and optimized to better control the current control system.

[0011] In step 10, the inheritance relationships of each class include single inheritance, no inheritance, and multiple inheritance. The parent class and child class are determined according to the inheritance relationship. Single inheritance and multiple inheritance classes and their parent classes have virtual functions, while no inheritance classes have no virtual functions. The child class inherits some or all of the virtual functions of the parent class. Based on the inheritance relationship of each class, the class names and member functions of the class in the decompiled pseudocode are traversed to construct the member function table of each class. The member function table includes the virtual functions of each parent class and the overloaded virtual functions of several classes, as well as all non-virtual functions in the decompiled pseudocode, excluding inherited virtual functions that are not overloaded, all of which are treated as member functions.

[0012] In step 20, the software variables include class member variables, local variables, input parameters, and output parameters. For each member function in the member function table of each class, all software variables related to the member function are extracted from the software variable relationship table, including the member function's local variables, input parameters, output parameters, and class member variables accessed by the member function. Each software variable of the member function is mapped to a graph node. Then, based on the relationships between the various software variables in the software variable relationship table, all relationship records where both sides belong to the variables related to the current member function are extracted. The relationship between every two graph nodes with a relationship is mapped to a directed edge. Then, every two graph nodes with a relationship are connected by the directed edge, and labels and additional attributes of the directed edges are added according to the relationship type between the software variables. Finally, a directed subgraph of the member function is constructed.

[0013] Step 30 is as follows: Step 31: For each member function's directed subgraph, obtain several graph nodes representing the function's input parameters, output parameters, and class member variables as potential connection points; at the same time, based on the explicit calling relationships between the member functions, the decompiled pseudocode can be directly analyzed to obtain the directed subgraphs of every two member functions with explicit calling relationships as subgraph pairs to be aggregated.

[0014] Step 32: Based on the subgraph pairs to be aggregated, determine the call edges and data flow edges between potential connection points.

[0015] Step 33: Based on the determined call edges and data flow edges, connect the potential connection points of the directed subgraphs of all member functions, so that the originally independent directed subgraphs are integrated into a single directed graph through call edges and data flow edges, and an initial overall graph is constructed. Then, optimize the initial overall graph, merge duplicate potential connection points, eliminate isolated potential connection points that are not connected by call edges or data flow edges, and finally generate the class hierarchy overall graph, while updating the software variable relationship table.

[0016] In step 32, for each pair of subgraphs to be aggregated, the pair is divided into a calling subgraph and a called subgraph according to the explicit calling relationship. The potential connection point in the calling subgraph that initiates the call is taken as the calling node, and the potential connection point in the called subgraph that is called by the called node is taken as the called node. The directed edge from the calling node to the called node is taken as the calling edge to connect the calling node and the called node, thereby connecting the pair of subgraphs to be aggregated.

[0017] For every two directed subgraphs, identify potential connection points with data transmission relationships. These potential connection points represent data transmission relationships between class member variables and between input and output parameters. The potential connection points in one directed subgraph that output data to the other are designated as output nodes, and the potential connection points in the other directed subgraph that receive data from the other are designated as receiving nodes. The directed edges from the output node to the receiving node are designated as data flow edges to connect the output and receiving nodes, representing the transfer and dependency of data between different functions, thus connecting the two directed subgraphs. Simultaneously, potential connection points representing class member variables that receive output data from the same output node are merged into shared nodes.

[0018] Step 40 is described in detail below: Step 41: Based on the pre-defined inference evidence base containing known information about member functions, the pre-defined inference evidence base contains known information about member functions. Within each member function of the class hierarchy graph, the graph nodes representing class member variables and local variables in the directed subgraph of the member function are used as inference nodes. Semantic inference is performed on the inference nodes to obtain the initial type and semantics of the inference nodes.

[0019] Step 42: Based on the initial type and semantics of each inference node in each member function, and using the global graph network structure of the class hierarchy graph, propagate and complete the initial type and semantics of each inference node across functions to obtain the final type and semantics of each inference node.

[0020] Step 43: Construct the final type and semantics of each inferred node of each class into a variable annotation table for the class. Annotate the variable annotation table back into the decompiled pseudocode in a readable form, or persist the class hierarchy graph model and its associated type and semantic attributes to form a queryable annotation database of the compiled binary code of the control system.

[0021] In step 41, for each inference node within a member function, the labels and additional attributes of several adjacent inference nodes connected to the inference node and the directed edges between them are obtained according to the updated software variable relationship table. If the current inference node is connected to a calling node that matches the function name evidence through a calling edge, the initial type and semantics of the current inference node are directly inferred based on the name of the member function of the current inference node. If the inference node is passed as a parameter to a known library function in the library function / API evidence, the initial type and semantics of the current inference node are inferred based on the parameter definition of the known library function. If the current inference node is connected to an inference node that matches the function name evidence through a data flow edge, the initial type and semantics of the current inference node are inferred based on the label and additional attributes of the data flow edge.

[0022] In step 42, for shared nodes in the class hierarchy graph that are shared by multiple directed subgraphs, the initial type and semantics inferred in all directed subgraphs are obtained. If the initial type and semantics of the current shared node are consistent in all directed subgraphs, they are directly used as the final type and semantics of the current shared node. If they are inconsistent, the current shared node is marked as pending. Iterative inference is performed based on the call edges and data flow edges between the directed subgraphs. If member function A calls member function B, and the initial semantics and return type of member function B have been inferred, the initial semantics and type of member function B are directly propagated back along the call edge to the calling node in member function A as its final semantics and type. If member function A transmits data to member function B, and the initial semantics and return type of member function B have been inferred, the initial semantics and type of member function B are directly propagated back along the data flow edge to the output node in member function A as its final semantics and type. The iteration continues until no new semantics and types are inferred, or the preset number of iterations is reached, to determine the final type and semantics of each inferred node.

[0023] The electronic device of the present invention includes: a memory and a processor coupled to each other, wherein the memory stores program data, and the processor invokes the program data to execute the method described above.

[0024] The present invention provides a computer-readable storage medium having program data stored thereon, characterized in that the program data, when executed by a processor, implements the method described above.

[0025] This invention reconstructs class hierarchy relationships, class functions, and class variables by analyzing the decompiled binary code. It determines the parent class and inheritance relationships by parsing the class constructor. Virtual function table pointers are extracted from the decompiled code to locate virtual function addresses and establish a mapping between virtual functions and actual functions. The variable storage layout is determined based on the class instantiation code, and a class variable association graph model is constructed. Aggregate analysis integrates scattered class information to improve the accuracy of variable inference. By combining function calls, code execution logs, and standard library function parameters, the types and semantics of member variables are inferred, enabling reverse analysis and understanding of software developed using object-oriented methods.

[0026] The beneficial effects of this invention are: The method of this invention can automatically extract class inheritance relationships, member functions, and variables from decompiled pseudocode, and form a class hierarchy graph by constructing and aggregating directed subgraphs. Then, based on the graph network structure, it can perform semantic inference of variable types. It can systematically solve problems such as class hierarchy relationship reconstruction, virtual function table parsing, and member variable inference, thereby providing more efficient and accurate technical support for reverse engineering and software analysis in the field of robotics. Attached Figure Description

[0027] Figure 1 This is a schematic flowchart of the method of the present invention; Figure 2 The first directed subgraph constructed for the class to be refactored in this invention; Figure 3 The second directed subgraph is constructed for the class to be refactored in this invention; Figure 4 The third directed subgraph constructed for the class to be refactored in this invention; Figure 5 The fourth directed subgraph constructed for the class to be refactored in this invention; Figure 6 The fifth directed subgraph constructed for the class to be refactored in this invention; Figure 7 The sixth directed subgraph constructed for the class to be refactored in this invention; Figure 8 The seventh directed subgraph constructed for the class to be refactored in this invention; Figure 9 The eighth directed subgraph constructed for the class to be refactored in this invention; Figure 10 The ninth directed subgraph constructed for the class to be refactored in this invention; Figure 11 This is the initial overall diagram of the polymerization process of the present invention. Detailed Implementation

[0028] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0029] like Figure 1 As shown, the graph network-based binary code recognition method of the present invention is as follows: Step 10: Obtain the compiled binary code to be identified in the control system. After decompiling the compiled binary code, obtain the decompiled pseudocode and the inheritance relationship of each class to be reconstructed. A disassembler can be used to perform static reverse analysis on the compiled binary code to obtain the decompiled pseudocode. Then, based on the class constructors of each class in the decompiled pseudocode, extract the inheritance relationship of each class to confirm whether the class has inheritance and its parent class. Then, construct the member function table of each class, which includes several member functions.

[0030] The inheritance relationships of each class include single inheritance, no inheritance, and multiple inheritance. The parent class and child class are identified according to the inheritance relationship. Single inheritance and multiple inheritance classes and their parent classes have virtual functions, while no inheritance classes have no virtual functions. The child class inherits some or all of the virtual functions of the parent class. Based on the inheritance relationship of each class, the class names and member functions of each class in the decompiled pseudocode are traversed to construct the member function table of each class. The member function table includes the virtual functions of each parent class and the overloaded virtual functions of several classes, as well as all non-virtual functions in the decompiled pseudocode, excluding inherited virtual functions that are not overloaded, all of which are treated as member functions.

[0031] When a class's constructor contains an instruction to call its parent class's constructor via an instance pointer, accompanied by instance pointer assignment, the parent class is determined to be a direct parent class, indicating that the class is a single-inheritance class, and both the current class and its parent classes have virtual functions. When a class's constructor does not call any parent class constructor, the class is a non-inheritance class. For classes with multiple inheritance structures, the constructor will apply different offsets to the instance pointer and call multiple parent class constructors. By identifying these offset calls, the inheritance relationship formed by multiple parent classes can be determined, indicating that the class is a multiple-inheritance class. Each class constructor represents a portion of the code in the decompiled pseudocode, and virtual function table pointers exist within these code regions.

[0032] When constructing the member function table, the process begins by searching for the assignment statement of the virtual function table pointer in the constructors of each class to locate the starting address of the virtual function table in memory. Then, virtual function address entries are read sequentially from this address to obtain the contents of the virtual function table. If no virtual function table pointer is found, it means there are no virtual functions. The virtual function definitions are then obtained from the virtual function table of the class to be refactored (the class with virtual functions). It is determined whether the virtual function is an overloaded virtual function. If so, the virtual function is marked as overloaded and written into the member function table. If the virtual function is not overloaded, it means it is inherited from a parent class, and the parent class's virtual function is written into the member function table. This process continues, reading and marking the virtual function table until the end marker is encountered, at which point the virtual function resolution is complete.

[0033] Step 20: Based on the decompiled pseudocode, obtain the software variables of each class, and construct a software variable relationship table based on the relationships between the software variables of each class; based on the software variable relationship table, traverse the member function tables of each class and construct a directed subgraph for each member function.

[0034] Software variables include class member variables, local variables, input parameters, and output parameters. For each member function in the member function table of each class, all software variables related to the member function are extracted from the software variable relationship table, including the member function's local variables, input parameters, output parameters, and class member variables accessed by the member function. Each software variable of the member function is mapped to a graph node. Then, based on the relationships between the various software variables in the software variable relationship table, all relationship records where both sides belong to the variables related to the current member function are extracted. The relationship between every two related graph nodes is mapped to a directed edge. Then, every two related graph nodes are connected by directed edges, and labels and additional attributes are added to the directed edges according to the relationship type between the software variables. Finally, a directed subgraph of the member function is constructed.

[0035] Relationships between software variables include offsets, assignments, operations, comparisons, function calls, references, subscript access, pointer dereferences, and member access relationships. The mapping between these relationship types and directed edges is as follows: Offset relationship, i.e., the form this->Var1: Create a directed edge from node this to node this->Var1, with the edge label "offset".

[0036] Assignment relationship, i.e., a=b: Create a directed edge from node b to node a, with the edge label "Assignment".

[0037] The operation relationship, i.e., c = a + b, is as follows: Create a directed edge from node a to node c, and simultaneously create a directed edge from node b to node c. The edge label is "operation", and the additional attribute "+" is added to the edge.

[0038] For comparison relationships, i.e., a > b: create a bidirectional edge from node a to node b, label the edge "comparison", and add the additional attribute ">".

[0039] Function call relationships, i.e., the form of func(a, b): Create directed edges from nodes a and b to a special node representing the function func operation, with the edge label being "function call" and the additional attribute "func" added to the edge.

[0040] Reference relationship, i.e., int&r = a: Create a directed edge from node a to node r, with the edge label "reference".

[0041] Subscript access relationship, i.e., arr[i] form: Create a directed edge from node arr to a temporary node representing the access result, with the edge label "subscript access" and the additional attribute "i".

[0042] Pointer dereference relationship, i.e., in the form of *p: Create a directed edge from node p to a temporary node representing the dereference result, with the edge label "pointer dereference".

[0043] Member access relationship, in the form of obj.member: Create a directed edge from node obj to node member, with the edge label "member access".

[0044] Step 30: Based on the calling relationships of each member function, aggregate all directed subgraphs into a class hierarchy graph, as follows: Step 31: For each member function's directed subgraph, obtain several graph nodes representing the function's input parameters, output parameters, and class member variables as potential connection points; at the same time, based on the explicit calling relationships between the member functions, the decompiled pseudocode can be directly analyzed to obtain the directed subgraphs of every two member functions with explicit calling relationships as subgraph pairs to be aggregated.

[0045] Step 32: Based on the subgraph pairs to be aggregated, determine the call edges and data flow edges between potential connection points.

[0046] For each pair of subgraphs to be aggregated, the pair is divided into a calling subgraph and a called subgraph according to the explicit calling relationship. The potential connection point that initiates the call in the calling subgraph is taken as the calling node, and the potential connection point that is called by the called node in the called subgraph is taken as the called node. The directed edge from the calling node to the called node is taken as the calling edge to connect the calling node and the called node, thereby connecting the pair of subgraphs to be aggregated.

[0047] For every two directed subgraphs, identify potential connection points with data transmission relationships. These potential connection points represent data transmission relationships between class member variables and between input and output parameters. The potential connection points in one directed subgraph that output data to the other are designated as output nodes, and the potential connection points in the other directed subgraph that receive data from the other are designated as receiving nodes. The directed edges from the output node to the receiving node are designated as data flow edges to connect the output and receiving nodes, representing the transfer and dependency of data between different functions, thus connecting the two directed subgraphs. Simultaneously, potential connection points representing class member variables that receive output data from the same output node are merged into shared nodes.

[0048] Step 33: Based on the determined call edges and data flow edges, connect the potential connection points of the directed subgraphs of all member functions, so that the originally independent directed subgraphs are integrated into a single directed graph through call edges and data flow edges, and an initial overall graph is constructed. Then, optimize the initial overall graph, merge duplicate potential connection points, eliminate isolated potential connection points that are not connected by call edges or data flow edges, and finally generate the class hierarchy overall graph, while updating the software variable relationship table.

[0049] Step 40: Based on the class hierarchy diagram, perform variable semantic inference and class variable reconstruction to identify the type and semantics of the compiled binary code, thereby determining the function of the compiled binary code in the control system. The identified compiled binary code can be modified and optimized to better control the current control system. Specifically: Step 41: Based on the pre-defined inference evidence base containing known information about member functions, the pre-defined inference evidence base contains known information about member functions. Within each member function of the class hierarchy graph, the graph nodes representing class member variables and local variables in the directed subgraph of the member function are used as inference nodes. Semantic inference is performed on the inference nodes to obtain the initial type and semantics of the inference nodes.

[0050] The pre-defined evidence base is as follows: Function name evidence: Inferring the semantic type and purpose of related parameters or return values ​​by matching member function names.

[0051] Code context evidence: Evidence of variable meaning is obtained by integrating string constants, numerical constants, debugging symbols, and code execution log information from decompiled pseudocode.

[0052] Library function / API evidence: By identifying calls to known standard library functions or system application programming interfaces (APIs), and based on the known parameter types and return value types of these functions, the types and semantics of the variables interacting with them are constrained and inferred.

[0053] Step 42: Based on the initial type and semantics of each inference node in each member function, and using the global graph network structure of the class hierarchy graph, propagate and complete the initial type and semantics of each inference node across functions to obtain the final type and semantics of each inference node.

[0054] For shared nodes in the class hierarchy graph that are shared by multiple directed subgraphs, obtain their initial type and semantics inferred in all directed subgraphs. If the initial type and semantics of the current shared node are consistent across all directed subgraphs, they are directly used as the final type and semantics of the current shared node. If they are inconsistent, the current shared node is marked as pending. Iterative inference is performed based on the call edges and data flow edges between the directed subgraphs. If member function A calls member function B, and the initial semantics and return type of member function B have been inferred, then the initial semantics and type of member function B are directly propagated back along the call edge to the calling node in member function A as its final semantics and type. If member function A transmits data to member function B, and the initial semantics and return type of member function B have been inferred, then the initial semantics and type of member function B are directly propagated back along the data flow edge to the output node in member function A as its final semantics and type. The iteration continues until no new semantics and types are inferred, or the preset number of iterations is reached, to determine the final type and semantics of each inferred node.

[0055] Step 43: Construct the final type and semantics of each inferred node of each class into a variable annotation table for the class. Annotate the variable annotation table back into the decompiled pseudocode in a readable form, or persist the class hierarchy graph model and its associated type and semantic attributes to form a queryable annotation database of the compiled binary code of the control system.

[0056] For each inference node within a member function, the labels and additional attributes of several adjacent inference nodes connected to the inference node and the directed edges between them are obtained based on the updated software variable relationship table. If the current inference node is connected to a calling node that matches the function name evidence through a calling edge, the initial type and semantics of the current inference node are directly inferred based on the name of the member function of the current inference node. For example, if the function name is string GetCompassState, the type is string, and its semantics is to obtain the electronic compass state. If the inference node is passed as a parameter to a known library function in the library function / API evidence, the initial type and semantics of the current inference node are inferred based on the parameter definition of the known library function. For example, when variable v1 appears in the strlen(v1) call, the initial type and semantics of the current inference node can be inferred based on the prototype definition of the strlen function: size_t strlen(const char *str) infers that the type of variable v1 is a pointer to a character constant (i.e., a string), and its semantics are the input parameter of the string of length to be calculated. If the current inference node is connected to an inference node that matches the function name evidence through a data flow edge, then the initial type and semantics of the current inference node are inferred based on the label and additional attributes of the data flow edge. The inference node can be either an input or an output. An inference node that matches the function name evidence can have both input and output. The current inference node can be either the input or the output of an inference node that matches the function name evidence. If a variable node A points to node B through an "assignment" edge, and the semantics of node A have been inferred, then the semantic attributes of node A are propagated to node B. If node A and node B both point to node C through an "operation" edge, and the types of nodes A and B are known, then the type of node C can be inferred.

[0057] The specific implementation process of this invention is as follows: The following example uses a simple object-oriented test code, compiled with gcc 2.2.0, and decompiled using IDA (Interactive Disassembler Professional) software for further illustration, but does not constitute a limitation on the scope of protection of this invention.

[0058] The test code contains a base class `Class_A` and a derived class `Class_B`. The base class `Class_A` contains three public members: `Var1`, `Var2`, and `Var3`, and two private members: `result` and `ResultVal`. It also includes eight methods, five of which are non-virtual functions and three are virtual functions. The derived class `Class_B` inherits from the base class `Class_A`, overrides the virtual functions `func1` and `func3`, and adds a member variable `Var4`. In the main function, instances of both the base class `Class_A` and the derived class `Class_B` are constructed, and their member functions are called. Then, the following steps are performed on the test code: Step 10: Use a reverse engineering tool to obtain the decompiled code of the compiled binary code to be identified.

[0059] Step 20: Refactor the Class_B class. The decompiled code of the Class_B constructor is as follows: void __cdecl Class_B::Class_B(Class_B *const this, int V2) { Class_B *thisa; / / [rsp+30h] [rbp+10h] thisa = this; Class_A::Class_A((Class_A *const)this, V2); thisa->_vptr_Class_A = (int (**)(...))&off_405630; thisa->Var4 = 14; } Then, when inputting the two parameters of the Class_B constructor, a1 is an instance pointer. It can be seen that a1 is called by the Class_A constructor in Class_A::Class_A(a1, a2);, which means that Class_A is the direct parent class of Class_B.

[0060] Step 30: Extract all member functions from the decompiled code and construct the complete member function table as follows: 1. Class_A member function table: Constructor: Class_A::Class_A.

[0061] Virtual functions: Class_A::func1, Class_A::func2, Class_A::func3.

[0062] Non-virtual functions: Class_A::SetResult, Class_A::GetResult, Class_A::SetResultVal, text_53 (i.e., GetResultVal).

[0063] 2. Class_B member function table: Constructor: Class_B::Class_B.

[0064] Overloaded virtual functions: Class_B::func1, Class_B::func3.

[0065] Inheriting virtual functions: Class_A::func2.

[0066] The virtual function is then analyzed as follows: Step 31: In the Class_B constructor, locate the virtual table pointer _vptr_Class_A, pointing to address off_405630.

[0067] Step 32: Read the contents of the virtual table and obtain the addresses of the virtual functions in sequence: Class_B::func1 (overloaded), Class_A::func2 (inherited), and Class_B::func3 (overloaded).

[0068] Step 33: Mark the overloaded virtual functions and write them into the member function table. Inherited virtual functions directly reference the parent class definition.

[0069] Step 40: Extract class-related variables from the decompiled code, including the following: Class_A member variables: Var1, Var2, Var3, result, ResultVal.

[0070] Class_B member variables: All variables inherited from Class_A, with the addition of Var4.

[0071] Function parameters and local variables: The input parameters, output parameters, and local variables of each function.

[0072] Step 50: Record the relationships between variables to form the following relationship table: 1. An example of an assignment relationship is as follows: this->ResultVal = Val / 2 (SetResultVal function).

[0073] this->Var1 = V(Class_A constructor).

[0074] 2. Examples of operational relationships are as follows: return xa + ya (func1 function).

[0075] k = Vala * Vala + thisa->Var2 - thisa->Var3 (SetResult function).

[0076] 3. An example of a function call relationship is as follows: Class_A::SetResultVal(thisa, Vala) (SetResult function).

[0077] Class_A::Class_A((Class_A *const)this, V2) (Class_B constructor).

[0078] 4. An example of member access relationships is as follows: thisa->Var4 + ya (Class_B::func3 function).

[0079] thisa->result&&thisa->Var3>10 (GetResult function).

[0080] Step 60, construct the directed subgraph of member functions, such as Figure 2 As shown, this is a directed subgraph `void __cdecl ClassA::Class A(int)`. The nodes of this directed subgraph include: the class instance pointer `this`, the input parameter `V`, and the class member variable `this+4`. Node `V` points to node `this+4` via a directed edge indicating that the input parameter is assigned to the class member variable in the constructor. Node `this` is connected to `this+4` via an offset relationship. Figure 3 As shown, the directed subgraph `void __cdecl Class A::SetResultVal(int)` contains the following nodes: the class instance pointer `this`, the input parameter `Val`, and the class member variable `this+20`. The node `Val` points to the node `this+20` via a directed edge indicating an operation on the input parameter, which is then written to the class member variable. The node `this` is connected to `this+20` via an offset relationship. Figure 4As shown, the directed subgraph `int __cdecl Class A::GetResultVal (Class_A *constthis)` contains the following nodes: the class instance pointer `this`, the class member variable `thisa`, `thisa+20`, and the return value node. The node `this` is connected to `thisa` through an assignment relationship, and the node `thisa` points to `thisa+20` and the return value node through an offset relationship, indicating that the function returns the current value of the class member variable; for example... Figure 5 As shown, this is a directed subgraph `bool __cdecl Class A::GetResult(void)`. The nodes of this directed subgraph include: the class instance pointer `this`, the class member variable `this+12`, the class member variable `this+16`, and the return value node. The node `this` is used to obtain nodes `this+12` and `this+16` through an "offset" relationship, and the nodes `this+12` and `this+16` are used to obtain the return value node through an "operation" relationship; for example... Figure 6 As shown, the directed subgraph `void __cdecl Class A::SetResult(int)` contains the following nodes: the class instance pointer `this`, the input parameter `Val`, the local variable `k`, and the class member variables `thisa+8`, `thisa+12`, and `thisa+16`. Nodes `Val`, `thisa+8`, and `thisa+12` are connected by directed edges that point to node `k` through "operation" relationships; node `Val` points to `thisa+16` through "comparison" relationships and is written to this member variable through "assignment" relationships; as shown... Figure 7 As shown, the directed subgraph `int __cdecl Class B::func1(int,int)` has nodes including: the class instance pointer `this`, input parameter `x`, input parameter `y`, and the class member variable `thisa+4`. Nodes `x`, `y`, and `thisa+4` all point to a function call node through an "operation" relationship, indicating that the calculation result is passed as an argument to the called function; the node `this` is connected to `this+4` through "assignment" and "offset" relationships; as shown... Figure 8 As shown, this is a directed subgraph `int __cdecl Class B::func3(int)`. The nodes of this directed subgraph include: the class instance pointer `this`, the input parameter `y`, the class member variable `thisa+24`, and the return value node. Nodes `thisa+24` and `y` are connected by a directed edge through an "operation" relationship, pointing to the return value node; the node `this` is connected to `thisa+24` through "assignment" and "offset" relationships. Figure 9As shown, this is a directed subgraph `void __cdeclClass B::Class B(int)`. The nodes of this directed subgraph include: the class instance pointer `this`, the input parameter `V2`, and the class member variable `thisa+24`. Node `V2` points to the parent class constructor call node through function call relationships; node `thisa+24` is initialized through an assignment relationship; node `this` is connected to `thisa+24` through both assignment and offset relationships. Figure 10 As shown, this is a directed subgraph `int __cdecl Class A::func2(int)`. The nodes of this directed subgraph include: the class instance pointer `this`, the input parameter `y`, the class member variable `thisa+8`, and the return value node. Nodes `thisa+8` and `y` both point to the return value node through assignment and offset relationships; the node `this` is connected to `thisa+8` through assignment and offset relationships.

[0081] A. Taking Class_A::SetResult as an example, such as Figure 6 As shown, the directed subgraph is constructed as follows: void __cdecl Class_A::SetResult(Class_A *const this, int Val) { __int64 v2; / / rax __int64 v3; / / rax __int64 v4; / / rax unsigned int k; / / [rsp+2Ch] [rbp-4h] Class_A *thisa; / / [rsp+40h] [rbp+10h] int Vala; / / [rsp+48h] [rbp+18h] thisa = this; Vala = Val; v2 = std::operator<< <std::char_traits <char>>(refptr__ZSt4cout, "SetResult called"); std::ostream::operator<<(v2, refptr__ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_); k = Vala * Vala + thisa->Var2 - thisa->Var3; v3 = std::operator<<<std::char_traits <char>>(refptr__ZSt4cout, "k="); v4 = std::ostream::operator<<(v3, k); std::ostream::operator<<(v4, refptr__ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_); thisa->result = Vala>100; Class_A::SetResultVal(thisa, Vala); } Step 61: Create nodes, including this, Vala, k, thisa->Var2, thisa->Var3, thisa->result, etc.

[0082] Step 62: Map the directed edges according to the relation table as follows: k = Vala * Vala + thisa->Var2 - thisa->Var3 → Creates operational edges pointing to k from Vala, thisa->Var2, and thisa->Var3.

[0083] thisa->result = Vala>100 → Creates a comparison edge and an assignment edge pointing from Vala to thisa->result.

[0084] Class_A::SetResultVal(thisa, Vala) → Creates function call edges from thisa and Vala pointing to the function call node.

[0085] B. Taking the Class_B::func1 function as an example: int __cdecl Class_B::func1(Class_B *const this, int x, int y) { __int64 v3; / / rbx unsigned int v4; / / eax __int64 v5; / / rax Class_B *thisa; / / [rsp+40h] [rbp-40h] thisa = this; Class_A::SetResultVal((Class_A *const)this, this->Var1 + y * x); v3 = std::operator<<<std::char_traits <char>>(refptr__ZSt4cout, "func1 of class B called ResultVal="); v4 = text_53((Class_A *const)thisa); v5 = std::ostream::operator<<(v3, v4); return std::ostream::operator<<(v5, refptr__ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_); } Step 61: Create nodes this, x, y, etc.

[0086] Step 62: The mapping relationship edges are as follows: Class_A::SetResultVal((Class_A *const)this, this->Var1 + y * x) → Creates operation edges and function call edges pointing from this->Var1 (thisa+4), x, and y to the function call node.

[0087] Step 71: Identify connection points between subgraphs: SetResult calls SetResultVal; Class_B::func1 calls Class_A::SetResultVal. Shared member variable nodes include ResultVal, Var1, etc.

[0088] Step 72: Establish call edges: from the call node of SetResult to the function entry node of SetResultVal; from the call node of Class_B::func1 to the function entry node of Class_A::SetResultVal.

[0089] Step 73: Process data flow edges: merge the this pointer nodes in all subgraphs; merge shared member variable nodes; create cross-function data dependency edges, such as the ResultVal set in SetResult being read by text_53 (GetResultVal).

[0090] Step 74: As Figure 11 As shown, the aggregation forms the initial overall graph, connecting all member function subgraphs.

[0091] Step 75: Optimize the overall graph, eliminate redundant nodes, and simplify relational edges.

[0092] Step 80: Variable semantic inference and class variable reconstruction.

[0093] Step 81: Initialize the evidence database: 81a. Evidence of function name: SetResult and SetResultVal are related to result settings.

[0094] GetResult and GetResultVal are related to result retrieval.

[0095] func1, func2, func3 → General-purpose functions.

[0096] 81b. Evidence from code context: String constants: the function prompts for "SetResult called", "GetResultVal called", etc.

[0097] Output information: "k=" indicates intermediate calculation results.

[0098] 81c, Evidence from library functions / APIs: std::operator<<→ Output operation, the relevant parameter is the content to be displayed.

[0099] Arithmetic operations → Infer numeric type variables.

[0100] Step 82: Subgraph Local Inference: Collect the adjacency relationships of each variable, such as ResultVal being read and written by multiple functions; Apply evidence base: Val parameter appears in SetResult and SetResultVal, inferred as "the result value to be set"; result variable is returned in GetResult, inferred as "result status flag"; Data flow propagation: ResultVal is calculated from Val and inherits its semantic properties; k is calculated from multiple variables, inferred as a temporary calculation result.

[0101] Step 83: Full graph aggregation inference: Shared node evidence convergence, such as ResultVal being written in SetResultVal and read in text_53, confirming its semantics as "stored result value"; call chain semantic propagation, such as SetResult calling SetResultVal, both having consistent operations on ResultVal; iterative execution of the inference process until the semantic information is stable.

[0102] Step 84: Generate the class variable annotation table and output the results: / / Example of member function comments for Class_A void Class_A::SetResult(Class_A *const this, int Val) { / / this: [ in Class instance pointer / / Val: [ in The result value to be set / / Function: Set the result status and result value based on the input value. int k = Val * Val + this->Var2 - this->Var3; / / k : Temporary calculation results this->result = (Val>100); / / result : Result status flag Class_A::SetResultVal(this, Val); / / Sets the stored result value } int Class_A::GetResultVal(Class_A *const this) { / / this : [ in Class instance pointer / / Returns: Stored result value return this->ResultVal; / / ResultVal : Stored result value } As can be seen from the example code above, the method of this invention can extract the constructor, member functions, and their inter-call relationships from decompiled pseudocode, identify class member variables, local variables, and function parameters, and construct a directed subgraph of member functions based on the relationships between variables such as assignment, operation, comparison, and function calls, thereby aggregating them to form a class hierarchy graph. Based on this graph structure, this invention can uniformly model shared variables and cross-function data flows, realizing the propagation and completion of variable type and semantic information between different member functions, thus effectively restoring the functional meaning of various member variables and their roles in the program in the example code. Therefore, the method of this invention has good practicality and scalability, and is suitable for reverse engineering scenarios of robot control system software, embedded programs, and other complex binary programs.

[0103] It should be noted that the parts not described in detail in the embodiments of the present invention belong to those that are common knowledge or publicly disclosed prior art to those skilled in the art. These contents are considered to be general knowledge in the industry.

[0104] Furthermore, for those skilled in the art, the steps in the embodiments described in this invention, whether all or part, can be implemented by programming instructions to corresponding hardware devices. The corresponding control program can be stored in various computer-readable media, such as, but not limited to, read-only memory, hard disks, or optical discs.

[0105] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims. The information disclosed in the background section is intended only to enhance the understanding of the overall background technology of the present invention and should not be construed as an admission or implication in any way that such information constitutes prior art known to those skilled in the art.< / char> < / char> < / char>

Claims

1. A method for recognizing compiled binary code based on graph networks, characterized in that, include: Step 10: Obtain the compiled binary code to be identified in the control system, decompile the compiled binary code to obtain the decompiled pseudocode and the inheritance relationship of each class, and then construct the member function table of each class, which includes several member functions; Step 20: Based on the decompiled pseudocode, obtain the software variables of each class, and construct a software variable relationship table based on the relationship between the software variables of each class; based on the software variable relationship table, traverse the member function table of each class and construct a directed subgraph of each member function; Step 30: Based on the calling relationships of each member function, aggregate all directed subgraphs into a class hierarchy graph; Step 40: Perform variable semantic inference based on the class hierarchy diagram to identify the type and semantics of the compiled binary code, thereby determining the function of the compiled binary code in the control system.

2. The method for identifying compiled binary code based on graph networks according to claim 1, characterized in that: In step 10, the inheritance relationships of each class include single inheritance, no inheritance, and multiple inheritance. The parent class and child class are determined according to the inheritance relationship. Single inheritance and multiple inheritance classes and their parent classes have virtual functions, while no inheritance classes have no virtual functions. The child class inherits some or all of the virtual functions of the parent class. Based on the inheritance relationship of each class, a member function table is constructed for each class. The member function table includes the virtual functions of each parent class and the overloaded virtual functions of several classes, all of which are used as member functions.

3. The method for identifying compiled binary code based on graph networks according to claim 1, characterized in that: In step 20, the software variables include class member variables, local variables, input parameters, and output parameters. For each member function in the member function table of each class, all software variables related to the member function are extracted from the software variable relationship table, and each software variable of the member function is mapped to a graph node. Then, based on the relationship between each software variable in the software variable relationship table, the relationship between every two related graph nodes is mapped to a directed edge, and then every two related graph nodes are connected by directed edges. Labels and additional attributes of the directed edges are added according to the relationship type between the software variables, and finally, a directed subgraph of the member function is constructed.

4. The method for identifying compiled binary code based on graph networks according to claim 3, characterized in that: Step 30 is as follows: Step 31: For each member function's directed subgraph, obtain several graph nodes representing the function's input parameters, output parameters, and class member variables as potential connection points; at the same time, based on the explicit calling relationships between member functions, take every two member functions with explicit calling relationships as a pair of subgraphs to be aggregated. Step 32: Based on the subgraph pairs to be aggregated, determine the call edges and data flow edges between potential connection points; Step 33: Based on the determined call edges and data flow edges, connect the potential connection points of the directed subgraphs of all member functions to construct an initial overall graph. Then optimize the initial overall graph, merge duplicate potential connection points, eliminate isolated potential connection points that are not connected by call edges or data flow edges, and finally generate a class hierarchy overall graph. At the same time, update the software variable relationship table.

5. The method for identifying compiled binary code based on graph networks according to claim 4, characterized in that: In step 32, for each pair of subgraphs to be aggregated, the pair is divided into a calling subgraph and a called subgraph according to the explicit calling relationship. The potential connection point in the calling subgraph that initiates the call is taken as the calling node, and the potential connection point in the called subgraph that is called by the called node is taken as the called node. The directed edge from the calling node to the called node is taken as the calling edge to connect the calling node and the called node, thereby connecting the pair of subgraphs to be aggregated. For every two directed subgraphs, identify potential connection points with data transmission relationships. Potential connection points representing class member variables have data transmission relationships, as do potential connection points representing input parameters and output parameters. Designate potential connection points in one directed subgraph that output data to another as output nodes, and potential connection points in another directed subgraph that receive data from the same output node as receiving nodes. Use directed edges from the output node to the receiving node as data flow edges to connect the output node and the receiving node, thus connecting the two directed subgraphs. Simultaneously, merge potential connection points representing class member variables that receive output data from the same output node into shared nodes.

6. The method for identifying compiled binary code based on graph networks according to claim 1, characterized in that: Step 40 is described in detail below: Step 41: Based on the preset inference evidence base of function name evidence and library function / API evidence between member functions, in each member function of the class hierarchy graph, the graph nodes representing class member variables and local variables of the directed subgraph of the member function are used as inference nodes, and semantic inference is performed on the inference nodes to obtain the initial type and semantics of the inference nodes. Step 42: Based on the initial type and semantics of each inference node in each member function, and using the global graph network structure of the class hierarchy graph, propagate and complete the initial type and semantics of each inference node across functions to obtain the final type and semantics of each inference node. Step 43: Construct the final type and semantics of each inferred node of each class into a variable annotation table for the class, and annotate the variable annotation table back into the decompiled pseudocode in a readable form to form a queryable annotation database of the compiled binary code of the control system.

7. The method for recognizing compiled binary code based on graph networks according to claim 6, characterized in that: In step 41, for each inference node within a member function, the labels and additional attributes of several adjacent inference nodes connected to the inference node and the directed edges between them are obtained. If the current inference node is connected to a calling node that matches the function name evidence through a calling edge, the initial type and semantics of the current inference node are directly inferred based on the name of the member function of the current inference node. If the inference node is passed as a parameter to a known library function in the library function / API evidence, the initial type and semantics of the current inference node are inferred based on the parameter definition of the known library function. If the current inference node is connected to an inference node that matches the function name evidence through a data flow edge, the initial type and semantics of the current inference node are inferred based on the label and additional attributes of the data flow edge.

8. The method for identifying compiled binary code based on graph networks according to claim 6, characterized in that: In step 42, for shared nodes in the class hierarchy graph that are shared by multiple directed subgraphs, the initial type and semantics inferred in all directed subgraphs are obtained. If the initial type and semantics of the current shared node are consistent in all directed subgraphs, they are directly used as the final type and semantics of the current shared node. If they are inconsistent, the current shared node is marked as pending. Iterative inference is performed based on the call edges and data flow edges between the directed subgraphs. If member function A calls member function B, and the initial semantics and type of member function B have been inferred, the initial semantics and type of member function B are directly propagated back along the call edge to the calling node in member function A as its final semantics and type. If member function A transmits data to member function B, and the initial semantics and type of member function B have been inferred, the initial semantics and type of member function B are directly propagated back along the data flow edge to the output node in member function A as its final semantics and type. The iteration continues until no new semantics and types are inferred, or the preset number of iterations is reached, to determine the final type and semantics of each inferred node.

9. An electronic device, characterized in that, include: A memory and a processor are coupled to each other, wherein the memory stores program data, and the processor invokes the program data to perform the method as described in any one of claims 1-8.

10. A computer-readable storage medium storing program data thereon, characterized in that, When the program data is executed by the processor, it implements the method as described in any one of claims 1-8.

Images