KR102110735B1 - Method and system for re-generating binary for vulnerability detection - Google Patents

Abstract

Provided are a method and a system for binary regeneration for vulnerability search. The method according to an embodiment of the present invention includes a step of applying an automatically generated code to a target binary to search for a vulnerability in a target region in the target binary. Other embodiments of the present invention may further include a step of performing a vulnerability search for the target binary by at least one of fuzzing and symbol execution, and a step of determining the target area based on the vulnerability search result.

Description

METHOD AND SYSTEM FOR RE-GENERATING BINARY FOR VULNERABILITY DETECTION}

The present invention relates to a method and system for regenerating program binaries to search for security vulnerabilities in programs. More specifically, the present invention relates to a method and system for changing a control flow of a target binary in order to search an unexplored region of a target binary for vulnerability detection.

In the process of developing a program, breakpoints are set where there is a possibility of vulnerability in the program's source code, usually by analyzing and verifying the program's source code, or by using a debugging program. When suspended, the vulnerability of the program is analyzed by observing the program's execution environment. However, after the program is developed, especially when a third party who is not the developer of the program analyzes the vulnerability of the program, vulnerability analysis is performed on the program binary in an environment where most of the source code cannot be obtained. Cannot be.

Fuzzing and symbol execution have been mainly used to search for vulnerabilities targeting program binaries. Fuzzing is a method that creates a situation where a program crashes (crashes) by repeatedly generating arbitrary values (test cases) and inputting them into a target program. Symbol execution is a method of specifying the input value of the target program as a symbol and finding a value that can reach the path of the program's vulnerability.

The techniques of fuzzing and symbolic execution each have advantages and disadvantages. Fuzzing can cause a crash at a high rate, but it has a limit to generate vulnerabilities by exploring the deep path of the program. Symbolic execution can find vulnerabilities by searching the deep path of the program, but the larger the program size, the slower the execution speed and the greater the consumption of computing resources. In recent years, in order to solve this problem, approaches in which shallow paths are used to quickly search for vulnerabilities using fuzzing, and path finding is exploited using symbol execution when it is no longer possible, that is, a combination of fuzzing and symbol execution Hybrid purging techniques are being researched and developed.

However, even with hybrid fuzzing, a situation in which a code region (coverage) that can be searched for a vulnerability reaches a limit and coverage is no longer increased frequently occurs. However, methods for designating an undetected region not searched by hybrid fuzzing and allowing additional search are not provided.

U.S. Patent No. 9454659

A technical problem to be solved by some embodiments of the present invention is to provide a method and system for regenerating program binaries for searching for security vulnerabilities in programs.

Another technical problem to be solved by some embodiments of the present invention is to provide a method and system for changing a control flow of a target binary in order to search an unexplored region of a target binary for vulnerability search.

Another technical problem to be solved by some embodiments of the present invention is to provide a method and system for selecting a search target region based on a risk level for each code region.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the following description.

In order to solve the above technical problem, a binary regeneration method for vulnerability search according to an embodiment of the present invention includes automatically generating code for vulnerability search for a target region in a target binary, and the code for the target And applying it to the binary.

In one embodiment, the method further includes performing a vulnerability search for the target binary by at least one of fuzzing and symbol execution, and determining the target area based on the vulnerability search result. can do.

In some embodiments, the determining of the target area may include identifying a plurality of undetected areas that have not been analyzed as a result of the vulnerability search, and determining the plurality of undetected areas based on a risk calculated for each of the plurality of undetected areas. It may include the step of determining the target area.

In some embodiments, the step of determining the target region may further include estimating the risk by static analysis of code generated as a result of disassembling the binary code. In some other embodiments, the determining of the target region may further include calculating the risk based on a comparison result of a list of standard library functions and vulnerable functions called in each of the plurality of undetected regions. In some other embodiments, the step of determining the target area may further include estimating the risk based on a memory management related function called in each of the plurality of undetected areas. In some other embodiments, the step of determining the target area further comprises estimating the risk based on the number and size of local variables defined in each user function including each of the plurality of undetected areas. can do.

In one embodiment, the step of automatically generating the code includes identifying a parameter of a target user function including the target area, and code enabling a fuzzer to purge the parameter. It may include the step of automatically generating a hook function.

In some embodiments, automatically generating the hook function may include generating code that calls a standard input function based on the parameter. In addition, the step of automatically generating the hook function may further include generating code that calls the target user function with the parameter.

In some other embodiments, automatically generating the hook function may include generating a header of the hook function based on at least some of signature information of the target user function. In some other embodiments, automatically generating the hook function includes generating a body of the hook function based on at least some of the target user function signature information and an address of the target user function. can do. In some other embodiments, applying the code to the target binary includes: generating a binary code segment corresponding to the hook function, inserting the binary code segment into the target binary, and the target The method may further include replacing a command that calls the target user function in a binary with a command that calls the hook function.

In order to solve the above technical problem, a binary regeneration system for vulnerability search according to another embodiment of the present invention includes a control flow change code generation unit and a binary regeneration unit. At this time, the control flow change code generator generates a hook function code based on the target user function signature, and builds the hook function code into a binary code segment. In addition, the binary regeneration unit inserts the binary code segment into a regeneration target binary, and replaces a command that calls the target user function in the regeneration target binary with a command that calls the hook function.

In one embodiment, the control flow change code generation unit further includes a DB, and the control flow change code generation unit generates a hook function corresponding to the target user function signature using a code template stored in the DB. Can be.

In one embodiment, the hook function may include code that allows a fuzzer to fuzz the parameters of the target user function. In some embodiments, the hook function may include code that calls a standard input function on the parameter.

1 is a view for explaining a binary vulnerability search system according to an embodiment of the present invention.
FIG. 2 is a diagram for explaining the operation of the risk analysis module of the system described in FIG. 1.
3A and 3B are diagrams illustrating exemplary vulnerability functions and memory management functions, respectively, that the risk analysis module described in FIG. 2 can refer to.
4A and 4B are diagrams each showing assembly instructions and standard library functions that the risk analysis module described in FIG. 2 can refer to for variable type inference.
5 is a view for explaining the operation of the binary regeneration module of the system described in FIG. 1.
6A is a diagram for explaining a control flow in which an additional search target user function is executed in a target binary, and FIG. 6B is a new control flow in which a user function is executed in a binary regenerated by the method according to an embodiment of the present invention It is a figure for illustration.
FIG. 7A is a diagram for describing an exemplary hook function generated by the binary regeneration module described in FIG. 5, and FIG. 7B is a diagram for illustrating an exemplary code template that can be used to generate a hook function.
8 is a diagram illustrating a binary regeneration system according to another embodiment of the present invention.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. Advantages and features of the present invention, and methods for achieving them will be clarified with reference to embodiments described below in detail together with the accompanying drawings. However, the technical spirit of the present invention is not limited to the following embodiments, but may be implemented in various different forms, and only the following embodiments make the technical spirit of the present invention complete and in the technical field to which the present invention pertains. It is provided to fully inform the person of ordinary skill in the scope of the present invention, and the technical spirit of the present invention is only defined by the scope of the claims.

It should be noted that in adding reference numerals to the components of each drawing, the same components have the same reference numerals as possible even though they are displayed on different drawings. In addition, in describing the present invention, when it is determined that detailed descriptions of related well-known structures or functions may obscure the subject matter of the present invention, detailed descriptions thereof will be omitted.

Unless otherwise defined, all terms (including technical and scientific terms) used in this specification may be used as meanings commonly understood by those skilled in the art to which the present invention pertains. In addition, terms defined in the commonly used dictionary are not ideally or excessively interpreted unless specifically defined. The terminology used herein is for describing the embodiments and is not intended to limit the present invention. In the present specification, the singular form also includes the plural form unless otherwise specified in the phrase.

In addition, in describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are only for distinguishing the component from other components, and the nature, order, or order of the component is not limited by the term. When a component is described as being "connected", "coupled" or "connected" to another component, that component may be directly connected to or connected to the other component, but another component between each component It should be understood that elements may be "connected", "coupled" or "connected".

Hereinafter, some embodiments of the present invention will be described in detail according to the accompanying drawings.

1 is a view for explaining a binary vulnerability search system 100 according to an embodiment of the present invention.

The binary vulnerability search system 100 according to the present embodiment includes a static analysis module 110, a risk analysis module 120, a vulnerability search module 130, and a binary regeneration module 140.

The system 100 receives the vulnerability search target binary 10, performs vulnerability search, and outputs crash information 30 generated in the process. The crash information 30 may be used for vulnerability analysis of the target binary 10. In addition, as a result of performing the vulnerability search, the system 100 generates binaries 20 having changed the control flow so as to additionally search undiscovered areas, and utilizes the vulnerability search.

The static analysis module 110 is configured to statically analyze the target binary 10 without executing the target binary 10. The static analysis module 110 disassembles the target binary 10 configured in machine language, and generates disassembled code. At this time, the static analysis module 110 may generate disassembled code, for example, by using a program such as'objdump'. In addition, the static analysis module 110 may analyze the disassembled code and extract a list of standard library functions that are called in the target binary 10 and user functions that call the standard library functions. have. The static analysis module 110 may provide the disassembly code and function call related information to the risk analysis module 120.

The risk analysis module 120 receives the disassembly code and function call related information from the static analysis module 110 and calculates the risk for the regions of the target binary 10. The risk analysis module 120 may allow the risk information to be used in the vulnerability search process of the target binary 10.

More specifically, the risk analysis module 120 may infer the number, type, and memory allocation range of variables used in the target binary 10 by analyzing the disassembly code, and based on this, the target binary 10 ) To estimate the risk for the domains. In addition, the risk analysis module 120 may calculate the risk for the regions of the target binary 10 based on the information related to the function call. The detailed method of calculating the risk will be described later with reference to FIGS. 2 and 3.

The risk analysis module 120 may provide the calculated risk information to the vulnerability search module 130 and the binary regeneration module 140. On the other hand, according to an embodiment, it is noted that the static analysis module 110 and the risk analysis module 120 described above may be implemented as one module.

The vulnerability search module 130 is configured to perform vulnerability search for the target binary 10. The vulnerability search module 130 performs vulnerability search using the risk information provided from the risk analysis module 120. The vulnerability search module 130 may include a fuzzing engine 131 and a symbol execution engine 132. The vulnerability search module 130 may selectively perform fuzzing and symbol execution to search for the vulnerability of the target binary 10. Vulnerability search module 130 outputs information 30 on the crash that occurred during the vulnerability search process. In addition, the vulnerability search module 130 may provide the binary regeneration module 140 with information on the area where the search is completed (analyzed) in the process of searching for the vulnerability of the target binary 10.

On the other hand, the vulnerability search module 120 receives the binary 20 regenerated by the binary regeneration module 140, and can be used to search for additional vulnerabilities for the target binary 10.

The binary regeneration module 140 is a module that changes the control flow of the target binary 10 so that the vulnerability search module 130 can additionally search areas of the target binary 10 that have not been searched (analyzed).

The binary regeneration module 140 receives information about the searched area from the vulnerability search module 130 and identifies areas not searched for in the target binary 10 ('undetected areas'). In some other embodiments, the binary regeneration module 140 may be provided with information about undetected areas from the vulnerability search module 130. In this case, the vulnerability search module 130 performs an operation of identifying an undetected area.

The binary regeneration module 140 may receive risk information from the risk analysis module 120 and determine an additional search target area among a plurality of undetected areas based on the risk information. For example, an additional search target region may be selected by giving priority to a region of high risk among a plurality of unexplored regions.

The binary regeneration module 140 applies the code for changing the control flow to the target binary 10 so that the vulnerability search module 130 can search the determined additional search target area, the binary 20 in which the control flow is changed. Can generate The binary 20 is provided to the vulnerability search module 130 and can be used for additional vulnerability search.

The above-described operations of the binary regeneration module 140 will be described later with reference to FIGS. 5 to 7.

Hereinafter, the operation of the risk analysis module 120 will be described in more detail with reference to FIGS. 2 to 4. The risk analysis module 120 receives the disassembly code for the target binary 10 from the static analysis module 110 and information on standard library functions used in the target binary 10, so that the target binary 10 Calculate the risk for the areas of.

The risk analysis module 120 calculates the risk by synthesizing the risk calculated based on the call function (see steps S210 to S220) and the risk calculated based on the number and size of the inferred local variables (see steps S230 to S240). It can be done (step S250).

First, the process of estimating the risk based on the calling function will be described.

In step S210 of FIG. 2, from the target binary 10, code regions that call vulnerable functions and/or memory management-related functions among standard library functions, such as user functions, are identified.

Here, the weak function may be exemplary functions illustrated in FIG. 3A. The vulnerable function may include functions such as scanf, strcpy, and memcpy, which can cause buffer overflow, functions such as format string related functions printf, fprintf, snprintf, and strtok. Differential risks may be assigned to the vulnerable functions. For example, functions such as scanf and snprintf may be assigned a risk of 0.5, and functions such as strcpy and syslog may be assigned a risk of 1.0. Functions with a risk of 1.0 may mean functions that should be banned.

Also, the memory management related functions may be exemplary functions illustrated in FIG. 3B. The memory management-related functions illustrated in FIG. 3B may not be prohibited, but are functions having a possibility of generating a memory-related vulnerability. Therefore, an appropriate risk level is assigned, so that an appropriate vulnerability search can be performed.

In step S220, a risk is calculated for user functions that call the vulnerable functions and/or memory management-related functions. The risk may be calculated by summing the risks assigned to the functions called by each user function.

So far, in steps S210 to S220, the process of calculating the risk based on the standard library function called by each user function has been described. Hereinafter, a process (steps S230 to S240) of calculating a risk based on the number and size of variables deduced for the local variables of each user function will be described.

In step S230, local variables defined in a code region or a user function of the target binary 10 are identified, and a variable type for the variables is inferred. The variable type can be inferred by analyzing the disassembly code of the target binary 10.

In some embodiments, the variable type may be inferred with reference to assembly instructions whose variables are operands. 4A shows example assembly instructions that can be referenced to infer the type of a variable.

For example, in the first item (No. 1) of FIG. 4A, the'movs' instruction sets the string of the memory address designated by the first operand (E)SI register and the memory designated by the second operand (E)DI register. This is a command to copy to an address. Therefore, it can be inferred that the type of the variable that stores data in the address indicated by the (E)SI register before the instruction and the variable that reads the data from the address indicated by the (E)DI register after the instruction is a string type.

As another example, the'fstp' instruction, which is the 24th item (No. 24) of FIG. 4A, is an instruction to copy data stored in the FPU stack register to the first operand (memory address or other register) and before or after the instruction. It can be inferred that the variable storing the data is of type'float' or'double'.

In some other embodiments, the variable type may be called with the variable as a parameter or inferred by reference to a standard library function that stores the return value in the variable. 4B shows example functions that can be referenced to infer the type of a variable.

For example, in the first item (No. 1) of FIG. 4B, the'strcpy' function has a type of a first parameter and a second parameter of a string pointer type, and a return value of a string pointer type. Therefore, it can be inferred that the type of the variable used as a parameter of the strcpy function or used to store the return value is a string pointer type.

As another example, the'itoa' function, which is the 49th item (No. 49) of FIG. 4B, is a function that converts an integer of type int to a string, the first parameter is of type'int', and the second parameter is of string. It is of type pointer and the third parameter is of type'int'. Therefore, the types of variables used as the first to third parameters of the'itoa' function can be inferred.

Step S240 will be described again with reference to FIG. 2. In step S240, the risk of the user function may be calculated based on the number and size of local variables defined and used in each of the user functions. In some embodiments, the risk of the user function may be calculated in proportion to the inferred number and size of local variables defined in the user function. For example, the risk of the user function may be calculated by summing the number of local variables multiplied by the first weight and the size of the local variables multiplied by the second weight. The first weight and the second weight may be appropriately selected in various embodiments.

So far, in steps S230 to S240, a process of estimating a risk based on the number and size of variables deduced for local variables of each user function has been described.

In step S250, the risk calculated based on the call function in step S220 and the risk calculated based on the number and size of variables deduced in step S240 may be combined to calculate the overall risk for each user function.

As described above, information on the risk of each user function calculated by the risk analysis module 120 is provided to the vulnerability search module 130 and used for vulnerability search. In addition, information on the risk calculated by the risk analysis module 120 is provided to the binary regeneration module 140, and may be used to select an additional search target area among undetected areas.

Hereinafter, the operation of the binary regeneration module 140 will be described in more detail with reference to FIGS. 5 to 7. The binary regeneration module 140 changes the control flow of the target binary 10 so that the vulnerability search module 130 can additionally search areas of the target binary 10 that have not been searched (analyzed).

First, it will be described with reference to FIG. 5. In step S510, an unexplored region in the target binary 10 is identified based on information on the region where the vulnerability search module 130 has completed searching for the target binary 10. In some other embodiments, identification information regarding the undetected area is provided from the vulnerability search module 130 and may be used in a process described later.

In some embodiments, the undetected area may be an area in which the control flow has not passed in the process of the vulnerability search module 130 performing vulnerability search on the target binary 10. For example, referring to FIG. 6A, the control flow in the process of searching for vulnerabilities is main#1(601), main#2(602), user#1(621), user#2(622), user#3 In the order of 623, user#5 625, main#3 603, and main#5 605, the undetected areas are main#4 604 and user#4 624.

In step S520, the risk for user functions including respective undetected areas is identified. In the example shown in FIG. 6A, the user function including the undetected area 624 is the UserFunction 620. The risk information provided from the risk calculation module 120 may be used to identify risks for user functions. Based on the risk information, a user function to be searched is selected. For example, among the plurality of user functions including a plurality of undetected areas, the user function to be searched may be selected by giving priority to the user function having the highest risk.

In step S530, the number and type of parameters of the user function to be searched are analyzed. The number and type of the parameters may be analyzed based on disassembly code provided by the static analysis module 110. For example, the number of parameters of the user function to be searched for may be identified by identifying the number of instructions to push data onto the stack before the assembly instruction that calls the user function to search for. In addition, the types of the parameters may be identified by various methods including the variable type inference method described with reference to FIGS. 4A and 4B in connection with step S230 of FIG. 2.

In step S540, a hook function is automatically generated to change the control flow of the target binary 10 so that the unexplored region can be searched.

Referring back to FIG. 6A, the control flow shown in FIG. 6A is controlled from the branch statement of main#1 (601) to main#2 (602) in the process of searching for vulnerabilities by, for example, fuzzing. It implies that only the input values to proceed are provided, and only the input values to control flow from user#1 621 to the user#2 622 are provided. That is, in the control flow shown in FIG. 6A, main#4 604 and user#4 624 are searched by input values generated by the vulnerability search module 130 during a vulnerability search process for a given time. Implies that it could not.

Referring to FIG. 6B, the hook function intercepts the control flow executed by the search target user function 620 by main#2 602, performs additional operations, and then performs the user function. It is a function 640 that calls 620.

In some embodiments, the hook function may include a command that allows the fuzzing engine 131 to fetch parameters of the UserFunction 620, which is a user function including the undetected area user#4 624. By allowing the parameters of the user function UserFunction 620 to be searched to be directly fuzzed, the control flow during vulnerability search of the binary 10 is transferred from the branch statement of user#1(621) to user#4(624). You can expect to be satisfied with the conditions that make it happen.

In some embodiments, the hook function may include a command that calls a standard input function with the parameters in order to allow the parameters of the user function to be searched to be fuzzed. As a result, the fuzzing engine 131 performing fuzzing for standard input can input arbitrary values to the parameter.

In some embodiments, the hook function includes a command to call the user function using the parameters after the command to call the standard input function. As a result, parameters fuzzed by the fuzzing engine 131 in the hook function may be transmitted as parameters of the user function.

Hereinafter, an exemplary implementation of the hook function described so far with respect to step S540 will be described with reference to FIG. 7A. In FIG. 7A, an exemplary hook function for a user function to be searched having a parameter of type'integer' ('parameter01') and a parameter of type'double' ('parameter02') is described in pseudocode.

The example hook function of FIG. 7A reads data of the size of the first parameter ('sizeof(int)') from standard input ('STDIN') to the memory address of the first parameter ('parameter01'). It contains a command to save ('read'). In addition, the hook function reads the data of the size of the second parameter ('sizeof(double)') from standard input ('STDIN') and stores it in the memory address of the second parameter ('parameter02'). ('read'). Accordingly, the fuzzing engine 131 performing fuzzing for standard input may input arbitrary values to the first parameter ('parameter01') and the second parameter ('parameter02').

Subsequently, the exemplary hook function of FIG. 7A calls the user function to be searched ('0x080484bb' expressed in the memory address of the function in FIG. 7A) using the first and second parameters as parameters. Accordingly, the first parameter ('parameter01') and the second parameter ('parameter02') fuzzed by the fuzzing engine 131 may be transmitted as parameters of the user function to be searched.

The pseudo-code of FIG. 7A is only an exemplary pseudo-code for helping to understand the principle of operation of the hook function according to some embodiments of the present invention, and the hook function of the present invention is not necessarily implemented with such contents. Be careful.

Meanwhile, in some embodiments, the hook function may be automatically generated by the binary regeneration module 140. Specifically, the hook function may be automatically generated based on the signature information of the user function to be searched (return type of user function, number and type of parameters, calling convention, symbol name, etc.) and the memory address of the user function to be searched. have.

For example, the hook function of FIG. 7A may be automatically generated by substituting the following properties into a code template as shown in FIG. 7B for a user function having the following properties.

(1) The calling convention is'cdecl'

(2) Return type is'void'

(3) Two parameters ('parameter01' and'parameter02')

(4) The parameter types are'int' and'double', respectively.

(5) Memory address is '0x080484bb'

That is, the hook function may be automatically generated based on the signature information (return type, number and type of parameters, calling convention, symbol name, etc.) and the memory address of the user function to be searched.

In some other embodiments, hook functions may be automatically generated based on pre-generated code templates for a common set of properties of user functions that are frequently used. The templates may be stored in a DB (not shown), for example, and used by the binary regeneration module 140.

Referring to FIG. 5 again, a process in which the hook function is inserted (patched) into the target binary 10 after the hook function generation step (S540) will be described.

In step S550, the hook function generated in step S540 is built into a binary code segment and may be inserted (patched) into the target binary 10. In addition, the command to call the search target user function in the target binary 10 is now replaced with a command to call the hook function. Accordingly, the control flow for calling the user function to be searched in the target binary 10 may be changed to the control flow for calling the user function through the hook function. As described above, the regenerated binary 20, which is the result of re-generating the target binary 10, is provided to the vulnerability search module 130 and can be used to search for a vulnerability in the undetected area.

FIG. 6B is a diagram showing an exemplary state of a result in which the control flow of the target binary 10 shown in 6A is changed by steps S510 to S550. In FIG. 6A, which shows the control flow of the target binary 10, the UserFunction 620 is called from main#2 602 to move the control flow to user#1 621, while the hook function is inserted and regenerated. In FIG. 6B showing the control flow of the binary 20, the hook function 640, which is a hook function from main#2 602, is called, and the control flow is moved to new#1 641, and new#1 641 again. ), it can be understood that the control flow moves to user#1 621 by calling UserFunction 620. In addition, it can be understood that, as described above, the values of parameters transmitted to the UserFunction 620 may be purged by commands executed in the hook function. In addition, it can be expected that the condition to proceed to the user#4 624 from the branch statement of the user#1 621 of the UserFunction 620 is satisfied by various input values input by the fuzzing.

So far, the operation of the binary regeneration module 140 of the vulnerability search system 100 has been described with reference to FIGS. 5 to 7. As described above, the binary regeneration module 140 selects the user function to be searched based on the risk, among the user functions including the undetected areas of the target binary 10, and further adds the unexplored area of the selected user function. Regenerate the binary 20 that has changed the control flow so that it can be searched. The regenerated binary 20 is provided to the vulnerability search module 130 and can be used to search for a vulnerability in the undetected area.

Hereinafter, a binary regeneration system 800 according to another embodiment of the present invention will be described with reference to FIG. 8. In interpreting the configurations of the binary regeneration system 800 according to the present embodiment, embodiments described with reference to FIGS. 1 to 7 may be reflected.

The binary regeneration system 800 receives the target binary 10 and generates the binary 20 with the control flow changed. Although not shown, binary regeneration of information about the target user function (the function's return type, the number and type of parameters, the calling convention, the function signature information such as the symbol name, the address of the function, etc.) that is the purpose of changing the control flow It can be provided as an input to the system 800. Based on the above information, the binary regeneration system 800 changes the control flow of the target binary 10 having a control flow as shown in FIG. 6A, for example, to generate the regenerated binary 20 having a control flow as shown in FIG. 6B. Can be created.

The binary regeneration system 800 includes a control flow change code generation unit 820 and a binary regeneration unit 840.

In some embodiments, the control flow change code generation unit 820 may include a hook function generation unit 822, a code template DB 824, and a code segment generation unit 826.

The hook function generator 822 automatically generates a hook function code for a target user function (not shown) in the target binary 10.

In some embodiments, the hook function for the target user function includes code that allows a fuzzer to fuzz the parameters of the target user function. For example, the hook function may include a command that calls a standard input function with parameters of the target user function. For more detailed operation of the hook function generator 822, the contents described above with reference to step S540 of FIG. 5 may be referred to.

In some embodiments, a hook function code template stored in the hook function generator 822 code template DB 824 may be used to automatically generate a hook function code for a target user function. More specifically, the hook function generator 822 substitutes at least a part of the target user function signature (return type, number and type of parameters, calling convention, symbol name, etc.) into the code template to generate the hook function code. Can be generated automatically. A detailed method of generating the hook function code using the code template may be a reference to the contents described above with reference to FIG. 7B in connection with step S540 of FIG. 5.

The code template DB 824 may store code templates for generating the header of the hook function and the body of the hook function. The code templates stored in the code template DB 824 can be used by the hook function generator 822 to automatically generate hook function codes for various user functions having various return types, parameters, and calling conventions.

The code segment generator 826 inserts the hook function code generated by the hook function generator 822 into the target binary 10 so that the operation of the hook function can be applied to the target binary 10, so that the hook function code is generated. Build with binary code segments (not shown).

The binary regenerating unit 840 includes a code segment injection unit 842 and an instruction correcting unit 844.

The code segment injection unit 842 is configured to insert and patch the binary code segment of the hook function generated by the control flow change code generation unit 820 into the target binary 10. The code segment injection unit 842 secures a space in the target binary 10 where the binary code segment can be inserted, and then inserts the binary code segment in the secured space.

The command corrector 844 utilizes the address information (not shown) of the command to call the target user function in the target binary 10, and the command to call the target user function is a command to call the hook function Replace.

The binary regenerating unit 840 outputs the regenerated binary 20 so that the control flow of the target binary 10 is changed by the operation of the code segment injection unit 842 and the instruction correction unit 844 described above.

As described above, the binary 20 regenerated by the binary regeneration system 800 may be used to expand the coverage of binary vulnerability search based on hybrid fuzzing.

The embodiments of the present invention described so far with reference to FIGS. 1 to 8 may be embodied as computer readable codes on a computer readable medium. The computer-readable recording medium may be, for example, a removable recording medium (CD, DVD, Blu-ray Disc, USB storage device, removable hard disk), or a fixed recording medium (ROM, RAM, computer-equipped hard disk). Can be. The computer program recorded on the computer-readable recording medium may be transmitted to another computing device through a network such as the Internet and installed on the other computing device, and thus used on the other computing device.

In the above, even if all the components constituting the embodiments of the present invention are described as being combined or operated as one, the technical spirit of the present invention is not necessarily limited to these embodiments. That is, within the object scope of the present invention, all of the components may be selectively combined and operated.

Although the operations in the drawings are shown in a specific order, it should not be understood that the operations must be performed in a specific order or in a sequential order, or that all the illustrated actions must be executed to obtain a desired result. In certain situations, multitasking and parallel processing may be advantageous. Moreover, the separation of various configurations in the above-described embodiments should not be understood as such separation is necessary, and the described program components and systems may generally be integrated together into a single software product or packaged into multiple software products. It should be understood that there is.

The embodiments of the present invention have been described above with reference to the accompanying drawings, but those of ordinary skill in the art to which the present invention pertains may also practice other specific forms without changing the technical spirit or essential features of the present invention. You can understand that it can be. Therefore, it should be understood that the above-described embodiments are illustrative in all respects and not restrictive. The scope of protection of the present invention should be interpreted by the claims below, and all technical spirits within the equivalent ranges should be interpreted as being included in the scope of the technical spirit defined by the present invention.

Claims (17)

A method performed on a computing device,
Performing a vulnerability search for the target binary;
Identifying a plurality of undetected areas that have not been analyzed as a result of performing the vulnerability search;
Determining a target area among the plurality of undetected areas based on a risk calculated for each of the plurality of undetected areas;
Automatically generating code for vulnerability search for the target region in the target binary; And
Applying the code to the target binary
Containing,
How to regenerate binaries to search for vulnerabilities. delete delete According to claim 1,
Determining the target area,
Comprising the step of calculating the risk by static analysis of the code generated by disassembling the binary code,
How to regenerate binaries to search for vulnerabilities. According to claim 1,
Determining the target area,
Comprising the step of calculating the risk based on the comparison result of the standard library function and the vulnerable function list called in each of the plurality of undetected areas,
How to regenerate binaries to search for vulnerabilities. According to claim 1,
Determining the target area,
Comprising the step of calculating the risk based on the memory management-related functions called in each of the plurality of undetected areas,
How to regenerate binaries to search for vulnerabilities. According to claim 1,
Determining the target area,
The method further includes estimating the risk based on the number and size of local variables defined in each user function including each of the plurality of undetected areas.
How to regenerate binaries to search for vulnerabilities. According to claim 1,
The step of automatically generating the code,
Identifying a parameter of a target user function that includes the target area; And
Automatically generating a hook function that includes code that allows a fuzzer to fetch the parameters.
Containing,
How to regenerate binaries to search for vulnerabilities. The method of claim 8,
The step of automatically generating the hook function,
Generating code that calls a standard input function on the parameters,
How to regenerate binaries to search for vulnerabilities. The method of claim 9,
The step of automatically generating the hook function,
Further comprising generating code to call the target user function with the parameters,
How to regenerate binaries to search for vulnerabilities. The method of claim 8,
The step of automatically generating the hook function,
And generating a header of the hook function based on at least some of signature information of the target user function.
How to regenerate binaries to search for vulnerabilities. The method of claim 8,
The step of automatically generating the hook function,
And generating a body of the hook function based on at least a part of signature information of the target user function and the address of the target user function,
How to regenerate binaries to search for vulnerabilities. The method of claim 8,
Applying the code to the target binary,
Generating a binary code segment corresponding to the hook function;
Inserting the binary code segment into the target binary; And
Replacing a command that calls the target user function in the target binary with a command that calls the hook function
Further comprising,
How to regenerate binaries to search for vulnerabilities. A control flow change code generator; And
Binary Regeneration Department
Including,
The control flow change code generation unit,
A target user function is determined among the plurality of unexplored areas based on the risk calculated for each of the unexplored areas that are not analyzed as a result of performing a vulnerability search for the regenerated target binary,
Generate a hook function code based on the signature of the target user function,
Build the hook function code into a binary code segment,
The binary regeneration unit,
Inserting the binary code segment into a binary to be regenerated,
Replacing the command that calls the target user function in the regeneration target binary with a command that calls the hook function,
Binary regeneration system for vulnerability search. The method of claim 14,
The control flow change code generation unit further includes a DB,
The control flow change code generation unit generates a hook function corresponding to the target user function signature using the code template stored in the DB,
Binary regeneration system for vulnerability search. The method of claim 14,
The hook function includes code that allows a fuzzer to fuzz the parameters of the target user function,
Binary regeneration system for vulnerability search. The method of claim 16,
The hook function includes code that calls a standard input function based on the parameter,
Binary regeneration system for vulnerability search.

Images