Fuzzy testing method and related device for trusted application program
By analyzing and data mutation of trusted applications, combining multi-mode interface testing and dynamic instrumentation technology, a comprehensive testing of trusted applications is achieved, significantly improving the depth and breadth of vulnerability detection and improving the security of trusted applications.
Patent Information
- Application Number
- CN202510224896.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-27
- Publication Date
- 2025-04-25
AI Technical Summary
It is difficult for existing technology to conduct comprehensive testing of trusted applications, improve the depth and breadth of vulnerability detection, and improve the security of trusted applications.
By analyzing the target trusted application, generating a function information file and an initial test case set, and mutating the test cases data to obtain the target test case set. The target test case set is comprehensively tested using multiple modes such as single-interface testing, multi-interface testing and concurrent testing to determine multiple potential vulnerabilities, and verify the cause of the vulnerability through dynamic instrumentation technology.
It significantly improves the depth and breadth of vulnerability detection, can detect the security of a single interface, potential vulnerabilities during interaction and concurrent calls between interfaces, accurately locate the root causes of vulnerabilities, and improves the security and testing efficiency of trusted applications.
Smart Images
Figure CN119883935A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data security technology, and in particular to a fuzz testing method and related device for a trusted application. Background Art
[0002] A trusted application (TA) is an application running in a trusted execution environment (TEE) that processes sensitive data and performs security-related operations. When there are security vulnerabilities in the interface functions provided by a trusted application, attackers may pass malicious data to these interfaces to trigger vulnerabilities in the TEE, bypass the security mechanism of the TEE, and cause the leakage or damage of sensitive operations. How to conduct comprehensive testing of trusted applications, improve the depth and breadth of vulnerability detection, and improve the security of trusted applications has become one of the technical issues that need to be solved in the field of data security. Summary of the invention
[0003] Based on the above problems, the present application provides a fuzz testing method for trusted applications, which is used to perform comprehensive testing on trusted applications, improve the depth and breadth of vulnerability detection, and improve the security of trusted applications.
[0004] The embodiments of the present application disclose the following technical solutions:
[0005] The first aspect of the present application discloses a fuzz testing method for a trusted application, comprising:
[0006] Parsing the target trusted application to obtain a function information file and an initial test case set; the initial test case set is generated based on the function information file;
[0007] Performing data mutation on the test cases in the initial test case set to obtain a target test case set;
[0008] Performing multi-mode interface testing on each target test case in the target test case set to determine multiple potential vulnerabilities; the multi-mode interface testing includes single interface testing, multi-interface testing and concurrent testing;
[0009] The potential vulnerability is verified to determine the cause of the potential vulnerability.
[0010] In an optional implementation, the step of the multi-interface test includes:
[0011] Determine a minimum command sequence set corresponding to the target test case; the minimum command sequence set includes multiple command sequences; each of the command sequences has a corresponding fitness value; the fitness value is generated based on the code coverage when the command sequence is executed;
[0012] selecting two command sequences from the plurality of command sequences as parent command sequences based on the fitness value of each of the command sequences and a roulette wheel method;
[0013] Based on the parent command sequence and the command mutation operation, a mutated command sequence is generated; the command mutation operation includes insertion, deletion and order change;
[0014] Based on the mutated command sequence and the minimum command sequence set, a target command sequence set is obtained, and a fuzzy test is performed on the target command sequence set.
[0015] In an optional implementation, performing data mutation on the test cases in the initial test case set to obtain the target test case set includes:
[0016] The target test case set is obtained by performing basic data mutation, file operation mutation and / or type confusion mutation on the test cases in the initial test case set; the basic data mutation indicates the mutation operation on the data at the byte level and the bit level; the file operation mutation indicates the mutation operation to generate abnormal file path, deformed file content and abnormal file attributes; the type confusion mutation indicates the mutation operation to construct data of a preset type.
[0017] In an optional implementation, performing a multi-mode interface test on each target test case in the target test case set to determine a plurality of potential vulnerabilities includes:
[0018] Through memory read and write hooks and interrupt hooks, potential vulnerabilities in memory read and write operations are determined; and through system call hooks, potential vulnerabilities in file system call functions and file reading and writing are determined.
[0019] In an optional implementation, the method further includes:
[0020] Based on the instruction execution hook, determine the code execution path running during the execution of the command sequence;
[0021] The code coverage is determined based on the code covered by the running code execution path.
[0022] In an optional implementation, the method for calculating the fitness value includes:
[0023] Determining code coverage, path similarity, and abnormal crash rate when the command sequence is executed;
[0024] A fitness value is determined based on the code coverage, path similarity, and abnormal crash rate.
[0025] In an optional implementation, verifying the potential vulnerability and determining the cause of the potential vulnerability includes:
[0026] Through dynamic instrumentation technology, the triggering conditions of the potential vulnerability are reproduced and the occurrence process of the potential vulnerability is restored;
[0027] Based on the traced data flow and control flow path during the occurrence of the potential vulnerability, the cause of the potential vulnerability is determined.
[0028] In an optional implementation, the process of obtaining the initial test case set includes:
[0029] Loading the target trusted application and simulating execution to obtain dynamic execution information;
[0030] The initial test case set is constructed based on the dynamic execution information, the interface specification file of the trusted execution environment client application and the interface specification document of the trusted application.
[0031] In an optional implementation, the function information file includes: a command identifier, a function name, the number of parameters, the parameter type and the return value.
[0032] A second aspect of the present application provides a fuzz testing device for a trusted application, comprising:
[0033] An initial information collection module, used to parse the target trusted application to obtain a function information file and an initial test case set; the initial test case set is generated based on the function information file;
[0034] A target test set generation module is used to perform data mutation on the test cases in the initial test case set to obtain a target test case set;
[0035] A potential vulnerability detection module is used to perform a multi-mode interface test on each target test case in the target test case set to determine multiple potential vulnerabilities; the multi-mode interface test includes a single interface test, a multi-interface test and a concurrent test;
[0036] The potential vulnerability verification module is used to verify the potential vulnerability and determine the cause of the potential vulnerability.
[0037] A third aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method introduced in any implementation manner of the first aspect.
[0038] A fourth aspect of the present application provides an electronic device, including:
[0039] a memory having a computer program stored thereon;
[0040] A processor is used to execute the computer program in the memory to implement the steps of the method introduced in any implementation manner of the first aspect.
[0041] Compared with the prior art, this application has the following beneficial effects:
[0042] The present application discloses a fuzz testing method for a trusted application, which generates a function information file and an initial test case set by parsing the target trusted application, and performs data mutation on the test case to obtain a target test case set; the target test case set is comprehensively tested using multiple modes such as single interface testing, multi-interface testing, and concurrent testing, which can cover various vulnerability scenarios from simple to complex. This multi-mode testing method can not only detect the security of a single interface, but also discover potential vulnerabilities that may be caused by interactions between interfaces and concurrent calls, thereby significantly improving the depth and breadth of vulnerability detection. Furthermore, by verifying the potential vulnerabilities and determining their causes, the root causes of the vulnerabilities can be accurately located, providing clear guidance for repairing the vulnerabilities. Therefore, the solution of the present application can effectively improve the security of trusted applications, reduce security risks caused by vulnerabilities, and improve testing efficiency and reliability. BRIEF DESCRIPTION OF THE DRAWINGS
[0043] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.
[0044] Figure 1 A flowchart of a fuzz testing method for a trusted application provided in an embodiment of the present application;
[0045] Figure 2 A flowchart of a multi-interface test provided in an embodiment of the present application;
[0046] Figure 3 A schematic diagram of the structure of a trusted application fuzz testing device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0047] A Trusted Execution Environment (TEE) is an independent and isolated execution environment that usually runs on a dedicated operating system and is mainly used to handle operations that require high security, such as payment verification and key management. A Trusted Application (TA) is an application running in a TEE that is specifically used to process sensitive data and perform security-related operations.
[0048] A Rich Execution Environment (REE) is an open environment that is typically used to run complex operating systems and applications. Applications in the main operating system (such as Android, iOS, or Linux) in the REE interact with trusted applications in the TEE through standard drivers, ensuring that sensitive operations are performed in a trusted environment and preventing the impact of potential threats in the main operating system.
[0049] When there are security vulnerabilities in the interface functions provided by trusted applications, attackers may trigger vulnerabilities in TEE by passing malicious data to these interfaces, thereby bypassing the security mechanism of TEE and causing the leakage or damage of sensitive operations.
[0050] In the process of security testing of trusted applications in traditional solutions, there are many problems such as complex test system construction, insufficient coverage of vulnerability types, and incomplete test scenarios. How to conduct comprehensive testing of trusted applications, improve the depth and breadth of vulnerability detection, and thus improve the security of trusted applications has become one of the technical problems that need to be solved in the field of data security.
[0051] The present application discloses a fuzz testing method for a trusted application, which generates a function information file and an initial test case set by parsing the target trusted application, and performs data mutation on the test case to obtain a target test case set; the target test case set is comprehensively tested using multiple modes such as single interface testing, multi-interface testing, and concurrent testing, which can cover various vulnerability scenarios from simple to complex. This multi-mode testing method can not only detect the security of a single interface, but also discover potential vulnerabilities that may be caused by interactions between interfaces and concurrent calls, thereby significantly improving the depth and breadth of vulnerability detection. Furthermore, by verifying the potential vulnerabilities and determining their causes, the root causes of the vulnerabilities can be accurately located, providing clear guidance for repairing the vulnerabilities. Therefore, the solution of the present application can effectively improve the security of trusted applications, reduce security risks caused by vulnerabilities, and improve testing efficiency and reliability.
[0052] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0053] Figure 1 A flowchart of a fuzzy testing method for a trusted application provided in an embodiment of the present application. Figure 1 As shown, the fuzz testing method of a trusted application disclosed in this application includes:
[0054] S101, parse the target trusted application to obtain a function information file and an initial test case set.
[0055] In this application, after determining the trusted application to be tested for security, i.e. the target trusted application, the function information file and the initial test case set are obtained through the following steps. Specifically:
[0056] First, use static analysis tools, such as IDA Pro (Interactive Disassembler Professional), Ghidra (Ghidra Software Reverse Engineering Framework) or parsing libraries to parse binary files of the target trusted application, such as standard OP-TEE (Open Portable Trusted Execution Environment) format and custom format files, to obtain function information such as command identifier, function name, number of parameters, parameter type and return value as a function information file.
[0057] Then, after obtaining the function information file, dynamically load the firmware of the target trusted application into a lightweight software emulator (such as Unicorn) and simulate the operation to observe the behavior data of the target trusted application during actual operation, that is, to obtain dynamic execution information; then, based on the dynamic execution information, the interface specification file of the trusted execution environment client application (TEE ClientAPI) and the interface specification document of the trusted application (TA), build an initial test case set.
[0058] After obtaining the function information file of the target test case, the input test case directory, output test case directory and target trusted application file are obtained; then the test engine is started to start the data mutation, firmware simulation, multi-mode interface testing and exception monitoring in the subsequent embodiments, so as to identify multiple potential vulnerabilities.
[0059] S102, performing data mutation on the test cases in the initial test case set to obtain a target test case set.
[0060] Specifically, at least one of basic data mutation, file operation mutation and type confusion mutation is performed on the test cases in the initial test case set to obtain new test cases, and then obtain the target test case set.
[0061] The basic data mutation instructions in this application perform byte-level and bit-level mutation operations on data. File operation mutation instructions generate mutation operations of abnormal file paths, deformed file contents and abnormal file attributes; type confusion mutation instructions construct mutation operations of data of preset types.
[0062] In other words, the data mutation in this application supports multiple testing scenarios, including basic mutation testing, type confusion testing, and file operation testing.
[0063] Basic mutation testing systematically generates various abnormal input scenarios by performing byte-level and bit-level mutation operations on input data. Mutation operations include flipping, inserting, deleting, and replacing. Basic mutation testing covers boundary values, special characters, and other typical input scenarios. Through basic mutation testing, security vulnerabilities caused by abnormal input data can be discovered.
[0064] File operation testing detects common file operation vulnerabilities such as path traversal and file access out-of-bounds by generating new test cases such as special file paths, malformed file contents, and abnormal file attributes.
[0065] Type confusion detection verifies the application's ability to handle abnormal type input by constructing specific type error data, and identifies potential vulnerabilities caused by lax type checking.
[0066] S103, performing a multi-mode interface test on each target test case in the target test case set to determine a plurality of potential vulnerabilities.
[0067] After obtaining the function information file and the target test case, configure the startup parameters such as the function information file directory, input test case directory, output test case directory, and target trusted application file (binary firmware), and then start the test engine. The engine loads the binary firmware of the target trusted application from the specified path, completes memory mapping, initializes registers and stack pointers, and dynamically simulates the execution of the target trusted application.
[0068] Multi-mode interface testing is performed on each target test case in the target test case set, that is, single interface testing, multi-interface testing and concurrent testing are performed on each target test case. During this process, key behaviors such as instruction execution, memory operations, system calls, etc. are monitored, and coverage information and abnormal events are recorded.
[0069] Single interface testing (single interface testing mode) refers to testing each interface in a trusted application individually to verify its function, performance, and security one by one.
[0070] During the single interface testing process, each command identifier in the function information file corresponding to the target test case is traversed in turn, and the corresponding interface function is called by transmitting parameters. The basic functions, boundary conditions, exception handling, and error return values of the interface are checked to explore potential security vulnerabilities.
[0071] Concurrency testing (concurrency testing mode) refers to evaluating the performance, stability and security of a system in a high-concurrency scenario by simulating multiple users or multiple threads to operate the system at the same time. The concurrency testing mode focuses on the system's resource management, thread scheduling, data consistency and potential concurrency issues in a concurrent environment, such as race conditions, deadlocks, data races, etc.
[0072] The concurrent testing process adopts a hierarchical and progressive strategy, implements a configurable concurrency control mechanism based on the thread pool, and flexibly adjusts the number of concurrent threads and execution strategies; and conducts targeted tests in combination with typical concurrent scenarios (such as resource competition under high load, failure of synchronization mechanisms, etc.) to comprehensively evaluate the stability and security of trusted applications in complex concurrent environments.
[0073] Multi-interface testing (multi-interface testing mode) refers to simulating complex interaction scenarios by calling multiple interfaces in a trusted application at the same time, testing the inter-interface collaboration capabilities and potential interaction problems. The multi-interface testing mode focuses on data dependency, call sequence, state management, and interaction logic between interfaces. It uses various complex interaction scenarios such as concurrent or sequential calls of multiple interfaces to uncover security issues caused by improper interactions between interfaces.
[0074] Figure 2 A flowchart of a multi-interface test provided in an embodiment of the present application. Figure 2 As shown, the steps for performing multi-interface testing on the target test case given in this application are as follows:
[0075] S201, determining a minimum command sequence set corresponding to the target test case.
[0076] Specifically, based on the depth-first generation strategy, the target test cases are statically analyzed to identify the dependencies between command sequences and state transition paths, and to generate a minimum set of command sequences covering the critical paths.
[0077] For example, suppose there are two commands, command A is used to initialize user data, and command B is used to process user requests. The execution of command B depends on the successful execution of command A, because command B needs to use the data initialized by command A; therefore, there is a dependency relationship between command A and command B.
[0078] For another example, suppose that in a certain application, after a user logs in, the user enters the "logged in" state, and if the user logs out, the state is converted to "not logged in". In this process, there is a state conversion relationship between the login command and the logout command.
[0079] For another example, after analysis, it is found that command A (initialize user data), command B (process user request) and command C (user logout) are the key paths. The minimum command sequence set can be [A, B, C], because executing these three commands can cover the entire process from the user not logged in to logged in and then to log out.
[0080] For example, the expression of the minimum command sequence set M=(S 1 , S 2 …, S N ), N is an integer greater than or equal to 2; N is the number of command sequences in the minimum command sequence set. 1 , S 2 and S N Both represent command sequences in the minimum command sequence set.
[0081] For example, the expression of the command sequence in the present application is S=(C 1 , C 2 ...., C m ), m is the number of instructions in the command sequence, m is an integer greater than or equal to 2, C 1 , C 2 and C m Each represents a command interface call in a command sequence set, which carries parameters and status information.
[0082] It can be understood that the minimum command sequence set in the present application includes multiple command sequences; each command sequence has a corresponding fitness value; and the fitness value is generated based on the code coverage when the command sequence is executed.
[0083] In an optional implementation, the fitness value of the command sequence can be calculated by formula (1). The expression of formula (1) is:
[0084] Fitness(S) = W1 ×Coverage(S) + W 2 ×Novelty(S) + W 3 ×Crash(S) (1)
[0085] The meanings of the letters in formula (1) are as follows: S represents the command sequence; Fitness(S) represents the fitness value of the command sequence S; Coverage(S) represents the coverage rate when the command sequence S is executed; Novelty(S) represents the path similarity when the command sequence S is executed; Crash(S) represents the abnormal crash rate when the command sequence S is executed; W1, W2 and W3 are preset weight parameters.
[0086] That is, the method of calculating the fitness value of the command sequence is to determine the code coverage, path similarity and abnormal crash rate when the command sequence is executed; substitute the obtained code coverage, path similarity and abnormal crash rate into formula (1) to obtain the fitness value.
[0087] S202: Based on the fitness value of each command sequence and the roulette method, select two command sequences from the multiple command sequences as parent command sequences.
[0088] When using the roulette wheel method, the probability of a command sequence being selected as the parent command sequence is proportional to its fitness value.
[0089] The fitness value of each command sequence in the minimum command sequence set can be calculated, and then the fitness value of each command sequence is substituted into the preset selection probability formula, that is, formula (2), to obtain the probability value of each command sequence. The expression of formula (2) is:
[0090]
[0091] The meanings of the letters in formula (2) are: Fitness(S i ) represents the command sequence S i Fitness(S j ) represents the command sequence S j fitness value; i represents the i-th command sequence in the minimum command sequence set; N represents the number of command sequences in the minimum command sequence set; j represents the j-th command sequence in the minimum command sequence set; P(S i ) represents the command sequence S i The probability value of .
[0092] After obtaining the probability value of each command sequence in the minimum command sequence set, a command sequence is randomly selected, and the sequence with a larger fitness value is more likely to be selected. This process will be repeated until the required parent sequence is selected for subsequent crossover mutation operations.
[0093] It should be noted that those skilled in the art may also adopt a tournament selection method to select two command sequences from a plurality of command sequences as parent command sequences.
[0094] S203: Generate a mutated command sequence based on the parent command sequence and the command mutation operation.
[0095] If the two selected parent command sequences are S1 and S2, respectively. The expressions of S1 and S2 are: S1 = (C1, C2, C3 ..., Cm) and S2 = (C1', C2', C3' ..., Cm'); then based on the parent command sequence and the command mutation operation, the process of generating the mutated command sequence is:
[0096] First, the elements of the parent command sequence S1 and the mother command sequence S2 are exchanged, that is, a cross operation is performed on the selected command sequence.
[0097] Exemplarily, the first k command interface calls in the parent command sequence S1 and the last (mk) command interface calls in the mother command sequence S2 are combined to obtain a new command sequence Snew = (C1, C2, ..., Ck, Ck+1', Ck+2', ..., Cm').
[0098] Then, mutation operations are performed on the elements in the new command sequence Snew, ie, the command interface calls, including but not limited to insertion, deletion, and order change, to obtain a mutated command sequence.
[0099] Exemplarily, after obtaining the new command sequence Snew, an element at at least one position may be randomly selected for change to obtain a mutated command sequence.
[0100] S204, obtaining a target command sequence set based on the mutated command sequence and the minimum command sequence set, and performing a fuzzy test on the target command sequence set.
[0101] After obtaining the mutated command sequence, the mutated command sequence may be added to the minimum command sequence set, or the mutated command sequence may be used to replace two parent command sequences in the minimum command sequence set to obtain a target command sequence set.
[0102] Then, fuzz testing is performed on the target command sequence set.
[0103] It should be noted that the aforementioned content of this application takes the minimum command sequence set as the initial command sequence set, and introduces the specific process of evaluating the fitness of the command sequence set, selecting the parent command sequence, generating a new command sequence, and generating a mutated command sequence.
[0104] When fuzz testing is performed on the target command sequence set in the aforementioned embodiment, the code coverage when the command sequence is executed can also be determined based on the instruction execution hook; potential vulnerabilities in memory read and write operations can be determined through memory read and write hooks and interrupt hooks; and potential vulnerabilities in system call functions of files and file reading and writing can be determined through system call hooks; based on the latest code coverage and the latest identified potential vulnerabilities, the fitness of each command sequence in the target command sequence set is updated, a new parent command sequence is reselected, and the target command set is used as the initial command sequence set to evolve and generate a new target command sequence set, and then the new target command sequence set is fuzz tested.
[0105] The process of fuzz testing each test case in this application is an iterative testing process. In each round of iteration, the parent command sequence is selected (selection), a new command sequence is generated (crossover), and a mutated command sequence is generated (mutation) to generate a new command sequence set; the newly generated command sequence set is used to replace the command sequence set tested in the previous round.
[0106] Furthermore, in the process of multi-mode interface testing for each target test case in the target test case set, this application uses dynamic stub technology to accurately capture key operations such as instruction execution, memory reading and writing, and system calls in the program, and uses coverage monitoring to improve the coverage and depth of vulnerability testing. In combination with a predefined vulnerability feature library, multiple types of security vulnerabilities are automatically identified through pattern matching, such as illegal memory access, file path traversal, privilege escalation, and type confusion vulnerabilities. Specifically,
[0107] (1) Based on the instruction execution hook, determine the code execution path that runs during the execution of the command sequence; and determine the code coverage rate based on the code covered by the running code execution path, that is, based on the coverage of the running code execution path. That is, through the instruction execution hook, the execution status of each instruction in the program is monitored in real time, and the code coverage information is dynamically captured. Combined with the shared memory mechanism, the coverage data is passed to the data mutation module in real time to provide data support for vulnerability testing and code path analysis.
[0108] (2) Identify potential vulnerabilities in memory read and write operations through memory read and write hooks and interrupt hooks. That is, monitor memory read and write operations through memory read and write hooks and interrupt hooks to capture illegal memory access behaviors, such as unallocated memory access, stack overflow, out-of-bounds access, etc.
[0109] (3) Through the system call hook, determine the system call function of the file and the potential vulnerabilities in file reading and writing. That is, through the system call hook, monitor the file-related system call function, monitor the file reading and writing process in real time, capture the parameters, return values and memory operations during the function call, and detect whether there are file path traversal and illegal file access vulnerabilities.
[0110] (4) Through memory read and write hooks and system call hooks, we monitor type forced conversion, pointer type mismatch and other operations to detect potential type confusion risks. That is, we combine the address and size information of memory operations to verify whether there are abnormal type conversions or memory out-of-bounds operations.
[0111] S104: verify the potential vulnerability to determine the cause of the potential vulnerability.
[0112] Through dynamic instrumentation technology, the triggering conditions of potential vulnerabilities are reproduced and the occurrence process of potential vulnerabilities is restored; based on the data flow and control flow path tracked during the occurrence of potential vulnerabilities, the cause of the potential vulnerability is determined.
[0113] Furthermore, the code coverage, vulnerability details, execution logs and other information generated during the target trusted application testing process are collected to automatically generate a detailed test report, providing vulnerability reproduction steps, impact assessment, repair suggestions, etc.
[0114] It should be noted that this application requires a high-performance computer or a virtualized environment to simulate the execution of trusted applications, as well as firmware simulation tools (such as Unicorn) and fuzz testing tools (such as AFL, American Fuzzy Lop).
[0115] After preparing the test environment and determining the binary file of the target trusted application, extract the function information file from the target trusted application through static analysis and dynamic analysis (the method in S101 in this application), store it in the configuration file, and build an initial test case set; configure the startup parameters such as the target trusted application path, input test case directory, output result directory and function information file, start the fuzz testing engine and automatically execute the test process (S102-S103 in this application); finally, specify the target application path, abnormal test cases and function interface configuration information, load the target application through the vulnerability verification tool, and set the entry address and parameters of the target function; execute the crash case and monitor the running status, capture abnormal behavior (potential vulnerabilities), and output the test report (S104 in this application).
[0116] In summary, the fuzz testing method for trusted applications disclosed in this application has the following advantages over traditional fuzz testing methods:
[0117] First, the fuzz testing solution in this application uses a lightweight software emulator (such as Unicorn), which can accurately simulate each instruction, facilitating vulnerability analysis, fuzz testing and binary analysis; compared with the hardware emulator in the traditional solution (the hardware emulator relies on interfaces such as JTAG or SWD to connect to the target device, which limits its flexibility on different platforms and operating systems), the solution in this application does not rely on physical hardware devices, has greater flexibility and cross-platform capabilities, can be more easily integrated into the vulnerability mining and security testing framework, and supports security testing of trusted applications on multiple platforms such as mobile terminal devices and IoT devices.
[0118] Second, the fuzz testing solution in this application is an integrated security testing solution for trusted applications. Through the methods in S101-S104, that is, through the deep integration of firmware simulation, multi-mode interface testing, anomaly monitoring and data mutation, a comprehensive automated vulnerability detection process is constructed, which effectively improves the efficiency and accuracy of vulnerability mining and achieves full coverage security detection from static analysis to dynamic testing.
[0119] Third, the fuzz testing solution in this application adopts dynamic instrumentation technology, combined with a path-aware mutation strategy, to record the execution path of the program in real time and capture the state changes of key branches; it not only provides more comprehensive data support for vulnerability mining, but also can locate key problem points, greatly improving the depth and accuracy of program analysis.
[0120] Fourth, the fuzz testing scheme in this application designs a variety of test modes suitable for different business scenarios, including single interface testing, multi-interface testing and concurrent testing. Through genetic algorithm optimization of test sequences and multi-threaded concurrent mechanisms, the system can effectively cover the dependencies in interface calls, state transitions, and potential security issues in concurrent scenarios.
[0121] Fifth, the fuzz testing scheme in this application supports comprehensive coverage of different types of security vulnerabilities, including but not limited to memory access vulnerabilities, type confusion vulnerabilities, file operation vulnerabilities, and concurrent competition vulnerabilities. Through targeted data mutation strategies and efficient anomaly monitoring mechanisms, the system can quickly identify and verify different categories of vulnerabilities to ensure the comprehensiveness of security detection.
[0122] In summary, the trusted application fuzz testing method disclosed in this application comprehensively evaluates potential security vulnerabilities in trusted applications through a multi-level, fine-grained testing strategy. This method combines static analysis and dynamic analysis techniques, and uses advanced methods such as dynamic instrumentation, data mutation, and coverage monitoring to test interfaces in multiple modes, which can effectively detect vulnerabilities such as memory access, file operations, and type confusion. Through intelligent testing processes, this method significantly improves the depth and breadth of vulnerability detection, thereby effectively improving the security of trusted applications.
[0123] Figure 3 A schematic diagram of the structure of a trusted application fuzzy testing device provided in an embodiment of the present application. Figure 3 As shown, the trusted application fuzz testing device disclosed in the present application includes: an information collection module, a vulnerability detection module and a vulnerability verification module.
[0124] The information collection module is responsible for comprehensively collecting function information such as command identifiers, function names, parameter types, and initial test cases of the target trusted application, and passing the collected function information to the vulnerability detection module.
[0125] The vulnerability detection module specifically includes a firmware simulation submodule, an interface test submodule, a data mutation submodule, and an anomaly monitoring submodule. The specific functions of each submodule are as follows:
[0126] The firmware simulation submodule is responsible for loading the binary firmware of the target trusted application into the simulation environment for analysis and testing, initializing registers and stack pointers, and dynamically simulating the firmware's code execution.
[0127] The interface test submodule is responsible for supporting single interface test mode, multi-interface test mode and concurrent test mode. The relevant contents of each interface test module are described above and will not be repeated here.
[0128] The data mutation submodule is responsible for using path-aware data mutation technology to efficiently discover potential security vulnerabilities through a systematic input data mutation strategy combined with code coverage feedback and dynamic behavior analysis. Data mutation supports multiple testing schemes, including basic mutation testing, type confusion detection, and file operation testing.
[0129] The exception monitoring submodule is responsible for using dynamic instrumentation technology to accurately capture key operations such as instruction execution, memory reading and writing, and system calls in the program. It uses coverage monitoring to improve the coverage and depth of vulnerability testing, and combines it with a predefined vulnerability feature library to automatically identify various types of security vulnerabilities through pattern matching, such as illegal memory access, file path traversal, privilege escalation, and type confusion vulnerabilities.
[0130] The vulnerability verification module is responsible for verifying the detected potential vulnerabilities and confirming the authenticity and degree of harm of the vulnerabilities. It receives the vulnerability information and related test scenarios transmitted by the vulnerability detection module, and uses dynamic plugging technology to reproduce the conditions that trigger the vulnerabilities; collects the log information, coverage data, and exception reports generated during the execution process, restores the process of vulnerability occurrence, tracks the flow of data, and finally confirms the root cause of the vulnerability and generates a detailed vulnerability report.
[0131] Based on the fuzz testing method and device for trusted applications provided in the aforementioned embodiments, the present application also provides a computer-readable storage medium, on which a computer program is stored, which, when executed by a processor, implements some or all of the steps in the fuzz testing method for trusted applications mentioned above.
[0132] Based on the fuzz testing method and device for trusted applications provided in the above embodiments, the present application further provides an electronic device, including:
[0133] a memory having a computer program stored thereon;
[0134] A processor is used to execute the computer program in the memory to implement part or all of the steps in the fuzz testing method for a trusted application provided in the above-mentioned embodiment.
[0135] It should be noted that each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The device embodiment described above is merely schematic, in which the unit described as a separate component may or may not be physically separated, and the component prompted as a unit may or may not be a physical unit, that is, it may be located in one place, or it may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative work.
[0136] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A fuzz testing method for a trusted application, characterized in that: The method comprises: Parsing the target trusted application to obtain a function information file and an initial test case set; the initial test case set is generated based on the function information file; Performing data mutation on the test cases in the initial test case set to obtain a target test case set; Performing multi-mode interface testing on each target test case in the target test case set to determine multiple potential vulnerabilities; the multi-mode interface testing includes single interface testing, multi-interface testing and concurrent testing; The potential vulnerability is verified to determine the cause of the potential vulnerability.
2. The method according to claim 1, characterized in that The steps of the multi-interface test include: Determine a minimum command sequence set corresponding to the target test case; the minimum command sequence set includes multiple command sequences; each of the command sequences has a corresponding fitness value; the fitness value is generated based on the code coverage when the command sequence is executed; selecting two command sequences from the plurality of command sequences as parent command sequences based on the fitness value of each of the command sequences and a roulette wheel method; Based on the parent command sequence and the command mutation operation, a mutated command sequence is generated; the command mutation operation includes insertion, deletion and order change; Based on the mutated command sequence and the minimum command sequence set, a target command sequence set is obtained, and a fuzzy test is performed on the target command sequence set.
3. The method according to claim 1, characterized in that The step of performing data mutation on the test cases in the initial test case set to obtain a target test case set includes: The target test case set is obtained by performing basic data mutation, file operation mutation and / or type confusion mutation on the test cases in the initial test case set; the basic data mutation indicates the mutation operation on the data at the byte level and the bit level; the file operation mutation indicates the mutation operation to generate abnormal file path, deformed file content and abnormal file attributes; the type confusion mutation indicates the mutation operation to construct data of a preset type.
4. The method according to claim 1, characterized in that The multi-mode interface test is performed on each target test case in the target test case set to determine multiple potential vulnerabilities, including: Through memory read and write hooks and interrupt hooks, potential vulnerabilities in memory read and write operations are determined; and through system call hooks, potential vulnerabilities in file system call functions and file reading and writing are determined.
5. The method according to claim 4, characterized in that The method further comprises: Based on the instruction execution hook, determine the code execution path running during the execution of the command sequence; The code coverage is determined based on the code covered by the running code execution path.
6. The method according to claim 2, characterized in that The method for calculating the fitness value includes: Determining code coverage, path similarity, and abnormal crash rate when the command sequence is executed; A fitness value is determined based on the code coverage, path similarity, and abnormal crash rate.
7. The method according to claim 1, characterized in that The verifying the potential vulnerability and determining the cause of the potential vulnerability includes: Through dynamic instrumentation technology, the triggering conditions of the potential vulnerability are reproduced and the occurrence process of the potential vulnerability is restored; Based on the traced data flow and control flow path during the occurrence of the potential vulnerability, the cause of the potential vulnerability is determined.
8. The method according to any one of claims 1 to 7, characterized in that The process of obtaining the initial test case set includes: Loading the target trusted application and simulating execution to obtain dynamic execution information; The initial test case set is constructed based on the dynamic execution information, the interface specification file of the trusted execution environment client application and the interface specification document of the trusted application.
9. The method according to claim 1, characterized in that: The function information file includes: command identifier, function name, number of parameters, parameter type and return value.
10. A fuzz testing device for a trusted application, characterized in that: The device comprises: An initial information collection module, used to parse the target trusted application to obtain a function information file and an initial test case set; the initial test case set is generated based on the function information file; A target test set generation module is used to perform data mutation on the test cases in the initial test case set to obtain a target test case set; A potential vulnerability detection module is used to perform a multi-mode interface test on each target test case in the target test case set to determine multiple potential vulnerabilities; the multi-mode interface test includes a single interface test, a multi-interface test and a concurrent test; The potential vulnerability verification module is used to verify the potential vulnerability and determine the cause of the potential vulnerability.