Data processing method, device and equipment

Abstract

The embodiment of the invention discloses a data processing method, device and equipment, and the method comprises the steps: obtaining target audio data used for carrying out fuzzy testing on a target audio processing program, obtaining an audio processing rule for the target audio data, and describing the content in the audio processing rule through a formalized language, the audio processing rule comprises setting a variation option for variation operation of the target audio data through an extensible characteristic customization option provided in a preset serialization rule; performing deserialization processing on the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data, performing variation operation on the intermediate data through a variation rule matched with a variation option based on the variation option in the audio processing rule to obtain variation data, and performing variation operation on the intermediate data based on the audio processing rule and the variation data. Determining a test case corresponding to the target audio data; and performing fuzzy testing on the target audio processing program based on the test case.

Description

Technical Field

[0001] This document relates to the field of computer technology, and in particular, to a data processing method, apparatus, and device. Background Art

[0002] In the fields of human-computer interaction, real-time communication, etc., web real-time audio communication is undoubtedly an important topic. However, with the continuous development of networks and terminal computing, its security and stability issues have gradually emerged. To ensure the security and stability of web real-time audio communication, fuzz testing of audio processing programs has become an essential part.

[0003] Fuzz testing of audio processing programs can be achieved through fuzz testing tools while protecting user privacy data. The fuzz testing tools improve the code coverage by monitoring the code coverage triggered by audio data, modifying the audio data to increase the probability of discovering vulnerabilities. However, during the process of fuzz testing the audio processing program through fuzz testing tools, due to the lack of structured information of the fuzz testing target and specific characteristics of the audio file format, the above method reduces the possibility of the fuzz testing tool generating effective test cases, resulting in most audio data being rejected at the initial format parsing stage, making it difficult to discover vulnerabilities hidden in subsequent stages. Therefore, a better fuzz testing method is needed to improve the possibility of generating effective test cases in fuzz testing, increase the breadth of vulnerability discovery, and improve the efficiency and accuracy of vulnerability discovery. Summary of the Invention

[0004] The purpose of the embodiments of this specification is to provide a better fuzz testing method to improve the possibility of generating effective test cases in fuzz testing, increase the breadth of vulnerability discovery, and improve the efficiency and accuracy of vulnerability discovery.

[0005] To achieve the above technical solution, the embodiments of this specification are implemented as follows: A data processing method provided by an embodiment of this specification, the method includes: obtaining target audio data for fuzz testing a target audio processing program, and obtaining an audio processing rule for the target audio data, the content in the audio processing rule is described by a formal language, and the audio processing rule includes setting mutation options for the mutation operation of the target audio data through an extensible feature customization option provided in a preset serialization rule; performing deserialization processing on the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rule, performing a mutation operation on the intermediate data through a preset mutation rule matching the mutation options to obtain mutated data, and determining a test case corresponding to the target audio data based on the audio processing rule and the mutated data; performing fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

[0006] A data processing device provided by an embodiment of this specification, the device includes: a data acquisition module, obtaining target audio data for fuzz testing a target audio processing program, and obtaining an audio processing rule for the target audio data, the content in the audio processing rule is described by a formal language, and the audio processing rule includes setting mutation options for the mutation operation of the target audio data through an extensible feature customization option provided in a preset serialization rule; an audio data processing module, performing deserialization processing on the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rule, performing a mutation operation on the intermediate data through a preset mutation rule matching the mutation options to obtain mutated data, and determining a test case corresponding to the target audio data based on the audio processing rule and the mutated data; a fuzz testing module, performing fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

[0007] A data processing device provided by an embodiment of this specification, the data processing device includes: a processor; and a memory arranged to store computer-executable instructions, the executable instructions, when executed, cause the processor to: obtain target audio data for fuzz testing a target audio processing program, and obtain an audio processing rule for the target audio data, the content in the audio processing rule is described by a formal language, and the audio processing rule includes setting mutation options for the mutation operation of the target audio data through an extensible feature customization option provided in a preset serialization rule; perform deserialization processing on the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rule, perform a mutation operation on the intermediate data through a preset mutation rule matching the mutation options to obtain mutated data, determine a test case corresponding to the target audio data based on the audio processing rule and the mutated data; perform fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

[0008] An embodiment of this specification also provides a storage medium, the storage medium is used to store computer-executable instructions, and the executable instructions, when executed by a processor, implement the following process: obtain target audio data for fuzz testing a target audio processing program, and obtain an audio processing rule for the target audio data, the content in the audio processing rule is described by a formal language, and the audio processing rule includes setting mutation options for the mutation operation of the target audio data through an extensible feature customization option provided in a preset serialization rule; perform deserialization processing on the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rule, perform a mutation operation on the intermediate data through a preset mutation rule matching the mutation options to obtain mutated data, determine a test case corresponding to the target audio data based on the audio processing rule and the mutated data; perform fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

[0009] An embodiment of this specification also provides a computer program product, including a computer program which, when executed by a processor, implements the following processes: obtaining target audio data for fuzz testing a target audio processing program, and obtaining an audio processing rule for the target audio data, where the content in the audio processing rule is described by a formal language, and the audio processing rule includes setting mutation options for the mutation operation of the target audio data through an extensible feature customization option provided in a preset serialization rule; performing deserialization processing on the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rule, performing a mutation operation on the intermediate data through a preset mutation rule matching the mutation options to obtain mutated data, determining a test case corresponding to the target audio data based on the audio processing rule and the mutated data; and performing fuzz testing on the target audio processing program based on the test case corresponding to the target audio data. Brief Description of the Drawings

[0010] To more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following briefly introduces the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings. Figure 1 This is an embodiment of a data processing method in this specification. Figure 2 This is a schematic diagram of a fuzz testing page in this specification. Figure 3 This is a schematic diagram of a data processing process in this specification. Figure 4 This is another embodiment of a data processing method in this specification. Figure 5 This is a schematic diagram of an input template in this specification. Figure 6 This is yet another embodiment of a data processing method in this specification. Figure 7 This is yet another embodiment of a data processing method in this specification. Figure 8 This is an embodiment of a data processing device in this specification. Figure 9 This is an embodiment of a data processing device in this specification. Detailed Embodiments

[0011] An embodiment of this specification provides a data processing method, device, and device.

[0012] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this specification without creative efforts shall fall within the scope of protection of this specification.

[0013] The embodiments of this specification provide a structure-aware audio processing program fuzz testing mechanism. The audio processing program can be an audio processing API. For example, an audio processing program based on WebAudio, etc. Taking the audio processing program based on WebAudio as an example, the audio processing program based on WebAudio is an audio processing API widely used in popular browsers, providing rich audio support for the browser Safari on macOS. On macOS, WebAudio is implemented through a series of service layers, and each service layer is supported by the extensive API infrastructure of macOS. Fuzz testing the audio processing program based on WebAudio is actually checking the above different services. Fuzz testing the audio processing program can be achieved in various ways, such as through black-box fuzz testing, white-box fuzz testing, coverage-based grey-box fuzz testing, and enhancement-based grey-box fuzz testing, etc. Among them, black-box fuzz testing uses the audio data format specification to generate input data for the audio processing program, and extensively uses input syntax to generate test cases, aiming to detect errors in the test engine by mutating the original audio data and replacing code fragments based on the analyzed original audio data; white-box fuzz testing uses the internal structure of the audio processing program to optimize test exploration, adopting symbolic execution engines such as KLEE and S2E, etc. It combines grammar-based fuzzing techniques to generate context-free and syntactically valid audio data, as well as model-based methods to impose semantic constraints beyond context-free grammar limitations; coverage-based grey-box fuzz testing, taking the AFL fuzzer and its variants as an example, strikes a balance between black-box and white-box techniques; coverage-based grey-box fuzz testing uses the least amount of instrumentation to guide fuzz testing towards unexplored code regions without incurring significant overhead associated with white-box fuzz testing; enhancement-based grey-box fuzz testing uses Markov chain modeling to target uncovered regions, which can discover known vulnerabilities faster and identify new vulnerabilities. This method usually performs reachability analysis to preferentially estimate the original audio data closer to a given location or target, thereby increasing the likelihood of reaching previously inaccessible code paths.

[0014] Honggfuzz is an open-source fuzz testing tool. By monitoring the code coverage triggered by audio data, Honggfuzz improves the audio data to increase the code coverage and the probability of discovering vulnerabilities. However, due to the lack of structured information about the fuzz testing target and specific features of the audio file format, the possibility of the fuzz testing tool generating effective test cases is reduced, resulting in most audio data being rejected during the initial format parsing stage, making it difficult to discover vulnerabilities hidden in subsequent stages. Therefore, there is a need to provide a fuzz testing solution that can perceive the structured information of the fuzz testing target and specific features of the audio file format, thereby increasing the possibility of the fuzz testing tool generating effective test cases, improving the breadth of vulnerability discovery, and enhancing the efficiency and accuracy of vulnerability discovery. For specific processing, refer to the specific content in the following embodiments.

[0015] As Figure 1 shown, an embodiment of this specification provides a data processing method. The execution subject of this method can be a terminal device or a server, etc. The terminal device can be a mobile terminal device such as a mobile phone or a tablet computer, or a computer device such as a laptop or a desktop computer, or it can also be an IoT device (specifically, a smart watch, a vehicle-mounted device, etc.). The server can be an independent server or a server cluster composed of multiple servers. The server can be a background server in the financial field or the online shopping field, or a background server of a certain application program, etc. In this embodiment, the server is used as an example of the execution subject for detailed description. For the case where the execution subject is a terminal device, refer to the following processing of the server, which will not be elaborated here. The method can specifically include the following steps: In step S102, obtain target audio data for fuzz testing a target audio processing program, and obtain an audio processing rule for the target audio data. The content in the audio processing rule is described in a formal language, and the audio processing rule includes setting mutation options for the mutation operation of the target audio data through the extensible feature customization options provided in a preset serialization rule.

[0016] Among them, the target audio processing program can be any audio processing program that needs to be fuzz-tested. For example, an audio processing program based on HTML5 Audio, an audio processing program based on WebAudio, etc. Specifically, it can be set according to the actual situation. Fuzz testing (i.e., Fuzz Testing) is an automated software testing mechanism. Its core idea is to input a large number of randomly generated unexpected data into the target program, and at the same time collect and monitor the abnormal information generated by the target program during the execution of the test cases, in order to discover as much as possible the illegal input data that causes errors in the target program and find the vulnerable points of the target program. The target audio data can be audio data in any format. In practical applications, in order to improve processing efficiency, the target audio data can be audio data that the target audio processing program can directly process. For example, if the target audio processing program is an audio processing program based on HTML5 Audio, the target audio data can be audio data in the ogg vorbis format. If the target audio processing program is an audio processing program based on WebAudio, the target audio data can be audio data in the CAF format, etc. Specifically, it can be set according to the actual situation. The content in the audio processing rules is described by a formal language. The audio processing rules can include the structured information of the fuzz testing target and can also include the specific characteristics of the format of the audio data. There can be multiple formal languages, such as Protocol Buffers, etc. The extensible feature customization options provided by the serialization rules in the audio processing rules are used to set mutation options for the mutation operation of the target audio data, in order to implement mutation restrictions for specific messages or fields. For example, it can be set that some fields remain unchanged during the mutation operation, and mutation operations such as flipping, deleting, or adding random bit data to the data of some fields can be set. Specifically, it can be set according to the actual situation.

[0017] In implementation, as Figure 2 shown, a fuzz testing page can be preset. This fuzz testing page can be a fuzz testing page for the target audio processing program. The fuzz testing page can include an audio input box, a confirm button, a cancel button, and a result output box, etc. When it is necessary to perform fuzz testing on the target audio processing program, the user or tester can open the above fuzz testing page and can input audio data in the audio input box on the above fuzz testing page. Among them, the input audio data can be one or multiple, in order to perform a more perfect fuzz testing on the target audio processing program. After the input is completed, the user or tester can click the confirm button on the fuzz testing page. At this time, the device displaying the fuzz testing page can obtain the audio data input in the audio input box and can use the obtained audio data as the target audio data for performing fuzz testing on the target audio processing program.

[0018] For the processing of fuzz testing a target audio processing program, as Figure 3 shown, an input template can be predefined. The common processing objects supported by the target audio processing program can be consulted, and the format of specified audio data can be selected. Furthermore, a structured input template can be created. This input template can use a formal language to describe the specific format information of the audio data. In addition, considering the uniqueness of the mutation operations of audio data, including the need to avoid mutating certain fields or specifying the length of string-type variables, etc., and a simple input template cannot meet the above specific requirements. Therefore, the above input template can be enhanced through the extensible feature customization options provided in the preset serialization rules. Additionally, the input template also allows serialization and deserialization processing, etc. Based on the above processing, an audio processing rule can be constructed based on the above input template. The content in this audio processing rule can be described by a formal language. The audio processing rule can include setting mutation options for the mutation operations of the target audio data through the extensible feature customization options provided in the preset serialization rules. In this way, audio data in multiple different formats and / or audio processing rules for different audio processing programs can be constructed. After obtaining the target audio data through the above method, the target audio data can be analyzed to determine the format of the target audio data. Based on the format of the target audio data and the relevant information of the target audio processing program that needs to be fuzz tested, an audio processing rule that matches the format of the target audio data and the target audio processing program can be obtained from the above constructed audio processing rules. Or, it may not be necessary to consider the format of the target audio data. In this case, based on the relevant information of the target audio processing program that needs to be fuzz tested, an audio processing rule that matches the target audio processing program can be obtained from the above constructed audio processing rules, and the obtained audio processing rule can be used as the audio processing rule for the target audio data. At this time, for the format of the target audio data, the target audio data can be converted into the specified format of audio data through the specific format information of the audio data (i.e., the above selected specified format of audio data) set in the audio processing rule.

[0019] In step S104, the target audio data is deserialized based on the audio processing rule to obtain the intermediate data corresponding to the target audio data. And based on the mutation options in the audio processing rule, the intermediate data is mutated through a preset mutation rule that matches the mutation options to obtain mutated data. Based on the audio processing rule and the mutated data, a test case corresponding to the target audio data is determined.

[0020] Among them, as Figure 3As shown, the mutation rules can include not only rules for simple mutation operations (i.e., mutation operations where the changes made to the audio data are not sufficient to significantly modify the structure of the audio data, such as flipping, deleting, or adding random bit data, etc.), but also rules for complex or advanced mutation operations (i.e., mutation operations where the changes made to the audio data can significantly modify the structure of the audio data, such as mutation operations based on complex mutation functions, etc.), so as to generate semantically correct and diverse test cases, thereby improving the effectiveness of fuzz testing and the probability of vulnerability discovery. The test cases can be audio data that can be directly used for fuzz testing the target audio processing program.

[0021] In implementation, the target audio data can be processed through audio processing rules. Specifically, Figure 3 As shown, first, the target audio data can be converted into data of a memory-based data structure through deserialization processing in the audio processing rules, that is, the target audio data can be deserialized through the audio processing rules to obtain intermediate data corresponding to the target audio data (such as data of a memory-based data structure, etc.). Then, Figure 3 As shown, the execution of mutation processing can be triggered through the mutation options in the audio processing rules. Specifically, a mutation library composed of basic mutation functions corresponding to common basic mutation operations can be preset. In addition, mutation strategies corresponding to mutation operations other than the above basic mutation operations (which can include simple mutation operations and complex mutation operations) can also be preset. In this way, more diverse test cases can be generated through the basic mutation functions and mutation strategies. Based on this, the mutation options included in the audio processing rules can be obtained, and each mutation option can be analyzed. Based on the analysis results, the matching basic mutation functions and / or mutation strategies can be selected from the above preset mutation library and mutation strategies. The selected basic mutation functions and / or mutation strategies can be used as mutation rules matching the mutation options. After that, the corresponding data in the intermediate data can be mutated through each of the above mutation rules. Finally, the mutated data corresponding to the intermediate data can be obtained. Figure 3 As shown, if the format of the target audio data is the same as the format set in the audio processing rules, then the target audio data does not need to be converted. Finally, the mutated data can be serialized through the audio processing rules to obtain the test case corresponding to the target audio data; if the format of the target audio data is different from the format set in the audio processing rules, then the mutated data can also be converted into data that meets the above format information through the format information set in the audio processing rules. Finally, Figure 3 As shown, the serialized processing can be performed on the above-converted data through the audio processing rules to obtain the test case corresponding to the target audio data, etc., which can be set according to the actual situation.

[0022] In step S106, fuzz testing is performed on the target audio processing program based on the test cases corresponding to the target audio data.

[0023] In implementation, the obtained test cases can be directly used to perform fuzz testing on the target audio processing program, that is, input the test cases into the target audio processing program, and the target audio processing program processes the test cases to obtain corresponding processing results. The code execution coverage rate in the target audio processing program can be judged through the processing results. The test samples can be adjusted through the obtained code execution coverage rate, so as to improve the code coverage rate and increase the probability of discovering vulnerabilities, so as to achieve the purpose of performing fuzz testing on the target audio processing program. Or, as Figure 3 shown, the test cases can be input into a specified fuzz testing tool. The code coverage rate triggered by the test cases can be monitored through this fuzz testing tool. The test samples can be adjusted through the obtained code coverage rate, so as to increase the probability of discovering vulnerabilities and achieve the purpose of performing fuzz testing on the target audio processing program. Specifically, it can also be set according to the actual situation.

[0024] An embodiment of this specification provides a data processing method. By obtaining target audio data for performing fuzz testing on a target audio processing program, and obtaining an audio processing rule for the target audio data, the content in the audio processing rule is described by a formal language. The audio processing rule includes setting mutation options for the mutation operation of the target audio data through the extensible feature customization options provided in a preset serialization rule. Then, the target audio data can be deserialized based on the audio processing rule to obtain intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rule, the mutation operation of the intermediate data is performed through a preset mutation rule matching the mutation options to obtain mutated data. Based on the audio processing rule and the mutated data, test cases corresponding to the target audio data are determined. Finally, fuzz testing can be performed on the target audio processing program based on the test cases corresponding to the target audio data. In this way, an audio processing rule can be constructed through a custom input template, so as to achieve precise structural perception of the input audio data, and design mutation options in combination with the perceived content, so that the mutation operation is no longer limited to simple mutation operations, thereby generating semantically correct and diverse test cases, and further improving the effectiveness of fuzz testing on the target audio processing program and the probability of discovering vulnerabilities.

[0025] In practical applications, considering that the mutation operation may damage the data structure of the intermediate data, after the mutation operation is completed, the damaged data format caused by the mutation operation can be repaired to ensure that the generated test cases meet the expected data structure and data format requirements. Specifically, the following content can be referred to: The mutated data is repaired based on the audio processing rules to obtain the repaired mutated data.

[0026] In implementation, as Figure 3 shown, post-processing rules can be preset in the audio processing rules. Through the post-processing rules, the data obtained after the mutation process can be evaluated, and post-processing such as correcting the data with errors in the data can be performed. When, based on the mutation options in the audio processing rules, the mutation operation on the intermediate data is performed through the preset mutation rules that match the mutation options to obtain the mutated data, the post-processing rules set in the audio processing rules can be used to evaluate the above mutated data, so as to obtain the data with errors in the mutated data. Then, the above error data can be repaired or corrected to repair the mutated data and obtain the repaired mutated data.

[0027] Based on the above repair process, the specific processing method for determining the test case corresponding to the target audio data in step S104 based on the audio processing rules and the mutated data can include: serializing the repaired mutated data based on the audio processing rules to obtain the test case corresponding to the target audio data.

[0028] In implementation, if the format corresponding to the repaired mutated data is the same as the format set in the audio processing rules at this time, then there is no need to convert the repaired mutated data. Finally, the repaired mutated data can be serialized through the audio processing rules to obtain the test case corresponding to the target audio data; if the format corresponding to the repaired mutated data is not the same as the format set in the audio processing rules at this time, the repaired mutated data can also be converted into data that meets the above format information through the format information set in the audio processing rules. Finally, the above converted data can be serialized through the audio processing rules to obtain the test case corresponding to the target audio data, etc., which can be specifically set according to the actual situation.

[0029] In practical applications, the above target audio processing program can be an audio processing program based on WebAudio, and the above serialization rules can include rules based on Protocol Buffers (Protobuf).

[0030] Among them, the audio processing program based on WebAudio is a program composed of an audio processing framework used in iOS and macOS operating systems, which allows developers to perform operations such as parsing, decoding, encoding, and converting audio data. Protobuf is a flexible and efficient structured data storage format, which can also be used for data serialization. Similar to XML (Extensible Markup Language), it is smaller, faster, and simpler than XML. Protobuf is a language-independent and platform-independent serialization framework, which is widely used in data storage, communication protocols, etc.

[0031] In practical applications, the format of the target audio data can be a format of audio data that the target audio processing program cannot directly process. At this time, the audio processing rule also includes format information for converting the target audio data into a format of audio data that the target audio processing program can process. Based on this, there can be various specific processing methods for determining the test case corresponding to the target audio data based on the audio processing rule and the mutated data in the above step S104. The following provides an optional processing method, as Figure 4 shown, which can specifically include the processing of the following steps S1042 and step S1044.

[0032] In step S1042, based on the above format information in the audio processing rule, the mutated data is converted into conversion data that matches the format information through a preset conversion rule.

[0033] In step S1044, based on the audio processing rule, the above conversion data is serialized to obtain a test case corresponding to the target audio data.

[0034] For the specific processing processes of the above steps S1042 and step S1044, reference can be made to the foregoing relevant content, which will not be elaborated here.

[0035] In practical applications, the test case can include audio data in CAF format. The test case consists of a file header and multiple blocks. The multiple blocks include an audio data block, an audio description block, and a data report block. The audio data block is used to store the metadata of the test case. The audio description block is used to store data packets. The data report block is used to monitor the size of each data packet. The file header includes a file type field, a file version field, and a file flag field. The audio description block includes a header and a body. The header contains a four-byte block type for identification and an eight-byte block size indicating the header range. The body contains a sampling rate field of eight-byte double-precision type to capture the characteristics of the audio data.

[0036] In implementation, as Figure 5The definition of the format information of audio data in CAF format in the input template defined as shown is that audio data in CAF format mainly consists of a file header and multiple blocks. Therefore, the top level can be defined as CAFFile, which contains a file header FileHeader and multiple blocks Chunks. Protobuf can use a syntax similar to a C array to define repeated blocks Chunks. The block Chunk message is defined using the oneof syntax, so that it can contain any field therein. The embodiment of this specification defines three types of blocks Chunks, namely audio data blocks AudioDataChunk, audio description blocks AudioDescriptionChunk and data report blocks PacketTableChunk. Among them, AudioDataChunk is mainly used to store metadata of test cases, while AudioDescriptionChunk is responsible for storing all data packets, and PacketTableChunk monitors the size of each data packet. Once the overall structure of audio data in CAF format is established, the FileHeader and the components of each Chunk are defined. FileHeader can contain three different fields, namely the file type field file_type, the file version field file_version and the file flag field file_flags. The AudioDescriptionChunk is divided into a header and a body. The header contains a four-byte chunk type for identification and an eight-byte chunk size indicating its range; the body contains an eight-byte double-precision sampling rate and various other fields to capture the characteristics of the audio data. Finally, AudioDataChunk and PacketTableChunk follow similar definitions to ensure consistency and coherence in data representation.

[0037] In practical applications, the specific processing methods of the above step S106 can be varied. An optional processing method is provided below, such as Figure 6 As shown, the processing may specifically include the following steps S1062 and S1064.

[0038] In step S1062, a fuzzy test is performed on the target audio processing program based on the test case corresponding to the target audio data, and code coverage information is determined during the fuzzy test.

[0039] In implementation, the obtained test cases above can be directly used to perform fuzz testing on the target audio processing program, that is, input the test cases into the target audio processing program, process the test cases through the target audio processing program to obtain corresponding processing results, and determine the code execution coverage rate in the target audio processing program based on the processing results, so as to determine the code coverage information. Or, the test cases can be input into a specified fuzz testing tool, and the code coverage rate triggered by the test cases can be monitored through this fuzz testing tool, which can also be specifically set according to the actual situation.

[0040] In step S1064, based on the determined code coverage information, adjust the mutation options set in the audio processing rule to obtain an adjusted audio processing rule, and process the obtained audio data based on the adjusted audio processing rule to obtain corresponding test cases.

[0041] In implementation, based on the determined code coverage information, adjust the mutation options set in the audio processing rule to obtain an adjusted audio processing rule, and repeat the processing of the above steps S102 to S106 based on the adjusted audio processing rule until the fuzz testing of the target audio processing program is completed.

[0042] In practical applications, the target audio data can be composed of multiple different message clusters. For example, Figure 5 "message CAFFile{required FileHeader file_header=1; reqeated Chunk chunks=2}" in Figure 5 is a message cluster, and "message Chunk{one of the_chunk{…PacketTableChunk packet_table_chunk=3}}" is also a message cluster, that is, Figure 5 the part containing "message xxx{…}" in Figure 7 is a message cluster. There are 4 message clusters in

[0043] where the 4th message cluster also contains a sub-message cluster. Based on this, the specific processing method of deserializing the target audio data based on the audio processing rule in the above step S104 to obtain the intermediate data corresponding to the target audio data can be various. Hereinafter, an optional processing method is provided, such as Figure 7 shown, which may specifically include the processing of the following steps S1046 and S1048.

[0043] In step S1046, based on the audio processing rule, obtain the first message cluster in the target audio data. If the length of the first message cluster is fixed, obtain the attribute information of the fields included in the first message cluster, and determine the size of the first message cluster based on the attribute information of the fields included in the first message cluster.

[0044] Among them, the first message cluster can be any message cluster in the target audio data.

[0045] In implementation, the deserialization process utilizes the reflection mechanism provided by protobuf in the audio processing rules. If a message cluster message (i.e., the first message cluster) is of fixed length, the attribute information of the fields contained in the message cluster message is dynamically obtained, and the size of the message cluster message is calculated.

[0046] In step S1048, the size Size information in the first message cluster is obtained based on the audio processing rules, and the obtained Size information is converted into a message cluster object corresponding to the first message cluster to perform deserialization processing on the target audio data, obtaining intermediate data corresponding to the target audio data.

[0047] In implementation, the corresponding size is read from the input stream and converted into a message cluster message object. The pseudo-code of the specific processing process is shown in Table 1 below.

[0048] Table 1

[0049] Among them, Deserialization Algorithm is the deserialization algorithm, Date represents the input data, Protobuf template T represents the protobuf template indicated by T Binary file F represents the binary file (i.e., the target audio data) indicated by F Result represents the output result, and A protobuf object O represents a protobuf object (i.e., the intermediate data) indicated by O O

[0050] If the message cluster message is of variable length, code needs to be written according to specific circumstances to read the field information and perform parsing.

[0051] In addition, for the serialization processing mentioned above (including serializing the repaired mutated data based on audio processing rules and serializing the converted data based on audio processing rules, etc.), it can be achieved in the following way: recursively traverse the protobuf tree structure, and during the traversal, convert the type of each field (i.e., the field type) into a binary byte stream to obtain the output result. For the sake of code simplicity, two classes are written in the embodiments of this specification that inherit from std::ostream, namely BigEndianOStream and LittleEndianOStream. For whether the output value is big-endian or little-endian, each of these two classes defines a template function, namely the writev function. According to the different types of the defined input templates, variables of types such as uint8_t, uint16_t, uint32_t, float, double, etc. can be output. The pseudo-code of the specific processing process is shown in Table 2 below.

[0052] Table 2

[0053] In practical applications, the mutation rules matching the mutation options include mutation rules with a mutation complexity higher than a preset complexity threshold.

[0054] Among them, the complexity threshold can be set according to the actual situation. The mutation rules with a mutation complexity higher than the preset complexity threshold can implement complex or advanced mutation operations, that is, mutation operations that can significantly modify the structure of the audio data, such as mutation operations based on complex mutation functions, etc., which can be specifically set according to the actual situation.

[0055] Embodiments of the present specification provide a data processing method, which obtains target audio data for fuzz testing a target audio processing program and obtains audio processing rules for the target audio data. The content of the audio processing rules is described in a formal language, and the audio processing rules include setting mutation options for mutation operations on the target audio data through extensible feature customization options provided in preset serialization rules. Then, the target audio data can be deserialized based on the audio processing rules to obtain intermediate data corresponding to the target audio data. Based on the mutation options in the audio processing rules, the intermediate data can be mutated using a preset mutation rule that matches the mutation option to obtain mutated data. Based on the audio processing rules and the mutated data, a test case corresponding to the target audio data is determined. Finally, the target audio processing program can be fuzz tested based on the test case corresponding to the target audio data. In this way, audio processing rules can be constructed using a customized input template to achieve accurate structural perception of the input audio data. Mutation options are designed based on the perceived content, so that the mutation operation is no longer limited to simple mutation operations, thereby generating semantically correct and diverse test cases, thereby improving the effectiveness of fuzz testing of the target audio processing program and the probability of vulnerability discovery.

[0056] In addition, by introducing complex or advanced mutation operations and post-processing mechanisms, the diversity and complexity of test cases generated during fuzz testing are greatly enhanced, while maintaining the integrity of the test case format, which helps to deeply explore potential security defects. In addition, a comprehensive and flexible security detection framework is proposed, which is particularly suitable for security assessment and processing of multimedia file formats and other data structures with similar complexity. This approach can not only improve the performance of existing fuzz testing tools, but also provide a valuable reference case for fuzz testing in other fields.

[0057] The above is a data processing method provided in the embodiment of this specification. Based on the same idea, the embodiment of this specification also provides a data processing device, such as Figure 8 shown.

[0058] The data processing device includes: a data acquisition module 801, an audio data processing module 802 and a fuzzy testing module 803, wherein: A data acquisition module 801 acquires target audio data for fuzz testing a target audio processing program, and acquires audio processing rules for the target audio data, wherein the audio processing rules are described in a formal language and include setting mutation options for mutation operations on the target audio data using extensible feature customization options provided in a preset serialization rule. The audio data processing module 802 performs deserialization processing on the target audio data based on the audio processing rules, obtains intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rules, performs a mutation operation on the intermediate data through a preset mutation rule matching the mutation options to obtain mutated data. Based on the audio processing rules and the mutated data, a test case corresponding to the target audio data is determined; The fuzz testing module 803 performs fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

[0059] In the embodiments of this specification, the device further includes: A repair module that performs repair processing on the mutated data based on the audio processing rules to obtain repaired mutated data; The audio data processing module 802 performs serialization processing on the repaired mutated data based on the audio processing rules to obtain a test case corresponding to the target audio data.

[0060] In the embodiments of this specification, the target audio processing program is an audio processing program based on WebAudio, and the serialization rules include rules built based on Protocol Buffers (Protobuf).

[0061] In the embodiments of this specification, the format of the target audio data is a format of audio data that the target audio processing program cannot process. The audio processing rules further include format information for converting the target audio data into a format of audio data that the target audio processing program can process. The audio data processing module 802 includes: A conversion unit that converts the mutated data into conversion data matching the format information through a preset conversion rule based on the format information in the audio processing rules; A serialization unit that performs serialization processing on the conversion data based on the audio processing rules to obtain a test case corresponding to the target audio data.

[0062] In the embodiments of this specification, the test case includes audio data in CAF format. The test case consists of a file header and multiple blocks. The multiple blocks include an audio data block, an audio description block, and a data report block. The audio data block is used to store the metadata of the test case. The audio description block is used to store data packets. The data report block is used to monitor the size of each data packet. The file header includes a file type field, a file version field, and a file flag field. The audio description block includes a header and a body. The header contains a four-byte block type for identification and an eight-byte block size indicating the range of the header. The body contains a sampling rate field of eight-byte double-precision type to capture the characteristics of the audio data.

[0063] In the embodiments of this specification, the fuzz testing module 803 includes: A code coverage determination unit that performs fuzz testing on the target audio processing program based on the test case corresponding to the target audio data and determines code coverage information during the fuzz testing process; An adjustment unit that adjusts the mutation options set in the audio processing rule based on the determined code coverage information to obtain an adjusted audio processing rule, and processes the obtained audio data based on the adjusted audio processing rule to obtain corresponding test cases.

[0064] In the embodiments of this specification, the target audio data is composed of multiple different message clusters. The audio data processing module 802 includes: A first calculation unit that obtains the first message cluster in the target audio data based on the audio processing rule. If the length of the first message cluster is fixed, it obtains the attribute information of the fields included in the first message cluster and determines the size of the first message cluster based on the attribute information of the fields included in the first message cluster. A second calculation unit that obtains the size Size information in the first message cluster based on the audio processing rule, converts the obtained Size information into a message cluster object corresponding to the first message cluster, and performs deserialization processing on the target audio data to obtain intermediate data corresponding to the target audio data.

[0065] In the embodiments of this specification, the mutation rule matching the mutation option includes a mutation rule with a mutation complexity higher than a preset complexity threshold.

[0066] Embodiments of the present specification provide a data processing device that obtains target audio data for fuzz testing a target audio processing program and obtains audio processing rules for the target audio data. The content of the audio processing rules is described in a formal language. The audio processing rules include setting mutation options for mutation operations on the target audio data through extensible feature customization options provided in preset serialization rules. Then, the target audio data can be deserialized based on the audio processing rules to obtain intermediate data corresponding to the target audio data. Based on the mutation options in the audio processing rules, the intermediate data can be mutated using a preset mutation rule that matches the mutation option to obtain mutated data. Based on the audio processing rules and the mutated data, a test case corresponding to the target audio data is determined. Finally, the target audio processing program can be fuzz tested based on the test case corresponding to the target audio data. In this way, audio processing rules can be constructed using a customized input template to achieve accurate structural perception of the input audio data. Mutation options are designed based on the perceived content, so that mutation operations are no longer limited to simple mutation operations, thereby generating semantically correct and diverse test cases, thereby improving the effectiveness of fuzz testing of the target audio processing program and the probability of vulnerability discovery.

[0067] In addition, by introducing complex or advanced mutation operations and post-processing mechanisms, the diversity and complexity of test cases generated during fuzz testing are greatly enhanced, while maintaining the integrity of the test case format, which helps to deeply explore potential security defects. In addition, a comprehensive and flexible security detection framework is proposed, which is particularly suitable for security assessment and processing of multimedia file formats and other data structures with similar complexity. This approach can not only improve the performance of existing fuzz testing tools, but also provide a valuable reference case for fuzz testing in other fields.

[0068] The above is a data processing device provided in the embodiment of this specification. Based on the same idea, the embodiment of this specification also provides a data processing device, such as Figure 9 shown.

[0069] The data processing device may provide a terminal device or a server, etc. for the above embodiments.

[0070] Data processing devices can vary significantly in configuration or performance. They can include one or more processors 901 and a memory 902. The memory 902 can store one or more applications or data. Among them, the memory 902 can be transient storage or persistent storage. The applications stored in the memory 902 can include one or more modules (not shown in the figure), and each module can include a series of computer-executable instructions for the data processing device. Further, the processor 901 can be configured to communicate with the memory 902 and execute a series of computer-executable instructions in the memory 902 on the data processing device. The data processing device can also include one or more power supplies 903, one or more wired or wireless network interfaces 904, one or more input / output interfaces 905, and one or more keyboards 906.

[0071] Specifically, in this embodiment, the data processing device includes a memory and one or more programs. One or more of the programs are stored in the memory, and one or more of the programs can include one or more modules. Each module can include a series of computer-executable instructions for the data processing device and is configured to be executed by one or more processors. The one or more programs include the following computer-executable instructions: Obtain target audio data for fuzz testing a target audio processing program, and obtain an audio processing rule for the target audio data. The content in the audio processing rule is described in a formal language, and the audio processing rule includes setting mutation options for the mutation operation of the target audio data through extensible feature customization options provided in a preset serialization rule; Perform deserialization processing on the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data. Based on the mutation options in the audio processing rule, perform a mutation operation on the intermediate data through a preset mutation rule matching the mutation options to obtain mutated data. Determine a test case corresponding to the target audio data based on the audio processing rule and the mutated data; Perform fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

[0072] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the data processing device embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For related parts, reference can be made to the description of the method embodiment.

[0073] An embodiment of this specification provides a data processing device. By obtaining target audio data for fuzz testing a target audio processing program, and obtaining an audio processing rule for the target audio data, the content in the audio processing rule is described by a formal language. The audio processing rule includes setting mutation options for the mutation operation of the target audio data through an extensible feature customization option provided in a preset serialization rule. Then, the target audio data can be deserialized based on the audio processing rule to obtain intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rule, the intermediate data is mutated through a preset mutation rule matching the mutation options to obtain mutated data. Based on the audio processing rule and the mutated data, a test case corresponding to the target audio data is determined. Finally, the target audio processing program can be fuzz tested based on the test case corresponding to the target audio data. In this way, an audio processing rule can be constructed through a custom input template, thereby achieving precise structural perception of the input audio data, and designing mutation options in combination with the perceived content, so that the mutation operation is no longer limited to simple mutation operations, thereby generating semantically correct and diverse test cases, and further improving the effectiveness of fuzz testing of the target audio processing program and the probability of vulnerability discovery.

[0074] Further, based on the above Figures 1 to 7 method shown, one or more embodiments of this specification also provide a storage medium for storing computer-executable instruction information. In a specific embodiment, the storage medium can be a USB flash drive, an optical disc, a hard disk, etc. When the computer-executable instruction information stored in the storage medium is executed by a processor, the following processes can be implemented: Obtain target audio data for fuzz testing a target audio processing program, and obtain an audio processing rule for the target audio data. The content in the audio processing rule is described by a formal language. The audio processing rule includes setting mutation options for the mutation operation of the target audio data through an extensible feature customization option provided in a preset serialization rule; Deserialize the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rule, mutate the intermediate data through a preset mutation rule matching the mutation options to obtain mutated data. Based on the audio processing rule and the mutated data, determine a test case corresponding to the target audio data; Fuzz test the target audio processing program based on the test case corresponding to the target audio data.

[0075] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the above-mentioned storage medium embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and reference can be made to the corresponding part of the method embodiment for related content.

[0076] An embodiment of this specification provides a storage medium. By obtaining target audio data for fuzz testing a target audio processing program, and obtaining an audio processing rule for the target audio data, the content in the audio processing rule is described in a formal language. The audio processing rule includes setting mutation options for the mutation operation of the target audio data through the extensible feature customization options provided in a preset serialization rule. Then, the target audio data can be deserialized based on the audio processing rule to obtain intermediate data corresponding to the target audio data. Based on the mutation options in the audio processing rule, the intermediate data is mutated through a preset mutation rule matching the mutation options to obtain mutated data. Based on the audio processing rule and the mutated data, a test case corresponding to the target audio data is determined. Finally, the target audio processing program can be fuzz tested based on the test case corresponding to the target audio data. In this way, an audio processing rule can be constructed through a custom input template, thereby achieving precise structural perception of the input audio data, and designing mutation options in combination with the perceived content, so that the mutation operation is no longer limited to simple mutation operations, thereby generating semantically correct and diverse test cases, and further improving the effectiveness of fuzz testing of the target audio processing program and the probability of vulnerability discovery.

[0077] Furthermore, based on the above Figures 1 to 7 shown method, one or more embodiments of this specification also provide a computer program product, including a computer program. When the computer program in this computer program product is executed by a processor, the following process can be implemented: Obtain target audio data for fuzz testing a target audio processing program, and obtain an audio processing rule for the target audio data. The content in the audio processing rule is described in a formal language. The audio processing rule includes setting mutation options for the mutation operation of the target audio data through the extensible feature customization options provided in a preset serialization rule; Deserialize the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data. Based on the mutation options in the audio processing rule, the intermediate data is mutated through a preset mutation rule matching the mutation options to obtain mutated data. Based on the audio processing rule and the mutated data, a test case corresponding to the target audio data is determined; Perform fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

[0078] Each embodiment in this specification is described in a progressive manner. For the parts that are the same or similar among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the above-mentioned embodiment of a computer program product, since it is basically similar to the method embodiment, the description is relatively simple, and reference can be made to the corresponding part of the method embodiment for the relevant content.

[0079] An embodiment of this specification provides a computer program product. By obtaining target audio data for performing fuzz testing on a target audio processing program, and obtaining an audio processing rule for the target audio data, the content in the audio processing rule is described by a formal language. The audio processing rule includes setting mutation options for the mutation operation of the target audio data through the extensible feature customization options provided in a preset serialization rule. Then, the target audio data can be deserialized based on the audio processing rule to obtain intermediate data corresponding to the target audio data. And based on the mutation options in the audio processing rule, the mutation operation of the intermediate data is performed through a preset mutation rule that matches the mutation options to obtain mutated data. Based on the audio processing rule and the mutated data, a test case corresponding to the target audio data is determined. Finally, fuzz testing can be performed on the target audio processing program based on the test case corresponding to the target audio data. In this way, an audio processing rule can be constructed through a custom input template, so as to achieve precise structural perception of the input audio data, and design mutation options in combination with the perceived content, so that the mutation operation is no longer limited to simple mutation operations, thereby generating semantically correct and diverse test cases, and further improving the effectiveness of fuzz testing on the target audio processing program and the probability of vulnerability discovery.

[0080] The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the particular order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0081] In the 1990s, it was obvious to distinguish whether an improvement to a technology was a hardware improvement (e.g., improvement to the circuit structure of diodes, transistors, switches, etc.) or a software improvement (improvement to the method flow). However, with the development of technology, many improvements to method flows today can be regarded as direct improvements to the hardware circuit structure. Almost all designers obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement to a method flow cannot be implemented with a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user programming the device. The designer can program by himself to "integrate" a digital system on a piece of PLD without asking the chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a hardware description language (HDL), and there is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. Currently, the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that by simply performing logical programming on the method flow with the above-mentioned several hardware description languages and programming it into the integrated circuit, it is easy to obtain the hardware circuit that implements the logical method flow.

[0082] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of the controller include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that, in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same function. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or structures within the hardware component.

[0083] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0084] For the convenience of description, when describing the above devices, they are described separately as various units according to their functions. Of course, when implementing one or more embodiments of this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0085] Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, one or more embodiments of this specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0086] Embodiments of this specification are described with reference to the flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It should be understood that each flow and / or block in the flowchart and / or block diagram, and combinations of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processors of general-purpose computers, special-purpose computers, embedded processors, or other programmable data processing devices to produce a machine, such that the instructions executed by the processors of the computer or other programmable data processing devices generate means for implementing the functions specified in one or more of the flows Figure 1 one or more of the flows and / or blocks Figure 1 one or more of the blocks for implementing the specified functions.

[0087] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable memory produce a manufacture including instruction means for implementing the functions specified in one or more of the flows Figure 1 one or more of the flows and / or blocks Figure 1 one or more of the blocks for implementing the specified functions.

[0088] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more of the flows Figure 1 one or more of the flows and / or blocks Figure 1 one or more of the blocks for implementing the specified functions.

[0089] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0090] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.

[0091] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can be implemented using any method or technology for information storage. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0092] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0093] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code.

[0094] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0095] Each embodiment in this specification is described in a progressive manner. For the parts that are the same or similar among the embodiments, reference can be made to each other, and the key points of each embodiment are the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for the relevant parts, reference can be made to the partial description of the method embodiment.

[0096] The above is only the embodiment of this specification and is not used to limit this document. For those skilled in the art, various modifications and changes can be made to this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims of this specification.

Claims

1. A data processing method, the method comprising: Obtaining target audio data for fuzz testing a target audio processing program, and obtaining an audio processing rule for the target audio data, the content in the audio processing rule being described in a formal language, and the audio processing rule including setting mutation options for the mutation operation of the target audio data through an extensible feature customization option provided in a preset serialization rule; Performing deserialization processing on the target audio data based on the audio processing rule to obtain intermediate data corresponding to the target audio data, and based on the mutation options in the audio processing rule, performing a mutation operation on the intermediate data through a preset mutation rule matching the mutation options to obtain mutated data, and determining a test case corresponding to the target audio data based on the audio processing rule and the mutated data; Performing fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

2. The method according to claim 1, the method further comprising: Performing repair processing on the mutated data based on the audio processing rule to obtain repaired mutated data; The determining a test case corresponding to the target audio data based on the audio processing rule and the mutated data includes: Performing serialization processing on the repaired mutated data based on the audio processing rule to obtain a test case corresponding to the target audio data.

3. The method according to claim 1 or 2, wherein the target audio processing program is an audio processing program based on WebAudio, and the serialization rule includes a rule constructed based on Protocol Buffers (Protobuf).

4. The method according to claim 3, wherein the format of the target audio data is a format of audio data that the target audio processing program cannot process, and the audio processing rule further includes format information for converting the target audio data into a format of audio data that the target audio processing program can process, The determining a test case corresponding to the target audio data based on the audio processing rule and the mutated data includes: Converting the mutated data into conversion data matching the format information through a preset conversion rule based on the format information in the audio processing rule; Performing serialization processing on the conversion data based on the audio processing rule to obtain a test case corresponding to the target audio data.

5. The method according to claim 4, wherein the test case includes audio data in CAF format, the test case consists of a file header and a plurality of blocks, the plurality of blocks include an audio data block, an audio description block, and a data report block, the audio data block is used to store metadata of the test case, the audio description block is used to store data packets, the data report block is used to monitor the size of each data packet, the file header includes a file type field, a file version field, and a file flag field, the audio description block includes a header and a body, the header contains a four-byte block type for identification and an eight-byte block size indicating the range of the header, and the body contains a sampling rate field of eight-byte double-precision type to capture the characteristics of the audio data.

6. The method according to claim 5, wherein the fuzz testing of the target audio processing program based on the test case corresponding to the target audio data includes: Performing fuzz testing on the target audio processing program based on the test case corresponding to the target audio data, and determining code coverage information during the fuzz testing; Based on the determined code coverage information, adjusting the mutation options set in the audio processing rules to obtain adjusted audio processing rules, and processing the obtained audio data based on the adjusted audio processing rules to obtain corresponding test cases.

7. The method according to claim 6, wherein the target audio data is composed of a plurality of different message clusters, and the deserializing the target audio data based on the audio processing rules to obtain intermediate data corresponding to the target audio data includes: Obtaining a first message cluster in the target audio data based on the audio processing rules, if the length of the first message cluster is fixed, obtaining attribute information of fields included in the first message cluster, and determining the size of the first message cluster based on the attribute information of the fields included in the first message cluster; Obtaining size information in the first message cluster based on the audio processing rules, and converting the obtained size information into a message cluster object corresponding to the first message cluster to perform deserialization processing on the target audio data to obtain intermediate data corresponding to the target audio data.

8. The method according to claim 7, wherein the mutation rules matching the mutation options include mutation rules with a mutation complexity higher than a preset complexity threshold.

9. A data processing device, the device includes: A data acquisition module, which acquires target audio data for fuzz testing a target audio processing program, and acquires audio processing rules for the target audio data, the content in the audio processing rules is described by a formal language, and the audio processing rules include setting mutation options for mutation operations of the target audio data through extensible feature customization options provided in a preset serialization rule; An audio data processing module performs deserialization processing on the target audio data based on the audio processing rule, obtains intermediate data corresponding to the target audio data, and performs a mutation operation on the intermediate data through a preset mutation rule that matches the mutation option in the audio processing rule to obtain mutated data. Based on the audio processing rule and the mutated data, a test case corresponding to the target audio data is determined; A fuzz testing module performs fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

10. A data processing device, the data processing device comprising: A processor; And A memory arranged to store computer-executable instructions, the executable instructions, when executed, causing the processor to: Obtain target audio data for performing fuzz testing on a target audio processing program, and obtain an audio processing rule for the target audio data, the content in the audio processing rule being described by a formal language, and the audio processing rule includes a mutation option for setting a mutation operation for the target audio data through an extensible feature customization option provided in a preset serialization rule; Perform deserialization processing on the target audio data based on the audio processing rule, obtain intermediate data corresponding to the target audio data, and perform a mutation operation on the intermediate data through a preset mutation rule that matches the mutation option in the audio processing rule to obtain mutated data. Based on the audio processing rule and the mutated data, a test case corresponding to the target audio data is determined; Perform fuzz testing on the target audio processing program based on the test case corresponding to the target audio data.

Images