Data security verification method, device and equipment and storage medium

Abstract

This application provides a data security verification method, apparatus, device, and storage medium. The method includes: acquiring an encrypted program to be processed; analyzing the encrypted program to generate an abstract syntax tree (AST); simulating the execution of the encrypted program based on externally controllable code contained in the AST; and performing security verification on the encrypted program based on the simulated execution process. Without requiring decryption of the encrypted program, security verification is achieved based on the analyzed AST. The simulated execution method does not consume excessive computational resources and is applicable to various execution environments. Furthermore, simulating execution based on the AST more fully represents the various branches and hierarchical relationships during the execution of the encrypted program, resulting in better security verification accuracy.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to data security verification methods, apparatus, devices and storage media. Background Technology

[0002] With the development of network technology, the attack methods of illegal websites are also gradually upgrading. In order to ensure the network security and stable operation, corresponding defense technologies have emerged.

[0003] In existing technologies, hackers may use webshells to intrude into websites. When making unauthorized intrusions, hackers typically mix webshell files with normal webpage files, then use the website's browser to access the server, thereby gaining control of the server. To ensure website servers are not attacked, static detection methods based on deep learning and natural language processing are used to detect illegal webshells. However, these methods are ineffective against webshells that have been obfuscated using techniques such as encryption or packing. While existing technologies utilize sandboxing for dynamic detection of obfuscated webshells, they have several drawbacks, such as requiring sufficient computing resources in the detection environment to deploy the sandbox. Even if the detection environment can utilize sandboxing for dynamic detection, problems such as low detection efficiency and low accuracy still exist. Summary of the Invention

[0004] To address or improve the problems existing in the prior art, various embodiments of this application provide data security verification methods, apparatuses, devices, and storage media.

[0005] Firstly, in one embodiment of this application, a data security verification method is provided. The method includes:

[0006] Obtain the encryption program to be processed;

[0007] The encryption program is analyzed to generate an abstract syntax tree;

[0008] The execution process of the encryption program is simulated based on the externally controllable code contained in the abstract syntax tree;

[0009] The encryption program is securely verified based on the simulated execution process.

[0010] Secondly, in one embodiment of this application, a data security verification device is provided. The device includes:

[0011] The acquisition module is used to acquire the encryption program to be processed;

[0012] A generation module is used to analyze the encryption program and generate an abstract syntax tree;

[0013] An execution module is used to simulate the execution process of the encryption program based on the externally controllable code contained in the abstract syntax tree;

[0014] The verification module is used to perform security verification on the encryption program based on the simulated execution process.

[0015] Thirdly, in one embodiment of this application, an electronic device is provided, including a memory and a processor; wherein...

[0016] The memory is used to store programs;

[0017] The processor, coupled to the memory, is used to execute the program stored in the memory to implement the data security verification method described in the first aspect.

[0018] Fourthly, in one embodiment of this application, a non-transitory machine-readable storage medium is provided, wherein executable code is stored on the non-transitory machine-readable storage medium, and when the executable code is executed by a processor of an electronic device, the processor executes a data security verification method as described in the first aspect.

[0019] In the technical solution provided in this application embodiment, the program is encrypted to ensure security. Meanwhile, some illegal programs may disguise themselves as legitimate programs and also use encryption to obtain encrypted versions. Since both illegal and legitimate programs are encrypted, it is difficult to determine whether the encrypted program is illegal without knowing the decryption password. However, when the encrypted program is executed, its execution logic is revealed through the code in the abstract syntax tree. Therefore, the execution process of the encrypted program can be further simulated based on the abstract syntax tree, and then the encrypted program can be securely verified based on the simulated execution process. Through the above solution, secure verification of the encrypted program can be achieved based on the analyzed abstract syntax tree without decryption. The simulated execution method for secure verification does not consume excessive computing resources and is applicable to various execution environments. Furthermore, simulation based on the abstract syntax tree can more fully represent the various branches and hierarchical relationships during the execution of the encrypted program, resulting in better security verification accuracy. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating the data security verification method provided in this application embodiment;

[0022] Figure 2 A schematic diagram illustrating the method flow of simulation execution based on simulated variables, as exemplified in an embodiment of this application;

[0023] Figure 3 A schematic diagram illustrating the method flow of simulated execution based on simulated code blocks, as exemplified in an embodiment of this application;

[0024] Figure 4 A schematic flowchart illustrating the branch layer identification method as exemplified in an embodiment of this application;

[0025] Figure 5 A flowchart illustrating the abstract syntax tree generation method provided in this application embodiment;

[0026] Figure 6 This is a schematic diagram of the structure of a data security verification device provided in an embodiment of this application;

[0027] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0029] In some processes described in the specification, claims, and accompanying drawings of this application, multiple operations appearing in a specific order are included. These operations may be executed out of order or in parallel. Operation numbers such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the terms "first," "second," etc., used herein are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types. Moreover, the embodiments described below are only a part of the embodiments of this application, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0030] With the development of network technology, website attack and defense technologies are constantly evolving in the competition. In existing technologies, hackers commonly use webshell technology to intrude into and control websites. Illegal webshell files are disguised as normal webpages, and to circumvent various website defenses, they are often obfuscated or easily detectable code is hidden in branch layers. Using sandbox technology to detect illegal webshells is a common defense method. However, while sandbox technology can detect illegal webshells in environments with high computing resources, it is difficult to use for security detection in dedicated cloud environments with limited computing resources or where deployment is inconvenient. Furthermore, even if sandbox technology can be used to detect obfuscated webshells, the detection efficiency and accuracy are not ideal. Therefore, this application proposes a security verification scheme for encrypted programs in various application environments by using an abstract syntax tree to simulate execution.

[0031] The specific working process in the technical solution of this application will be described in the following embodiments.

[0032] like Figure 1 This is a flowchart illustrating the data security verification method provided in an embodiment of this application. The entity executing this data security verification method can be a local computer, cloud service device, etc. Figure 1 As shown, this data security verification method includes the following steps:

[0033] 101: Obtain the encryption program to be processed.

[0034] 102: Analyze the encryption program to generate an abstract syntax tree.

[0035] 103: Simulate the execution process of the encryption program based on the externally controllable code contained in the abstract syntax tree.

[0036] 104: Perform security verification on the encryption program based on the simulated execution process.

[0037] For ease of understanding, the encryption program in the following embodiments will be illustrated using a packed webshell as an example.

[0038] It's easy to understand that if an unauthorized webshell is displayed in plaintext without any encryption, it's relatively easy to analyze and perform security verification. In conventional security verification methods, when verifying a encrypted webshell without knowing the decryption password, various methods are typically used to try and decrypt it to obtain the plaintext. This decryption is inefficient, especially when verifying a large number of encrypted programs, severely impacting the overall security verification efficiency.

[0039] It's important to note that there are many encryption methods used in encryption programs, such as unexpansion encryption, ordered expansion encryption, and obfuscation encryption. For example, obfuscation encryption involves: 1. Removing variables from the code and replacing them with gibberish. This replaces plaintext strings in the code itself, such as variable names and function names. This is especially effective when some encryption actions target code hidden deep within the score layer, making them difficult to detect during security verification.

[0040] When there is a security verification requirement for an encrypted program, it is not necessary to directly decrypt it. Instead, the compiler can analyze the code to obtain an Abstract Syntax Tree (AST). The AST serves as structured intermediate data for code compilation, and the reconstruction process can be achieved by traversing, adding, and deleting elements within the tree. The AST provides a clearer and more comprehensive view of the execution logic and key code contained within the encrypted program.

[0041] The externally controllable code mentioned here can be externally controllable parameters or functions. For example, it could be I / O operations (input / output operations), database operations, network operations, thread creation, or other code that implicitly passes information or indirectly obtains external resources. It could also include loops, branches, recursion, or code that is interrupted. Because this externally controllable code could provide unauthorized users with the possibility of achieving illegal control, the focus is on comprehensively verifying the execution process related to externally controllable code in the encryption program. For example, when an externally controllable function is found in the abstract syntax tree, it can be marked as a taint, and during simulated execution, execution log information related to the taint can be recorded.

[0042] The simulated execution mentioned here can be understood as simulating the human brain's reasoning process based on the information transmission relationships between the various nodes of code embodied in the abstract syntax tree. This will be explained in detail below with specific examples, and will not be repeated here.

[0043] After simulation execution based on the abstract syntax tree, the simulation execution result can be obtained and the simulation execution process can be recorded (for example, by generating various simulation execution logs, and also by generating analysis abstract syntax tree logs, performance monitoring logs, etc., as needed). If the simulated variable is an externally controllable variable or the simulated code block contains an externally controllable function, and the simulation execution process is related to the risk function in the encryption program (it can be understood that the risk function participates in the simulation execution process of the simulated variable or the simulated code block, for example, the simulated variable is input into the risk function when it reaches a certain node, or the simulated code block calls the risk function during the simulation execution), then the verification result is determined to be that the encryption program is a risky program. The risk function mentioned here is a function that is frequently used or may be used by unauthorized users to achieve illegal operations (such as controlling the website server), summarized based on experience. As mentioned above, if an unauthorized user wants to achieve the purpose of illegal operation, they need to use the externally controllable code in the encryption program to pass illegal parameters to the target server, and then execute the risk function to achieve the purpose of illegal control. Therefore, generally speaking, an encryption program is considered a risky program only when the simulation execution process related to externally controllable code involves risky functions, because in normal programs, it may also be necessary to use externally controllable code or risky functions to perform normal operations.

[0044] For example,

[0045]

[0046] In this example, $_GET['filename'] is an externally controllable function, and file_put_contents() is a risky function. Through the simulation and inference execution in the above example, 1.txt is related to both the externally controllable function and the risky function; therefore, the encryption program in the above example is a risky program.

[0047] Using the above method, when performing security verification on encrypted programs, there is no need to decrypt them. A virtual machine can be used to simulate the execution of the abstract syntax tree (AST) derived from the encrypted program. Since the AST has more detailed and clearer code node information than the opcode, it can achieve security verification for various details (such as the scoring layer), resulting in more accurate verification results. Furthermore, because it uses virtual machine simulation, it does not require the large computing resources of sandbox security verification, allowing for better deployment in various environments (including private clouds with limited computing resources), thus broadening its applicability.

[0048] In one or more embodiments of this application, the step of simulating the execution process of the encryption program based on the externally controllable code contained in the abstract syntax tree includes: determining the runtime simulation variables and simulation code blocks based on the context relationship of the externally controllable code; and simulating execution based on the simulation execution methods corresponding to the simulation variables and simulation code blocks respectively.

[0049] An abstract syntax tree (AST) represents a complete context. This context needs to store various types of information, including: simulated variable names and current values, simulated code blocks and related functions, parameters, etc. During simulation execution, these various types of information can be managed in different ways, forming a logical hierarchical relationship. For example, context management includes global variable management, global symbol management, global constant management, and stack management. Stack management includes the current function stack, local variable management, static variable management, branch / level management, the previous function stack, the stack of the function before that, etc. In practical applications, the runtime environments of different languages ​​(e.g., PHP, JSP, etc.) are largely the same. Therefore, in addition to considering language differences, the design should strive to achieve a language-independent runtime environment. Based on the various types of stored information and their hierarchical relationships, the relationships between the nodes (variables, functions) represented in the AST can be understood. It also provides a reasoning basis for node relationships not explicitly shown in the AST, enabling a more comprehensive simulation execution based on simulated variables and simulated code.

[0050] like Figure 2 This is a schematic flowchart illustrating a method for simulating execution based on simulated variables, as exemplified in an embodiment of this application. From... Figure 2 As can be seen, the simulation execution based on the simulation execution method corresponding to the simulation variables specifically includes the following steps:

[0051] 201: Determine whether the simulated variable has a specific scope.

[0052] 202: If so, simulate execution for the specified scope.

[0053] 203: If not, then the simulation will be executed sequentially in multiple scopes according to the action order corresponding to the variable type of the simulated variable.

[0054] For example, if there is a mock variable 'a' in the abstract syntax tree, it's necessary to determine how many scopes 'a' might belong to and in what order it should be searched. In most cases, the mock variable 'a' might belong to the following scopes: local scope, static scope (static variables within functions), this scope (instance member variables), class scope (class member variables), closure scope, and global scope. If the mock variable 'a' is a reference type, it might belong to any scope.

[0055] In practical applications, when simulating the execution of variables, the search order for simulated variables should be consistent with the characteristics of the language (PHP, JSP, etc.). If the scope is clear, the specific scope is searched directly. Otherwise, the variables are searched in sequence; for example, in the order of local scope, static scope, this scope, class scope, closure scope, and global scope, and the execution result (variable value) of the simulated variables in each scope is recorded.

[0056] The above methods can be used to simulate the possible scope of the simulated variables more comprehensively, discover various possible execution results and interrelationships of the simulated variables, and effectively improve the accuracy of security verification of encryption programs.

[0057] like Figure 3 This is a schematic flowchart illustrating a method for simulating execution based on simulated code blocks, as exemplified in an embodiment of this application. Figure 3 As can be seen, the simulation execution based on the simulation execution method corresponding to the simulation code block specifically includes the following steps:

[0058] 301: Determine the simulated code block based on the code block symbol.

[0059] 302: Determine whether the simulated code block contains a branch layer.

[0060] 303: If the branch layer is not included, then the simulation execution is performed according to the simulation execution method corresponding to the language type.

[0061] 304: If the branch layer is included, then the execution is simulated according to the branch hierarchy relationship.

[0062] As mentioned earlier, some risky and illegal encryption programs, in order to evade security checks, place risky code in branch layers. Conventional security checks cannot effectively detect this risky code within the branch layers. Furthermore, it should be noted that conventional checks generate opcodes based on the obtained abstract syntax tree and then perform dynamic checks. However, the opcodes do not represent the branch layers and their hierarchical relationships, meaning that dynamic checks based on opcodes cannot comprehensively check the branch layers. Therefore, this solution simulates execution at the branch layers based on the abstract syntax tree, thereby achieving comprehensive detection of the branch layers.

[0063] Code block notation may differ between languages. In most languages, a general code block begins and ends with curly braces. A branching layer, however, is a special type of layer. For example:

[0064]

[0065] It should be noted that the handling of variables exiting a regular layer differs depending on the language in the above examples. For instance, in Java, variables within a regular layer need to be destroyed upon exiting, while in PHP they need to be retained. Therefore, different methods are required for recording the execution process and results of branch layers within code blocks for different languages.

[0066] In practical applications, a normal layer only needs to consider whether variables within the layer are destroyed when exiting the layer, and take targeted measures to record relevant log data during the execution process. A branch layer, on the other hand, needs to consider which branch is the correct branch, the state of simulated variables when exiting the branch layer, and the merging of simulated variables, etc.

[0067] As described in step 302, it is determined whether the simulated code block contains a branch layer. The specific implementation process is as follows: Figure 4 This is a schematic flowchart illustrating a branch layer identification method as exemplified in an embodiment of this application. Specifically, it includes the following steps:

[0068] 302a: Determine whether the simulated code block contains a state change identifier and value change amount representing the branch layer.

[0069] 302b: If included, then the simulated code block contains the branch layer.

[0070] 302c: Record the state change identifier and the value change amount.

[0071] During simulation execution, it has the ability to identify branching layers, which can identify two types of changes in simulated variables, and thus determine whether there are branching layers in the code block:

[0072] Simulate the state changes of variables in the branch layer and label these changes. For example, state change labels include: UNKNOWN (unknown), ASSIGNED (assigned a value), DANGER (mixed state, combining TAINTED and ASSIGNED labels), and TAINTED (contaminated). For instance:

[0073]

[0074] Identifying the value changes of simulated variables within a code block. During simulated execution, after entering a branch level, the simulated variable may be reassigned. After reassignment, the value of the simulated variable within the branch level is deterministic. However, after exiting the branch level, the simulated variable becomes indeterminate because the code in the branch level may or may not be executed in actual execution. To enumerate all possible scenarios, it is necessary to record the value changes.

[0075] For example, value changes include: the current value, which can be the most certain value; and possible values ​​(including values ​​obtained based on the inference strategy), of which there may be multiple, and these should be recorded as much as possible. By recording various value changes, various branch layers (including multi-layered nested branch layers) can be discovered, and execution records can be simulated based on each branch layer, thereby enabling secure verification of the branch layers.

[0076]

[0077] In one or more embodiments of this application, if the branch layer is included, the step of simulating execution according to the branch hierarchy includes: determining the branch hierarchy based on the state change identifier and the value change amount; and simulating execution according to the branch hierarchy. The step of performing security verification on the encryption program based on the simulation execution result includes: using the state change identifier and the value change amount when exiting the branch layer as the simulation execution result; and performing security verification based on the state change identifier and the value change amount.

[0078] During the simulation execution based on the state change identifiers and value changes, execution must be performed according to the branch hierarchy. When generating the abstract syntax tree, branch layers with clear hierarchical relationships can be represented in the tree structure, and the information in each branch layer can be recorded. Furthermore, simulation execution can be performed based on possible score hierarchy relationships according to the reasoning logic. When the branch layer simulation execution ends and the layer exits, the state change identifiers and value changes within the layer are recorded to securely verify the simulation execution results and whether the state change identifiers and value changes during the simulation execution are related to the risk function, thus achieving secure verification of the code block.

[0079] In one or more embodiments of this application, the method further includes: determining whether the simulation execution result is an unreliable result. If it is an unreliable result, a reasoning strategy is determined based on the state change identifier and the value change amount. The simulation is then performed on the simulation variable based on the reasoning strategy.

[0080] In practical applications, various inference strategies are developed for different situations. When the simulation execution result is unreliable (e.g., the result is considered inaccurate, or the result is incomplete, and there may be results from other unobtained scenarios), an inference strategy is needed for simulation execution. The inference strategy mentioned here is a heuristic inference strategy, such as adjusting the state change indicators or value changes of simulated variables in different scopes, or adjusting the value changes representing the loop count in simulated variables. Because some malicious encryption programs may embed code that loops for 1 minute or waits for 1 minute, and these nodes are represented by simulated variables in the abstract syntax tree, to determine whether this 1-minute loop or wait is associated with other malicious behavior, the inference strategy can be used to reduce the loop count, thus reducing the loop time, or adjust the wait time to reduce the wait time. This allows for simulation execution based on the inference strategy, determining whether the execution process or simulation result is associated with a risk function, thereby achieving security verification of the encryption program.

[0081] For example, as shown below, the correct value of e is calculated using a heuristic strategy.

[0082]

[0083] In practical applications, inference strategies can be added to each simulation result for correction; inference strategies can also be added to results that are judged as unreliable for correction.

[0084] In one or more embodiments of this application, the step of simulating the simulation of the simulated variables based on the inference strategy includes: generating a speculative state identifier based on the state change identifier and the context relationship; and generating a speculative value based on the value change amount and the context relationship.

[0085] During the simulation execution based on the inference strategy, the inferred state identifiers in other possible scopes are inferred based on the records in a previous scope identified by state change identifiers. Furthermore, the inferred values ​​in other scopes are inferred based on the value of a variable in a certain scope.

[0086] For example, the following examples all achieve detection through inference correction:

[0087]

[0088]

[0089] like Figure 5 This is a flowchart illustrating the abstract syntax tree generation method provided in an embodiment of this application. Figure 5 As shown, the step of analyzing the encryption program to generate an abstract syntax tree includes: 501: Performing lexical and syntactic analysis on the encryption program to generate a basic syntax tree. 502: If the execution result of any node in the basic syntax tree is a constant, then replacing any node in the basic syntax tree with a constant. 503: Generating the abstract syntax tree.

[0090] In compiler theory, the compiler typically transforms code through three steps: lexical analysis, syntax analysis, and then generates an abstract syntax tree (AST).

[0091] A packer (the encryption program mentioned earlier) is a program that performs certain actions after an executable file has been compiled, for specific needs. It can be used to protect copyrighted information and prevent unauthorized modification. It can also be used to pack malware and other software to avoid detection during security checks by security software.

[0092] A syntax tree is a tree-like structure used by computers to describe something. The syntax tree corresponding to code is the tree-like structure describing that code, representing its syntactic structure. In this application, unless otherwise specified, "syntax tree" refers to an abstract syntax tree. An abstract syntax tree (AST) is an abstract representation of the syntactic structure of source code, representing the syntactic structure of a programming language in a tree-like form. After obtaining a piece of code, it can be parsed according to the syntactic rules of the programming language used by that code, thereby constructing the AST.

[0093] The process of generating an abstract syntax tree will be illustrated below with specific examples.

[0094] Lexical analysis: Text -> token list, including: removing spaces, classifying tokens, removing spaces, then classifying tokens again, identifying which are syntax keywords, which are operators, which are statement cutoffs, and which are data.

[0095] Syntax analysis: token list -> syntactic binary tree, including: scanning the token stream, then analyzing its syntax. This step should analyze the specific execution rules of a statement ending with a semicolon, then use Reverse Polish notation to combine them, and finally form a binary tree. The binary tree is merged step by step from bottom to top.

[0096] Specifically:

[0097] Step 1: Lexical analysis, also known as scanning. This involves reading the encryption program's code and then merging it into tokens according to predetermined rules. Whitespace, comments, and other identifiers are removed. Finally, the entire code is divided into a list of tokens (or a one-dimensional array).

[0098] const a = 5;

[0099] / / Convert to

[0100] [{value:'const',type:'keyword'},{value:'a',type:'identifier'},...]

[0101] Copy code

[0102] When lexical analysis is performed on the source code, it reads the code letter by letter. When it encounters a space, an operator, or a special character, it considers a sentence to be complete.

[0103] The second step is syntax analysis, also known as parsing. This process transforms the array obtained from lexical analysis into a tree structure and verifies the syntax. If there are errors, it throws a syntax error.

[0104]

[0105] In practical applications, when generating a tree, the parser will remove some unnecessary tokens (such as incomplete parentheses).

[0106] The basic syntax tree obtained through the above method is the initial syntax tree. To facilitate subsequent analysis and make it easier for users to analyze intuitively, some nodes can be optimized. For example, nodes can be replaced with constants. If the execution result of any node in the basic syntax tree is a constant, then any node in the basic syntax tree can be replaced with a constant. After the above optimization process, a relatively simplified abstract syntax tree is obtained.

[0107] In one or more embodiments of this application, the method further includes: determining the formulas and functions of each node in the executable code content; recording the processing records of the formulas and functions during the generation of the simulated execution result; and performing a risk assessment on the simulated execution result based on the processing records.

[0108] In practical applications, false positives and false negatives may occur. Therefore, it is necessary to take measures to identify and address these vulnerabilities. Security checks can be performed on data and functions that are prone to false positives or false negatives. For example, the operations of each node can be recorded, such as assignment records and calculation records. Call records can also be kept for each function, including ordinary functions, class functions, and closure functions.

[0109] For example, time-based adversarial techniques are often used in illegal programs.

[0110] As shown in the example below, if the return value of the function time() is not marked as TAINTED (tainted), this sample will be missed.

[0111] <?php

[0112] $a = time();

[0113] sleep(60*5); / / Sleep for 5 minutes, a time-countermeasure.

[0114] $b = time();

[0115] $index = $b - $a - (5 * 60) + 2;

[0116] $c=array('11','22','eval($_GET[1])','44');

[0117] system($c[$index]);

[0118] As shown in the example below, if the return value of time() is directly marked as TAINTED and contaminated, this sample will be falsely reported.

[0119]

[0120] Therefore, corrections can be made based on contextual semantics, and corrections can be performed in as many operations and functions as possible, which can effectively reduce the occurrence of false alarms and false negatives.

[0121] Based on the same idea, this application also provides a data security verification device. For example... Figure 6 This is a schematic diagram of a data security verification device provided in an embodiment of this application. The data security verification device includes:

[0122] The acquisition module 61 is used to acquire the encryption program to be processed.

[0123] The generation module 62 is used to analyze the encryption program and generate an abstract syntax tree.

[0124] The execution module 63 is used to simulate the execution process of the encryption program based on the externally controllable code contained in the abstract syntax tree.

[0125] The verification module 64 is used to perform security verification on the encryption program based on the simulated execution process.

[0126] Optionally, the execution module 63 is used to determine the simulated variables and simulated code blocks at runtime based on the context relationship of the externally controllable code; and to simulate execution based on the simulated execution methods corresponding to the simulated variables and simulated code blocks respectively.

[0127] Optionally, the execution module 63 is used to determine whether the simulated variable has a specific scope;

[0128] If so, then simulate execution for the specific scope;

[0129] If not, the simulation will be executed sequentially in multiple scopes according to the action order corresponding to the variable type of the simulated variable.

[0130] Optionally, the execution module 63 is configured to determine the simulated code block based on the code block symbol;

[0131] Determine whether the simulated code block contains a branch layer;

[0132] If the branch layer is not included, then the execution is simulated according to the simulation execution method corresponding to the language type;

[0133] If the branch layer is included, the execution is simulated according to the branch hierarchy relationship.

[0134] Optionally, it also includes a judgment module 65, used to determine whether the simulated code block contains a state change identifier and value change amount representing the branch layer;

[0135] If it is included, then the simulated code block contains the branch layer;

[0136] Record the state change identifier and the value change amount.

[0137] Optionally, the execution module 63 is used to determine the branch hierarchy relationship based on the state change identifier and the value change amount;

[0138] Simulate execution based on the described branch hierarchy;

[0139] The security verification of the encryption program based on the simulation execution results includes:

[0140] The state change identifier and the value change amount when exiting the branch layer are used as the simulation execution result;

[0141] Security verification is performed based on the state change identifier and the value change amount.

[0142] Optionally, it also includes a judgment module 65, used to determine whether the simulation execution result is an unreliable result;

[0143] If the result is unreliable, then the reasoning strategy is determined based on the state change identifier and the value change amount;

[0144] The simulation is performed on the simulated variables based on the inference strategy.

[0145] Optionally, the execution module 63 is configured to generate a speculative state identifier based on the state change identifier and the context relationship;

[0146] Based on the change in value and the contextual relationship, a predicted value is generated.

[0147] Optionally, the generation module 62 is used to perform lexical analysis and syntax analysis on the encryption program to generate a basic syntax tree;

[0148] If the execution result of any node in the basic syntax tree is a constant, then any node in the basic syntax tree is replaced with a constant.

[0149] Generate the abstract syntax tree.

[0150] Optionally, it also includes a determining module 66, used to determine the formulas and functions of each node in the executable code content;

[0151] Record the processing steps performed by the formula and the function during the generation of the simulated execution result;

[0152] A risk assessment is performed on the simulation execution results based on the processing records.

[0153] Optionally, the verification module 64 is configured to determine that the encryption program is a risky program if the simulated variable is an externally controllable variable or the simulated code block contains an externally controllable function, and the simulated execution process is related to the risky function in the encryption program.

[0154] One embodiment of this application also provides an electronic device. For example... Figure 7 This is a schematic diagram of an electronic device provided in an embodiment of this application. The electronic device includes a memory 701, a processor 702, and a communication component 703; wherein,

[0155] The memory 701 is used to store programs;

[0156] The processor 702, coupled to the memory, is configured to execute the program stored in the memory for:

[0157] Obtain the encryption program to be processed;

[0158] The encryption program is analyzed to generate an abstract syntax tree;

[0159] The execution process of the encryption program is simulated based on the externally controllable code contained in the abstract syntax tree;

[0160] The encryption program is securely verified based on the simulated execution process.

[0161] Optionally, the processor 702 is configured to determine the simulated variables and simulated code blocks at runtime based on the context of the externally controllable code;

[0162] Simulation execution is performed based on the simulation variables and the simulation code blocks, respectively, according to their corresponding simulation execution methods.

[0163] Optionally, the processor 702 is used to determine whether the simulated variable has a specific scope;

[0164] If so, then simulate execution for the specific scope;

[0165] If not, the simulation will be executed sequentially in multiple scopes according to the action order corresponding to the variable type of the simulated variable.

[0166] Optionally, the processor 702 is configured to determine the simulated code block based on the code block symbol;

[0167] Determine whether the simulated code block contains a branch layer;

[0168] If the branch layer is not included, then the execution is simulated according to the simulation execution method corresponding to the language type;

[0169] If the branch layer is included, the execution is simulated according to the branch hierarchy relationship.

[0170] Optionally, the processor 702 is used to determine whether the simulated code block contains a state change identifier and value change amount representing the branch layer;

[0171] If it is included, then the simulated code block contains the branch layer;

[0172] Record the state change identifier and the value change amount.

[0173] Optionally, the processor 702 is configured to determine the branch hierarchy relationship based on the state change identifier and the value change amount;

[0174] Simulate execution based on the described branch hierarchy;

[0175] The security verification of the encryption program based on the simulation execution results includes:

[0176] The state change identifier and the value change amount when exiting the branch layer are used as the simulation execution result;

[0177] Security verification is performed based on the state change identifier and the value change amount.

[0178] Optionally, the processor 702 is used to determine whether the simulation execution result is an unreliable result;

[0179] If the result is unreliable, then the reasoning strategy is determined based on the state change identifier and the value change amount;

[0180] The simulation is performed on the simulated variables based on the inference strategy.

[0181] Optionally, the processor 702 is configured to generate a speculative state identifier based on the state change identifier and the context relationship;

[0182] Based on the change in value and the contextual relationship, a predicted value is generated.

[0183] Optionally, the processor 702 is used to perform lexical analysis and syntax analysis on the encryption program to generate a basic syntax tree;

[0184] If the execution result of any node in the basic syntax tree is a constant, then any node in the basic syntax tree is replaced with a constant.

[0185] Generate the abstract syntax tree.

[0186] Optionally, the processor 702 is used to determine the formulas and functions of each node in the executable code content;

[0187] Record the processing steps performed by the formula and the function during the generation of the simulated execution result;

[0188] A risk assessment is performed on the simulation execution results based on the processing records.

[0189] Optionally, the processor 702 is configured to determine that the security verification result is that the encryption program is a risky program if the simulated variable is an externally controllable variable or the simulated code block contains an externally controllable function, and the simulated execution process is associated with the risky function in the encryption program.

[0190] The aforementioned memory 701 can be configured to store various other data to support operation on the electronic device. Examples of such data include instructions for any application or method used to operate on the electronic device. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0191] Furthermore, the processor 702 in this embodiment may specifically be a programmable switching processing chip, which is configured with a data copying engine and can copy the received data.

[0192] When the processor 702 executes the program in memory, in addition to the functions described above, it can also perform other functions, as detailed in the descriptions of the preceding embodiments. Furthermore, as... Figure 7 As shown, the electronic device also includes other components such as the power supply component 704.

[0193] This application also provides a non-transitory machine-readable storage medium storing executable code. When the executable code is executed by a processor of an electronic device, the processor performs... Figure 1 The method described in the corresponding embodiment.

[0194] This application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, enable the processor to perform... Figure 1 The method described in the corresponding embodiment.

[0195] Based on the above embodiments, the program is encrypted to ensure security. Meanwhile, some illegal programs may disguise themselves as legitimate programs and also use encryption to obtain encrypted versions. Since both illegal and legitimate programs are encrypted, it is difficult to determine whether the encrypted program is illegal without knowing the decryption key. However, when the encrypted program is executed, its execution logic is revealed through the code in the abstract syntax tree. Therefore, the execution process of the encrypted program can be further simulated based on the abstract syntax tree, and then the encrypted program can be securely verified based on the simulated execution process. Through this scheme, secure verification of the encrypted program can be achieved based on the analyzed abstract syntax tree without decryption. The simulated execution method does not consume excessive computing resources and is applicable to various execution environments. Furthermore, simulation based on the abstract syntax tree can more fully represent the various branches and hierarchical relationships during the execution of the encrypted program, resulting in better security verification accuracy.

[0196] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0197] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0198] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A data security verification method, characterized in that, The method includes: Obtain the encryption program to be processed; The encryption program is analyzed to generate an abstract syntax tree; Based on the contextual relationships of the externally controllable code contained in the abstract syntax tree, the simulated variables and simulated code blocks of the simulated execution runtime are determined. The simulated execution is understood as the reasoning execution that simulates the human brain reasoning process based on the information transmission relationships between the various node codes embodied in the abstract syntax tree. Simulation execution is performed based on the simulation variables and the simulation code blocks, respectively, according to their corresponding simulation execution methods. The encryption program is securely verified based on the simulated execution process.

2. The method according to claim 1, characterized in that, Simulation execution is performed based on the simulation execution method corresponding to the simulated variables, including: Determine whether the simulated variable has a specific scope; If so, then simulate execution for the specific scope; If not, the simulation will be executed sequentially in multiple scopes according to the action order corresponding to the variable type of the simulated variable.

3. The method according to claim 1, characterized in that, Simulated execution is performed based on the simulated execution method corresponding to the simulated code block, including: The simulated code block is determined based on the code block symbol; Determine whether the simulated code block contains a branch layer; If the branch layer is not included, then the execution is simulated according to the simulation execution method corresponding to the language type; If the branch layer is included, the execution is simulated according to the branch hierarchy relationship.

4. The method according to claim 3, characterized in that, The step of determining whether the simulated code block contains a branch layer includes: Determine whether the simulated code block contains a state change identifier and value change amount representing the branch layer; If it is included, then the simulated code block contains the branch layer; Record the state change identifier and the value change amount.

5. The method according to claim 4, characterized in that, If the branch layer is included, the simulation execution is performed according to the branch hierarchy, including: The branch hierarchy is determined based on the state change identifier and the value change amount; Simulate execution based on the described branch hierarchy; The security verification of the encryption program based on the simulated execution process includes: The state change identifier and the value change amount when exiting the branch layer are used as the simulation execution result; Security verification is performed based on the state change identifier and the value change amount.

6. The method according to any one of claims 4 or 5, characterized in that, Also includes: Determine whether the simulated execution result is unreliable; If the result is unreliable, then the reasoning strategy is determined based on the state change identifier and the value change amount; The simulation is performed on the simulated variables based on the inference strategy.

7. The method according to claim 6, characterized in that, The simulation of the simulated variables based on the inference strategy includes: Based on the state change identifier and the context relationship, a predicted state identifier is generated; Based on the change in value and the contextual relationship, a predicted value is generated.

8. The method according to claim 1, characterized in that, The step of analyzing the encryption program to generate an abstract syntax tree includes: Lexical and syntactic analysis are performed on the encryption program to generate a basic syntax tree; If the execution result of any node in the basic syntax tree is a constant, then any node in the basic syntax tree is replaced with a constant. Generate the abstract syntax tree.

9. The method according to claim 1, characterized in that, Also includes: Determine the formulas and functions of each node in the executed code; Record the processing steps performed by the formula and function during the generation of the simulation execution results; A risk assessment is performed on the simulation execution results based on the processing records.

10. The method according to claim 1, characterized in that, The security verification of the encryption program based on the simulated execution process includes: If the simulated variable is an externally controllable variable or the simulated code block contains an externally controllable function, and the simulated execution process is related to the risky function in the encryption program, then the verification result is determined to be that the encryption program is a risky program.

11. A data security verification device, characterized in that, The device includes: The acquisition module is used to acquire the encryption program to be processed; A generation module is used to analyze the encryption program and generate an abstract syntax tree; The execution module is used to determine the simulated variables and simulated code blocks of the runtime of the simulated execution based on the context relationship of the externally controllable code contained in the abstract syntax tree. The simulated execution is understood as the reasoning execution that simulates the human brain reasoning process based on the information transmission relationship between the code nodes embodied in the abstract syntax tree. Simulation execution is performed based on the simulation variables and the simulation code blocks, respectively, according to their corresponding simulation execution methods. The verification module is used to perform security verification on the encryption program based on the simulated execution process.

12. An electronic device, characterized in that, Includes memory and processor; among which, The memory is used to store programs; The processor, coupled to the memory, is configured to execute the program stored in the memory for implementing the method of any one of claims 1 to 10.

13. A non-transitory machine-readable storage medium, characterized in that, The non-transitory machine-readable storage medium stores executable code that, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1 to 10.

Images