KR102483489B1 - Hybrid fuzzing device capable of dynamic resource distribution - Google Patents

Abstract

A hybrid fuzzing device of the present invention may include: a fuzzing unit configured to execute fuzzing on software; a concolic unit configured to execute concolic on the software; and a coverage analysis unit configured to receive first coverage information on a fuzzing execution result of the software from the fuzzing unit and second coverage information on a concolic execution result of the software from the concolic unit.

Description

Hybrid purging device capable of dynamic resource distribution {HYBRID FUZZING DEVICE CAPABLE OF DYNAMIC RESOURCE DISTRIBUTION}

The present invention relates to a hybrid purging device, and more particularly, to a hybrid purging device capable of dynamic resource distribution according to software.

Bugs present in the software not only interfere with the functioning of the program, but can also attack the user's device through malicious attackers. However, since it is practically difficult to find all bugs existing in the software during the development stage, various static and dynamic analysis techniques are used to find software bugs not found during the development stage.

Dynamic analysis methods for finding bugs include fuzzing and concolic execution. Fuzzing is fast and has the advantage of being able to test a large number of input values in a short time. However, since fuzzing randomly generates input values or transforms given input values according to predetermined rules, it has a disadvantage in that it is difficult to enter branching statements with complex or limited conditions. Conversely, concolic execution has the advantage of being able to enter a branch with complex or limited entry conditions by generating input values through complex operations. However, since concolic execution is very slow compared to fuzzing, it is inefficient to use concolic execution as a single analysis method.

The present invention relates to hybrid fuzzing using both fuzzing and concolic execution for efficient dynamic testing of software. The present invention relates to a hybrid fuzzing technology capable of dynamic resource distribution for fuzzing or concolic according to characteristics of software to be tested with respect to fixed resources.

One object of the present invention relates to a hybrid purging device capable of dynamic resource distribution.

A hybrid purging apparatus according to an embodiment includes a purging unit configured to perform fuzzing on software; a concolic unit configured to execute concolic on the software; and a coverage analyzer configured to receive first coverage information on a fuzzing execution result of the software from the fuzzing unit and second coverage information on a concolic execution result of the software from the concolic unit.

Here, the coverage analysis unit may include a coverage learning unit that performs machine learning based on the first coverage information and the second coverage information.

Here, the coverage analyzer may determine whether to execute fuzzing or concolic on the software based on a result value of the coverage learning unit.

Here, the resulting value may include a fuzzing score and a concolic score for the software.

Here, the first coverage information or the second coverage information may include a plurality of parts included in the software and a plurality of part values corresponding to each of the plurality of parts.

Here, the coverage learning unit calculates a fuzzing score and a concolic score for each of the plurality of parts based on the values of the plurality of parts, and the coverage analyzer calculates a fuzzing score for the first part of the software as a concolic score. greater than or equal to, transmits a first signal related to the fuzzing execution of the first part to the fuzzing unit, and when the fuzzing score for the first part is smaller than the concolic score, related to the fuzzing execution of the first part A resource allocator for transmitting a second signal to the concolic unit may be included.

Here, the plurality of parts may be distinguished by at least one of a function, a line, a block, a decision, an edge, a branch, and a condition of the source code of the software.

Here, the coverage analysis unit may include a coverage processing unit that processes the first coverage information or the second coverage information to output character data recognizable by a user.

Here, an input unit providing an input value for the execution of the software; and a crash management unit that obtains crash information on execution of the software from the fuzzing unit or the concolic unit, wherein the crash management unit receives a signal about the occurrence of a crash from the fuzzing unit or the concolic unit. , a call stack corresponding to the occurrence of a crash, memory information, and an input value provided from the input unit may be stored.

A hybrid fuzzing method according to an embodiment is a hybrid fuzzing method performed by at least one processor, comprising: executing fuzzing on software; running concolic on the software; receiving first coverage information on a fuzzing execution result of the software and second coverage information on a concolic execution result of the software; and performing machine learning based on the first coverage information and the second coverage information.

Here, a computer program stored in a computer-readable recording medium to execute the hybrid purging method may be provided.

According to an embodiment of the present invention, a hybrid purging apparatus capable of dynamic resource distribution may be provided.

1 is a block diagram of a hybrid purging device according to an embodiment.
2 is a flowchart of a resource allocation method of a hybrid purging apparatus according to an embodiment.
3 is a diagram for explaining coverage information according to an exemplary embodiment.
4 is a diagram for explaining processing of coverage according to an exemplary embodiment.

The embodiments described in this specification are intended to clearly explain the spirit of the present invention to those skilled in the art to which the present invention belongs, so the present invention is not limited to the embodiments described in this specification, and the The scope should be construed to include modifications or variations that do not depart from the spirit of the invention.

The terms used in this specification have been selected as general terms that are currently widely used as much as possible in consideration of the functions in the present invention, but these may vary depending on the intention of those skilled in the art, precedents, or the emergence of new technologies to which the present invention belongs. can However, in the case where a specific term is defined and used in an arbitrary meaning, the meaning of the term will be separately described. Therefore, the terms used in this specification should be interpreted based on the actual meaning of the term and the overall content of this specification, not the simple name of the term.

The drawings accompanying this specification are intended to easily explain the present invention, and the shapes shown in the drawings may be exaggerated as necessary to aid understanding of the present invention, so the present invention is not limited by the drawings.

If it is determined that a detailed description of a known configuration or function related to the present invention in this specification may obscure the gist of the present invention, a detailed description thereof will be omitted if necessary.

Bug hunting is an important task that not only has to do with the running of the software, but also with the maintenance of the device. Among dynamic analysis methods for bug detection, fuzzing is a dynamic analysis method that detects abnormal operation of software by randomly generating input values or modifying given input values. At this time, the abnormal operation of the software means that the software is not executed as the developer considered and a bug occurs. For example, the abnormal operation may be an operation such as outputting an unexpected value or an operation such as abnormal termination.

Fuzzing is fast and has the advantage of being able to test a large number of input values in a short time. On the other hand, since fuzzing randomly generates an input value or transforms a given input value according to a predetermined rule, it has a disadvantage in that it is difficult to enter branching statements with complex or limited conditions.

For example, assume that there is a 4-byte integer variable x that can be manipulated through input in the software to be tested, and that there is a branch that can be entered when the value contained in the variable x is 0xdeadbeef. Since fuzzing randomly transforms the input value, the randomly selected 4-byte input value must accidentally become 0xdeadbeef to enter the branch. However, since the probability that a randomly selected 4-byte value is exactly 0xdeadbeef is very low, 2^(-32), it is very difficult to test that branch through fuzzing.

Conversely, concolic execution, another dynamic analysis method, has the advantage of being able to enter a branch with complex or limited entry conditions by generating input values through complex operations. However, concolic runs are very slow compared to fuzzing, making it inefficient to use concolic runs as a single analysis method.

Hybrid fuzzing is a fuzzing strategy that uses fuzzing and concolic execution together to compensate for the disadvantages of single execution of fuzzing or concolic execution. Uncomplicated branches are quickly explored through fuzzing, and complex branches that are difficult to explore through fuzzing are explored through concolic execution.

When using the hybrid fuzzer, the user sets in advance how much resources to allocate to each of fuzzing and concolic execution, and performs fuzzing. However, for each branch or part of the software under test, an efficient search method may be different. Specifically, concolic execution is more efficient than fuzzing when searching for a definite branch, and fuzzing is more efficient than concolic execution when a test needs to be performed through many executions. Therefore, if fuzzing is performed by allocating and fixing a fixed amount of resources to fuzzing and concolic execution, resources may be used inefficiently.

Conventionally, QSYM, which can perform hybrid purging quickly and efficiently, has been introduced. However, when performing hybrid fuzzing, QSYM did not consider that the efficiency of fuzzing and concolic execution varies depending on the software being tested, the test inputs possessed, and the progress.

Specifically, when evaluating QSYM, two cores were assigned to fuzzing and one core to concolic execution, so a total of three cores were set to be used. At this time, if the fuzzer encounters a complicated branch and cannot enter for a long time, it is more efficient to allocate resources to concolic execution rather than fuzzing. However, QSYM still allocates 2 cores for initially configured fuzzing and 1 core for concolic execution, resulting in inefficient use of the given resources.

QSYM only deals with hybrid fuzzing using a fuzzing module and a path search module. That is, QSYM does not deal with how to efficiently distribute and use many computing resources to each device.

As another prior art, in relation to hybrid fuzzing, fuzzolic, which is a concolic engine that analyzes complex software being executed and efficiently performs concolic execution, has been introduced. In addition, there was a way to use concolic execution more quickly and efficiently by using Fuzzy-Sat, which calculates an approximate value cheaply, instead of the SMT solver, which takes a lot of time and resources, but calculates an accurate answer. However, since the above methods do not consider how to allocate resources to the concolic engine and fuzzing, there is a limitation that given resources cannot be efficiently utilized.

The above problem occurs more frequently as the purging time increases and the amount of given resources increases. In general, when performing software testing using a hybrid fuzzer, dozens of cores are used. Therefore, the need for a dynamic resource distribution method and device is more needed from a practical point of view.

In order to overcome the above problem, while performing fuzzing, the efficiency of fuzzing and concolic execution must be identified in real time and resources must be reallocated. However, it is impossible for the user to allocate resources considering this in real time. Therefore, the present invention proposes a technique capable of identifying the efficiency of fuzzing and concolic execution in real time and dynamically allocating resources.

1 is a block diagram of a hybrid purging device according to an embodiment.

Referring to FIG. 1 , a hybrid purging device 1000 according to an embodiment may include an input unit 100, a purging unit 200, a concolic unit 300, and a coverage analysis unit 400. The hybrid purging device 1000 is not limited to the illustration of FIG. 1 and may include fewer or more components than these. For example, the hybrid purging apparatus 1000 may include a crash manager (not shown).

1 illustrates that each component is a separate department or device, but is not limited thereto, and some components may be configured as one device. For example, the first input unit may be included in the purging unit, or the second input unit may be included in the concolic unit, but is not limited thereto.

The input unit 100 may generate and/or output an input value for testing software. The input unit 100 may output an input value based on pre-stored input data or generate and/or output a random input value using a random function. Also, the input unit 100 may generate new input values by modifying values included in pre-stored input data.

The input unit 100 may store significant input values among input values used for fuzzing or concolic execution from the fuzzing unit 200 or the concolic unit 300 in an input pool. At this time, a meaningful input value is an input value that can obtain new coverage without overlapping with existing input values, an input value that has the same coverage as the previous one, but is simplified and can save execution time, etc. It can be an input value.

Input values stored in the input pool of the input unit 100 may be used as initial values for performing a mutation in the purging unit 200 or may be used as test input values of the concolic unit 300 .

The fuzzing unit 200 may perform fuzzing on the software to be tested. 1 shows that the hybrid purging device 1000 includes the purging unit 200, but is not limited thereto, and the purging unit 200 may exist as another device separately from the hybrid purging device 1000. there is. The purging unit 200 may also be referred to as a purging device.

The purging unit 200 may include an input designation unit 210 , an input variation unit 220 , an input execution unit 230 and a coverage measuring unit 240 . However, the purging unit 200 is not limited thereto, and the purging unit 200 may perform a task by one processor rather than by several factors.

The purging unit 200 may obtain an input value from the input unit 100 . The input designator 210 may designate a first input value among input values obtained from the input unit 100 . The input variation unit 220 may mutate the first input value designated by the input designation unit 210 to generate a second input value that is a new input. Specifically, the input variation unit 220 may generate a second input value by using bit conversion, byte conversion, partial substitution, partial deletion, or byte addition with respect to the first input value.

The input execution unit 230 of the fuzzing unit 200 may receive the second input value from the input variation unit 220 and execute fuzzing on the software under test. The coverage measurer 240 may generate crash information and coverage information while performing fuzzing.

Specifically, the crash information may include whether or not a crash occurs in the software to be tested, and call stack and memory information when the crash occurs. At this time, the crash may mean that a bug occurs in the software to be tested due to an arbitrary input value and ends abnormally. If a crash occurs, this means that an input value causing a software bug has been found, so the fuzzing unit 200 can record information about it.

Also, coverage information may refer to information indicating a flow of software being executed according to an input value. Specifically, the coverage information may include a plurality of parts included in the software to be tested and a plurality of part values corresponding to each of the plurality of parts. In this case, the plurality of parts may vary according to the type of coverage. For example, the plurality of parts may be distinguished by at least one of functions, lines, blocks, decisions, edges, branches, and conditions of the source code of the software to be tested.

As a specific example, if N functions are included in the source code, the software may include N parts by dividing parts for each function. In addition, when the source code is composed of L lines, the software may include L parts by dividing parts for each line. In addition, when the source code includes B blocks, the software may include B blocks by dividing parts for each block. Specific examples of parts and part values of coverage will be described below with reference to FIG. 3 .

The purging unit 200 may transmit the generated coverage information to the coverage analysis unit 400 . Also, the fuzzing unit 200 may transmit generated crash information to a crash management unit (not shown).

The concolic unit 300 may execute concolic for the software to be tested. 1 shows that the concholic unit 300 is included in the hybrid purging device 1000, but is not limited thereto, and the concholic unit 300 is transferred to another device separately from the hybrid purging device 1000. may exist The concolic unit 300 may also be named a concolic execution device.

The concolic unit 300 may include an input designator 310, a concolic execution unit 320, and a coverage measurement unit 330. However, the concolic unit 300 is not limited thereto, and the task may be performed by one processor rather than by several factors.

The concolic unit 300 may obtain an input value from the input unit 100. The input designation unit 310 of the concolic unit 300 analyzes the input value obtained from the input unit 100 and the software to be tested, and may designate a test input value suitable for concolic execution. Specifically, the input specifying unit 310 identifies the number of subblocks or branches to which the test input value can further reach through coverage information of the test input and a function call graph of the software under test, and inputs the test based on this. can be specified.

The concolic execution unit 320 of the concolic unit 300 may receive a test input value from the input designator 310 and execute concolic on the software to be tested. The coverage measurement unit 330 may generate crash information and coverage information while executing concolic. Since descriptions of crash information and coverage information may overlap with descriptions of crash information and coverage information of the fuzzing unit 200, detailed descriptions thereof are omitted.

The coverage analysis unit 400 may allocate resources suitable for the test target software based on the coverage information obtained from the fuzzing unit 200 and the concolic unit 300 . Specifically, the coverage analyzer 400 may perform dynamic resource allocation for each specific part of software by analyzing coverage information.

The coverage analysis unit 400 may include a coverage learning unit 410 , a resource allocation unit 420 and a coverage processing unit 430 .

The coverage analysis unit 400 may collect coverage information generated whenever the purging unit 200 and the concolic unit 300 perform software testing in real time. Specifically, the coverage analysis unit 400 may obtain first coverage information from the fuzzing unit 200 and second coverage information from the concolic unit 300 for each testing of the software to be tested. Acquisition of coverage information may be performed by the coverage learning unit 410 of the coverage analysis unit 400 .

The coverage learning unit 410 may perform machine learning based on the coverage information obtained from the purging unit 200 and the concolic unit 300 . Specifically, the coverage learning unit 410 may learn coverage information using a reinforcement learning algorithm. However, it is not limited thereto, and the coverage learning unit 410 may use a machine learning algorithm other than reinforcement learning.

As reinforcement learning is performed by the coverage learning unit 410, the number of newly found coverages compared to execution time may be output. The coverage learning unit 410 may accumulate rewards based on a reinforcement learning algorithm during software testing. At this time, the coverage learning unit 410 may initialize the accumulated compensation at regular intervals.

The coverage learning unit 410 may calculate a fuzzing score and a concolic score by reward accumulation through reinforcement learning. That is, based on the score calculation by the coverage learning unit 410, the resource allocator 420 may allocate resources to a testing performance with a high score. In this case, the fuzzing score or the concolic score may be calculated based on the number of newly found coverages compared to the execution time.

Based on the model learned by the coverage learning unit 410, the resource allocator 420 may determine how much to allocate to each of fuzzing and concolic execution the resources returned after testing or the total resources. In this case, the resource may be a core of a processor, time, memory, capacity of a storage device, and the like.

Specifically, the resource allocator 420 may set limits on a minimum required resource and a maximum allocation amount for each of fuzzing and concolic execution. The resource allocator 420 may allocate all remaining resources to one of fuzzing and concolic execution or determine a resource allocation ratio for each, based on a reward accumulated through reinforcement learning and a newly obtained reward. In this case, the remaining resources may be unallocated resources or resources returned after testing is completed.

For example, when the fuzzing score of the first part of software is greater than or equal to the concolic score, the resource allocator 420 may allocate resources for fuzzing execution to the first part. Also, for example, if the fuzzing score for the second part of the software is smaller than the concolic score, the resource allocator 420 may allocate resources for concolic execution to the second part. However, the relative comparison of fuzzing scores or concolic scores is not limited, and fuzzing execution or concolic execution of a resource may be determined by an absolute value of a score according to a user's setting.

The hybrid fuzzing apparatus 1000 of the present invention dynamically allocates resources based on real-time coverage information to solve the problem of inefficient resource use in which resources initially allocated for conventional fuzzing and concolic execution are continuously fixed. to be used efficiently.

For example, if there are 5 cores, it is conventionally assumed that 3 cores are allocated to fuzzing execution and 2 cores are allocated to concolic execution at the beginning of testing. Conventionally, three cores were assigned to fuzzing execution and two cores to concolic execution without considering whether or not the software had complex branching statements. Therefore, since the three cores continuously performed fuzzing on source code parts that had complex branching statements and concolic execution was advantageous, it was difficult not only to properly test software but also to test efficiently.

However, even if three cores are initially allocated to fuzzing execution and two cores are allocated to concolic execution, the hybrid fuzzing apparatus 1000 of the present invention may redistribute resources through coverage analysis after one execution. Therefore, not only the two cores initially set for the source code part for which concolic execution is advantageous, but also the remaining cores (cores that are not used or returned after execution) may be capable of concolic execution.

The hybrid purging device 1000 of the present invention may include a crash management unit (not shown). The crash manager may include crash information about software execution from the fuzzing unit 200 or the concolic unit 300 . In this case, the crash information may include whether a crash occurs, a call stack corresponding to the crash, memory information, and an input value that causes the crash.

If an input acquired or mutated from the input unit 100 causes a crash, this may mean that an input value causing a software bug has been found. Accordingly, the crash management unit may record this information and store crash information for analyzing bugs in the software to be tested.

2 is a flowchart of a resource allocation method of a hybrid purging apparatus according to an embodiment.

Referring to FIG. 2 , the resource allocation method according to an embodiment includes initial input designation and resource allocation (S110), fuzzing and concolic execution (S120), coverage information acquisition (S130), coverage It may include performing machine learning on (S140) and allocating resources based on the machine learning result (S150).

The step of designating an initial input and allocating resources (S110) may be a step of designating an initial input and allocating resources for initial test execution for obtaining coverage information. The designated initial input may be a pre-stored input or a randomly generated input.

The processor of the hybrid fuzzing apparatus 1000 may initially allocate initial resources to fuzzing and concolic execution according to user settings. For example, when resources are three processors, initial resources may be allocated so that two processors perform fuzzing and one processor performs concolic execution. At this time, the same input value may be used for fuzzing and concolic execution, or different input values may be used.

The fuzzing and concolic execution step (S120) is a step in which fuzzing and concolic execution are performed on the software to be tested by the fuzzing unit 200 and the concolic unit 300 based on the resources and input values allocated in step S110. can be During the execution process, coverage information may be generated in real time, and the generated coverage information may be transmitted to the coverage analyzer 400 .

Acquiring coverage information (S130) may be a step in which the coverage analysis unit 400 obtains coverage information from the purging unit 200 or the concolic unit 300 in real time.

The step of performing machine learning on the coverage ( S140 ) may be a step in which the coverage learning unit 410 performs machine learning on the coverage information obtained from the fuzzing unit 200 or the concolic unit 300 . Specifically, the coverage learning unit 410 may perform reinforcement learning based on coverage information.

In the step of allocating resources based on the machine learning result value (S150), the resource allocation unit 420 allocates the remaining resources based on the reinforcement learning result of the coverage learning unit 410 to the purging unit 200 or the concolic unit 300. ). In this case, the remaining resources may mean resources not allocated as initial resources in step S110 or resources returned after testing is finished.

The allocated resource may perform fuzzing and concolic execution based on the allocated content (S120). The hybrid fuzzing apparatus 1000 performs dynamic resource allocation by continuously analyzing/learning coverage information for fuzzing and concolic execution.

The processes of steps S120 to S150 may be performed until a user requests termination or resources such as storage capacity are exhausted. In addition, if the user has set an end time or timeout when the fuzzer is executed for the first time, the corresponding process may be terminated according to the setting.

3 is a diagram for explaining coverage information according to an exemplary embodiment.

3(a) is a diagram showing an example of general coverage information, and FIG. 3(b) is a diagram showing simplified coverage information of FIG. 3(a).

Referring to FIG. 3(a), the coverage information may include a part value indicating how many times each part has been executed. As a specific example, if the source code includes B blocks, the software includes B parts. At this time, if the first part of the B parts is executed 10 times, the second part is executed 10 times, and the third part is executed 8 times, the coverage information is 10, which is the first part value corresponding to the first part, A second part value of 8 corresponding to the second part and a third part value of 8 corresponding to the third part may be included.

Referring to FIG. 3(b), coverage information may be simplified to include only part values. The coverage information as shown in FIG. 3(a) has the advantage of being easy for the user to view, but may have disadvantages in terms of size and speed. Specifically, in FIG. 3(a), since there is a lot of information to be recorded in the file, the execution speed slows down, and as the program grows, the size of the file storing the coverage information also increases.

3(b) is an example in which only part values are stored in the coverage information, and through this, the speed can be improved and the size of the file can be reduced. The simplified coverage information of FIG. 3 (b) can be transformed into the form shown in FIG. 3 (a) again through a separate tool that interprets it.

Coverage information may be further simplified by including non-printable characters that are difficult for a user to determine, further from FIG. 3(b), for speed improvement and size reduction. This will be explained with reference to FIG. 4 below.

4 is a diagram for explaining processing of coverage according to an exemplary embodiment.

4(a) is a diagram showing an example of coverage information including non-printable characters, and FIG. 4(b) is a diagram showing an example of coverage information including printable characters generated by processing FIG. 4(a). to be.

Referring to FIG. 4(a), since coverage information is stored in units of bytes or bits for efficient storage, it may include characters that are difficult for humans to read (non-printable characters). Coverage information containing non-printable characters can be very efficient in terms of computing. However, sometimes there may be a case where it is necessary to check coverage information at the user's request. Therefore, it is necessary to process non-printable characters into human-readable characters.

The coverage analysis unit 400 may include a coverage processing unit 430 to process coverage information including non-printable characters. The coverage processing unit 430 may include a tool for analyzing coverage including non-printable characters and a tool for generating printable characters after analysis.

Referring to FIG. 4(b) , the coverage processing unit 430 may process coverage information including non-printable characters to generate coverage information including printable characters. Accordingly, the user can recognize coverage information through the coverage processing unit 430 .

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. Program commands recorded on the medium may be specially designed and configured for the embodiment or may be known and usable to those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic media such as floptical disks. - includes hardware devices specially configured to store and execute program instructions, such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include high-level language codes that can be executed by a computer using an interpreter, as well as machine language codes such as those produced by a compiler. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

As described above, although the embodiments have been described with limited examples and drawings, those skilled in the art can make various modifications and variations from the above description. For example, the described techniques may be performed in an order different from the method described, and/or components of the described system, structure, device, circuit, etc. may be combined or combined in a different form than the method described, or other components may be used. Or even if it is replaced or substituted by equivalents, appropriate results can be achieved.

Therefore, other implementations, other embodiments, and equivalents of the claims are within the scope of the following claims.

Claims (11)

a fuzzing unit configured to perform fuzzing on software;
a concolic unit configured to execute concolic on the software;
a coverage analyzer configured to receive first coverage information on a result of fuzzing execution of the software from the fuzzing unit and second coverage information on a result of concolic execution of the software from the concolic unit;
an input unit providing input values for execution of the software; and
A crash management unit for obtaining crash information about the execution of the software from the fuzzing unit or the concolic unit;
The coverage analysis unit includes a coverage learning unit that performs machine learning based on the first coverage information and the second coverage information;
The coverage analysis unit determines whether to execute fuzzing or concolic on the software based on a result value of the coverage learning unit,
The resulting value includes a fuzzing score and a concolic score for the software,
The first coverage information or the second coverage information includes a plurality of parts included in the software and a plurality of part values corresponding to each of the plurality of parts,
The coverage learning unit calculates a fuzzing score and a concolic score for each of the plurality of parts based on the values of the plurality of parts,
The coverage analysis unit transmits a first signal related to fuzzing execution of the first part to the fuzzing unit when the fuzzing score of the first part of the software is greater than or equal to the concolic score, and A resource allocator for transmitting a second signal related to the concolic execution of the first part to the concolic unit when the fuzzing score is less than the concolic score;
The plurality of parts are distinguished by at least one of functions, lines, blocks, decisions, edges, branches, and conditions of the source code of the software,
The coverage analysis unit includes a coverage processing unit that processes the first coverage information or the second coverage information to output character data recognizable by a user;
When the crash management unit receives a signal about the occurrence of a crash from the fuzzing unit or the concolic unit, storing a call stack corresponding to the occurrence of the crash, memory information, and an input value provided from the input unit
Hybrid purging device. delete delete delete delete delete delete delete delete delete delete

Images