Data security hardening method, apparatus, device, and medium

Abstract

Embodiments of the present application provide a data security hardening method and device, equipment and medium, the method relates to the security technical field, can be applied in the application software of terminal equipment;Including: obtaining the conversion hit frequency between the basic function code blocks in the target program, determining the error handling path in the basic function code blocks of the target program according to the conversion hit frequency;Obtain the variable configuration information used for configuring program jump parameters, generate the obstacle code containing the cooperative jump table according to the variable configuration information;The cooperative jump table in the obstacle code is used to hinder the fuzz testing for the target program;Insert the obstacle code in the error handling path of the target program, generate the hardened binary file for publishing. By adopting the embodiments of the present application, the vulnerability detection capability in the fuzz testing can be reduced, and then the security of data can be improved.

Description

Technical Field

[0001] This application relates to the field of security technology, and in particular to a data security hardening method, apparatus, equipment, and medium. Background Technology

[0002] With the rapid development of application software, users are increasingly using it through terminal devices. While applications bring convenience to users' lives, they also create security problems. For example, before an application is released, researchers can conduct software testing to discover and fix vulnerabilities before release. However, after release, attackers can also test the application. If researchers fail to detect all vulnerabilities before release, attackers may find them and launch attacks to steal user privacy, defraud users of their property, etc., posing a significant security risk to users. Summary of the Invention

[0003] This application provides a data security hardening method, apparatus, device, and medium that can reduce the vulnerability detection capability in fuzz testing, thereby improving data security.

[0004] This application provides a data security hardening method, including: Obtain the conversion hit frequency between basic functional code blocks in the target program, and determine the error handling path in the basic functional code blocks of the target program based on the conversion hit frequency; Obtain variable configuration information used to configure program jump parameters, and generate obstacle code containing a cooperative jump table based on the variable configuration information; the cooperative jump table in the obstacle code is used to prevent fuzz testing against the target program; Insert barrier code into the error handling path of the target program to generate a hardened binary for release.

[0005] One embodiment of this application provides a data security hardening device, including: The path determination module is used to obtain the conversion hit frequency between basic functional code blocks in the target program, and determine the error handling path in the basic functional code blocks of the target program based on the conversion hit frequency; The code generation module is used to obtain variable configuration information for configuring program jump parameters, and generate obstacle code containing a cooperative jump table based on the variable configuration information; the cooperative jump table in the obstacle code is used to prevent fuzz testing against the target program. The code insertion module is used to insert obstruction code into the error handling path of the target program, generating a hardened binary file for release.

[0006] The path determination module includes: The valid data execution unit is used to obtain a valid test set, execute the target program based on the valid test data contained in the valid test set, and obtain the target execution edge set; each executed edge in the target execution edge set is used to connect two basic functional code blocks in the target program. The random data execution unit is used to obtain a random test set, execute the target program according to the random test data contained in the random test set, and obtain a random execution edge set; each executed edge in the random execution edge set is used to connect two basic functional code blocks in the target program; The hit frequency determination unit is used to count the first occurrence count corresponding to each executed edge in the target execution edge set and the second occurrence count corresponding to each executed edge in the random execution edge set, and to determine the hit frequency of the transition between basic functional code blocks in the target program based on the first occurrence count and the second occurrence count. The error handling path determination unit is used to determine the error handling path of the target program from the set of randomly executed edges based on the conversion hit frequency.

[0007] The error handling path determination unit includes: The executed edge acquisition subunit is used to acquire the executed edge i from the set of randomly executed edges. The executed edge i is used to connect the basic function code block a and the basic function code block b in the target program. i is a positive integer less than or equal to the number of executed edges in the set of randomly executed edges. a and b are both positive integers less than or equal to the number of basic function code blocks in the target program. The error handling edge determination subunit is used to determine the executed edge i as an error handling edge if the hit frequency of the transition between basic function code block a and basic function code block b is less than the frequency threshold and the executed edge i does not belong to the target execution edge set. The error handling edge combination subunit is used to combine the error handling edges in the random execution edge set to obtain D error edge sets. Based on the basic functional code block associated with the error handling edge in each error edge set, the error handling path of the target program is determined; D is a positive integer.

[0008] The program jump parameters include jump restriction parameters, length restriction parameters, and jump table size parameters. The variable configuration information includes jump configuration information for jump restriction parameters, length configuration information for length restriction parameters, and size configuration information for jump table size parameters. The code generation module includes: The jump table declaration unit is used to declare K cooperative jump tables based on the jump configuration information, length configuration information, and size configuration information in the variable configuration information; K is a positive integer. The label insertion unit is used to insert a label to mark the jump position in each of the K collaborative jump tables, generating a barrier code containing the K collaborative jump tables.

[0009] The size configuration information includes first sub-configuration information and second sub-configuration information, wherein the jump table size determined by the first sub-configuration information is greater than the jump table size determined by the second sub-configuration information. The jump table declaration unit is specifically used for: Based on the jump configuration information, length configuration information, and first sub-configuration information in the variable configuration information, declare a first type jump table; the first type jump table is used to indicate the error handling path to be executed by retaining test cases in fuzz testing; Based on the jump configuration information, length configuration information, and second sub-configuration information in the variable configuration information, declare a second type of jump table, and determine the first type of jump table and the second type of jump table as K cooperative jump tables; the second type of jump table is used for test cases of decay fuzz testing.

[0010] The code insertion module includes: The critical location determination unit is used to determine the critical location corresponding to the obstacle code in the error handling path of the target program, and insert the obstacle code into the critical location by the compiler; The compilation processing unit is used in the compiler to compile the target program into which the obstruction code is inserted, generating a hardened binary file for distribution.

[0011] The device also includes: The file publishing module is used to publish the hardened binary file to the software management platform, so that the first device in the software management platform can obtain the hardened binary file, load the hardened binary file, and access the application software corresponding to the hardened binary file.

[0012] The device also includes: The target test set acquisition module is used to acquire the target test set provided by the second device in the fuzz test when it is detected that the second device is performing fuzz testing on the hardened binary file. The test case retention module is used to retain target test cases associated with error handling paths from the target test set by hardening the obstacle code in the binary file; the target test cases are used to hinder the vulnerability finding capability in fuzzing.

[0013] Among them, the collaborative jump table in the obstacle code includes the first type of jump table; The test case retention module includes: The scheduling acquisition unit is used to acquire the computational power scheduling of test case x in the first type of jump table in the obstacle code when the execution path of test case x in the target test set is an error handling path; x is a positive integer. The quality assessment unit is used to assess the quality of the computational power scheduling of test case x through the test case evaluator of fuzz testing, and obtain the quality assessment value of test case x. The quality judgment unit is used to determine test case x as the target test case when the quality evaluation value of test case x meets the evaluation threshold condition.

[0014] Among them, the collaborative jump table in the obstacle code includes a second type of jump table; The test case retention module includes: The mutation processing unit is used to mutate test case y in the test case mutant of fuzzing test according to the second type jump table in the obstacle code when the execution path of test case y in the target test set is an error handling path in the hardened binary file, so as to generate candidate test cases; y is a positive integer; The data length determination unit is used to determine the candidate test case as the target test case when the data length of the candidate test case is greater than the data length of the test case y.

[0015] The device also includes: The execution trajectory generation module is used in fuzz testing to execute a hardened binary file based on test cases in the target test set. By using the random logic contained in the obstacle code in the hardened binary file, it generates one or more execution trajectories corresponding to the test cases in the target test set. The feedback information accumulation module is used to obtain the execution feedback information corresponding to one or more execution trajectories, and to accumulate the execution feedback information corresponding to the test cases in the target test set to obtain the total amount of feedback information. The saturation record generation module is used to generate a storage saturation record when the total amount of feedback information in memory is greater than or equal to the storage space. The storage saturation record is used to indicate that the fuzz test should stop collecting execution feedback information.

[0016] One aspect of this application provides a computer device, including a memory and a processor. The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to call the computer programs so that the computer device executes the method provided in one aspect of this application.

[0017] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having a processor performs the method provided in one aspect of this application.

[0018] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in the above aspect.

[0019] This application embodiment can obtain the transition hit frequency between basic functional code blocks in the target program, determine the error handling path in the basic functional code blocks of the target program based on the transition hit frequency, and then obtain variable configuration information for configuring program jump parameters. Based on the variable configuration information, barrier code containing a cooperative jump table is generated. The cooperative jump table in this barrier code is used to prevent fuzzing of the target program. By inserting the barrier code into the error handling path of the target program, a hardened binary file for release is generated. It is evident that after determining the error handling path from the target program, a hardened binary file is obtained by inserting barrier code into the error handling path. Inserting the barrier code into the error handling path does not affect the normal execution efficiency of the target program. That is, the data corresponding to the hardened binary file, while executing normally, can reduce the vulnerability detection capability in fuzzing, thereby improving data security. 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 only 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 This is a schematic diagram illustrating a scenario for security hardening of an application provided in an embodiment of this application; Figure 2 This is a schematic diagram of a network architecture provided in an embodiment of this application; Figure 3 This is a schematic diagram of an attack process provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a data security hardening method provided in an embodiment of this application; Figure 5This is a schematic diagram of a process for generating a hardened binary file provided in an embodiment of this application; Figure 6 This is a flowchart illustrating a data security hardening method provided in an embodiment of this application; Figure 7 This is a schematic diagram of the component structure for grayscale fuzzy testing provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a data security hardening device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0023] This application relates to cloud security technology. Cloud security refers to the collective term for security software, hardware, users, organizations, and security cloud platforms based on cloud computing business models. Cloud security integrates emerging technologies and concepts such as parallel processing, grid computing, and unknown virus behavior detection. It uses a large number of clients in a mesh network to monitor abnormal software behavior, obtain the latest information on Trojans and malware on the Internet, and send it to the server for automatic analysis and processing. Finally, it distributes solutions for viruses and Trojans to each client.

[0024] This application specifically relates to application attack protection in cloud security technology. Before the application software is released, the source code of the application software can be hardened to generate a protected binary code file, which can then be released. When an attacker uses fuzzing to attack the protected binary code file, this protected binary code file can ensure that the attacker cannot access the source code of the application software, thereby improving the security of the application software.

[0025] This application also involves the following concepts: Fuzzing is a method of discovering software faults by providing unexpected input and monitoring anomalous results. It's an automatic or semi-automatic forced discovery technique. Instead of guessing which data will cause damage, fuzzing throws as much random data as possible into the program, offering advantages such as high automation, good usability, and low false positive rate. In other words, fuzzing can run a target program with random input to observe anomalous behavior, which often indicates a defect in the target program. Fuzzing techniques are generally categorized into black-box fuzzing, white-box fuzzing, and gray-box fuzzing.

[0026] Black-box fuzzing: Treating the target program as a black box and generating input data based on mathematical or statistical models, the lack of knowledge about the internal knowledge structure of the target program limits the use of black-box fuzzing.

[0027] White-box fuzzing: It can fully access the target program and perform a large amount of program analysis, such as symbolic execution, but due to the cost of program analysis, white-box fuzzing has poor scalability.

[0028] Gray-box fuzzing strikes a balance between effectiveness and scalability by using lightweight program analysis to capture execution feedback from the target program during testing. This feedback effectively helps generate high-quality seeds (also known as test cases) without slowing down the target program's execution.

[0029] Basic block: A basic block refers to a sequence of statements executed sequentially in the target program. A basic block has only one entry point and one exit point. The entry point can be the first executable statement in the statement sequence, and the exit point is the last statement. Execution of a basic block requires entering from the entry point and exiting from the exit point. In the embodiments of this application, the basic block can also be referred to as the basic functional code block in the target program.

[0030] Jump List: A jump list is a method for transferring program control from one part to another, allowing jumps between marked locations in the code. Because labels are stored in the jump list, program control can be transferred to any labeled location by querying the jump list.

[0031] Vulnerability: A vulnerability is a flaw in the specific implementation of hardware, software, protocols, or system security policies that allows an attacker to gain unauthorized access to or compromise the system. Finding exploitable vulnerabilities is often the starting point of an attack.

[0032] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating a scenario for security hardening of an application, provided in an embodiment of this application. For example... Figure 1As shown, during the application software development phase, after developers complete the writing of the application software code, they can obtain the application software's source code (also called source program). Source code can refer to a human-readable file written according to a specific programming language specification; source code is usually written in a high-level language. Source code can be a text file, which can be compiled into a program executable by a computer. Of course, source code can also be in the form of books, magnetic tapes, or other media; this application does not specifically limit the media format of the source code. By compiling the application software's source code, binary code (also called a binary file) executable by a computer is generated. This compilation can be understood as the process of translating human-readable source code into a program executable by a computer, and this process can be performed by various compilers.

[0033] During the application software testing phase, testers (who can be assumed to be trustworthy individuals, such as any member of the application software development team) can test the source code. This includes compiling the source code to obtain unprotected binary code, testing this unprotected binary code to identify and fix vulnerabilities, thus improving the application software. Once all vulnerabilities identified during testing have been fixed, the source code can be hardened to generate self-protected binary code. This self-protected binary code can be used to resist fuzzing attacks on the application software and can be released publicly. After the protected binary code is released, ordinary users can use the application software through it; when an attacker wants to attack the application software, the attacker can only obtain the protected binary code and cannot access the application software's source code.

[0034] It should be noted that the hardening involved in this application only targets the binary code used for distribution and does not affect the internal testing process of the application software by testers, nor does it affect the normal execution of the application software. When an attacker wants to find vulnerabilities in the application software through fuzzing and exploit these vulnerabilities to attack or damage the application software, the protected binary code can hinder the attacker's fuzzing, such as reducing the vulnerability detection capability of fuzzing.

[0035] Please see Figure 2 , Figure 2 This is a schematic diagram of a network architecture provided in an embodiment of this application. Figure 2 As shown, the network architecture may include servers and terminal devices. The number of servers and terminal devices included in the network architecture can be one or more. Figure 2The terminal devices 10a, 10b, and 10c shown are merely examples, and this application does not limit the number of servers and terminal devices. Terminal devices 10a and 10b can be smartphones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, etc.), smart speakers, in-vehicle terminals, smart TVs, etc.; server 10c can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms, but is not limited to these.

[0036] After the application software is released, such as Figure 2 The terminal devices 10a, 10b, and server 10c shown can obtain the distribution file of the application software (such as the protected binary code mentioned above). If terminal device 10a is a device used by an ordinary user, it can use the application software through the distribution file, such as accessing the client corresponding to the application software and using the services in the application software. If terminal device 10b is a device used by an attacker (which can also be considered an attacker), the attacker can perform fuzz testing on the distribution file after obtaining it through terminal device 10b, attempting to find vulnerabilities in the application software and attack them. However, the distribution file (protected binary code) can prevent terminal device 10b from performing fuzz testing on the application software, reducing the vulnerability detection capability in the fuzz testing.

[0037] The following description uses terminal device 10b as an example, representing the device used by the attacker. Please refer to [link / reference]. Figure 3 , Figure 3 This is a schematic diagram of an attack flow provided in an embodiment of this application. When terminal device 10b acts as an attacker, or a device used by an attacker, it attempts to find exploitable vulnerabilities in the application software and uses these vulnerabilities to attack the application software. Figure 3As shown, for terminal device 10b to launch an attack on application software, the following three conditions must be met: ① The application software contains vulnerabilities; ② Terminal device 10b has permission to access the vulnerable application software; ③ The vulnerabilities can be exploited by terminal device 10b. In other words, the goal of terminal device 10b is to: perform fuzz testing on the application software's distribution files to identify vulnerabilities in the application software; during the process of accessing the application software, select exploitable vulnerabilities from the identified vulnerabilities; and use these vulnerabilities to control the application software's internal programs and damage the application software.

[0038] In this embodiment, the binary file of the application software is hardened and protected before its release. That is, the release file obtained by terminal device 10b is protected binary code. Even if testers fail to detect all vulnerabilities before the application software is released (i.e., vulnerabilities may still exist in the released application software), when terminal device 10b performs fuzz testing on the protected binary code, it may not detect the vulnerabilities present in the application software, or may only detect a very small number of vulnerabilities, due to the self-protection mechanism within the binary code. Therefore, terminal device 10b may be unable to exploit the vulnerabilities to attack the application software. In other words, by hardening and protecting the release file of the application software, the attacker's vulnerability detection capability can be reduced, thereby improving the security of the application software.

[0039] Please see Figure 4 , Figure 4 This is a flowchart illustrating a data security hardening method provided in an embodiment of this application. It is understood that this data security hardening method can be applied after the testing phase of application software and before the release phase. The hardened binary file obtained through this data security hardening method can be distributed to terminal devices or servers used to run the application software; for example... Figure 4 As shown, this data security hardening method may include the following steps: Step S101: Obtain the conversion hit frequency between basic function code blocks in the target program, and determine the error handling path in the basic function code blocks of the target program based on the conversion hit frequency.

[0040] Specifically, before the target data is released, the computer device can obtain the target program corresponding to the target data. Here, the target program can refer to the source code corresponding to the target data. The target data can be a website, a mini-program, an application software, etc. This application does not limit the type of target data; for ease of description, the following description will use application software as an example. It is understood that the target program involved in the embodiments of this application can refer to the source code after fixing vulnerabilities detected by testers. The target program can consist of a series of basic function code (basic blocks), where a basic function code block refers to a sequence of statements executed sequentially by the target program. The aforementioned computer device can refer to a device used for data hardening of the target program, which can be a terminal device or a server; this application does not limit this.

[0041] When executing a target program, all or part of its basic functional code blocks can be executed. For example, different test data can execute different basic functional code blocks, meaning different test data can correspond to different execution trajectories. Here, different test data can correspond to different services or functions of the application software. The computer device can obtain the conversion hit frequency between basic functional code blocks contained in the target program by analyzing the basic functional code blocks executed with different test data. Since the target program may not contain actual error handling code, the conversion hit frequency in this application can refer to the frequency at which any two basic functional code blocks are executed sequentially (i.e., the frequency of basic functional code block call relationships), or it can be understood as the access frequency of edges in the control flow graph corresponding to the target program, rather than the access frequency of basic functional code blocks. Here, edges can be used to connect two basic functional code blocks in the target program, and the word "conversion" in conversion hit frequency can be understood as "edge". For example, the execution path of test data 1 in the target program is: basic function code block 1 -> basic function code block 2 -> basic function code block 3, and the execution path of test data 2 in the target program is: basic function code block 1 -> basic function code block 2 -> basic function code block 4 -> basic function code block 5. It can be determined that the transition hit frequency between basic function code block 1 and basic function code block 2 is 2, the transition hit frequency between basic function code block 2 and basic function code block 3 is 1, the transition hit frequency between basic function code block 2 and basic function code block 4 is 1, and the transition hit frequency between basic function code block 4 and basic function code block 5 is 1. Optionally, the above transition hit frequency can also refer to the proportion of the number of hits of each edge in the control flow graph corresponding to the target program to the total number of hits of all edges. This application does not limit the method of obtaining the transition hit frequency between basic function code blocks.

[0042] Furthermore, the computer device can analyze the basic functional code blocks in the target program based on the frequency of hits between these blocks, and determine error handling paths from these blocks. These error handling paths can refer to the paths executed by invalid test data in the target program, such as paths formed by basic functional code blocks that are rarely hit under normal execution but frequently used in fuzz testing. In other words, error handling paths are those where basic functional code blocks are rarely executed under normal execution, meaning paths where valid test data will not be executed.

[0043] In one or more embodiments, the computer device can generate a configuration file for determining error handling paths using a configuration file generator. This configuration file can be a file containing one or more error handling paths in the target program. The computer device can obtain a valid test set, execute the target program based on the valid test data contained in the valid test set, and obtain a target execution edge set. Each executed edge in the target execution edge set is used to connect two basic functional code blocks in the target program; that is, each executed edge in the target execution edge set can be used to represent the calling relationship between two basic functional code blocks under valid test data. Simultaneously, the computer device can also obtain a random test set, execute the target program based on the random test data contained in the random test set, and obtain a random execution edge set. Each executed edge in the random execution edge set is used to connect two basic functional code blocks in the target program; that is, each executed edge in the random execution edge set can be used to represent the calling relationship between two basic functional code blocks under random test data. The set of valid test cases can contain one or more valid test data sets, while the set of random test cases can contain one or more random test data sets, which can be valid or invalid. The target execution edge set contains the edges between the basic functional code blocks executed in the target program for each valid test data set in the valid test case set. The execution paths of different valid test data sets in the target program may contain the same executed edges; therefore, the target execution edge set can contain the same executed edge once or multiple times. Similarly, the set of random execution edges can also contain one or more executed edges. Of course, the target execution edge set and the set of random execution edges can contain the same executed edges; that is, there may be some duplicate executed edges in the target execution edge set and the set of random execution edges.

[0044] The computer device can count the first occurrence count of each executed edge in the target execution edge set, which is the frequency of each executed edge in the target execution edge set, and obtain the second occurrence count of each executed edge in the random execution edge set, which is the frequency of each executed edge in the random execution edge set. Based on the first and second occurrence counts, the conversion hit frequency between basic functional code blocks in the target program is determined. Furthermore, based on the conversion hit frequency, the error handling path of the target program can be determined from the random execution edge set. Further, for any executed edge in the random execution edge set (e.g., executed edge i), executed edge i can be used to connect basic functional code block a and basic functional code block b in the target program, that is, to represent the calling relationship between basic functional code block a and basic functional code block b. i is a positive integer less than or equal to the number of executed edges in the random execution edge set, and a and b are both positive integers less than or equal to the number of basic functional code blocks in the target program. If the conversion hit frequency between basic functional code block a and basic functional code block b is less than a frequency threshold (this frequency threshold can be set according to actual needs), the error handling path of the target program can be determined. (The application does not specify this), and if the executed edge i does not belong to the target execution edge set, then the executed edge i can be identified as an error handling edge; by combining the error handling edges in the random execution edge set, D error edge sets can be obtained. Based on the basic function code block associated with the error handling edge in each error edge set, the error handling path of the target program is determined, where D is a positive integer, such as D can take the value 1, 2, ...; since the executed edges in the target execution edge set are all edges executed by valid test data, the executed edges in the target execution edge set cannot be error handling edges, and the error handling edges all belong to the random execution edge set.

[0045] Optionally, the computer device can input valid test data from the valid test set and random test data from the random test set into a configuration file generator. In this generator, the valid test data from the valid test set is used to execute the initial binary code corresponding to the target program (i.e., the unprotected binary code that can be tested by internal testers after compilation of the target program, also known as the initial binary file), and the set of executed edges is collected, i.e., the target execution edge set. Similarly, the configuration file generator uses random test data from the random test set to execute the initial binary code corresponding to the target program and collects the set of executed edges, i.e., the random execution edge set. After statistically obtaining the conversion hit frequency, error handling edges can be determined from the random execution edge set. Combining all error handling edges yields D error edge sets, where the error handling edges in each set can constitute one or more error handling paths.

[0046] Suppose we denote the effective test set as V, the random test set as R, the target execution edge set as E(V), the random execution edge set as E(R), and the error edge set as EHE. Then the error edge set EHE can be represented as the executed edges corresponding to at least n% of the random test data, as shown in the following formula (1): (1) Where e represents the error handling edge in the error edge set, P(E(R)) represents the power set of the randomly executed edge set E(R), and E(i) represents the executed edge set from i, where the test data comes from i. The value of i can be used to control the number of available key positions. The higher the value of n, the fewer the number of executed edges included in the error edge set EHE. n can be a positive integer, and i can be an integer. A configuration file containing the above error edge set EHE can be generated by the configuration file generator. The configuration file can also specify the number of available key positions in each error edge set EHE. These key positions can be used to inject subsequent obstacle code. It should be noted that the above formula (1) is only one way to obtain the error edge set. This application can also use other methods to determine the error edge set, such as random combination.

[0047] Step S102: Obtain variable configuration information for configuring program jump parameters, and generate obstacle code containing a cooperative jump table based on the variable configuration information; the cooperative jump table in the obstacle code is used to prevent fuzz testing against the target program.

[0048] Specifically, the computer device can acquire variable configuration information for configuring program jump parameters. These program jump parameters can be one or more, such as jump restriction parameters (also known as statement jump restrictions), length restriction parameters (also known as input length restrictions), and jump table size parameters (also known as the size of the jump table). The variable configuration information can include the configuration information for each of these program jump parameters. Based on the variable configuration information, a barrier code containing a cooperative jump table is generated. The core logic of this barrier code can refer to a set of cooperative jump tables, which can be used to hinder fuzz testing of the target program (application software). Optionally, the computer device can input the above variable configuration information into a fuzz testing barrier generator, which can generate barrier code based on the variable configuration information. The variable configuration information can be user-configured information.

[0049] Optionally, when the program jump parameters include jump restriction parameters, length restriction parameters, and jump table size parameters, the variable configuration information may include jump configuration information for the jump restriction parameters, length configuration information for the length restriction parameters, and size configuration information for the jump table size parameters. The computer device may declare K cooperative jump tables based on the jump configuration information, length configuration information, and size configuration information in the variable configuration information; K is a positive integer; a label for marking the jump position is inserted in each of the K cooperative jump tables to generate a barrier code containing the K cooperative jump tables.

[0050] This system allows for the configuration of two different types of collaborative jump tables. The first type of jump table can contain more labels; the second type of jump table can have multiple entries of the same size, but smaller than the first type. For example, when the size configuration information includes first and second sub-configuration information, and the jump table size determined by the first sub-configuration information is larger than the jump table size determined by the second sub-configuration information, the computer device can declare a first type of jump table based on the jump configuration information, length configuration information, and first sub-configuration information in the variable configuration information. This first type of jump table is used to indicate the retention of test cases in fuzzing to execute error handling paths. It can also be understood as the first type of jump table misleading the fuzzer to retain more test cases to execute error handling paths. Here, the fuzzer can refer to a tool used for fuzzing. Based on the jump configuration information, length configuration information, and second sub-configuration information in the variable configuration information, a second type of jump table is declared, and the first and second types of jump tables are determined as K collaborative jump tables. This second type of jump table is used to attenuate the test cases in the fuzzing test. After declaring the collaborative jump table, tags can be added to the jump table to mark the jump positions. When jumping between marked positions, the jump limit parameter (statement jump limit) controls when to exit, limiting the number of jumps before exiting the jump table logic. If the jump limit is reached, the program will exit the collaborative jump table. The next position to jump to is randomly selected from the collaborative tag table. Furthermore, the program will only continue executing the next collaborative jump table if the length exceeds the length configuration information corresponding to the length limit parameter; this mechanism can cover more collaborative jump tables.

[0051] Step S103: Insert barrier code into the error handling path of the target program to generate a hardened binary file for release.

[0052] Specifically, computer devices can insert obstruction code into the error handling path of a target program, generating self-protective binary code, i.e., a hardened binary file. This hardened binary file can ensure the target program executes normally while hindering the vulnerability detection capabilities of fuzzing.

[0053] The computer device can identify the critical location corresponding to the obstacle code in the error handling path of the target program, and insert the obstacle code into the critical location through the compiler. The critical location can be determined by the available location in the configuration file generated by the configuration file generator. The target program with the inserted obstacle code is compiled in the compiler to generate a hardened binary file for release.

[0054] Furthermore, the computer device can publish the hardened binary file to the software management platform, so that the first device in the software management platform can obtain the hardened binary file, load the hardened binary file, and access the application software corresponding to the hardened binary file. Here, the first device can refer to the terminal device used by an ordinary user. Ordinary users can use the application software corresponding to the hardened binary file normally through the first device.

[0055] Please see Figure 5 , Figure 5 This is a schematic diagram illustrating a process for generating a hardened binary file, provided in an embodiment of this application. For example... Figure 5 As shown, a computer device can provide a configuration file generator with a set of valid inputs (i.e., a valid test set) and a set of random inputs (i.e., a random test set). Using the valid inputs, the initial binary code of the target program is executed, and a target execution edge set is collected. Using the random inputs, the initial binary program is executed, and a random execution edge set is collected. The target execution edge set and the random execution edge set can be used to statistically analyze the transition hit frequency between various basic functional code blocks. Based on the transition hit frequency, the error handling path can be determined, and a configuration file containing the error handling path can be generated. This configuration file can be input into a custom compiler. The fuzzing obstacle generator can generate obstacle code based on variable configuration information used to configure program jump parameters. The custom compiler can break the error handling edges of the error handling path and, based on the configuration file generated by the configuration file generator, insert obstacle code that hinders gray-box fuzzing into the error handling path of the source code (i.e., the target program), generating a hardened binary file.

[0056] In this embodiment, after determining the error handling path from the target program, a hardened binary file is obtained by inserting obstacle code into the error handling path. Inserting obstacle code into the error handling path does not affect the normal execution efficiency of the target program. That is, the data corresponding to the hardened binary file can reduce the vulnerability detection capability in fuzzing while executing normally, thereby improving data security. The hardened binary file has robust anti-fuzzing characteristics, which means that the target program can obtain similar results when facing gray-box fuzzing with different implementation methods, further reducing the vulnerability detection capability in fuzzing. The hardened binary file will neither interrupt normal functions nor significantly reduce the execution efficiency of the original program.

[0057] Please see Figure 6 , Figure 6 This is a flowchart illustrating a data security hardening method provided in an embodiment of this application. It is understood that this data security hardening method can be executed by a computer device, which can be a server or a terminal device; such as... Figure 6 As shown, this data security hardening method may include the following steps: Step S201: When it is detected that the second device is performing fuzz testing on the hardened binary file, the target test set provided by the second device in the fuzz testing is obtained.

[0058] Specifically, when the second device wants to attack the application software, it can use test cases from the target test set to perform fuzz testing on the hardened binary file. At this time, the computer device can obtain the target test set provided by the second device in the fuzz testing. The target test set can include the test cases used by the second device when performing fuzz testing on the hardened binary file.

[0059] In this application, if the second device wants to attack the application software, it can obtain the hardened binary file released from the software management platform. Since this hardened binary file refers to binary code generated after inserting obstruction code into the source code, the second device cannot access the application's source code and can only perform fuzzing on the hardened binary file. This fuzzing can be either gray-box or black-box fuzzing. When performing fuzzing on the hardened binary file, the second device can determine the fuzzing input data (also called input vectors). This input data can be file data, network data, environment variables, etc. This application does not limit the type of input data. Based on the input data, test cases for performing fuzzing can be generated. For example, by designing fuzzing methods and test data generation algorithms, test cases corresponding to the input data can be generated. The number of test cases used in the fuzzing process can be multiple, and these multiple test cases can constitute a target test set. This application does not limit the fuzzing methods or test data generation algorithms.

[0060] After obtaining the target test set, the second device can launch a target process for performing fuzz testing, send the target test set to the test device, and open the hardened binary file in the test device; wherein, the test device can refer to any device with the hardened binary file, and this application does not specifically limit the type of test device. For ease of description, the following description uses the aforementioned computer device as the test device. After the second device sends the target test set to the computer device, the computer device can receive the target test set sent by the second device.

[0061] Step S202: By hardening the barrier code in the binary file, retain the target test cases associated with the error handling path from the target test set; the target test cases are used to hinder the vulnerability detection function in fuzzing.

[0062] Specifically, because the hardened binary contains barrier code, computer devices can use this barrier code to retain target test cases associated with error handling paths from the target test set. These target test cases can then be used to fuzz test the hardened binary. See also... Figure 7 , Figure 7 This is a schematic diagram of the component structure for grayscale fuzzy testing provided in an embodiment of this application. The following description uses gray-box fuzzy testing as an example. Figure 7As shown, gray-box fuzzing can include a seed (also called a test case) evaluator, a seed mutant, and a feedback collector. The seed evaluator is a component used to maintain a seed queue, which can refer to a queue used to store test cases in the target test set. Typically, the seed evaluator is responsible for selecting the next seed to mutate and proposing how much computational power to spend on that seed (also called computational power scheduling). The seed evaluator can help maximize output by providing an optimal solution for seed selection and computational power scheduling. Because the hardened binary file in this application contains barrier code, which tampers with the seed evaluator, it can induce the seed evaluator to incorrectly evaluate the quality of the seeds, or even discard some high-quality seeds.

[0063] Seed mutants are the foundation of all fuzzing techniques, effectively generating high-quality new test cases. Hardening binaries contain obstruction code that tampers with the seed mutant, preventing it from generating new test inputs—i.e., new test cases—that differ from the seed content and coverage.

[0064] A feedback collector is a component that gathers feedback from hardened binary tests during execution. Feedback collectors can be used to provide accurate and concise feedback, while feedback collectors modified by the barrier code can collect reported errors and compelling feedback results.

[0065] like Figure 7 As shown, the role of the hardened binary file in this application (i.e., the role of the barrier code) can include: seed queue explosion, seed decay, and feedback pollution. Seed queue explosion can refer to obfuscating the seed evaluator in gray-box fuzzing through barrier code; seed decay can refer to distorting the seed mutant through barrier code to generate larger seeds, reducing the overall efficiency of fuzzing; additionally, barrier code can pollute feedback information by generating saturated records and nondeterministic execution behavior.

[0066] The following describes the seed queue explosion: The collaborative jump table in the obstacle code can include a first-type jump table. When the execution path of test case x in the target test set is an error handling path in the hardened binary file, the computational power scheduling of test case x is determined through the first-type jump table in the obstacle code. Here, x can be a positive integer, such as x can take the value 1, 2, ..., and test case x can be any test case in the target test set. The computational power scheduling of test case x is evaluated by the fuzzing test case evaluator (i.e., the seed evaluator mentioned above), and the quality evaluation value of test case x is obtained. When the quality evaluation value of test case x meets the evaluation threshold condition, test case x is determined as the target test case. Understandably, the purpose of the test case evaluator is to generate high-quality test cases. However, because the hardened binary file contains obstruction code, the test case evaluator cannot accurately evaluate test case x. That is, after obtaining the quality evaluation value of test case x through the evaluator, this value may meet the evaluation threshold condition, such as being greater than the threshold (this threshold can be set according to actual needs, and this application does not limit it). However, test case x may inherently be a low-quality test case. In other words, if the hardened binary file does not contain obstruction code, such as a first-type jump table, the quality evaluation value obtained by the test case evaluator may not meet the evaluation threshold condition. However, due to the insertion of obstruction code, the evaluation result of the test case evaluator is misled, causing the quality evaluation value of test case x to meet the evaluation threshold condition, thus identifying the test case as a high-quality target test case. Based on the above principle, the test case evaluator can retain a large number of low-quality target test cases. These target test cases can be used to execute the error handling paths in the hardened binary file, causing fuzzing to waste a lot of computing power on low-quality target test cases, thereby reducing the efficiency of fuzzing.

[0067] In this embodiment, a large number of target test cases can be retained through misleading fuzzing to execute error handling paths, thereby causing an explosion in the number of seed queues. Since the hardened binary can jump from one labeled location to another based on a collaborative jump table, a collaborative jump table containing n labels can provide n basic functional code blocks and n... 2 The transformation of a basic functional code block (which can be understood as an edge) is considered. Therefore, the cooperative jump table (barrier code) injected into the hardened binary can provide considerable program coverage feedback to deceive fuzz tests by retaining a large amount of data as target test cases for executing the barrier code. Furthermore, since the barrier code is injected into the error handling path, test cases for new fake paths are retained. Meanwhile, in the first type of jump table of the barrier code, even more target test cases can be retained to practice the error handling path.

[0068] Optionally, the seed decay technique is described below: The collaborative jump table in the barrier code may include a second type of jump table; when the execution path of test case y in the target test set is an error handling path in the hardened binary file, according to the second type of jump table in the barrier code, test case y is mutated in the fuzzing test case mutant (i.e., the aforementioned seed mutant) to generate candidate test cases; where y can be a positive integer, such as y can take the value 1, 2, ..., and test case y can be any test case in the target test set; when the data length of the candidate test case is greater than the data length of test case y, the candidate test case is determined as the target test case. Fuzzing essentially favors concise test cases because test cases with smaller mutations are more likely to hit valuable bytes and cover new paths in the hardened binary file. For example, if an XML (Extensible Markup Language) file is modified to test an XML parser, changing the markup is more important than changing the data, and changing a smaller XML file is more likely to hit the markup in the hardened binary file. Therefore, some fuzz tests attempt to prune the seed by deleting certain bytes that do not affect program coverage. However, in this embodiment, by hardening the barrier code inserted into the binary file, the fuzz test can be guided to retain increasingly larger data as target test cases, thus reducing the influence of valuable bytes. In other words, guided by the barrier code, the test case mutant can retain target test cases with larger data lengths, where data length can refer to the byte length of the test case.

[0069] It should be noted that the second type of jump table in the obstacle code provides more feedback as the data length of the test cases increases. Optionally, additional tools can be used to detect the input reading position of the target program and retain a copy of the obstacle code input length. The fuzzing can then be guided by the length limit parameter (i.e., the input length limit variable) in the second type of jump table, gradually retaining target test cases with increasingly longer data lengths. This allows the fuzzing to ultimately retain more target test cases with larger data lengths and lower mutation efficiency.

[0070] Optionally, feedback pollution is described below: In fuzzing, a hardened binary is executed based on test cases in the target test set. Through the random logic contained in the obstacle code within the hardened binary, one or more execution paths corresponding to the test cases in the target test set are generated. Execution feedback information corresponding to one or more execution paths is obtained, and this feedback information is accumulated to obtain the total amount of feedback information. When the total amount of feedback information in memory is greater than or equal to the storage space, a storage saturation record is generated. This record can be used to instruct fuzzing to stop collecting execution feedback information. A key characteristic of fuzzing is the collection of runtime feedback to identify valuable input data and use it as test cases for further mutations. However, feedback information in fuzzing cannot be stored indefinitely; the storage area used to store feedback information may reach saturation, thus limiting the scalability of fuzzing. Furthermore, because the hardened binary uses multithreading or random logic, some test cases may generate different execution paths in different runs. When fuzzing attempts to store the feedback collected in the execution paths of these test cases, it may lead to confusion in the feedback information.

[0071] For example, taking AFL (American Fuzzy Lop, a coverage-guided fuzzing tool) as an example, it can perform more calibration runs on test cases with different behaviors. Otherwise, the feedback information of these test cases would pollute the existing feedback records saved by the fuzzing. In other words, more computing power will be used to calibrate these test cases, while relatively less computing power can be used for mutations, etc. The embodiments of this application can pollute the fuzzing feedback records by saturating the feedback records (i.e., the aforementioned saturated storage records) and introducing test cases with variable behavior, which can also be called polluting the feedback information collected in the feedback collector.

[0072] It should be noted that the cooperative jump table in the hardened binary file in this embodiment can provide a large amount of false feedback information for fuzzing and can quickly saturate the feedback records, i.e., generate storage saturation records. Furthermore, when executing the obstacle code in the hardened binary file, the next jump position is randomly selected from the cooperative jump table. Therefore, test cases that trigger the cooperative jump table will naturally exhibit different behaviors during execution. To further mask the target test cases by executing test cases that follow the normal path, random logic unrelated to the target program can be added at the location where the test cases are read. This random logic can be used to indicate that all test cases hold different execution trajectories in different runs, thereby causing the target test cases executing the obstacle code to behave very unstablely. This results in fuzzing mistakenly and effectively utilizing the feedback information, reducing the vulnerability detection capability of fuzzing.

[0073] Optionally, to verify the ability of the hardened binary file to resist fuzzing, experiments were conducted on different devices in this application embodiment. This experiment is merely one example, and the actual application of the hardened binary file is not limited to this experiment. In the experiment, two devices can be used, both capable of running at over 2400 CPU (Central Processing Unit) clock speeds. Each machine is configured with an Intel(R) Core(TM) i9-7940X CPU @ 3.10GHz (CPU performance parameters), 28 logical processor cores, and 128GB RAM (random access memory). The hardened binary file can be repeatedly tested in the fuzzing experiment (e.g., repeated 10 times, the number of times can be set according to actual needs) to reduce the randomness of the fuzzing test.

[0074] In this experiment, the parameter n in formula (1) can be configured to be 95, and the jump limit parameter to be 10; the input length limit (i.e., the length limit parameter) starts from 100, increases by 5 at each step, and ends at 8000. The memory space of the hardened binary file in this experiment is greater than the memory space of the initial binary code. The hardened binary file can be evaluated on three different fuzzers. The three different fuzzers can include AFL-QEMU (a black-box fuzzer), AFL-Blackbox (AFL-BB, a gray-box fuzzer), and FairFuzz-QEMU (a gray-box fuzzer). It is assumed that the protected program in the hardened binary file can be exiv2 (an application extension file in the operating system), mjs (a file that can be used for embedded engines), mp4aac (an online audio file converter), nm (a file associated with application software), objdump (a command program for executable files), etc. This experiment uses the number of crashes and the control flow graph edge coverage as measures of the effectiveness of the hardened binary file.

[0075] This experiment demonstrates that, compared to the initial binary code, fuzzing with AFL-QEMU reduces the number of crashes detected by AFL-QEMU by an average of 87%; fuzzing with FairFuzz-QEMU reduces the number of crashes detected by FairFuzz-QEMU by an average of 74%. Furthermore, on exvi2, mjs, and mp42aac, fuzzing makes AFL-QEMU perform worse than black-box fuzzing in crash detection. In terms of coverage, by adding obstacle codes to the fuzzed binary, the fuzzer not only introduces a large number of test cases for fake paths but also generates fewer test cases for real paths. AFL-QEMU coverage decreased by an average of 23%, even worse than black-box fuzzing. Based on all experimental results, fuzzing the binary is an effective way to combat fuzzing techniques and offers higher security performance.

[0076] Optionally, delayers can be set in some rare code paths (such as file format error checking paths) contained in the source code to slow down the execution speed of the code, thereby reducing the execution efficiency of fuzz testing.

[0077] Optionally, errors can be encapsulated in the source code, changing the type of error so that the attacker's (e.g., the second device mentioned above) fuzzer might mistakenly send an accurate judgment of the current feedback information, thereby interfering with the efficiency of the entire fuzzing process.

[0078] In this embodiment, after determining the error handling path from the target program, a hardened binary file is obtained by inserting obstacle code into the error handling path. The obstacle code inserted into the error handling path does not affect the normal execution efficiency of the target program. That is, the data corresponding to the hardened binary file can reduce the vulnerability detection capability in fuzzing while executing normally, thereby improving data security. The obstacle code in the hardened binary code can involve obstacle code from aspects such as seed queue explosion, seed decay, and feedback pollution, and thus resist the attacker's fuzzing. The hardened binary file containing obstacle code has robust anti-fuzzing characteristics, so that the hardened binary file can obtain similar results in gray-box fuzzing with different implementation methods, further reducing the vulnerability detection capability in fuzzing. The hardened binary file will neither interrupt normal function nor significantly reduce the execution efficiency of the original program.

[0079] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a data security hardening device provided in an embodiment of this application. Figure 8As shown, the data security hardening device 1 may include: a path determination module 11, a code generation module 12, and a code insertion module 13; The path determination module 11 is used to obtain the conversion hit frequency between basic functional code blocks in the target program, and determine the error handling path in the basic functional code blocks of the target program based on the conversion hit frequency. The code generation module 12 is used to obtain variable configuration information for configuring program jump parameters, and generate obstacle code containing a cooperative jump table based on the variable configuration information; the cooperative jump table in the obstacle code is used to prevent fuzz testing against the target program. Code insertion module 13 is used to insert obstruction code into the error handling path of the target program to generate a hardened binary file for release.

[0080] The specific implementation methods of the path determination module 11, code generation module 12, and code insertion module 13 can be found in [reference needed]. Figure 4 Steps S101-S103 in the corresponding embodiments will not be described again here.

[0081] In one or more embodiments, the path determination module 11 may include: an effective data execution unit 111, a random data execution unit 112, a hit frequency determination unit 113, and an error handling path determination unit 114. The effective data execution unit 111 is used to obtain a valid test set, execute the target program according to the valid test data contained in the valid test set, and obtain a target execution edge set; each executed edge in the target execution edge set is used to connect two basic functional code blocks in the target program. The random data execution unit 112 is used to obtain a random test set, execute the target program according to the random test data contained in the random test set, and obtain a random execution edge set; each executed edge in the random execution edge set is used to connect two basic functional code blocks in the target program. The hit frequency determination unit 113 is used to count the first occurrence count corresponding to each executed edge in the target execution edge set and the second occurrence count corresponding to each executed edge in the random execution edge set, and to determine the hit frequency of the conversion between basic functional code blocks in the target program based on the first occurrence count and the second occurrence count. Error handling path determination unit 114 is used to determine the error handling path of the target program from the set of randomly executed edges based on the conversion hit frequency.

[0082] The specific functional implementation methods of the effective data execution unit 111, the random data execution unit 112, the hit frequency determination unit 113, and the error handling path determination unit 114 can be found in [reference needed]. Figure 4Step S101 in the corresponding embodiment will not be described again here.

[0083] In one or more embodiments, the error handling path determination unit 114 may include: an executed edge acquisition subunit 1141, an error handling edge determination subunit 1142, and an error handling edge combination subunit 1143; The executed edge acquisition subunit 1141 is used to acquire the executed edge i from the random execution edge set; the executed edge i is used to connect the basic function code block a and the basic function code block b in the target program, i is a positive integer less than or equal to the number of executed edges in the random execution edge set, and a and b are both positive integers less than or equal to the number of basic function code blocks in the target program; Error handling edge determination subunit 1142 is used to determine the executed edge i as an error handling edge if the hit frequency of the transition between basic function code block a and basic function code block b is less than the frequency threshold and the executed edge i does not belong to the target execution edge set. Error handling edge combination subunit 1143 is used to combine error handling edges in the random execution edge set to obtain D error edge sets. Based on the basic function code block associated with the error handling edge in each error edge set, the error handling path of the target program is determined; D is a positive integer.

[0084] The specific implementation of the functions of obtaining subunit 1141 while handling errors, determining subunit 1142 while handling errors, and combining subunit 1143 can be found in [reference needed]. Figure 4 Step S101 in the corresponding embodiment will not be described again here.

[0085] In one or more embodiments, the program jump parameters include jump restriction parameters, length restriction parameters, and jump table size parameters, and the variable configuration information includes jump configuration information for jump restriction parameters, length configuration information for length restriction parameters, and size configuration information for jump table size parameters; The code generation module 12 may include: a jump table declaration unit 121 and a tag insertion unit 122; Jump table declaration unit 121 is used to declare K cooperative jump tables based on the jump configuration information, length configuration information and size configuration information in the variable configuration information; K is a positive integer. The label insertion unit 122 is used to insert a label for marking the jump position in each of the K collaborative jump tables to generate a barrier code containing the K collaborative jump tables.

[0086] Optionally, the size configuration information includes first sub-configuration information and second sub-configuration information, wherein the jump table size determined by the first sub-configuration information is larger than the jump table size determined by the second sub-configuration information; Jump table declaration unit 121 is specifically used for: Based on the jump configuration information, length configuration information, and first sub-configuration information in the variable configuration information, declare a first type jump table; the first type jump table is used to indicate the error handling path to be executed by retaining test cases in fuzz testing; Based on the jump configuration information, length configuration information, and second sub-configuration information in the variable configuration information, declare a second type of jump table, and determine the first type of jump table and the second type of jump table as K cooperative jump tables; the second type of jump table is used for test cases of decay fuzz testing.

[0087] The specific implementation methods of the jump table declaration unit 121 and the label insertion unit 122 can be found in [reference needed]. Figure 4 Step S102 in the corresponding embodiment will not be described again here.

[0088] In one or more embodiments, the code insertion module 13 may include: a key location determination unit 131 and a compilation processing unit 132; The critical location determination unit 131 is used to determine the critical location corresponding to the obstacle code in the error handling path of the target program, and insert the obstacle code into the critical location by the compiler; The compilation processing unit 132 is used to compile the target program into which the obstruction code is inserted in the compiler to generate a hardened binary file for distribution.

[0089] The specific functional implementation methods of the key location determination unit 131 and the compilation processing unit 132 can be found in [reference needed]. Figure 4 Step S103 in the corresponding embodiment will not be described again here.

[0090] In one or more embodiments, the data security hardening device 1 may further include: a file publishing module 14; The file publishing module 14 is used to publish the hardened binary file to the software management platform, so that the first device in the software management platform can obtain the hardened binary file, load the hardened binary file, and access the application software corresponding to the hardened binary file.

[0091] The specific implementation of the file publishing module 14 can be found in [link to documentation]. Figure 4 Step S103 in the corresponding embodiment will not be described again here.

[0092] In one or more embodiments, the data security hardening device 1 may include: a target test set acquisition module 15 and a test case retention module 16; The target test set acquisition module 15 is used to acquire the target test set provided by the second device in the fuzz test when it is detected that the second device is performing fuzz testing on the hardened binary file; Test case retention module 16 is used to retain target test cases associated with error handling paths from the target test set by hardening the obstacle code in the binary file; the target test cases are used to hinder the vulnerability finding capability in fuzzing.

[0093] The specific implementation methods of the target test set acquisition module 15 and the test case retention module 16 can be found in [link to relevant documentation]. Figure 6 Steps S201-S202 in the corresponding embodiments will not be described again here.

[0094] In one or more embodiments, the collaborative jump table in the barrier code includes a first type of jump table; Test case retention module 16 may include: scheduling acquisition unit 161, quality assessment unit 162, and quality judgment unit 163; The scheduling acquisition unit 161 is used to acquire the computational power scheduling of test case x through the first type jump table in the obstacle code when the execution path of test case x in the target test set is an error handling path in the hardened binary file; x is a positive integer; The quality assessment unit 162 is used to assess the quality of the computational power scheduling of test case x through the test case evaluator of fuzz testing, and obtain the quality assessment value of test case x. The quality judgment unit 163 is used to determine test case x as the target test case when the quality evaluation value of test case x meets the evaluation threshold condition.

[0095] Optionally, the collaborative jump table in the barrier code may include a second type of jump table; The test case retention module 16 may also include: a mutation processing unit 164 and a data length judgment unit 165; The mutation processing unit 164 is used to mutate test case y in the test case mutator of fuzzing test according to the second type jump table in the obstacle code when the execution path of test case y in the target test set is an error handling path in the hardened binary file, so as to generate candidate test cases; y is a positive integer. The data length judgment unit 165 is used to determine the candidate test case as the target test case when the data length of the candidate test case is greater than the data length of the test case y.

[0096] The specific functional implementation methods of the scheduling acquisition unit 161, quality assessment unit 162, quality judgment unit 163, mutation handling unit 164, and data length judgment unit 165 can be found in [reference needed]. Figure 6 Step S202 in the corresponding embodiment will not be described again here.

[0097] In one or more embodiments, the data security hardening device 1 may further include: an execution trajectory generation module 17, a feedback information accumulation module 18, and a saturation record generation module 19; The execution trajectory generation module 17 is used to generate one or more execution trajectories corresponding to the test cases in the target test set by executing the hardened binary file according to the test cases in the target test set during fuzzing, and by generating one or more execution trajectories corresponding to the test cases in the target test set through the random logic contained in the obstacle code in the hardened binary file. The feedback information accumulation module 18 is used to obtain the execution feedback information corresponding to one or more execution trajectories, and to accumulate the execution feedback information corresponding to the test cases in the target test set to obtain the total amount of feedback information. The saturation record generation module 19 is used to generate a storage saturation record when the total amount of feedback information in memory is greater than or equal to the storage space; the storage saturation record is used to indicate that the fuzz test stops collecting execution feedback information.

[0098] The specific implementation methods of the execution trajectory generation module 17, the feedback information accumulation module 18, and the saturation record generation module 19 can be found in [reference needed]. Figure 6 Step S202 in the corresponding embodiment will not be described again here.

[0099] In this embodiment, after determining the error handling path from the target program, a hardened binary file is obtained by inserting obstacle code into the error handling path. The obstacle code inserted into the error handling path does not affect the normal execution efficiency of the target program. That is, the data corresponding to the hardened binary file can reduce the vulnerability detection capability in fuzzing while executing normally, thereby improving data security. The obstacle code in the hardened binary code can involve obstacle code from aspects such as seed queue explosion, seed decay, and feedback pollution, and thus resist the attacker's fuzzing. The hardened binary file containing obstacle code has robust anti-fuzzing characteristics, so that the hardened binary file can obtain similar results in gray-box fuzzing with different implementation methods, further reducing the vulnerability detection capability in fuzzing. The hardened binary file will neither interrupt normal function nor significantly reduce the execution efficiency of the original program.

[0100] Further, please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 9As shown, the computer device 1000 can be a user terminal or a server; this is not a limitation. For ease of understanding, this application takes the computer device as a user terminal as an example. The computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to implement communication between these components. The user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface). The memory 1004 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. The memory 1005 may optionally be at least one storage device located remotely from the aforementioned processor 1001. Figure 9 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0101] The network interface 1004 in the computer device 1000 can also provide network communication functions, and the optional user interface 1003 can also include a display screen and a keyboard. Figure 9 In the computer device 1000 shown, the network interface 1004 provides network communication functionality; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve: Obtain the conversion hit frequency between basic functional code blocks in the target program, and determine the error handling path in the basic functional code blocks of the target program based on the conversion hit frequency; Obtain variable configuration information used to configure program jump parameters, and generate obstacle code containing a cooperative jump table based on the variable configuration information; the cooperative jump table in the obstacle code is used to prevent fuzz testing against the target program; Insert barrier code into the error handling path of the target program to generate a hardened binary for release.

[0102] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 4 and Figure 6 The description of the data security hardening method in any of the corresponding embodiments can also be performed as described above. Figure 8The description of the data security hardening device 1 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0103] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data security hardening device 1. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 4 and Figure 6 The description of the data security hardening method in any corresponding embodiment is already provided and will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments involved in this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed and executed on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network. These multiple computing devices distributed across multiple locations and interconnected via a communication network can constitute a blockchain system.

[0104] Furthermore, it should be noted that this application also provides a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, causing the computer device to perform the aforementioned actions. Figure 4 and Figure 6 The description of the data security hardening method in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program products or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0105] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0106] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0107] The modules in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0108] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0109] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data security hardening method, characterized in that, include: Obtain the conversion hit frequency between basic functional code blocks in the target program, and determine the error handling path in the basic functional code blocks of the target program based on the conversion hit frequency; Obtain variable configuration information for configuring program jump parameters; the program jump parameters include jump restriction parameters, length restriction parameters, and jump table size parameters; the variable configuration information includes jump configuration information for the jump restriction parameters, length configuration information for the length restriction parameters, and first sub-configuration information and second sub-configuration information for the jump table size parameters, wherein the jump table size determined by the first sub-configuration information is greater than the jump table size determined by the second sub-configuration information; Based on the jump configuration information, the length configuration information, and the first sub-configuration information, declare a first type of jump table; The first type of jump table is used to mislead the fuzz tester into retaining more test cases to execute error handling paths; Based on the jump configuration information, the length configuration information, and the second sub-configuration information, a second type of jump table is declared; the second type of jump table is used for test cases of decay fuzz testing; The first type of jump table and the second type of jump table are determined as K cooperative jump tables. A label for marking the jump position is inserted into each cooperative jump table to generate a barrier code containing the K cooperative jump tables. K is a positive integer. The collaborative jump table in the obstacle code is used to prevent fuzz testing against the target program. When jumping between label positions, the jump limit parameter is used to limit the number of jumps before exiting the jump table logic. If the jump limit is reached, the program will exit the collaborative jump table. When the input length is greater than the length configuration information corresponding to the length limit parameter, the next collaborative jump table will be executed. The obstruction code is inserted into the error handling path of the target program to generate a hardened binary file for release.

2. The method according to claim 1, characterized in that, The step of obtaining the transition hit frequency between basic functional code blocks in the target program, and determining the error handling path in the basic functional code blocks of the target program based on the transition hit frequency, includes: Obtain a valid test set, execute the target program based on the valid test data contained in the valid test set, and obtain a target execution edge set; each executed edge in the target execution edge set is used to connect two basic functional code blocks in the target program; Obtain a random test set, execute the target program based on the random test data contained in the random test set, and obtain a random execution edge set; each executed edge in the random execution edge set is used to connect two basic functional code blocks in the target program; The first occurrence count for each executed edge in the target execution edge set and the second occurrence count for each executed edge in the random execution edge set are counted. Based on the first and second occurrence counts, the conversion hit frequency between basic functional code blocks in the target program is determined. Based on the conversion hit frequency, the error handling path of the target program is determined from the set of random execution edges.

3. The method according to claim 2, characterized in that, The step of determining the error handling path of the target program from the set of random execution edges based on the conversion hit frequency includes: Obtain the executed edge i from the set of random execution edges; the executed edge i is used to connect the basic function code block a and the basic function code block b in the target program, i is a positive integer less than or equal to the number of executed edges in the set of random execution edges, and a and b are both positive integers less than or equal to the number of basic function code blocks in the target program; If the conversion hit frequency between the basic function code block a and the basic function code block b is less than the frequency threshold, and the executed edge i does not belong to the target execution edge set, then the executed edge i is determined as an error handling edge. The error handling edges in the random execution edge set are combined to obtain D error edge sets. The error handling path of the target program is determined according to the basic function code block associated with the error handling edge in each error edge set; D is a positive integer.

4. The method according to claim 1, characterized in that, The step of inserting the obstruction code into the error handling path of the target program to generate a hardened binary file for release includes: In the error handling path of the target program, the key position corresponding to the obstacle code is determined, and the obstacle code is inserted into the key position by the compiler; The target program into which the obstruction code is inserted is compiled in the compiler to generate the hardened binary file for release.

5. The method according to claim 1, characterized in that, Also includes: The hardened binary file is published to the software management platform so that the first device in the software management platform can obtain the hardened binary file, load the hardened binary file, and access the application software corresponding to the hardened binary file.

6. The method according to claim 1, characterized in that, Also includes: When it is detected that the second device performs a fuzz test on the hardened binary file, the target test set provided by the second device in the fuzz test is obtained; By using the obstacle code in the hardened binary file, target test cases associated with the error handling path are retained from the target test set; The target test case is used to disable the vulnerability detection function in the fuzz test.

7. The method according to claim 6, characterized in that, The collaborative jump table in the obstacle code includes a first type of jump table; The step of retaining target test cases associated with the error handling path from the target test set through the obstacle code in the hardened binary file includes: When the execution path of test case x in the target test set is the error handling path in the hardened binary file, the computational power scheduling of test case x is determined through the first type of jump table in the obstacle code; x is a positive integer; The quality assessment value of test case x is obtained by using the test case evaluator of the fuzz test to evaluate the computational power scheduling of test case x. When the quality assessment value of test case x meets the assessment threshold condition, test case x is determined as the target test case.

8. The method according to claim 6, characterized in that, The collaborative jump table in the obstacle code includes a second type of jump table; The step of retaining target test cases associated with the error handling path from the target test set through the obstacle code in the hardened binary file includes: When the execution path of test case y in the target test set is the error handling path in the hardened binary file, the test case y is mutated in the test case mutant of the fuzz test according to the second type jump table in the obstacle code to generate candidate test cases; y is a positive integer; When the data length of the candidate test case is greater than the data length of the test case y, the candidate test case is determined as the target test case.

9. The method according to claim 7, characterized in that, Also includes: In the fuzz test, the hardened binary file is executed according to the test cases in the target test set, and one or more execution trajectories corresponding to the test cases in the target test set are generated through the random logic contained in the obstacle code in the hardened binary file. Obtain the execution feedback information corresponding to the one or more execution trajectories respectively, and accumulate the execution feedback information corresponding to the test cases in the target test set to obtain the total amount of feedback information; When the total amount of feedback information in memory is greater than or equal to the storage space, a storage saturation record is generated; the storage saturation record is used to indicate that the fuzz test stops collecting execution feedback information.

10. A data security hardening device, characterized in that, include: The path determination module is used to obtain the conversion hit frequency between basic functional code blocks in the target program, and determine the error handling path in the basic functional code blocks of the target program according to the conversion hit frequency; The code generation module is used to obtain variable configuration information for configuring program jump parameters; the program jump parameters include jump restriction parameters, length restriction parameters, and jump table size parameters; the variable configuration information includes jump configuration information for the jump restriction parameters, length configuration information for the length restriction parameters, and first sub-configuration information and second sub-configuration information for the jump table size parameters, wherein the jump table size determined by the first sub-configuration information is greater than the jump table size determined by the second sub-configuration information; A jump table declaration unit is used to declare a first type of jump table based on the jump configuration information, the length configuration information, and the first sub-configuration information; the first type of jump table is used to mislead the fuzz tester to retain more test cases to execute error handling paths; The jump table declaration unit is further configured to declare a second type of jump table based on the jump configuration information, the length configuration information, and the second sub-configuration information; the second type of jump table is used for test cases of decay fuzz testing; The tag insertion unit is used to determine the first type of jump table and the second type of jump table into K cooperative jump tables, insert a tag for marking the jump position in each cooperative jump table, and generate a barrier code containing the K cooperative jump tables; K is a positive integer. The collaborative jump table in the obstacle code is used to prevent fuzz testing against the target program. When jumping between label positions, the jump limit parameter is used to limit the number of jumps before exiting the jump table logic. If the jump limit is reached, the program will exit the collaborative jump table. When the input length is greater than the length configuration information corresponding to the length limit parameter, the next collaborative jump table will be executed. The code insertion module is used to insert the obstruction code into the error handling path of the target program, generating a hardened binary file for release.

11. A computer device, characterized in that, Including memory and processor; The memory is connected to the processor, the memory is used to store computer programs, and the processor is used to invoke the computer programs so that the computer device performs the method according to any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any one of claims 1-9.

13. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the method described in any one of claims 1-9.

Images