Method for recovering sensitive data in a binary program and electronic device

Abstract

The application provides a method for recovering sensitive data in a binary program and an electronic device. The method comprises: generating a corresponding semantic graph based on the binary program; identifying sensitive data nodes from the semantic graph; identifying recovery functions from the semantic graph; traversing the semantic graph based on function call relationships and data reference relationships from the sensitive data nodes to obtain candidate propagation chains; selecting recovery-related propagation chains from the candidate propagation chains based on the recovery functions; extracting a recovery chain to be executed from the recovery-related propagation chains according to data objects, recovery functions and function call relationships in the recovery-related propagation chains; and performing binary instrumentation on the recovery functions in the recovery chain to be executed to obtain a data recovery result. The application can automatically extract a data recovery chain from a binary program, realize deep tracking and comprehensive recovery of sensitive data, and effectively improve the integrity and accuracy of data recovery.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and more specifically, to a method and electronic device for recovering sensitive data in a binary program. Background Technology

[0002] With the continuous evolution of the software industry and internet technology, a large number of applications, system components, third-party dependency libraries, and firmware products are released and deployed in binary form. Since source code is often difficult to obtain, binary program analysis has become an indispensable technical means in fields such as software security auditing, supply chain security testing, malware analysis, and vulnerability research.

[0003] However, in actual software development practice, developers often employ various techniques to protect sensitive data, such as string encryption, encoding conversion, dynamic concatenation, runtime decryption, resource hiding, and custom obfuscation, in order to improve program security or increase the difficulty of reverse engineering. These protection mechanisms significantly increase the difficulty of identifying and extracting sensitive information at the binary level.

[0004] Currently, the recovery of sensitive data in binary programs mainly falls into two categories: static analysis and dynamic analysis. Static analysis techniques typically use disassembly, decompilation, control flow graph construction, call relationship analysis, and string extraction to study the program structure and behavior. Dynamic analysis techniques, on the other hand, obtain information about the actual behavior of the program during execution through program runtime monitoring, sandbox execution, behavior logging, and memory monitoring.

[0005] In practice, sensitive data often undergoes multiple layers of encryption, encoding, and concatenation, forming a complex decryption chain. Existing methods mostly target a single transformation step, making it difficult to automatically trace and reconstruct the complete decryption chain. Summary of the Invention

[0006] The purpose of this application is to provide a method and electronic device for recovering sensitive data in a binary program, so as to realize the automatic discovery of sensitive data in the binary program, construct a propagation chain containing sensitive data nodes, and recover the propagation chain, thereby reducing the false alarm rate.

[0007] In a first aspect, embodiments of this application provide a method for recovering sensitive data in a binary program, including: The semantic graph is generated based on the binary program; the nodes in the semantic graph include functions and data objects, and the edges include function call relationships and data reference relationships. Sensitive data nodes are obtained by identifying sensitive data in the semantic graph. Recovery functions are obtained by performing recovery function identification on semantic graphs. Starting from sensitive data nodes, candidate propagation chains are obtained by traversing the semantic graph based on function call relationships and data reference relationships. Select the relevant propagation chain from the candidate propagation chains based on the recovery function; Based on the data objects, recovery functions, and function call relationships in the recovery-related propagation chain, extract the recovery chain to be executed from the recovery-related propagation chain; Binary instrumentation is performed on the recovery functions in the recovery chain to obtain the data recovery results.

[0008] This application embodiment constructs a semantic graph and integrates sensitive data identification and recovery function identification, which can automatically extract the data recovery chain from binary programs, realize in-depth tracking and comprehensive recovery of sensitive data, and effectively improve the integrity and accuracy of data recovery.

[0009] In one possible implementation of the first aspect, sensitive data identification is performed on the semantic graph to obtain sensitive data nodes, including: Input the semantic graph into the sensitive data identification model to obtain the sensitive data nodes in the semantic graph; The sensitive data identification model is obtained by training a semantic graph that includes both sensitive and non-sensitive data nodes.

[0010] This application embodiment employs a sensitive data identification model based on trained semantic graphs to identify sensitive data from semantic graphs. This can automatically and accurately identify sensitive data nodes from the semantic graphs of binary programs, reducing reliance on manual analysis, improving the efficiency and accuracy of sensitive data identification, and providing a reliable foundation for the subsequent construction of recovery chains and data recovery.

[0011] In one possible implementation of the first aspect, the semantic graph is subjected to recovery function identification to obtain the recovery function, including: The features of function nodes in the semantic graph are matched using a feature library of recovery functions, and the functions corresponding to the successfully matched function nodes are identified as recovery functions; and / or Extract the behavioral features of the functions corresponding to the function nodes, and construct a behavioral feature vector based on the behavioral features; Calculate the similarity between the behavioral feature vector and the baseline feature vector of the recovery function; determine the recovery function based on the similarity.

[0012] This application embodiment combines two recognition methods: matching the feature library of recovery functions and similarity calculation based on behavioral feature vectors. It can achieve fast and accurate matching of recovery functions using known feature libraries, and effectively identify variants or unknown recovery functions not covered by the feature library by calculating the similarity between behavioral feature vectors and benchmark feature vectors, thereby significantly improving the coverage and accuracy of recovery function recognition.

[0013] In one possible implementation of the first aspect, starting from sensitive data nodes, the semantic graph is traversed based on function call relationships and data reference relationships to obtain candidate propagation chains, including: Starting from sensitive data nodes, traverse the semantic graph based on function call relationships and data reference relationships; During the traversal, the relationships between each data object node and function node are recorded, including parameter passing relationships, return value relationships, memory read / write relationships, and data conversion relationships; The data object nodes, function nodes, and relations are combined into a candidate propagation chain.

[0014] This application embodiment starts from sensitive data nodes, traverses the semantic graph based on function call relationships and data reference relationships, and comprehensively records various data flow relationships such as parameter passing relationships, return value relationships, memory read and write relationships, and data conversion relationships. It can automatically and completely track the propagation path of sensitive data in binary programs and construct candidate propagation chains covering various data flow forms, thereby effectively avoiding missing potential propagation links of sensitive data.

[0015] In one possible implementation of the first aspect, the relevant propagation chain is selected from the candidate propagation chains based on the recovery function, including: If a candidate propagation chain contains a recovery function, and there is a data dependency between the input data object of the recovery function and the sensitive data node, then the candidate propagation chain is marked as a recovery-related propagation chain.

[0016] This application embodiment uses the existence of the recovery function and the data dependency relationship between the input data object of the recovery function and the sensitive data node as dual screening conditions. It can accurately identify the propagation chain that is really related to the recovery of sensitive data from the candidate propagation chain, effectively eliminating irrelevant propagation chains that do not contain a recovery function or have no data dependency relationship, thereby improving the accuracy and pertinence of the screening of recovery-related propagation chains.

[0017] In one possible implementation of the first aspect, the recovery chain to be executed is extracted from the recovery-related propagation chain based on the data objects, recovery functions, and function call relationships in the recovery-related propagation chain, including: Based on the data object nodes, recovery functions, and function call relationships in the recovery propagation chain, extract the continuous path from the sensitive data node to the input of the recovery function, and from the output of the recovery function to the subsequent data object node, to form a candidate recovery chain; If a candidate recovery chain meets the preset data dependency and path depth conditions, then the candidate recovery chain is the recovery chain to be executed.

[0018] This application embodiment extracts a continuous path from the sensitive data node through the input end of the recovery function to the output end of the recovery function and then points to the subsequent data object node from the recovery-related propagation chain. Based on preset data dependency conditions and path depth conditions, it performs dual screening, which can accurately define the complete execution path of sensitive data recovery and effectively exclude data streams with incomplete paths or unreasonable depths.

[0019] In one possible implementation of the first aspect, the data dependency conditions include: The candidate recovery chain contains recovery functions; There is a data dependency between sensitive data nodes and the input data of the recovery function; The similarity between the behavioral feature vector of the recovery function and the baseline feature vector of the recovery function is greater than a preset similarity threshold, or the recovery function hits a predefined recovery function feature; The path depth condition includes: the call depth of the candidate recovery chain does not exceed the preset maximum call depth.

[0020] This application embodiment uses the existence of the recovery function, the data dependency relationship between sensitive data and the input of the recovery function, the similarity of the recovery function's behavioral features or the hit rate of the feature library as multi-dimensional data dependency conditions, and combines them with the path depth condition that the call depth does not exceed the preset maximum call depth for comprehensive constraints. This can accurately filter out the recovery chains to be executed from the recovery-related propagation chains, which have complete data dependency relationships, high recovery function credibility and reasonable path depth, and effectively exclude invalid paths with missing dependencies, unreliable recovery functions or excessive call depth.

[0021] In one possible implementation of the first aspect, binary instrumentation is performed on the recovery functions in the recovery chain to be executed, including: Data acquisition points are set at the entry address, exit address, input buffer, output buffer, and critical data access locations of the recovery function, and the runtime state of sensitive data nodes in the recovery chain to be executed is recorded during the execution of the recovery function.

[0022] This application embodiment sets data collection points at multiple locations, including the entry address, exit address, input buffer, output buffer, and key data access locations of the recovery function, enabling fine-grained monitoring of the entire execution process of the recovery function. This comprehensively captures the runtime state of sensitive data nodes during the operation of the recovery function, thereby providing complete and traceable dynamic execution information for the sensitive data recovery process and effectively improving the observability and reliability of data recovery.

[0023] In one possible implementation of the first aspect, the method further includes: The data recovery result includes the output data corresponding to the recovery function. The output data includes the output buffer address, output data length, and output data content. Associate the output data with the corresponding recovery function, input data object, and output data object; The output data object is added to the semantic graph as a new data object, and the data dependency relationship between the output data object and the recovery function is established.

[0024] This application embodiment establishes an association between the data recovery result output by the recovery function and the corresponding recovery function, input data object, and output data object. It also adds the output data object as a new data object node to the semantic graph and establishes its data dependency relationship with the recovery function. This enables closed-loop feedback of the data recovery result and dynamic expansion of the semantic graph, allowing the recovered data object to be reused for subsequent sensitive data identification and propagation chain analysis. This supports an iterative data recovery process, effectively improving the coverage and recovery integrity of deep sensitive data in binary programs, while enhancing the traceability and relevance of the data recovery result.

[0025] In one possible implementation of the first aspect, the method further includes: During the binary instrumentation of the recovery function in the recovery chain to be executed, the binary instrumentation operation is terminated if any of the following termination conditions are met. Termination conditions include: Reaching the preset maximum call depth; The preset maximum number of instructions to be executed has been reached; Reach the preset maximum number of loops; Reaching the preset maximum execution time; The recovery function finishes execution and obtains the output data; No new data state changes occurred during continuous execution; An abnormal control flow, access exception, or other execution error was detected.

[0026] This application embodiment enables comprehensive boundary control over the instrumentation process by setting termination conditions during binary instrumentation, effectively preventing excessive resource consumption and system crash risks caused by infinite recursion, infinite loops, or execution anomalies, while ensuring timely termination of instrumentation operations when the data recovery target is achieved or no new data can be recovered.

[0027] In one possible implementation of the first aspect, the method further includes: Based on the API function classification rule library, we identify purpose function nodes from the semantic graph; Based on the node type and context parameter features in the recovery chain to be executed, the purpose function nodes are classified using rule matching or a lightweight classification model to obtain the purpose category and risk level.

[0028] This application embodiment identifies purpose function nodes from the semantic graph based on an API function classification rule base, and combines the node type and context parameter features in the recovery chain to be executed. It uses rule matching or a lightweight classification model to classify the purpose function nodes by purpose category and risk level. This can automatically identify API functions related to sensitive data operations and assess their potential risks, providing a more comprehensive semantic understanding and security awareness capability for the sensitive data recovery process.

[0029] Secondly, embodiments of this application provide a device for recovering sensitive data in a binary program, comprising: The graph generation module is used to generate corresponding semantic graphs based on binary programs; the nodes in the semantic graph include functions and data objects, and the edges include function call relationships and data reference relationships. The sensitive data identification module is used to identify sensitive data in the semantic graph and obtain sensitive data nodes. The recovery function identification module is used to identify the recovery function in the semantic graph and obtain the recovery function. The node traversal module is used to start from sensitive data nodes and traverse the semantic graph based on function call relationships and data reference relationships to obtain candidate propagation chains; The propagation chain selection module is used to select the recovery-related propagation chain from the candidate propagation chains based on the recovery function. The recovery chain extraction module is used to extract the recovery chain to be executed from the recovery-related propagation chain based on the data objects, recovery functions, and function call relationships in the recovery-related propagation chain. The instrumentation module is used to perform binary instrumentation on the recovery functions in the recovery chain to obtain data recovery results.

[0030] Thirdly, embodiments of this application provide an electronic device, including: a processor, a memory, and a bus, wherein: The processor and memory communicate with each other via a bus; The memory stores program instructions that can be executed by the processor, and the processor can execute the method of the first aspect by calling the program instructions.

[0031] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium, comprising: A non-transitory computer-readable storage medium stores computer instructions that cause the computer to perform the methods in the various possible implementations of the first aspect.

[0032] Fifthly, embodiments of this application provide a computer program product, including computer program instructions, which, when read and executed by a processor, perform the methods in various possible implementations of the first aspect.

[0033] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description and the accompanying drawings. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This application provides a schematic flowchart of a method for recovering sensitive data in a binary program. Figure 2 A schematic diagram of a device for recovering sensitive data in a binary program, provided in an embodiment of this application; Figure 3 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0036] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this application; the terms “comprising” and “having”, and any variations thereof, in the specification and the foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0038] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0039] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0040] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0041] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0042] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0043] With the continuous development of the software industry and internet technology, a large number of applications, system components, and firmware products are released in binary form. Since the source code is usually unavailable, binary program analysis has become a key means of software security auditing, supply chain security testing, and malware analysis. However, developers often use techniques such as string encryption, dynamic concatenation, runtime decryption, and custom obfuscation to protect sensitive data, significantly increasing the difficulty of identifying and recovering sensitive information at the binary level.

[0044] To address this issue, existing methods for sensitive data recovery mainly include static analysis (such as string extraction and decompilation-assisted decryption), dynamic analysis (such as memory dumping, binary instrumentation, and taint tracing), entropy statistical analysis, cryptographic operation identification, and symbolic execution. However, each of these methods has significant limitations: static analysis relies on known features and cannot handle runtime decryption; dynamic analysis faces challenges such as incomplete execution path coverage and anti-debugging attacks; entropy analysis has a high false positive rate and cannot reconstruct the specific content; and cryptographic operation identification has limited ability to capture modified algorithms and transient keys.

[0045] In practice, sensitive data often undergoes multiple layers of encryption, encoding, and concatenation, forming a complex decryption chain. Existing methods mostly target a single transformation step, making it difficult to automatically trace and reconstruct the complete decryption chain.

[0046] Based on the above-mentioned technical problems, this application provides a method for recovering sensitive data in a binary program. This method can automatically discover sensitive data in a binary program, trace the complete decryption chain, and recover the data, thereby improving the ability to identify hidden sensitive data and effectively reducing the false alarm rate.

[0047] It is understood that the method for recovering sensitive data in a binary program provided in this application embodiment can be applied to electronic devices, including terminals and servers; wherein the terminal may specifically be a smartphone, tablet computer, computer, personal digital assistant (PDA), etc.; and the server may specifically be an application server or a web server.

[0048] Figure 1 This is a flowchart illustrating a method for recovering sensitive data in a binary program, provided as an embodiment of this application. The method includes: Step 101: Generate the corresponding semantic graph based on the binary program.

[0049] Electronic devices use disassembly and decompilation techniques to statically analyze binary programs, identifying functions, data objects, function call relationships, and data reference relationships within the binary program. Function characteristic parameters can include one or more of the following: function identifier, function address, function size, number of parameters, parameter type, parameter length, external API call set, API call order, instruction type distribution, proportion of bitwise operations, proportion of arithmetic operations, loop structure characteristics, control flow complexity, memory read / write characteristics, and data dependencies between input and output data objects; these parameters carry the program's functional logic. Data objects can include global variables, constants, memory regions, strings, etc., and can carry attributes such as data type, address range, and initial value. It is understandable that external call information within the binary program can also be identified. Using functions and data objects as nodes, and function call relationships and data reference relationships as edges, a semantic graph is generated. A semantic graph is a data structure that represents the semantic information of a program using a graph structure. Therefore, a semantic graph includes function nodes, data object nodes, and may also include API call nodes.

[0050] Step 102: Perform sensitive data identification on the semantic graph to obtain sensitive data nodes.

[0051] Sensitive data nodes refer to objects in the semantic graph that contain sensitive data, such as keys, certificates, hard-coded passwords, and personal privacy information.

[0052] When identifying sensitive data using semantic graphs, various identification methods can be employed. Specifically, methods such as static feature rule matching and entropy analysis can be used. Static feature rule matching, for example, involves scanning string constants that conform to the format of ID card numbers or API keys. Entropy analysis methods, for example, detect whether the information entropy of a data block exceeds a random threshold to locate potentially encrypted ciphertext or highly obfuscated data.

[0053] Step 103: Perform recovery function identification on the semantic graph to obtain the recovery function.

[0054] Recovery functions refer to functions in binary programs used to reverse process data to recover the original data, such as decryption functions, decompression functions, and decoding functions.

[0055] After obtaining the semantic graph, the features corresponding to the function nodes in the semantic graph can be matched with the features based on the preset recovery function feature library, thereby obtaining the recovery function in the semantic graph.

[0056] Step 104: Starting from the sensitive data nodes, traverse the semantic graph based on function call relationships and data reference relationships to obtain candidate propagation chains.

[0057] Starting from sensitive data nodes, and following a series of function calls and data references, it records the chain-like structure formed by the propagation path of data in the program, including data object nodes, function nodes, and various relationships between them.

[0058] For example: For a identified sensitive data node D1, if D1 is passed as a parameter to function F1, F1 performs data transformation on D1 and generates a data object D2, D2 is further passed as a parameter to function F2, F2 outputs a data object D3, and D3 is then used by function F3 to construct an authentication request, and finally passed to the network communication API F4, then the following candidate propagation chain is formed: D1→F1→D2→F2→D3→F3→F4.

[0059] During the traversal, the parameter passing relationships, return value relationships, memory read / write relationships, and data conversion relationships between each data object node and function node are recorded, and these nodes and relationships are organized into candidate propagation chains. Parameter passing relationships refer to the relationship between actual parameters and formal parameters during function calls, reflecting the flow of data at the function call interface. Return value relationships refer to the relationship where the function return value is received and used by the caller, reflecting the propagation of data to upper-level functions through the return value. Memory read / write relationships refer to the data dependencies formed by functions reading or writing memory addresses, such as global variable read / write and heap memory operations. Data conversion relationships refer to the relationship where data undergoes type or format conversion after being processed by a function, such as data format changes caused by encryption, encoding, and compression operations.

[0060] It should be noted that the traversal depth is limited by a preset maximum level to prevent path explosion.

[0061] Step 105: Select the recovery-related propagation chain from the candidate propagation chains based on the recovery function.

[0062] From the candidate propagation chains obtained in step 104, there may be a large number of paths related to the propagation of sensitive data but not involving recovery operations. This step uses a dual screening criterion for precise filtering: First, the candidate propagation chain must contain at least one recovery function identified in step 103; second, the input data object of the recovery function must have a data dependency relationship with the sensitive data node, that is, the data processed by the recovery function does indeed originate from sensitive data. Candidate propagation chains that meet these two conditions are marked as recovery-related propagation chains. This screening process effectively eliminates irrelevant paths that do not contain recovery logic or whose data sources are unrelated, allowing subsequent analysis to focus on propagation chains that are truly likely to perform data recovery, significantly improving processing efficiency and analysis accuracy.

[0063] Step 106: Extract the recovery chain to be executed from the recovery-related propagation chain based on the data objects, recovery functions and function call relationships in the recovery-related propagation chain.

[0064] In the specific implementation process, based on the selected recovery-related propagation chain, an executable logical sequence is further extracted. The data dependencies between nodes in the chain are analyzed, and combined with the call sequence, the scattered nodes are arranged into a linear operation sequence. Here, data dependency refers to whether the output of one function is directly used as the input of another function. The call sequence refers to which function is called first and which is called later. This sequence clarifies the input data object necessary for performing recovery (i.e., the ciphertext to be decrypted), the intermediate processing steps (the call order of multiple recovery functions), and the final output data object. After parameter binding and sequence correction, a logically complete recovery chain that can be directly mapped to an executable script is finally generated.

[0065] Step 107: Perform binary instrumentation on the recovery functions in the recovery chain to be executed to obtain the data recovery results.

[0066] The target program is loaded using a dynamic binary instrumentation framework (such as Intel Pin or DynamoRIO), and hooks are set for specific function addresses in the recovery chain to be executed extracted in step 106. It should be noted that binary instrumentation is a dynamic program analysis technique that collects runtime data, execution traces, and other information by inserting additional monitoring code at specific locations in the binary program (such as function entry points, exit points, and memory access points) without changing the original logic of the program.

[0067] Therefore, when the program reaches these recovery functions, the instrumentation engine pauses the original process, automatically records the function's input parameters (i.e., the ciphertext / encoded data to be processed) and return value (i.e., the decrypted plaintext / original data), and saves these real-time captured memory snapshots. After instrumentation is complete, the data recovery results are extracted from the collected data, including information such as the content, length, and address of the output data.

[0068] This application embodiment constructs a semantic graph and integrates sensitive data identification and recovery function identification, which can automatically extract the data recovery chain from binary programs, realize in-depth tracking and comprehensive recovery of sensitive data, and effectively improve the integrity and accuracy of data recovery.

[0069] Based on the above embodiments, sensitive data identification is performed on the semantic graph to obtain sensitive data nodes, including: Input the semantic graph into the sensitive data identification model to obtain the sensitive data nodes in the semantic graph; The sensitive data identification model is obtained by training a semantic graph that includes both sensitive and non-sensitive data nodes.

[0070] In the specific implementation process, the sensitive data identification model is pre-trained. Its training process includes: acquiring a training semantic graph, which includes both sensitive and non-sensitive data nodes. The training semantic graph is then input into the model to be trained. Through extensive learning of this labeled graph structure data, the model self-adjusts its parameters to acquire the deep semantic patterns, association rules, and contextual features required for sensitive data nodes. Ultimately, it acquires the ability to identify sensitive data nodes from unknown semantic graphs, which is the sensitive data identification model in this application embodiment.

[0071] After obtaining a trained sensitive data recognition model, the semantic graph is input into the sensitive data recognition model to obtain the sensitive data nodes in the semantic graph output by the sensitive data recognition model.

[0072] It should be noted that, in addition to using sensitive data identification models, feature rule matching, entropy value matching, etc., can also be used.

[0073] The specific implementation of the feature rule matching method is as follows: Pattern matching is performed on the content samples (sample data) of each data field node in the semantic graph, and the feature rules relied upon include, but are not limited to: Regular expression rules: For data with fixed lengths and check digit patterns, such as ID card numbers, bank card numbers, mobile phone numbers, and IP addresses, regular expressions are used for precise matching.

[0074] Keyword / Dictionary Rules: Based on a pre-built sensitive word dictionary (such as password, balance, ID card, disease name, etc.), the node's own attribute values ​​or field names are matched.

[0075] Metadata-assisted rules: When there is ambiguity in the identification of sample data, the metadata of the field (such as field comments and field business names) is introduced to assist in the rule determination and serve as a confidence correction factor.

[0076] Unlike traditional rule matching for isolated fields, this application's embodiments utilize edge relationships between nodes for semantic enhancement when performing matching on the semantic graph. For example, it may include semantic verification of neighboring nodes. For instance, when a node matches a six-digit number rule, the system checks whether its adjacent nodes contain semantic nodes such as transaction passwords or verification codes. If so, it is determined to be a sensitive password node; if it only borders a postal code node, it is excluded from suspicion of sensitivity. It may also include relation propagation reasoning. For example, if a node is strongly identified as an ID number, then name nodes and address nodes with affiliation to it, even if they do not match explicit rules, will gain a high sensitivity confidence propagation due to semantic association.

[0077] The entropy matching method is implemented as follows: For each data field node in the semantic graph, calculate its Shannon information entropy for the set of sample values. The entropy value (H) quantifies the dispersion and randomness of the data values ​​within that field. It is calculated by evaluating the probability distribution of different values ​​appearing in the field's value set.

[0078] Based on the calculated entropy value, nodes are mapped to different entropy value ranges, and corresponding sensitive data judgment logic is matched accordingly: Extremely high entropy ranges (e.g., H > threshold) represent field values ​​that are nearly random and irregular. Typical matching scenarios include: encrypted ciphertext, randomly generated session tokens, API keys, biometric templates, etc. Due to the high degree of uncertainty in the information, these nodes typically belong to highly sensitive data.

[0079] Extremely low entropy ranges (e.g., H < threshold) indicate a highly concentrated set of field values, potentially containing only a single value or very few enumerated values. This might be a low-sensitivity category attribute (e.g., gender), but could also be highly sensitive data in a specific context. For example, in a semantic graph, if a node is connected to a diagnosis result node and its entropy value is extremely low, it might point to a specific prevalent disease, constituting personal health privacy data. In this case, a secondary judgment needs to be made based on the semantic types of adjacent nodes.

[0080] Within a specific range of medium entropy values, certain formatted sensitive data (such as ID card numbers) may appear random, but the pattern of their last check digit can cause the entropy value to fall within a specific low-to-medium range. By pre-collecting the entropy distribution of such sensitive data samples, an entropy fingerprint database can be established to supplement omissions in pure rule matching and improve the recall rate of formatted sensitive data.

[0081] This application embodiment employs a sensitive data identification model based on trained semantic graphs to identify sensitive data from semantic graphs. This can automatically and accurately identify sensitive data nodes from the semantic graphs of binary programs, reducing reliance on manual analysis, improving the efficiency and accuracy of sensitive data identification, and providing a reliable foundation for the subsequent construction of recovery chains and data recovery.

[0082] Based on the above embodiments, semantic graph recovery function identification can be performed using feature matching and / or feature vector similarity. Specifically, the method for performing semantic graph recovery function identification using feature matching is as follows: The features of function nodes in the semantic graph are matched using a recovery function feature library, and the functions corresponding to the successfully matched function nodes are identified as recovery functions.

[0083] In the specific implementation process, the recovery function feature library serves as a benchmark reference library for matching determination. Its construction process needs to cover the multidimensional features exhibited by the recovery function in the semantic graph. Specific function parameter features are detailed in the above embodiment. Before matching, multidimensional features are extracted from each function node in the semantic graph to form a feature vector corresponding to that node. The feature extraction methods include extracting static information such as function name, parameter list, return value type, and class / module from the function node's metadata. During feature matching, the function name of the function node is precisely matched or fuzzily matched with keywords in the feature library. The function corresponding to the matched node is called the recovery function.

[0084] Based on the above embodiments, the adjacency relationships of function nodes in the semantic graph can also be extracted, including the node types connected by the incoming and outgoing edges, and the semantic types of the edges (such as calls, data flows, control flows, etc.), forming local subgraph structure features; the semantic labels of function nodes and their adjacent nodes are encoded to obtain the semantic context vector of the node.

[0085] When performing feature matching, a hierarchical matching strategy can be adopted. For example, high-confidence features can be matched first, followed by low-confidence features for auxiliary judgment. For instance, the function name of the function node can be matched precisely or fuzzily with keywords in the feature library, and the matching nodes receive an initial high-confidence score. Then, the similarity between the adjacent subgraph pattern of the function node in the semantic graph and the pre-stored context pattern in the feature library is calculated, and nodes that do not match the function name are identified. Finally, the data flow and control flow path of the function node in the semantic graph are analyzed and compared with the behavioral pattern templates in the feature library to filter out functionally equivalent but non-standard named recovery functions.

[0086] The specific method for recognizing semantic graph recovery functions based on feature vector similarity is as follows: Extract the behavioral features of the functions corresponding to the function nodes, and construct a behavioral feature vector based on the behavioral features; Calculate the similarity between the behavioral feature vector and the baseline feature vector of the recovery function; determine the recovery function based on the similarity.

[0087] In the specific implementation process, function behavior features are extracted based on the disassembled instruction sequence and control flow graph. These function behavior features include one or more of the following: bit operation instruction ratio, arithmetic operation instruction ratio, loop structure complexity, control flow complexity, memory read ratio, memory write ratio, continuous memory access features, and data dependency features between input data objects and output data objects.

[0088] The extracted function behavior features are constructed into a function behavior feature vector, and similarity is calculated with a pre-established baseline feature vector of the recovery function to obtain the behavior similarity score corresponding to the function node. When the behavior similarity score reaches a preset candidate threshold, the corresponding function node is marked as a candidate custom recovery function and added to the candidate path for subsequent data propagation and restricted dynamic analysis.

[0089] It should be noted that feature matching and feature vector similarity can also be combined to identify recovery functions in semantic graphs. That is, feature matching is first used to determine recovery functions from the semantic graph. For function nodes that fail to match the recovery function feature library, feature vector similarity is used to determine the recovery nodes.

[0090] This application embodiment combines two recognition methods: matching the feature library of recovery functions and similarity calculation based on behavioral feature vectors. It can achieve fast and accurate matching of recovery functions using known feature libraries, and effectively identify variants or unknown recovery functions not covered by the feature library by calculating the similarity between behavioral feature vectors and benchmark feature vectors, thereby significantly improving the coverage and accuracy of recovery function recognition.

[0091] Based on the above embodiments, the method for extracting the recovery chain to be executed from the recovery-related propagation chain includes: In the semantic graph, data object nodes (such as backup files, encrypted data blocks, and abnormal data records) and function nodes (such as recovery functions, transcoding functions, and decryption functions) are connected through data flows or call edges. The system starts from a marked sensitive data node and traverses forward along directed edges: first, it locates the recovery function node that takes that sensitive data node as its input, and then traces its downstream data object nodes along the output edges of the recovery function node. This process automatically connects the sensitive data, recovery function input, recovery function, recovery function output, and subsequent data objects into a continuous path, and extracts this path as a candidate recovery chain.

[0092] Candidate recovery chains include at least one or more of the following: sensitive data candidate objects, recovery function nodes, and recovery function output data objects; when a candidate recovery chain simultaneously meets the preset data dependency conditions and path depth conditions, it is determined as the recovery chain to be executed.

[0093] The data dependency conditions include at least one of the following: (1) The candidate recovery chain contains a recovery function; (2) There is a data dependency between the sensitive data nodes and the input data of the recovery function; (3) The similarity between the behavioral feature vector of the recovery function and the baseline feature vector of the recovery function is greater than the preset similarity threshold, or the recovery function hits the predefined recovery function feature.

[0094] The path depth condition includes ensuring that the call depth of the candidate recovery chain does not exceed a preset maximum call depth. The preset maximum call depth limits the number of hops in function nodes or the total number of steps in which data object nodes and function nodes alternate within the candidate recovery chain. This embodiment of the application, through the constraint of the preset maximum call depth, prevents the computational load from becoming infinitely large.

[0095] This application embodiment uses the existence of the recovery function, the data dependency relationship between sensitive data and the input of the recovery function, the similarity of the recovery function's behavioral features or the hit rate of the feature library as multi-dimensional data dependency conditions, and combines them with the path depth condition that the call depth does not exceed the preset maximum call depth for comprehensive constraints. This can accurately filter out the recovery chains to be executed from the recovery-related propagation chains, which have complete data dependency relationships, high recovery function credibility and reasonable path depth, and effectively exclude invalid paths with missing dependencies, unreliable recovery functions or excessive call depth.

[0096] Based on the above embodiments, after obtaining the data recovery result, the data recovery result includes the output data corresponding to the recovery function. This output data includes an output buffer address, an output data length, and output data content. The output buffer address points to the temporary storage location of the recovered data in memory or storage. The output data length indicates the size of the recovered data content. The output data content refers to the actual recovered data, such as phone numbers, bank card numbers, etc.

[0097] This application uses structured output data as a connection hub to establish a mapping relationship between the output data and key upstream and downstream entities in the recovery operation. That is, the output data is bound to the specific recovery function that generated it. The output data is also associated with its recovery source, i.e., the original input data object.

[0098] Furthermore, embodiments of this application can also update the semantic graph, that is, add the output data object as a new node to the semantic graph. In the semantic graph, an edge is established from the newly added output data object to its source recovery function, and this edge is explicitly defined as a data dependency relationship.

[0099] This application embodiment establishes an association between the data recovery result output by the recovery function and the corresponding recovery function, input data object, and output data object. It also adds the output data object as a new data object node to the semantic graph and establishes its data dependency relationship with the recovery function. This enables closed-loop feedback of the data recovery result and dynamic expansion of the semantic graph, allowing the recovered data object to be reused for subsequent sensitive data identification and propagation chain analysis. This supports an iterative data recovery process, effectively improving the coverage and recovery integrity of deep sensitive data in binary programs, while enhancing the traceability and relevance of the data recovery result.

[0100] Based on the above embodiments, during the binary instrumentation process of the recovery function in the recovery chain to be executed, the binary instrumentation operation is terminated if any of the following termination conditions are met. Termination conditions include: The system reaches a preset maximum call depth; call depth refers to the call chain hierarchy formed by a series of function calls starting from the entry point of the recovery function. Termination is triggered when the nested call depth reaches a preset threshold. This threshold can be configured before instrumentation to limit the tracing of deep recursion or complex call chains.

[0101] The instrumentation process reaches a preset maximum number of instructions executed. This number refers to the total number of machine instructions executed by the recovery function and its internal calls from the start of instrumentation. Instrumentation terminates immediately when the counter reaches the preset maximum number of instructions. This condition controls the computational overhead of a single recovery function analysis, preventing CPU time from being infinitely consumed due to individual functions entering infinite loops or processing extremely large files. It also avoids excessive memory and storage consumption from the massive trajectory data generated by instrumentation.

[0102] The instrumentation process reaches a preset maximum number of iterations; the number of iterations specifically refers to the execution count of loop structures (such as for and while loops) identified during instrumentation. Instrumentation terminates when the maximum number of iterations for a particular loop or the overall loop is reached. This condition aims to prevent analysis from stalling due to prolonged loops in data recovery processes such as scanning, searching, and pattern matching. This condition targets loop logic more directly than the number of instructions, allowing for earlier exits from the loop.

[0103] The instrumentation process reaches a preset maximum execution time. Measured by actual clock time or CPU time, the timer starts from the start of instrumentation, and instrumentation is immediately terminated once the preset time threshold is exceeded. This condition provides a time-budget-based hard termination mechanism, ensuring that the instrumentation task does not block other tasks in the overall recovery process.

[0104] The recovery function has finished executing and obtained the output data; this is a normal natural termination condition, meaning the recovery function has executed to the return instruction and successfully produced the expected output data (such as the output buffer address, output data length, etc.). At this point, the instrumentation task has completed its mission and does not need to continue.

[0105] No new data state changes occur during continuous execution; data state (such as register values, memory write operations, control flow changes, etc.) is continuously monitored during instrumentation. If no new data state changes are observed after a period of continuous execution (such as after executing a certain number of instructions or loops), i.e. the program enters a state of stagnation or loop repetition without substantial progress, termination is triggered.

[0106] An abnormal control flow, access exception, or other execution error has been detected. This condition covers a range of runtime exceptions, including but not limited to: jump to an invalid address, execution of an illegal instruction, access to unmapped memory (segmentation fault), division by zero, null pointer dereference, etc. Instrumentation terminates once the instrumentation environment catches these hardware or software exception signals.

[0107] This application embodiment enables comprehensive boundary control over the instrumentation process by setting termination conditions during binary instrumentation, effectively preventing excessive resource consumption and system crash risks caused by infinite recursion, infinite loops, or execution anomalies, while ensuring timely termination of instrumentation operations when the data recovery target is achieved or no new data can be recovered.

[0108] Based on the above embodiments, the method further includes: Based on the API function classification rule library, we identify purpose function nodes from the semantic graph; Based on the node type and context parameter features in the recovery chain to be executed, the purpose function nodes are classified using rule matching or a lightweight classification model to obtain the purpose category and risk level.

[0109] The API function classification rule base is pre-built. This rule base defines which functions belong to the category of utility functions and classifies them accordingly. Utility functions differ from general computational or logical functions; they specifically refer to functions that perform concrete external operations and may produce side effects or security impacts. Examples include: network communication functions, file system operation functions, process / system operation functions, encryption / decryption functions, etc.

[0110] In the constructed semantic graph, this feature identifies all nodes belonging to the purpose function by traversing the graph nodes and matching the function represented by each node with the rule base, and uses these nodes as the target objects for subsequent analysis.

[0111] For the identified functional nodes, a refined classification and risk rating are performed by combining multidimensional information. Specific analytical methods include: Consider the contextual role of the function in the recovery chain. For example, the same file writing function is considered normal output recovery behavior if its upstream is a decompression function; however, if its upstream is a network download function and it is immediately followed by a command execution function, the nature of the risk is completely different.

[0112] Analyze the specific parameter values ​​when calling the function. For example, if the parameter of the connect function points to an internal network IP, the risk is relatively controllable; if the parameter points to an unknown external network IP and communicates through a non-standard port, the risk level increases significantly.

[0113] Regarding the rule matching method, a predefined rule set based on expert experience is used, such as IF (function type is network connection) AND (parameter IP is external IP) AND (data flow direction is upload) THEN Risk level = High.

[0114] For lightweight classification models, a pre-trained lightweight machine learning model (such as a decision tree, random forest, or small neural network) is used. Node types, parameter features, etc., are vectorized and input into the model, which then outputs the category and risk level. This approach can capture complex patterns that are difficult to exhaustively represent using rules.

[0115] After classifying the use function node using rule matching or a lightweight classification model, the use category and risk level corresponding to the use function node can be obtained.

[0116] This application embodiment identifies purpose function nodes from the semantic graph based on an API function classification rule base, and combines the node type and context parameter features in the recovery chain to be executed. It uses rule matching or a lightweight classification model to classify the purpose function nodes by purpose category and risk level. This can automatically identify API functions related to sensitive data operations and assess their potential risks, providing a more comprehensive semantic understanding and security awareness capability for the sensitive data recovery process.

[0117] To further demonstrate the practicality and feasibility of the method described in this invention, this embodiment takes an obfuscated malicious binary remote control program (compiled in C++) as an example to demonstrate how to automatically extract its hidden C2 (controller) server address, encryption key, and determine its harmful uses.

[0118] Step 1: Binary program structure analysis; The analysis system loads the target malicious binary program sample.exe and performs static disassembly analysis: Information extraction: Extract external API calls (such as InternetConnectA, WSASend) and identify all functions and basic blocks within the program.

[0119] Graph Construction: A semantic graph consisting of 320 nodes was constructed. This includes function nodes Func_Init and Func_Unknown_X (an unknown function that was not found), data object node Data_Block_1 (a piece of seemingly random ciphertext data), and external API node InternetConnectA.

[0120] Establishing connections: A data reference edge Func_Init -> Reference -> Data_Block_1 and a function call edge Func_Init -> Call -> Func_Unknown_X were established in the graph.

[0121] Step 2: Sensitive data candidate identification; The system performs a global scan of all data object nodes in the graph: Rule matching: Static search did not find any obvious plaintext Base64, URL, or plaintext hexadecimal key characteristics.

[0122] Entropy analysis: Information entropy was calculated for Data_Block_1 using a sliding window of 64 bytes. The results showed that the average information entropy of this data block was as high as 7.85 (very close to the limit of random distribution, 8.0). Based on this, the system determined that Data_Block_1 was not regular text, but rather highly encrypted or obfuscated data, and listed it as a candidate for sensitive data.

[0123] Step 3: Recovery function identification; The system scans function nodes in the graph and compares them with a predefined recovery function feature library: Feature library matching: No function names, constants (such as the S-box of AES) or specific initialization features of standard algorithms such as AES_Decrypt or RC4_Init were found.

[0124] Similarity scoring: The system then performed instruction behavior statistics on the missed custom function Func_Unknown_X. Analysis revealed that its instruction sequence contained a large number of XOR and ROR / ROL instructions, with bit operations accounting for 34% of the total number of instructions in the function; it also contained a three-level nested loop structure, and the memory read and write pattern exhibited a strong "read-XOR transform-write" characteristic.

[0125] Threshold determination: After weighted algorithm calculation, the function’s behavior similarity score is 88 points, which exceeds the preset threshold of 75 points. The system successfully determined the function as a candidate custom recovery function.

[0126] Step 4: Data propagation path tracing and usage identification; Path tracing: Starting from the sensitive data candidate node Data_Block_1, the system performs a finite-depth traversal (maximum depth set to 5 layers) in the semantic graph based on data references and call relationships. The following candidate propagation chain was successfully traced: Data_Block_1 (high-entropy ciphertext) -> Func_Unknown_X (candidate recovery function) -> Buffer Buf_Output -> Func_Network_Send -> External API InternetConnectA.

[0127] Step 5: Restricted Dynamic Execution and Data Recovery; Because a complete candidate propagation chain is established, the system triggers a restricted dynamic execution mechanism to avoid path explosion caused by blind execution across the entire path: Execution scope constraint: The system enables a pruning mechanism, limiting the dynamic execution environment to Func_Unknown_X and its direct call paths before and after it, with the maximum call depth strictly limited to 2 levels.

[0128] Lightweight execution model; the system starts with a built-in instruction-level interpreter that simulates changes in CPU registers and stack space, without releasing real system calls to the outside world.

[0129] Key data extraction and partial decryption and recovery; Input loading: Load the high-entropy ciphertext data of Data_Block_1 into the simulated memory as an input buffer.

[0130] Probe differential analysis: Input multiple sets of preset feature probe data (such as all 0s and all 1s) into this function, compare the trajectory difference changes between the input and output buffers, observe that the output stream and the input stream have a stable linear difference relationship, and establish an input-output mapping model based on this (for example, the logic of the malware recovery function is XOR and ROL right shift operation).

[0131] Decryption result extraction: The executor simulates the execution of Func_Unknown_X. When execution reaches the stub at the function's exit, it intercepts and extracts a memory snapshot of the output buffer Buf_Output. At this point, the originally high-entropy ciphertext is successfully restored to the plaintext string: "http: / / malicious-c2-server.com / api / hacked" and the authentication key string "Flag@2026!Key".

[0132] Termination condition trigger (corresponding to S6.5): When the entropy value of plaintext data in the output buffer drops sharply from 7.85 and stabilizes at 2.41 (exhibiting standard ASCII plaintext characteristics), and no new path expansion is detected, the system automatically terminates dynamic analysis.

[0133] Step Six: Purpose Determination and Output; Purpose determination: Based on the recovered plaintext (standard URL and online key format) and the context features of its final inflow into the network communication function (InternetConnectA), the system uses a rule matching model to ultimately determine that the purpose of the sensitive data is to initiate online reporting and authentication to the remote control server (C2).

[0134] Output results: The system ultimately outputs the following structured analysis report to security analysts.

[0135] Purpose identification: Since the terminal function of this propagation chain matches the network communication category (InternetConnectA) in the classification rule base, the system automatically marks the external API node as a purpose function node.

[0136] Figure 2 This is a schematic diagram of a device for recovering sensitive data in a binary program, provided as an embodiment of this application. The device can be a module, program segment, or code on an electronic device. It should be understood that this device is similar to the one described above. Figure 1 The method implementation corresponds to this and can be executed. Figure 1 The specific functions of the device involved in each step of the method embodiment can be found in the description above; to avoid repetition, detailed descriptions are omitted here. The device includes: a graph generation module 201, a sensitive data identification module 202, a recovery function identification module 203, a node traversal module 204, a propagation chain selection module 205, a recovery chain extraction module 206, and an instrumentation module 207, wherein: The graph generation module 201 is used to generate a corresponding semantic graph based on a binary program; the nodes in the semantic graph include functions and data objects, and the edges include function call relationships and data reference relationships. Sensitive data identification module 202 is used to identify sensitive data in the semantic graph and obtain sensitive data nodes; The recovery function identification module 203 is used to identify the recovery function in the semantic graph and obtain the recovery function; The node traversal module 204 is used to start from sensitive data nodes and traverse the semantic graph based on function call relationships and data reference relationships to obtain candidate propagation chains; The propagation chain selection module 205 is used to select the recovery-related propagation chain from the candidate propagation chains based on the recovery function; The recovery chain extraction module 206 is used to extract the recovery chain to be executed from the recovery-related propagation chain based on the data objects, recovery functions and function call relationships in the recovery-related propagation chain; The instrumentation module 207 is used to perform binary instrumentation on the recovery functions in the recovery chain to be executed, so as to obtain the data recovery results.

[0137] Based on the above embodiments, the sensitive data identification module 202 is specifically used for: The semantic graph is input into the sensitive data identification model to obtain the sensitive data nodes in the semantic graph; The sensitive data identification model is obtained by training a semantic graph that includes both sensitive and non-sensitive data nodes.

[0138] Based on the above embodiments, the recovery function identification module 203 is specifically used for: The features of function nodes in the semantic graph are matched using a recovery function feature library, and the functions corresponding to the successfully matched function nodes are determined as the recovery functions; and / or Extract the behavioral features of the functions corresponding to the function nodes, and construct a behavioral feature vector based on the behavioral features; Calculate the similarity between the behavioral feature vector and the baseline feature vector of the recovery function; determine the recovery function based on the similarity.

[0139] Based on the above embodiments, the node traversal module 204 is specifically used for: Starting from the sensitive data nodes, the semantic graph is traversed based on the function call relationships and the data reference relationships; During the traversal, the relationship between each data object node and the function node is recorded, including parameter passing relationship, return value relationship, memory read / write relationship and data conversion relationship; The data object node, the function node, and the relationship are combined to form the candidate propagation chain.

[0140] Based on the above embodiments, the propagation chain selection module 205 is specifically used for: If a candidate propagation chain contains the recovery function, and there is a data dependency between the input data object of the recovery function and the sensitive data node, then the candidate propagation chain is marked as a recovery-related propagation chain.

[0141] Based on the above embodiments, the recovery chain extraction module 206 is specifically used for: Based on the data object nodes, recovery functions, and function call relationships in the recovery-related propagation chain, extract the continuous path from the sensitive data node to the input of the recovery function, and from the output of the recovery function to the subsequent data object nodes, to form a candidate recovery chain; If the candidate recovery chain meets the preset data dependency conditions and path depth conditions, then the candidate recovery chain is the recovery chain to be executed.

[0142] Based on the above embodiments, the data dependency conditions include: The candidate recovery chain includes the recovery function; There is a data dependency between the sensitive data node and the input data of the recovery function; The similarity between the behavioral feature vector of the recovery function and the baseline feature vector of the recovery function is greater than a preset similarity threshold, or the recovery function hits a predefined recovery function feature; The path depth condition includes: the call depth of the candidate recovery chain does not exceed the preset maximum call depth.

[0143] Based on the above embodiments, the stake module 207 is specifically used for: Data acquisition points are set at the entry address, exit address, input buffer, output buffer, and key data access locations of the recovery function, and the runtime status of sensitive data nodes in the recovery chain to be executed is recorded during the execution of the recovery function.

[0144] Based on the above embodiments, the device further includes a map update module, used for: The data recovery result includes the output data corresponding to the recovery function, and the output data includes the output buffer address, the output data length, and the output data content. Associate the output data with the corresponding recovery function, input data object, and output data object; The output data object is added to the semantic graph as a new data object, and the data dependency relationship between the output data object and the recovery function is established.

[0145] Based on the above embodiments, the device further includes a termination module, used for: During the binary instrumentation of the recovery function in the recovery chain to be executed, the binary instrumentation operation is terminated if any of the following termination conditions are met. The termination conditions include: Reaching the preset maximum call depth; The preset maximum number of instructions to be executed has been reached; Reach the preset maximum number of loops; Reaching the preset maximum execution time; The recovery function finishes execution and obtains the output data; No new data state changes occurred during continuous execution; An abnormal control flow, access exception, or other execution error was detected.

[0146] Based on the above embodiments, the device further includes a purpose identification module for: Based on the API function classification rule library, the purpose function nodes are identified from the semantic graph; Based on the node type and context parameter characteristics in the recovery chain to be executed, the purpose function nodes are classified using rule matching or a lightweight classification model to obtain the purpose category and risk level.

[0147] Figure 3 This is a schematic diagram of the physical structure of the electronic device provided in the embodiments of this application, such as... Figure 3 As shown, the electronic device includes: a processor 301, a memory 302, and a bus 303; wherein: The processor 301 and the memory 302 communicate with each other through the bus 303; The processor 301 is used to call program instructions in the memory 302 to execute the methods provided in the above-described method embodiments, including, for example, generating a corresponding semantic graph based on a binary program; the nodes in the semantic graph include functions and data objects, and the edges include function call relationships and data reference relationships; performing sensitive data identification on the semantic graph to obtain sensitive data nodes; performing recovery function identification on the semantic graph to obtain recovery functions; starting from the sensitive data nodes, traversing the semantic graph based on the function call relationships and the data reference relationships to obtain candidate propagation chains; selecting recovery-related propagation chains from the candidate propagation chains based on the recovery functions; extracting recovery chains to be executed from the recovery-related propagation chains according to the data objects, recovery functions, and function call relationships in the recovery-related propagation chains; and performing binary instrumentation on the recovery functions in the recovery chains to be executed to obtain data recovery results.

[0148] Processor 301 can be an integrated circuit chip with signal processing capabilities. The processor 301 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor.

[0149] The memory 302 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0150] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions, and when the program instructions are executed by a computer, the computer can execute the methods provided in the above-described method embodiments, such as: generating a corresponding semantic graph based on a binary program; the nodes in the semantic graph include functions and data objects, and the edges include function call relationships and data reference relationships; identifying sensitive data in the semantic graph to obtain sensitive data nodes; identifying recovery functions in the semantic graph to obtain recovery functions; starting from the sensitive data nodes, traversing the semantic graph based on the function call relationships and data reference relationships to obtain candidate propagation chains; selecting recovery-related propagation chains from the candidate propagation chains based on the recovery functions; extracting recovery chains to be executed from the recovery-related propagation chains according to the data objects, recovery functions, and function call relationships in the recovery-related propagation chains; and performing binary instrumentation on the recovery functions in the recovery chains to be executed to obtain data recovery results.

[0151] This embodiment provides a non-transitory computer-readable storage medium storing computer instructions that cause the computer to execute the methods provided in the above-described method embodiments. These instructions include, for example,: generating a corresponding semantic graph based on a binary program; nodes in the semantic graph including functions and data objects, and edges including function call relationships and data reference relationships; identifying sensitive data in the semantic graph to obtain sensitive data nodes; identifying recovery functions in the semantic graph to obtain recovery functions; starting from the sensitive data nodes, traversing the semantic graph based on the function call relationships and data reference relationships to obtain candidate propagation chains; selecting recovery-related propagation chains from the candidate propagation chains based on the recovery functions; extracting recovery chains to be executed from the recovery-related propagation chains according to the data objects, recovery functions, and function call relationships in the recovery-related propagation chains; and performing binary instrumentation on the recovery functions in the recovery chains to be executed to obtain data recovery results.

[0152] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0153] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0154] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0155] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0156] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for recovering sensitive data in a binary program, characterized in that, include: A semantic graph is generated based on a binary program; the nodes in the semantic graph include functions and data objects, and the edges include function call relationships and data reference relationships. Sensitive data nodes are obtained by performing sensitive data identification on the semantic graph. The semantic graph is subjected to recovery function identification to obtain the recovery function; Starting from the sensitive data nodes, the semantic graph is traversed based on the function call relationships and the data reference relationships to obtain candidate propagation chains; Based on the recovery function, a recovery-related propagation chain is selected from the candidate propagation chains; Based on the data objects, recovery functions, and function call relationships in the recovery-related propagation chain, extract the recovery chain to be executed from the recovery-related propagation chain; Binary instrumentation is performed on the recovery functions in the recovery chain to be executed to obtain the data recovery results.

2. The method according to claim 1, characterized in that, The step of identifying sensitive data nodes from the semantic graph includes: The semantic graph is input into the sensitive data identification model to obtain the sensitive data nodes in the semantic graph. The sensitive data identification model is obtained by training a semantic graph that includes both sensitive and non-sensitive data nodes.

3. The method according to claim 1, characterized in that, The step of performing recovery function identification on the semantic graph to obtain the recovery function includes: The features of function nodes in the semantic graph are matched using a recovery function feature library, and the functions corresponding to the successfully matched function nodes are determined as the recovery functions; and / or Extract the behavioral features of the functions corresponding to the function nodes, and construct a behavioral feature vector based on the behavioral features; Calculate the similarity between the behavioral feature vector and the baseline feature vector of the recovery function; determine the recovery function based on the similarity.

4. The method according to claim 1, characterized in that, The step of traversing the semantic graph based on the function call relationship and the data reference relationship, starting from the sensitive data node, to obtain candidate propagation chains includes: Starting from the sensitive data nodes, the semantic graph is traversed based on the function call relationships and the data reference relationships; During the traversal, the relationship between each data object node and the function node is recorded, including parameter passing relationship, return value relationship, memory read / write relationship and data conversion relationship; The data object node, the function node, and the relationship are combined to form the candidate propagation chain.

5. The method according to claim 1, characterized in that, The step of selecting a recovery-related propagation chain from the candidate propagation chains based on the recovery function includes: If a candidate propagation chain contains the recovery function, and there is a data dependency between the input data object of the recovery function and the sensitive data node, then the candidate propagation chain is marked as a recovery-related propagation chain.

6. The method according to claim 1, characterized in that, The step of extracting the recovery chain to be executed from the recovery-related propagation chain based on the data objects, recovery functions, and function call relationships in the recovery-related propagation chain includes: Based on the data object nodes, recovery functions, and function call relationships in the recovery-related propagation chain, extract the continuous path from the sensitive data node to the input of the recovery function, and from the output of the recovery function to the subsequent data object node, to form a candidate recovery chain; If the candidate recovery chain meets the preset data dependency conditions and path depth conditions, then the candidate recovery chain is the recovery chain to be executed.

7. The method according to claim 6, characterized in that, The data dependency conditions include: The candidate recovery chain includes the recovery function; There is a data dependency between the sensitive data node and the input data of the recovery function; The similarity between the behavioral feature vector of the recovery function and the baseline feature vector of the recovery function is greater than a preset similarity threshold, or the recovery function hits a predefined recovery function feature; The path depth condition includes: the call depth of the candidate recovery chain does not exceed the preset maximum call depth.

8. The method according to claim 1, characterized in that, The binary instrumentation of the recovery functions in the recovery chain to be executed includes: Data acquisition points are set at the entry address, exit address, input buffer, output buffer, and key data access locations of the recovery function, and the runtime status of sensitive data nodes in the recovery chain to be executed is recorded during the execution of the recovery function.

9. The method according to claim 1, characterized in that, The method further includes: The data recovery result includes the output data corresponding to the recovery function, and the output data includes the output buffer address, the output data length, and the output data content. Associate the output data with the corresponding recovery function, input data object, and output data object; The output data object is added to the semantic graph as a new data object, and the data dependency relationship between the output data object and the recovery function is established.

10. The method according to claim 1, characterized in that, The method further includes: During the binary instrumentation of the recovery function in the recovery chain to be executed, the binary instrumentation operation is terminated if any of the following termination conditions are met. The termination conditions include: Reaching the preset maximum call depth; The preset maximum number of instructions to be executed has been reached; Reach the preset maximum number of loops; Reaching the preset maximum execution time; The recovery function finishes execution and obtains the output data; No new data state changes occurred during continuous execution; An abnormal control flow, access exception, or other execution error was detected.

11. The method according to any one of claims 1-10, characterized in that, The method further includes: Based on the API function classification rule library, the purpose function nodes are identified from the semantic graph; Based on the node type and context parameter characteristics in the recovery chain to be executed, the purpose function nodes are classified using rule matching or a lightweight classification model to obtain the purpose category and risk level.

12. An electronic device, characterized in that, include: Processor, memory, and bus, among which: The processor and the memory communicate with each other via the bus; The memory stores program instructions that can be executed by the processor, and the processor can invoke the program instructions to perform the method as described in any one of claims 1-11.

13. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions that, when executed by a computer, cause the computer to perform the method as described in any one of claims 1-11.

14. A computer program product, characterized in that, It includes computer program instructions, which, when read and executed by a processor, perform the method as described in any one of claims 1-11.

Images