Automatic detection method and system for program vulnerabilities under hardware TEE

Abstract

The present invention proposes a method and system for automated detection of program vulnerabilities under hardware TEE. The method places a target program, a fuzz testing engine, and a corpus in a TEE environment, preprocesses the target program, and obtains a number of initial seeds from the corpus. Through shared memory, the fuzz testing engine parent worker thread creates a number of corresponding execution processes, uses the execution processes to execute the preprocessed target program in parallel, uses the initial seeds as the initial input of the execution processes, and performs parallel fuzz testing in an iterative manner. In each iteration, the mutation strategy of the seed is dynamically adjusted until the termination condition is reached or an interrupt signal is received, so as to complete the automated detection of program vulnerabilities and output a fuzz testing report. The present invention gives full play to the advantages of fuzz detection, realizes a feedback-guided fuzz testing method in a real hardware trusted execution environment, automatically detects and analyzes application security vulnerabilities, and enhances the security and credibility of TEE.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to a method and system for automatically detecting program vulnerabilities under hardware TEE. Background Art

[0002] Intel SGX (Software Guard Extensions) is a hardware-based TEE security technology designed to protect sensitive data and code within applications from malware and operating system attacks. It securely isolates and protects data by creating a protected execution environment (enclave), ensuring that sensitive information is not leaked or tampered with during execution. Due to application porting, vulnerabilities specific to the SGX environment or the application itself may exist within the enclave, seriously compromising the security of the code and data within the enclave. Enclaves are designed to be introspective and lack automatic vulnerability detection capabilities.

[0003] Fuzzing, as an automated software testing technique, automatically or semi-automatically generates random data based on certain rules. This data is then fed into the entry point of a dynamically running target program, while monitoring the target program for anomalies such as system crashes and assertion failures to uncover software defects. Fuzzing is a leading option for vulnerability detection. However, TEEs enforce strict isolation policies, making it difficult for fuzz testing processes to monitor applications within enclaves. In-enclave fuzzing relies heavily on operating system services, and the testing process cannot run in a secure isolated zone. Traditional in-enclave fuzzing primarily addresses inter-enclave isolation by locally simulating enclave execution, deploying a runtime within the trusted zone to provide operating system services to the testing process.

[0004] However, the simulated execution method cannot truly restore the enclave operating environment and may miss or misjudge some vulnerabilities specific to the TEE environment. Summary of the Invention

[0005] In view of the above situation, the main purpose of the present invention is to propose a method and system for automatic detection of program vulnerabilities under hardware TEE to solve the above technical problems.

[0006] The present invention proposes a method for automatically detecting program vulnerabilities in hardware TEE, which includes the following steps:

[0007] Step 1: Place the target program, fuzz testing engine, and corpus in the TEE environment, preprocess the target program, and obtain several initial seeds from the corpus;

[0008] Step 2: The fuzz testing engine parent worker thread creates several corresponding execution processes through shared memory, and uses the execution processes to execute the preprocessed target program in parallel, using the initial seed as the initial input of the execution process for parallel fuzz testing;

[0009] Step 3: During the fuzz testing process, monitor the target program's running information and coverage information, store the running information and coverage information in the shared memory, and put the corresponding seeds into the corpus to update the corpus according to the coverage information;

[0010] When a process triggers an abnormal signal, the running information and the abnormal signal are stored in the corresponding shared memory, and the abnormal signal is analyzed to obtain analysis data. At the same time, the corresponding seed is put into the corpus to update the corpus;

[0011] Step 4: Based on the analysis data and coverage information, dynamically select a mutation strategy for the initial seed and mutate it, which will serve as the input for the next stage of parallel fuzz testing.

[0012] Step 5: Repeat steps 2 and 4 in an iterative manner to perform parallel fuzz testing until the termination condition is reached or an interrupt signal is received, so as to complete the automated detection of program vulnerabilities and output a fuzz testing report.

[0013] The present invention also provides a system for automatically detecting program vulnerabilities in hardware TEE, wherein the system applies the method for automatically detecting program vulnerabilities in hardware TEE as described above, and the system includes:

[0014] Library operating system modules for:

[0015] Place the target program, fuzz testing engine, and corpus within the TEE environment;

[0016] By sharing memory, the fuzz testing engine parent worker thread creates several corresponding execution processes;

[0017] During the fuzz testing process, the target program's running information and coverage information are monitored and stored in the shared memory;

[0018] When an exception signal is triggered by one of the execution processes, the operation information and the exception signal are stored in the corresponding shared memory;

[0019] Fuzz testing engine module for:

[0020] Preprocess the target program and obtain several initial seeds from the corpus;

[0021] The pre-processed target program is executed in parallel by the execution process, and the initial seed is used as the initial input of the execution process for parallel fuzz testing;

[0022] According to the coverage information, the corresponding seeds are put into the corpus to update the corpus;

[0023] Analyze abnormal signals to obtain analytical data, and put corresponding seeds into the corpus to update the corpus;

[0024] Based on the analysis data and coverage information, a mutation strategy is dynamically selected for the initial seed, which is then used as the input for the next stage of parallel fuzz testing.

[0025] Parallel fuzz testing is performed in an iterative manner until the termination condition is reached or an interrupt signal is received, so as to complete the automated detection of program vulnerabilities and output a fuzz testing report.

[0026] Compared with the prior art, the present invention has the following beneficial effects:

[0027] 1. This invention implements a fuzz tester inside the enclave through a lightweight library operating system, supporting automated vulnerability monitoring within the TEE without crossing the trusted domain boundary.

[0028] 2. The present invention proposes a secure process management mechanism based on shared memory to realize parallel fuzz testing and improve fuzz testing efficiency.

[0029] 3. This paper designs a weight-based seed strategy optimization selection algorithm, dynamically adjusts weights according to coverage information, and improves exploration efficiency. It also implements a signal-based abnormal information monitoring method to collect target program abnormal information in an isolated environment.

[0030] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through embodiments of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 This is a flowchart of the method for automatically detecting program vulnerabilities under hardware TEE proposed in the present invention;

[0032] Figure 2 This is a flow chart of the fuzzy testing algorithm of the present invention;

[0033] Figure 3 This is a schematic diagram of the shared memory-based secure process management mechanism of the present invention;

[0034] Figure 4 This is a schematic diagram of the signal-based information monitoring method within the enclave of the present invention;

[0035] Figure 5Flowchart of program execution exception tracking of the present invention;

[0036] Figure 6 This is a framework diagram of the automatic program vulnerability detection system under the hardware TEE proposed in this invention. DETAILED DESCRIPTION

[0037] The following describes embodiments of the present invention in detail. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended only to explain the present invention and are not to be construed as limiting the present invention.

[0038] These and other aspects of the embodiments of the present invention will become clear with reference to the following description and accompanying drawings. In these descriptions and accompanying drawings, some specific implementations of the embodiments of the present invention are specifically disclosed to illustrate some ways of implementing the principles of the embodiments of the present invention, but it should be understood that the scope of the embodiments of the present invention is not limited thereto.

[0039] See also Figure 1 and Figure 2 This embodiment provides a method for automatically detecting program vulnerabilities in a hardware TEE, the method comprising the following steps:

[0040] Step 1: Place the target program, fuzz testing engine, and corpus in the TEE environment, preprocess the target program, and obtain several initial seeds from the corpus;

[0041] In step 1, the target program is preprocessed by using the clang compiler to perform an instrumentation operation on the target program source code. The instrumentation operation includes inserting a sig_handler (exception signal handling) function for capturing runtime information and exception signals of the target program and a statistical function for recording coverage and statistical information.

[0042] Step 2: The fuzz testing engine parent worker thread creates several corresponding execution processes through shared memory, and uses the execution processes to execute the preprocessed target program in parallel, using the initial seed as the initial input of the execution process for parallel fuzz testing;

[0043] like Figure 3 As shown, in step 2, the method in which the fuzz testing engine parent working thread creates several corresponding execution processes by sharing memory specifically includes the following steps:

[0044] The fuzz test parent worker process creates a fuzz test parent worker thread through the clone system call;

[0045] The worker thread uses the spawn (process creation) system call to create a child process to execute the target program. The parent worker thread and the child execution process it creates are called a work group. The parent worker thread and the child execution process communicate through shared memory.

[0046] Therefore, by having the target program store runtime information in it, the parent worker thread can monitor the runtime status of the target program child process in real time, thereby achieving secure inter-process communication in the enclave.

[0047] Preferably, before the worker thread calls the process creation function to create a child process, it needs to perform preparatory work, which specifically includes the following steps:

[0048] Use the posix_spawn_file_actions_addopen function (which sets a file descriptor for the newly created process) to close the standard input and output of the child process to avoid unnecessary interface (I / O) operations interfering with process execution;

[0049] Initialize the args[] array to store the execution parameters of the target program;

[0050] Use the posix_spawnattr_set (process parameter setting) function to prepare the child process running environment and write relevant environment variables.

[0051] Step 3: During the fuzz testing process, monitor the target program's running information and coverage information, store the running information and coverage information in the shared memory, and put the corresponding seeds into the corpus to update the corpus according to the coverage information;

[0052] When an execution process triggers an exception signal, the operation information and the exception signal are stored in the corresponding shared memory, and the exception signal is analyzed to obtain analysis data. At the same time, the corresponding seed is put into the corpus to update the corpus;

[0053] like Figure 4 As shown, in step 3, when one of the execution processes triggers an abnormal signal, the method of storing the operation information and the abnormal signal in the corresponding shared memory specifically includes the following steps:

[0054] When the program triggers an exception signal, read the siginfo_t (signal information) structure to obtain the exception signal number, error number, signal code and error address;

[0055] Read the program counter;

[0056] Parse the / proc / [pid] / maps file to obtain the target program's memory mapping information;

[0057] Use the libunwind (stack unwinding) library to obtain call stack information, traverse each call frame to obtain the PC (program counter) value and function name of each frame, and determine the module name by parsing the memory map information in the / proc / [pid] / maps file;

[0058] The Capstone engine is used to disassemble the instructions read from the memory, so as to store the operation information and abnormal signal information into the corresponding shared memory according to the instructions.

[0059] Preferably, the operation information and the abnormal signal information respectively use three fields to store information in the shared memory, and the three fields are exec, info, and stak, wherein the operation information includes operation status information, PC information, and stack information;

[0060] The exec field is used to store the running status information of the child process, including: 1) "done" indicates that the process exited normally; 2) "segv" indicates that the process encountered a SIGSEGV (segmentation fault) exception; 3) "ill" indicates that the process encountered a SIGILL (illegal instruction) exception; 4) "abrt" indicates that the process encountered a SIGABRT (process termination) exception; 5) "fpe" indicates that the process encountered a SIGFPE (page fault) exception;

[0061] The info field is used to store PC information and exception signal information, and the stack field is used to store stack information.

[0062] Coverage information is stored in a user-specified feedback file, which is managed by the fuzz testing worker thread.

[0063] To analyze crash uniqueness, this paper proposes a novel crash determination criterion. Given the unique nature of process creation using the spawn function, the same instruction address may correspond to different addresses, making the address unsuitable as the sole criterion for determining crash uniqueness. Although each child process runs in a different virtual space, the layout of the code segments in the virtual address space is identical. The location and structure of the code segments within the same program are consistent within the virtual address space. Therefore, when a program fails on a specific instruction, the lower 12 bits of the instruction's virtual address (the page offset) will be the same, as the instruction's location within the code segment of each process is fixed. Based on this characteristic, four metrics are selected to determine crash uniqueness: 1) exception signal type; 2) lower 12 bits of the current instruction address; 3) current instruction; and 4) stack hash value. We determine crash uniqueness by comparing the status of all four metrics. Therefore, when a child process crashes, the parent thread's TID (thread ID) is used to index into the corresponding shared memory.

[0064] Get the exception signal type, current instruction, lower 12 bits of current instruction address and stack hash value from shared memory;

[0065] The uniqueness of the crash is determined by comparing the type of the exception signal, the current instruction, the lower 12 bits of the current instruction address, and the stack hash value to see if they have all changed. The crash uniqueness judgment model has the following relationship:

[0066] ;

[0067] ;

[0068] in, Indicates whether the abnormal signal types of the current and next stages are the same. Indicates whether the lower 12 bits of the instruction address of the current and next stages are consistent. Indicates whether the instructions of the current and next stages are consistent. Indicates whether the stack hash values ​​of the current and next stages are consistent. Indicates the logical relationship "exclusive or", Indicates the logical relationship "AND"; obtains the RES judgment value. When the result is 1, it means that the crash has not been discovered before, indicating that a new vulnerability has been tested.

[0069] Figure 5 This is a flowchart of program execution exception tracking of the present invention. During the target program instrumentation stage, an exception custom function is registered in the target program. This function is called when an exception occurs in the target program to collect crash information. The fuzz test engine starts the fuzz test process and executes the target application. When an exception occurs in the target program (such as "movq %rcx, (%rdi)" triggers SIGSEGV), it will jump to the custom processing function, collect crash information, and write this information into the shared memory. The analyzer parses the runtime information to identify the crash type. If a new crash is found, the crash information is reported and the seed is placed in the corpus. After the analysis is completed, the analyzer sends a return to continue execution signal to the target application, so that the target routine continues to execute at the current line. Subsequently, SIGSEGV is triggered again, the target process exits due to the exception, and this fuzz test iteration ends. Then, the controller creates a new child process to start the next iteration until the termination condition is met and the fuzz test ends.

[0070] Step 4: Based on the analysis data and coverage information, dynamically select a mutation strategy for the initial seed and mutate it, which will serve as the input for the next stage of parallel fuzz testing.

[0071] In step 4, the method of dynamically selecting a mutation strategy for the initial seed according to the analysis data and coverage information and performing mutation as the input for the next stage of parallel fuzz testing specifically includes the following steps:

[0072] Each seed mutation strategy is assigned a counter;

[0073] In a fuzz testing iteration, if the coverage of an execution with one of the seeds as input improves or triggers a vulnerability, the mutation strategy of that seed will be considered an "interesting" strategy, and its corresponding counter will be automatically incremented by 1;

[0074] According to the size of the counter, the probability of the corresponding seed being selected is adjusted. The probability of the seed mutation strategy being selected in the corpus can be calculated by the following formula:

[0075] ;

[0076] in Indicates strategy, Representation Strategy The probability of being selected, It represents the counter corresponding to the i-th seed, which will be dynamically adjusted according to the runtime information, and n represents the total number of mutation strategies.

[0077] In step 4, the seed mutation strategy includes: 1) adjusting data size; 2) mutating bytes and bits; 3) mutating memory; 4) mutating data blocks; 5) mutating ASCII (Standard Code for Information Interchange) numbers; 6) mutating using a dictionary; and 7) mutating using a random buffer.

[0078] Step 5: Repeat steps 2 and 4 in an iterative manner to perform parallel fuzz testing until the termination condition is reached or an interrupt signal is received, so as to complete the automated detection of program vulnerabilities and output a fuzz testing report.

[0079] Please refer to Figure 6 This embodiment further provides a system for automatically detecting program vulnerabilities in hardware TEE, wherein the system applies the method for automatically detecting program vulnerabilities in hardware TEE as described above, and the system includes:

[0080] Library operating system modules for:

[0081] Place the target program, fuzz testing engine, and corpus within the TEE environment;

[0082] By sharing memory, the fuzz testing engine parent worker thread creates several corresponding execution processes;

[0083] During the fuzz testing process, the target program's running information and coverage information are monitored and stored in the shared memory;

[0084] When an execution process triggers an exception signal, the operation information and the exception signal are stored in the corresponding shared memory;

[0085] Fuzz testing engine module for:

[0086] Preprocess the target program and obtain several initial seeds from the corpus;

[0087] The pre-processed target program is executed in parallel by the execution process, and the initial seed is used as the initial input of the execution process for parallel fuzz testing;

[0088] According to the coverage information, the corresponding seeds are put into the corpus to update the corpus;

[0089] Analyze abnormal signals to obtain analytical data, and put corresponding seeds into the corpus to update the corpus;

[0090] Based on the analysis data and coverage information, a mutation strategy is dynamically selected for the initial seed, which is then used as the input for the next stage of parallel fuzz testing.

[0091] Parallel fuzz testing is performed in an iterative manner until the termination condition is reached or an interrupt signal is received, so as to complete the automated detection of program vulnerabilities and output a fuzz testing report.

[0092] To meet the requirement of executing the entire fuzz testing process within a real TEE environment, the library operating system module of the present invention can be directly designed into the hardware TEE, allowing the complete fuzz testing engine to be ported and run within the enclave. Because the fuzz testing engine contains relatively complex execution logic, it is necessary to provide corresponding request services within the TEE environment. The library operating system will include key modules such as secure dynamic memory management, multithreading, synchronization locks, exception handling, system call and special instruction processing to support its normal operation and minimize its weight.

[0093] To dynamically track the runtime state of the target program, a method for controlling the target process was designed and implemented. Within the library operating system, a signal-based information monitoring module was implemented to control the pause and resume of the target program, thereby manipulating its execution state. Furthermore, shared memory, the perf (system performance analysis) tool, and file symbol transfer were used to collect and feedback runtime and coverage information, enabling the fuzz testing process to obtain real-time information about the target program.

[0094] like Figure 6As shown, the system inputs the TEE program's source code or binary file, and outputs detailed fuzz testing information, including vulnerability reports and coverage. In the TEE process's fuzz testing engine, the controller uses the process creation system call to create the fuzzing process. The seed module reads the initial seed from the vault operating system's file encryption module and mutates it. The mutated seed is stored in a corpus, which is updated based on runtime information to preserve high-quality seeds. Under the management of the secure process management module, new TEE processes are continuously created, and fuzz testing cycles are performed. Different inputs explore a richer range of enclave code paths. During runtime, the analyzer monitors the program's running status using the vault operating system's memory information monitoring module. When the program crashes, a custom handler in the detection engine collects crash information, which the analyzer parses. Any new vulnerabilities discovered are reported. When the detection loop reaches its termination condition (timeout or an external termination signal), a detailed fuzz testing vulnerability and coverage report is output.

[0095] It should be understood that various components of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having logic gate circuits for implementing logic functions on data signals, an application-specific integrated circuit having suitable combinational logic gate circuits, a programmable gate array (PGA), a field-programmable gate array (FPGA), etc.

[0096] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0097] The above-described embodiments merely illustrate several implementations of the present invention, and while their descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

Claims

1. A method for automatically detecting program vulnerabilities in hardware TEE, characterized in that: The method comprises the following steps: Step 1: Place the target program, fuzz testing engine, and corpus in the TEE environment, preprocess the target program, and obtain several initial seeds from the corpus; Step 2: The fuzz testing engine parent worker thread creates several corresponding execution processes through shared memory, and uses the execution processes to execute the preprocessed target program in parallel, using the initial seed as the initial input of the execution process for parallel fuzz testing; Step 3: During the fuzz testing process, monitor the target program's running information and coverage information, store the running information and coverage information in the shared memory, and put the corresponding seeds into the corpus to update the corpus according to the coverage information; When an exception signal is triggered by one of the execution processes, the operation information and the exception signal are stored in the corresponding shared memory, and the exception signal is analyzed to obtain analysis data. At the same time, the corresponding seed is put into the corpus to update the corpus; Step 4: Based on the analysis data and coverage information, dynamically select a mutation strategy for the initial seed and mutate it, which will serve as the input for the next stage of parallel fuzz testing. Step 5: Repeat steps 2 and 4 in an iterative manner to perform parallel fuzz testing until the termination condition is reached or an interrupt signal is received, so as to complete the automated detection of program vulnerabilities and output a fuzz testing report.

2. The method for automatically detecting program vulnerabilities under hardware TEE according to claim 1, characterized in that: In step 1, the target program is preprocessed by using the clang compiler to perform an instrumentation operation on the target program source code. The instrumentation operation includes inserting a sig_handler function for capturing runtime information and exception signals of the target program and a statistical function for recording coverage and statistical information.

3. The method for automatically detecting program vulnerabilities under hardware TEE according to claim 2, characterized in that: In step 2, the method of establishing several execution processes by the parent worker thread through shared memory specifically includes the following steps: The fuzz test parent worker process creates a fuzz test parent worker thread through the clone system call; The worker thread uses the spawn system call to create a child process to execute the target program. The parent worker thread and the child execution process it creates are called a work group. The parent worker thread and the child execution process communicate through shared memory.

4. The method for automatically detecting program vulnerabilities under hardware TEE according to claim 3, characterized in that: Before a worker thread calls a process creation function to create a child process, it must first perform preparatory work. The preparatory work specifically includes the following steps: Use the posix_spawn_file_actions_addopen function to close the standard input and output of the child process; Initialize the args[] array to store the execution parameters of the target program; Use the posix_spawnattr_set function to prepare the child process running environment and write relevant environment variables.

5. The method for automatically detecting program vulnerabilities under hardware TEE according to claim 4, characterized in that: In step 3, when an execution process triggers an abnormal signal, the method of storing the operation information and the abnormal signal in the corresponding shared memory specifically includes the following steps: When the program triggers an exception signal, read the siginfo_t structure to obtain the exception signal number, error number, signal code and error address; Read the program counter; Parse the / proc / [pid] / maps file to obtain the target program's memory mapping information; Use the libunwind library to obtain call stack information, traverse each call frame to obtain the PC value and function name of each frame, and determine the module name by parsing the memory map information in the / proc / [pid] / maps file; The Capstone engine is used to disassemble the instructions read from the memory, so as to store the operation information and abnormal signal information into the corresponding shared memory according to the instructions.

6. The method for automatically detecting program vulnerabilities under hardware TEE according to claim 5, characterized in that: The running information and exception signal information use three fields to store information in the shared memory. The three fields are exec, info, and stak. The running information includes running status information, PC information, and stack information. The exec field is used to store the running status information of the child process, which includes: 1) "done" indicates that the process exited normally; 2) "segv" indicates that the process encountered a segmentation fault exception; 3) "ill" indicates that the process encountered an illegal instruction exception; 4) "abrt" indicates that the process encountered a process termination exception; 5) "fpe" indicates that the process encountered a page fault exception; The info field is used to store PC information and exception signal information, and the stack field is used to store stack information.

7. The method for automatically detecting program vulnerabilities under hardware TEE according to claim 6, characterized in that: In step 3, the method of analyzing the abnormal signal to obtain analysis data specifically includes the following steps: When a child process crashes, the corresponding shared memory is indexed through the parent thread TID; Get the exception signal type, current instruction, lower 12 bits of current instruction address and stack hash value from shared memory; The uniqueness of the crash is determined by comparing the type of the exception signal, the current instruction, the lower 12 bits of the current instruction address, and the stack hash value to see if they have all changed. The crash uniqueness judgment model has the following relationship: ； ； in, Indicates whether the abnormal signal types of the current and next stages are the same. Indicates whether the lower 12 bits of the instruction address of the current and next stages are consistent. Indicates whether the instructions of the current and next stages are consistent. Indicates whether the stack hash values ​​of the current and next stages are consistent. Indicates the logical relationship "XOR", Indicates the logical relationship "and"; Get the RES judgment value. When the result is 1, it means that the crash has not been discovered before, which means a new vulnerability has been tested.

8. The method for automatically detecting program vulnerabilities under hardware TEE according to claim 7, characterized in that: In step 4, the method of dynamically selecting a mutation strategy for the initial seed according to the analysis data and coverage information and performing mutation as the input for the next stage of parallel fuzz testing specifically includes the following steps: Each seed mutation strategy is assigned a counter; In a fuzz testing iteration, if the coverage of an execution with one of the seeds as input improves or triggers a new vulnerability, the mutation strategy of this seed will be considered "interesting" and its corresponding counter will be automatically incremented by 1; According to the size of the counter, the probability of the corresponding seed being selected is adjusted. The probability of the seed mutation strategy being selected in the corpus can be calculated by the following formula: ； in Indicates strategy, Representation Strategy Probability of being selected; represents the counter corresponding to the i-th seed, which will be dynamically adjusted according to runtime information; n represents the total number of mutation strategies.

9. The method for automatically detecting program vulnerabilities under hardware TEE according to claim 8, characterized in that: In step 4, the seed mutation strategy includes: 1) adjusting data size; 2) mutating bytes and bits; 3) mutating memory; 4) mutating data blocks; 5) mutating ASCII code numbers; 6) mutating using a dictionary; and 7) mutating using a random buffer.

10. An automated system for detecting program vulnerabilities in hardware TEE, characterized in that: The system applies the method for automatically detecting program vulnerabilities in a hardware TEE according to any one of claims 1 to 9, and the system includes: Library operating system modules for: Place the target program, fuzz testing engine, and corpus within the TEE environment; By sharing memory, the fuzz testing engine parent worker thread creates several corresponding execution processes; During the fuzz testing process, the target program's running information and coverage information are monitored and stored in the shared memory; When an execution process triggers an exception signal, the operation information and the exception signal are stored in the corresponding shared memory; Fuzz testing engine module for: Preprocess the target program and obtain several initial seeds from the corpus; The pre-processed target program is executed in parallel by the execution process, and the initial seed is used as the initial input of the execution process for parallel fuzz testing; According to the coverage information, the corresponding seeds are put into the corpus to update the corpus; Analyze abnormal signals to obtain analytical data, and put corresponding seeds into the corpus to update the corpus; Based on the analysis data and coverage information, a mutation strategy is dynamically selected for the initial seed, which is then used as the input for the next stage of parallel fuzz testing. Parallel fuzz testing is performed in an iterative manner until the termination condition is reached or an interrupt signal is received, so as to complete the automated detection of program vulnerabilities and output a fuzz testing report.

Images