Test case generation method and device, equipment, storage medium and product

Abstract

The invention discloses a test case generation method and device, equipment, a storage medium and a product. The method comprises the following steps: acquiring vulnerability information of Internet of Things equipment and a function data packet of to-be-tested equipment; clustering the vulnerability information to obtain a clustering result, the clustering result comprising a plurality of vulnerability types and a first dimension feature corresponding to each vulnerability type; inputting the function data packet into a preset model, and generating at least one first test file through the preset model; for any second test file in the at least one first test file, matching the any second test file with the first dimension feature to obtain a second dimension feature corresponding to the second test file, the second dimension feature being included in the first dimension feature; and generating a test case with guidance by using the second dimension feature, the test case being used for performing fuzz testing on the to-be-tested device. According to the embodiment, the testing efficiency of the fuzz testing can be improved.

Description

Test case generation methods, devices, equipment, storage media, and products Technical Field

[0001] This application belongs to the field of computer text processing technology, and in particular relates to a test case generation method, apparatus, device, storage medium and product. Background Technology

[0002] Fuzz testing is an automated software security testing technique that discovers software vulnerabilities by providing unexpected inputs to a target system and monitoring for unusual results.

[0003] In existing technologies, when using automatically generated test cases for fuzzing, the generation of fuzzing test cases mainly relies on the fuzzing tool itself, which lacks vulnerability targeting and guidance, resulting in low testing efficiency. Summary of the Invention

[0004] This application provides a test case generation method, apparatus, device, storage medium, and product to address the problem that test cases used in fuzz testing lack vulnerability targeting and guidance, resulting in low testing efficiency.

[0005] In a first aspect, embodiments of this application provide a test case generation method, the method comprising:

[0006] Obtain vulnerability information of IoT devices, as well as function data packets of the device under test;

[0007] The vulnerability information is clustered to obtain multiple vulnerability types;

[0008] Obtain the first dimension features corresponding to each of the multiple vulnerability types;

[0009] The function data package is input into a preset model, and at least one first test file is generated through the preset model;

[0010] For any second test file in the at least one first test file, the arbitrary second test file is matched with the first dimension feature to obtain a second dimension feature corresponding to the second test file, and the second dimension feature is included in the first dimension feature;

[0011] Using the second dimension feature, guided test cases are generated, which are used to perform fuzz testing on the device under test.

[0012] Secondly, embodiments of this application provide a test case generation apparatus, the apparatus comprising:

[0013] The first acquisition module is used to acquire vulnerability information of IoT devices and function data packets of the device under test;

[0014] The clustering module is used to cluster the vulnerability information to obtain multiple vulnerability types;

[0015] The second first acquisition module is used to acquire the first dimension features corresponding to the multiple vulnerability types respectively;

[0016] The input module is used to input the function data package into a preset model and generate at least one first test file through the preset model;

[0017] The matching module is used to match any second test file in the at least one first test file with the first dimension feature to obtain a second dimension feature corresponding to the second test file, wherein the second dimension feature is included in the first dimension feature;

[0018] The generation module is used to generate guided test cases using the second dimension feature, and the test cases are used to perform fuzz testing on the device under test.

[0019] Thirdly, embodiments of this application provide a terminal device, the device including: a processor and a memory storing computer program instructions;

[0020] The processor implements the test case generation method as described in the first aspect when executing computer program instructions.

[0021] Fourthly, embodiments of this application provide a computer storage medium on which computer program instructions are stored, and when the computer program instructions are executed by a processor, they implement the test case generation method as described in the first aspect.

[0022] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform the test case generation method as described in the first aspect.

[0023] This application provides a fuzzing method, apparatus, device, and storage medium that acquires vulnerability information from IoT devices, clusters it into multiple vulnerability types, and then generates test cases using the first-dimensional features corresponding to each vulnerability type. This enables the generation of test cases for testing multiple vulnerability types, ensuring the relevance of the test cases. Simultaneously, it uses a preset model to generate a first test file for testing the device under test. By using the first test file and the first-dimensional features to generate test cases, it can specifically test the device under test, allowing the test cases to more accurately cover potentially vulnerable functional points in the device under test. This enhances the relevance and guidance of the test cases, thereby improving the efficiency of fuzzing. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 is a flowchart illustrating the test case generation method provided in an embodiment of this application;

[0026] Figure 2 is a schematic diagram of the overall process of the test case generation method provided in the embodiment of this application;

[0027] Figure 3 is a schematic diagram of the training process of the preset model provided in the embodiment of this application;

[0028] Figure 4 is a schematic diagram of the structure of the preset model provided in the embodiment of this application;

[0029] Figure 5 is a schematic diagram of the test case generation device provided in an embodiment of this application;

[0030] Figure 6 is a schematic diagram of the structure of the terminal device provided in an embodiment of this application. Detailed Implementation

[0031] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0032] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0033] Before providing a detailed description of the technical solutions of the embodiments of this application, a brief explanation of the fuzz testing methods in related technologies will be given first.

[0034] The rapid development of IoT technology has led to an increasing number of IoT devices entering people's lives, bringing great convenience to their daily routines, work, and studies. Different IoT devices offer different services, and people's lives, work, and studies are increasingly integrated with various IoT devices. However, this over-reliance on these IoT devices means that security issues can have serious consequences, even threatening users' lives. Discovering potential vulnerabilities and weaknesses in IoT devices and promptly fixing them is crucial to improving their security. Fuzzing is a highly efficient method for testing IoT devices to detect vulnerabilities. Traditional fuzzing relies heavily on manual processing and tools to manipulate data packets, resulting in low efficiency. Therefore, deep learning-based fuzzing has become a key research focus in recent years. Deep learning is applied to many crucial steps in fuzzing to improve efficiency and increase the likelihood of discovering vulnerabilities, such as seed file generation, test case generation, test case filtering, mutation strategy selection, and monitoring strategies. However, current applications of deep learning in fuzzing do not focus on IoT devices, and the datasets used in deep learning are collected from the internet, making direct application to fuzzing IoT devices impractical. While certain mutation strategies or path collection methods can improve fuzzing efficiency to some extent, they are primarily designed for open-source software and are inapplicable to closed-source IoT devices. Furthermore, the mutation payloads used to generate test cases are mainly used within the fuzzing tool itself and lack vulnerability targeting or guidance.

[0035] Based on this, this application provides a test case generation method, the method comprising: acquiring vulnerability information of an IoT device and a function data package of the device under test; clustering the vulnerability information to obtain multiple vulnerability types; acquiring first dimension features corresponding to the multiple vulnerability types respectively; inputting the function data package into a preset model to generate at least one first test file through the preset model; for any second test file in the at least one first test file, matching the any second test file with the first dimension features to obtain a second dimension feature corresponding to the second test file, the second dimension feature being included in the first dimension features; and using the second dimension features to generate guided test cases, the test cases being used for fuzz testing of the device under test.

[0036] To address the problems in the prior art, embodiments of this application provide a test case generation method, apparatus, device, storage medium, and product.

[0037] The test case generation method provided in the embodiments of this application will be introduced first below.

[0038] Figure 1 shows a flowchart of a test case generation method provided in one embodiment of this application. As shown in Figure 1, the method includes:

[0039] Step 101: Obtain vulnerability information of IoT devices and function data packets of the device under test;

[0040] In this embodiment, vulnerability information is collected from vulnerability websites and open-source vulnerability databases. For example, raw vulnerability information is collected from vulnerability websites such as Common Vulnerabilities and Exposures (CVE), Common Weakness Enumeration (CWE), the National Vulnerability Database (NVD), the China National Vulnerability Database of Information Security (CNNVD), and the Software Assurance Reference Dataset (SARD), as well as open-source vulnerability databases such as Metasploit and network security platforms such as Kanxue, Security Guest, and Freebuf. This vulnerability information includes vulnerability type, vulnerable function, vulnerable component information, vulnerability exploitation method, mutation rules, etc. Mutation rules refer to detecting whether the target program triggers the vulnerability by filling the seed with various mutated vulnerability payloads or modifying the format.

[0041] The function data packets for the device under test (DUT) are obtained by accessing the relevant functions of the DUT. The DUT can be a physical device such as a router or camera, or a virtual device in emulation mode. Regardless of whether it's an emulation mode or a real physical device, all the device's functions can be accessed through a browser to obtain the relevant function data packets.

[0042] In this embodiment of the application, taking a router as an example, in order to ensure the comprehensiveness of the fuzz test scope, all functions of the router can be accessed to obtain relevant functional data packets.

[0043] Step 102: Cluster the vulnerability information to obtain clustering results. The clustering results include multiple vulnerability types and a first dimension feature corresponding to each vulnerability type.

[0044] In one embodiment, specifically, the vulnerability information can be clustered using the System Clustering (CURE) algorithm to obtain clustering results.

[0045] In this embodiment, the vulnerability types include buffer overflow vulnerabilities and command injection vulnerabilities. The CURE clustering algorithm is a bottom-up hierarchical clustering algorithm that clusters vectorized vulnerability information (i.e., a set of points with n-dimensional feature attributes, where the set of points can be any vulnerability information). Since vulnerability information has already been obtained in step 101, and this information includes vulnerability type, vulnerability function, vulnerability component information, vulnerability exploitation method, mutation rules, etc., after clustering, the vulnerability function, vulnerability payload, and vulnerability exploitation method can be directly used as the first-dimensional feature to be categorized into the corresponding vulnerability type. This can be done through manual annotation and automated script analysis.

[0046] It should be noted that common functions that cause buffer overflow vulnerabilities include gets, strcpy, strcat, sprintf, vsprintf, fscanf, scanf, sscanf, fscanf, vfscanf, vscanf, vssscanf, streadd, and strecpy. Dangerous functions for command injection include sensitive function calls to system and the exec family of functions: execl, execlp, execle, execv, execvp, execvpe, and envp. The vulnerability payload is the main functional code written to trigger and exploit the vulnerability after understanding its specific cause.

[0047] The definitions and formulas involved in the hierarchical clustering algorithm are as follows:

[0048] Definition 1: The initial data partitioning for clustering can be represented by a number of dispersed representative points. That is, a data cluster s is represented as s.mP. i (s.mean, sn), where P i s.mean is the representative point of the cluster, m is the number of representative points, s.mean is the center point of the cluster, and sn represents the capacity of the cluster, i.e., the number of data objects.

[0049] The method for selecting representative points is as follows:

[0050] First, determine the number of representative points m and the contraction factor α;

[0051] Select an initial set of m representative points. The first representative point is the point farthest from the cluster center, and subsequent representative points are selected from the data points farthest from the previously selected representative point.

[0052] The shrinkage factor α is used to shrink the representative point, adjust the shape of the class, and eliminate the influence of isolated points. The shrinkage formula is:

[0053] sP i '=sP i +α(s.mean-sP i (1)

[0054] Definition 2: Dispersion. Euclidean distance represents the degree of dispersion of a point in a sample from a representative point. A higher dispersion indicates a greater distance from the representative point. Let P be the set of representative points, and let x be any sample data point. i For a point P in set P, i The dispersion is as follows:

[0055]

[0056] Where, x ij For sample point x i The j-th eigenvalue, P ij Let P be the representative point i The j-th eigenvalue is given by the formula, where n is the dimension of the vector space model. This formula represents the distance between two documents.

[0057] Definition 3: Let D be the set of discreteness for each sample point, and let the average of the discretenesses be the discrete decision value AD of the sample data.

[0058]

[0059] Definition 4: Let the anomaly detection threshold parameter be δ:

[0060]

[0061] Wherein, min(d) i ) represents the minimum dispersion.

[0062] In this embodiment, CURE clustering is based on crawling publicly available vulnerability data and using the CURE clustering algorithm to cluster vulnerability information. Through clustering, different vulnerability types (buffer overflow, command injection) exhibit different characteristics in dimensions such as vulnerability function, vulnerability exploitation method, vulnerability load, and impact on device functions. In subsequent fuzzing, test cases can be generated in a targeted manner based on the functional functions in the function data package of the device under test, resulting in more efficient and targeted test cases.

[0063] Step 103: Input the function data package into a preset model, and generate at least one first test file through the preset model;

[0064] In this embodiment, the preset model can be a Long Short-Term Memory (LSTM) model. This model can take function data packets as input, process the data, and output a first test file that can be used to perform fuzz testing on the functions of the device under test.

[0065] It should be noted that the function data package includes the critical functions and functional functions of the device under test (DUT). These critical and functional functions cover all the functions of the DUT. Therefore, the first test file generated based on the function data package can serve as a target functional point of the DUT, and all generated first test files collectively represent all functional points of the entire DUT. Furthermore, the generated first test files can be driven and modified using a fuzzer (Boofuzz). Therefore, the first test file is a fuzzer file that can be driven by a fuzzer and meets the Boofuzz ​​format requirements.

[0066] Step 104: For any second test file in the at least one first test file,

[0067] The second test file is matched with the first dimension feature to obtain the second dimension feature corresponding to the second test file, and the second dimension feature is included in the first dimension feature;

[0068] In one embodiment, step 103 includes:

[0069] Using the first functional function in the second test file, keyword matching is performed with the second functional function in the first dimension feature. The first functional function is a data field in the first test file, and the second functional function is a data field in the first dimension feature.

[0070] If the first functional function and the second functional function are successfully matched, the dimensional feature containing the second functional function will be determined as the second dimensional feature.

[0071] In this embodiment, the aforementioned data fields can be functional data fields. Both the first dimension feature and the first test file contain a large number of data fields. The first dimension feature is obtained through various vulnerability information collected from existing platforms, while the first test file is generated using the device under test. Therefore, the second dimension feature obtained after keyword matching is used to determine the functionality of the device under test, thereby making the test cases generated using the second dimension feature more targeted to the device under test.

[0072] Through the above embodiments, the first functional function in the first test file is matched with the functional functions in the first dimension features; if a match is found, guided test cases are generated based on the second dimension features. This can guide the first test file to generate test cases of different functions and vulnerability types, making the test cases more targeted, thereby improving the accuracy of fuzz testing and also increasing the bias in vulnerability discovery.

[0073] Step 105: Using the second dimension feature, generate guided test cases, which are used to perform fuzz testing on the device under test.

[0074] In this embodiment, the second-dimensional feature is included within the first-dimensional feature; therefore, the second-dimensional feature also includes the vulnerable function, the vulnerable payload, and the vulnerability exploitation method. After obtaining the above information, test cases can be generated using the vulnerable function, the vulnerable payload, and the vulnerability exploitation method to perform fuzz testing on the device under test.

[0075] In this embodiment, vulnerability information of IoT devices is acquired and clustered into multiple vulnerability types. Then, test cases are generated using the first-dimensional feature corresponding to each vulnerability type. This allows for the generation of test cases that test multiple vulnerability types, ensuring the relevance of the test cases. Simultaneously, a first test file for testing the device under test is generated using a preset model. By using the first test file and the first-dimensional feature to generate test cases, targeted testing of the device under test can be achieved. This allows the test cases to more accurately cover potentially vulnerable functional points in the device under test, enhancing the relevance and direction of the test cases, thereby improving the testing efficiency of fuzz testing.

[0076] In one embodiment of this application, obtaining the function data packet of the device under test includes:

[0077] The firmware of the device under test is unpacked to obtain the key functional components of the firmware.

[0078] Extract the key functions from the key functional components; and

[0079] The firmware is simulated to obtain the working page of the device under test;

[0080] Packet capture is performed on the working page to obtain the functional functions of the device under test.

[0081] In this embodiment, the function data package includes key functions and functional functions, as shown in Figure 2. The key functions are obtained by unpacking the firmware of the device under test to obtain key functional components. Then, using IDA Pro and an auxiliary script, the key functions of these key components are extracted from the firmware. Commonly used tools for firmware unpacking and extraction include binwalk and Firmware Mod Kit.

[0082] Firmware emulation uses tools like QEMU, Firmmadyne, and FirmAE to simulate the firmware and create a real router environment. Taking a router as an example, after successful simulation, you can access the router's web interface in a browser and use its functions. Simultaneously, you can use a network packet capture tool (Wireshark) to capture communication protocol packets from the router's web interface in real time, thus obtaining multiple function data packets. To ensure the comprehensiveness of the fuzzy testing, all router functions should be accessed to obtain the relevant function data packets. Additionally, a large portion of the obtained data packets are invalid, resembling static pages, and need to be filtered and deduplicated to obtain valid function data packets. Then, the obtained data packets are parsed and extracted to obtain the router's functional functions.

[0083] In this embodiment, by extracting the key functions and functional functions of the firmware of the device under test, it is possible to ensure the integrity of the test cases generated, thereby improving the accuracy of vulnerability testing.

[0084] In one embodiment of this application, before inputting the function data package into a preset model and generating at least one first test file through the preset model, the method further includes:

[0085] Acquire pending data packets from IoT devices;

[0086] The data packets to be processed are filtered to obtain valid data packets;

[0087] The valid data packet is converted into a feature vector conforming to a first preset format;

[0088] The recurrent neural network model is trained using the feature vectors to obtain the preset model.

[0089] In this embodiment, the IoT device is different from the device under test. It can be a real physical device or a virtual device. This embodiment does not impose any restrictions on this.

[0090] In this embodiment, as shown in Figures 2 and 3, based on the simulation mode and real physical device, taking a router as an example, the router's web interface is accessed in a browser and its related functions are used. Simultaneously, Wireshark is opened to capture the communication protocol packets of the router's web interface in real time, obtaining the experimental dataset. To ensure the comprehensiveness of the fuzzing test, all functions of the router should be accessed to obtain the relevant functional data packets, i.e., the data packets to be processed.

[0091] The acquired data set needs to be filtered (e.g., static pages), categorized, integrated, and deduplicated to obtain a valid functional data package.

[0092] The first preset format includes the HTTP data packet format and the Boofuzz ​​syntax structure. After obtaining a valid data packet, it undergoes format conversion, the specific conversion process of which is as follows:

[0093] The main analysis of the acquired functional data packets involves data frame format, data base conversion, and data normalization. The data packets obtained by clicking the router's web interface and capturing packets are in HTTP format. The data frames are hexadecimal strings, which need to be converted from hexadecimal to decimal numbers. The conversion formula is as follows: Data normalization involves removing invalid, missing, and incomplete data, thus normalizing the resulting data. Redundancy removal primarily eliminates null values, while normalization uses the softmax function to normalize the data to a value between 0.0 and 0.5. The processed character dataset needs to be converted into a vector dataset. One-hot encoding is used here, which saves time and, to some extent, expands the features. One-hot encoding generates a unique character set for all characters in the dataset, mapping each character one-to-one to a data vector, creating a mapping table for character-data vector conversion. Converting the character data into vector form using one-hot encoding allows it to be used as input to the LSTM model.

[0094] Finally, the transformed feature vectors are used for model training. The extracted features are input into the recurrent escalation network model for training. This recurrent neural network model is an LSTM model. During training, the training parameters can be specifically configured into two sets of parameters with batch sizes of 31 and 61, with other settings including a sequence length of 2, 1 layer, 4 hidden nodes, a learning rate of 0.01, and 100 training epochs. After training, the preset model is obtained, and its output is a fuzzer file that corresponds to the valid data packets and meets the requirements of the Boofuzz ​​format.

[0095] It should be noted that the specific LSTM model in this invention is shown in Figure 4. One switch is used to store the long-term state c, another is responsible for transferring the current state to the long-term state c, and the last switch is used to control the degree to which the output at the current moment is affected by the long-term state c. A gate is a fully connected layer in a neural network; the input vector passes through a gate and outputs a real number vector between 0 and 1. All three switches are related to gates, corresponding to the forget gate, input gate, and output gate, respectively. Within the same neuron layer, not only do the values ​​of the hidden layers flow over time, but the cell state also flows over time.

[0096] Input gate: This determines how much of the current input information needs to be stored in the current cell state. The relevant formula is as follows: ht-1 is the hidden layer output of the previous time step, xt is the current input, calculated using the parameter matrix Wi and the bias parameter bi, and then passed through a sigmoid layer to obtain it. The values ​​are all between 0 and 1, indicating which parts of the input need to be used. (Note: σ represents the sigmoid function, whose output is between 0 and 1. The interaction between the output of the upper node and the input of the lower node is achieved through an activation function. tanh is the hyperbolic tangent function, whose output is between -1 and 1.)

[0097] i t =σ(W i ·[h t-1 ,x t ]+b i (5)

[0098]

[0099] Forget gate: Used to control what information can be forgotten, discarding unnecessary information to avoid consuming resources across the entire model framework. The relevant formula is as follows:

[0100] ht-1 is the hidden layer output of the previous time step, and xt is the current input. The result is calculated by combining it with the parameter matrix Wf and the bias parameter bf, and then passed through the Sigmoid layer to obtain ft. The values ​​of ft are all between 0 and 1. It is multiplied by the cell state Ct-1 of the previous time step, which can discard unnecessary information.

[0101] f t =σ(W f ·[h t-1 ,x t ]+b f (7)

[0102] Cell state update: The results of both the forget gate and the input gate affect the cell state. The formulas related to cell update are as follows: the forget gate (ft) is multiplied by the cell state Ct-1 from the previous time step, indicating how much of the information received in the previous time step needs to be discarded. The input gate (it) is multiplied by the current candidate input vector. Multiplication indicates how much information from the current input needs to be added to the current cell state Ct.

[0103]

[0104] Output gate: It determines what to output based on the cell state update. The relevant formula is as follows: ht-1 is the hidden layer output of the previous time step, xt is the current input, the result is calculated by the parameter matrix Wo and the bias parameter bo, and then passed through the Sigmoid layer to obtain ot. The values ​​are all between 0 and 1, indicating which parts of the cell state need to be output.

[0105] o t =σ(W o [h t-1 ,x t ]+b o (9)

[0106] h t =o t *tanh(C t (10)

[0107] In this embodiment, by using an LSTM model for learning and training, the format of the data packets to be processed can be accurately identified and test files that satisfy the Boofuzz ​​syntax structure can be generated.

[0108] In one embodiment of this application, after matching the arbitrary second test file with the first dimension feature to obtain the second dimension feature corresponding to the second test file, the method further includes:

[0109] If the second test file does not match the first dimension feature, the test cases are generated using the preset compilation rules in the fuzz tester.

[0110] In one embodiment of this application, after generating guided test cases using the second dimension feature, the method further includes:

[0111] The device under test is subjected to fuzz testing using the fuzz tester and the test cases to obtain the response results of the device under test;

[0112] If the response result is the expected result corresponding to the test case, the device under test is determined to be normal.

[0113] In this embodiment, Boofuzz ​​is used as the fuzz tester. Boofuzz ​​is a black-box fuzzing tool, meaning it cannot obtain information about the device under test (DUT) such as memory or file information during testing. Therefore, the fuzzing process relies on the response results of the DUT to make judgments. For the firmware under test, the simulation state can be directly checked to see if it can execute normally. For the real DUT, the ability to provide normal functional requests and indicator light status can be directly checked. Simultaneously, the logs are checked for crash events, which are incidents that can cause device failure. These crash events are analyzed to determine if vulnerabilities were discovered during the fuzzing process. Thus, using Boofuzz ​​to generate guided test cases improves the efficiency of fuzzing compared to traditional fuzzing and increases the likelihood of vulnerability discovery.

[0114] As shown in Figure 5, this application embodiment also provides a test case generation device 500, the device comprising:

[0115] The first acquisition module 501 is used to acquire vulnerability information of IoT devices and function data packets of the device under test;

[0116] Clustering module 502 is used to cluster the vulnerability information to obtain clustering results, the clustering results including multiple vulnerability types and a first dimension feature corresponding to each vulnerability type;

[0117] Input module 503 is used to input the function data package into a preset model and generate at least one first test file through the preset model;

[0118] The matching module 504 is used to match any second test file in the at least one first test file with the first dimension feature to obtain a second dimension feature corresponding to the second test file, wherein the second dimension feature is included in the first dimension feature;

[0119] The generation module 505 is used to generate guided test cases using the second dimension feature, the test cases being used to perform fuzz testing on the device under test.

[0120] Optionally, the first acquisition module 501 includes:

[0121] The unpacking module is used to unpack the firmware of the device under test to obtain the key functional components of the firmware.

[0122] Extraction submodule, used to extract key functions from the key functional components; and

[0123] The simulation submodule is used to simulate the firmware to obtain the working page of the device under test;

[0124] The packet capture module is used to capture packets on the working page to obtain the functional functions of the device under test.

[0125] Optionally, the test case generation device 500 includes:

[0126] The second acquisition module is used to acquire data packets to be processed from IoT devices;

[0127] The processing module is used to filter the data packets to be processed to obtain valid data packets;

[0128] The conversion module is used to convert the valid data packet into a feature vector that conforms to a first preset format;

[0129] The training module is used to train the recurrent neural network model using the feature vectors to obtain the preset model.

[0130] Optionally, the matching module 504 includes:

[0131] The matching submodule is used to perform keyword matching with the second function in the first dimension feature using the first function in the second test file. The first function is a data field in the first test file, and the second function is a data field in the first dimension feature.

[0132] The determination submodule is used to determine the dimension feature containing the second function as the second dimension feature when the first function and the second function are successfully matched.

[0133] Optionally, the test case generation device 500 is also used for:

[0134] If the second test file does not match the first dimension feature, the test cases are generated using the preset compilation rules in the fuzz tester.

[0135] Optionally, the test case generation device 500 further includes:

[0136] The testing module is used to perform fuzz testing on the device under test using the fuzz tester and the test cases, and obtain the response results of the device under test.

[0137] The determination module is used to determine that the device under test is normal if the response result is the expected result corresponding to the test case.

[0138] It should be noted that the test case generation device 500 is a device corresponding to the test case generation method described above. All implementation methods in the above method embodiments are applicable to the embodiments of this device and can achieve the same technical effect.

[0139] Figure 6 shows a schematic diagram of the hardware structure of the terminal device provided in an embodiment of this application.

[0140] The terminal device may include a processor 601 and a memory 602 storing computer program instructions.

[0141] Specifically, the processor 601 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0142] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory.

[0143] In a particular embodiment, memory 602 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Thus, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0144] The processor 601 reads and executes computer program instructions stored in the memory 602 to implement any of the test case generation methods in the above embodiments.

[0145] In one example, the terminal device may also include a communication interface 606 and a bus 610. As shown in Figure 6, the processor 601, memory 602, and communication interface 606 are connected via the bus 610 and communicate with each other.

[0146] The communication interface 606 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0147] Bus 610 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 610 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0148] Furthermore, in conjunction with the test case generation methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the test case generation methods in the above embodiments.

[0149] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0150] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0151] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0152] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable test case generation apparatus to produce a machine such that these instructions, executed via the processor of the computer or other programmable test case generation apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0153] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A test case generation method, characterized in that, The method includes: acquiring vulnerability information of an IoT device and a function data package of the device under test; clustering the vulnerability information to obtain a clustering result, the clustering result including multiple vulnerability types and a first dimension feature corresponding to each vulnerability type; inputting the function data package into a preset model to generate at least one first test file; for any second test file in the at least one first test file, matching the arbitrary second test file with the first dimension feature to obtain a second dimension feature corresponding to the second test file, the second dimension feature being included in the first dimension feature; and using the second dimension feature to generate guided test cases, the test cases being used to perform fuzz testing on the device under test.

2. The test case generation method as described in claim 1, characterized in that, The types of vulnerabilities include buffer overflow vulnerabilities and command injection vulnerabilities.

3. The test case generation method as described in claim 1, characterized in that, The first dimension features include the vulnerability function, vulnerability payload, and vulnerability exploitation method corresponding to the vulnerability type.

4. The test case generation method as described in claim 1, characterized in that, The function data package includes key functions and functional functions; obtaining the function data package of the device under test includes: unpacking the firmware of the device under test to obtain the key functional components of the firmware; extracting the key functions from the key functional components; simulating the firmware to obtain the working page of the device under test; and capturing packets from the working page to obtain the functional functions of the device under test.

5. The test case generation method as described in claim 1, characterized in that, Before inputting the function data packet into the preset model and generating at least one first test file through the preset model, the method further includes: acquiring the data packet to be processed from the Internet of Things device; filtering the data packet to be processed to obtain a valid data packet; converting the valid data packet into a feature vector conforming to a first preset format; and using the feature vector to train a recurrent neural network model to obtain the preset model.

6. The test case generation method as described in claim 3, characterized in that, The step of matching any second test file with the first dimension feature to obtain a second dimension feature corresponding to the second test file includes: using a first functional function in the second test file to perform keyword matching with a second functional function in the first dimension feature, where the first functional function is a data field in the first test file and the second functional function is a data field in the first dimension feature; if the first functional function and the second functional function match successfully, the dimension feature containing the second functional function is determined as the second dimension feature.

7. The test case generation method as described in claim 1, characterized in that, After matching the arbitrary second test file with the first dimension feature to obtain the second dimension feature corresponding to the second test file, the method further includes: generating the test cases using preset compilation rules in the fuzz tester when the second test file does not match the first dimension feature.

8. The test case generation method as described in claim 7, characterized in that, After generating guided test cases using the second dimension feature, the method further includes: performing fuzz testing on the device under test using the fuzz tester and the test cases to obtain the response result of the device under test; and determining that the device under test is normal if the response result is the expected result corresponding to the test case.

9. A test case generation device, characterized in that, The device includes: a first acquisition module for acquiring vulnerability information of IoT devices and function data packets of the device under test; a clustering module for clustering the vulnerability information to obtain clustering results, the clustering results including multiple vulnerability types and a first dimension feature corresponding to each vulnerability type; an input module for inputting the function data packets into a preset model to generate at least one first test file; a matching module for matching any second test file among the at least one first test file with the first dimension feature to obtain a second dimension feature corresponding to the second test file, the second dimension feature being included in the first dimension feature; and a generation module for generating guided test cases using the second dimension feature, the test cases being used to perform fuzz testing on the device under test.

10. A terminal device, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the test case generation method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the test case generation method as described in any one of claims 1-8.

12. A computer program product, characterized in that, The computer product includes a computer program that, when executed by a processor, implements the test case generation method according to any one of claims 1-8.

Images