KR101741131B1

KR101741131B1 - Apparatus and method for analysing crash, and computer-readable medium storing program for method thereof

Info

Publication number: KR101741131B1
Application number: KR1020160024583A
Authority: KR
Inventors: 조은선; 전현구; 목성균; 엄기진; 류재철
Original assignee: 충남대학교산학협력단
Priority date: 2016-02-29
Filing date: 2016-02-29
Publication date: 2017-05-29

Abstract

Provided is a device for analyzing a danger degree of a crash. The device of the present invention comprises: a disassembler for disassembling a binary program to be converted into a machine language, and obtaining flow control information from the machine language; an intermediate language converter for converting the machine language into an intermediate language; a crash generator for generating multiple crashes by a crash causing program produced in advance to intentionally cause a crash; and a crash danger degree analyzer for analyzing a danger degree of a corresponding crash by statically analyzing all commands affected by each of commands which have generated the crashes from commands converted into the intermediate language.

Description

TECHNICAL FIELD [0001] The present invention relates to a crash risk analysis apparatus and method, and a computer readable recording medium on which a program for executing the crash risk analysis apparatus is recorded.

The present invention relates to a crash analysis apparatus and a method thereof, and more particularly, to a crash analysis apparatus and method for determining a risk of a vulnerability occurring when a crash occurs by statically analyzing a program.

Recently, the use of mobile devices such as smart phones and tablet PCs has increased dramatically. In addition, damage from mobile security infringement such as personal information leakage is increasing rapidly. Recent reports on mobile security threats have increased infringement by malicious code on mobile devices to a degree comparable to PC environments. These security threats generally exploit program vulnerabilities and lead to malicious behavior. Therefore, in order to appropriately respond to these security threats, it is required to develop an analysis technique for detecting vulnerability of mobile code.

For mobile code analysis, some constraints must be considered. First, since mobile applications are generally provided to users as binary executables, analysis techniques targeting binary code are needed. And because most mobile devices use ARM processors, which consume less power than x86 processors, analysis techniques for ARM binary code should be studied. However, compared to x86 binary code, analysis research on ARM binary code is relatively inactive, and there are not many analysis tools suitable for ARM binary code analysis. Therefore, we need a static analyzer for ARM binary code.

Korean Patent Laid-Open Publication No. 10-2014-52200 (System and Method for Application Verification, published by SKK Planet Co., Ltd., May 31, 2014)

Accordingly, the present invention provides a crash analysis apparatus and method for determining a risk of a vulnerability occurring when a binary program is converted into an intermediate language and then a static analysis is performed on the binary program.

The present invention also provides a crash analysis apparatus and method for automatically analyzing a binary program according to an attack pattern of a hacker to detect the possibility of an attack by a hacker.

In addition, the present invention provides a crash analysis apparatus and method for improving the accuracy of a memory analysis result by analyzing a memory in the case of a storage-related command.

The present invention also provides a computer-readable recording medium on which a program for executing a method for automatically analyzing the crash is recorded.

In order to achieve the above object, a crash risk analysis apparatus provided by the present invention comprises a disassembler for disassembling a binary program into a machine language, and obtaining control flow information from the machine language; An intermediate language converter for converting the machine language into an intermediate language; A crash generator for generating a plurality of crashes by a crash-inducing program previously created to intentionally cause a crash; And a crash risk analyzer for statically analyzing all the commands affected by each of the instructions that have generated the plurality of crashes among the instructions converted into the intermediate language and analyzing the risk of the corresponding crash.

Advantageously, the risk analyzer identifies the arrival points of the instructions for each of the instructions that generated the plurality of crashes, finds the point at which the instruction is actually used among the reach points, It can be derived as a graph.

Preferably, the risk analyzer identifies a command that can transfer control of the program from the usage point graph, and then, if the command that generated the crash is a store series command or a branch series command, The possibility can be analyzed.

If the target address of the branch sequence command is influenced by the command that generated the crash, the risk analyzer may determine that the crash is attackable.

Preferably, the risk analyzer further performs a memory analysis process of subdividing a memory region when the instruction that generated the crash is a store sequence command, and analyzing a region that can be stored in the register and the memory for each instruction .

Preferably, the risk analyzer may refine the stack memory area after dividing the heap memory area and the stack memory area to perform the memory analysis process.

Preferably, the risk analyzer detects a heap memory using the fact that the return value is an address of a heap area allocated after the dynamic memory allocation function call, and uses the initialized register information at the function start point To detect a stack memory.

According to another aspect of the present invention, there is provided a crash risk analysis method comprising: disassembling a binary program into a machine language; Obtaining control flow information from the machine language; Converting the machine language into an intermediate language; Generating a plurality of crashes by a crash-inducing program previously created to intentionally cause a crash; And statically analyzing all the commands affected by each of the plurality of commands generated in the intermediate language and analyzing the risk of the corresponding crash.

Advantageously, said risk analysis step comprises the steps of: identifying the arrival points of said instructions for each of said instructions that have generated said plurality of crashes; Finding a point at which the corresponding instruction is actually used among the reaching points and deriving the result as a usage point graph; And analyzing an attack possibility by identifying an instruction that can transfer control of the program from the use point graph.

Preferably, the attack possibility analysis step may analyze an attack possibility when the command that generated the crash is a store series command or a branch series command.

Preferably, if the target address of the branch sequence command is influenced by the instruction that generated the crash, the attack possibility analysis step may determine that the crash is attackable.

Preferably, the risk analysis step further includes a memory analysis step of subdividing the memory area when the instruction causing the crash is a store sequence command, and analyzing a region that can be stored in the register and the memory for each instruction can do.

Preferably, the memory analysis step may include: dividing a heap memory area and a stack memory area; And elaborating the stack memory region.

According to another aspect of the present invention, there is provided a computer-readable recording medium having recorded thereon a program for performing one of the methods described above.

The present invention enables a crash analysis for a binary program by statically analyzing a program based on an intermediate language. Therefore, it is possible to automatically determine the risk of a vulnerability if a binary program crash occurs. In particular, when a crash occurs in a binary program, the present invention can automatically prevent a hacker from analyzing a binary program according to an attack pattern of the hackers, thereby determining the possibility of an attack by the hacker. As a result, the present invention has an advantage of effectively reducing invasion of malicious code for mobile devices. In addition, the present invention has the advantage of increasing the accuracy of the memory analysis result by analyzing the memory in the case of the storage related command.

1 is a schematic block diagram of an apparatus for analyzing a crash risk according to an embodiment of the present invention.
2 is a schematic flowchart of a crash risk analysis method according to an embodiment of the present invention.
3 is a schematic flowchart of the risk analysis process of FIG.
FIG. 4 is a diagram for explaining the memory analysis process of FIG. 3. Referring to FIG.
5 is a view for explaining the arrival point identification process of FIG.
FIG. 6 is a view for explaining an actual use point derivation process of FIG. 3. FIG.
FIG. 7 is a schematic processing flowchart of the memory analysis process of FIG. 3. FIG.
8 is a view for explaining a memory area dividing process of FIG.
FIGS. 9 to 11 are views for explaining the stack memory area refinement process of FIG.
12 is a diagram illustrating an example of a screen outputting a memory area analysis result according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings, which will be described in detail to facilitate a person skilled in the art to which the present invention pertains. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. In order to clearly illustrate the present invention, parts not related to the description are omitted, and like parts are denoted by similar reference numerals throughout the specification. And a detailed description thereof will be omitted to omit descriptions of portions that can be readily understood by those skilled in the art.

Throughout the specification and claims, where a section includes a constituent, it does not exclude other elements unless specifically stated otherwise, but may include other elements.

1 is a schematic block diagram of an apparatus for analyzing a crash risk according to an embodiment of the present invention. Referring to FIG. 1, an apparatus 100 for analyzing a crash risk according to an exemplary embodiment of the present invention includes a disassembler 110, an intermediate language converter 120, a crash generator 130, and a crash risk analyzer 140.

A disassembler 110 converts the input data into a machine language. In particular, the disassembler 110 disassembles a binary program (for example, an ARM binary program), which is a crash hazard information analysis target, into a machine language, and generates control flow information ).

The Abstract Interpretation Framework 120 converts a machine language output from the disassembler 110 into an intermediate language. For example, the intermediate language converter 120 converts the machine language into an intermediate language called REIL (Reverse Engineering Intermediate Language). In this case, converting the machine language into an intermediate language as described above is intended to provide convenience of static analysis by reducing the number of commands in excess. For example, if about 300 ARM instructions are entered, it can be reduced to 17 when converted to an intermediate language called REIL.

The crash generator 130 intentionally causes a crash. To this end, the crash generator 130 incorporates a pre-built crash-inducing program for intentionally generating a plurality of crashes, and generates a plurality of crashes by the crash-inducing program (for example, a Fuzzer program). In general, hackers use a crash-inducing program such as Fuzzer to generate a lot of cranks in the target program, analyze the crashes one by one, and then, if there is an attack possibility, It is intended to reverse the attack pattern of creating and attacking. That is, it is for automatically analyzing the attack possibility (that is, the risk level) for each of the deliberately generated crashes.

The crash risk analyzer 140 analyzes the risk of the corresponding crash based on the instructions converted into the intermediate language in the intermediate language converter 120 and the crash information generated in the crash generator 130. That is, the crash risk analyzer 140 statically analyzes all the commands affected by each of the instructions that have generated the plurality of crashes among the instructions converted into the intermediate language, and analyzes the risk of the corresponding crash. To this end, the risk analyzer 140 identifies the arriving points of the instructions for each of the instructions that generated the plurality of crashes, and determines the point at which the corresponding instruction is actually used Chaining), and then derive the result as a point of use graph. Then, the risk analyzer 140 identifies an instruction that can transfer the control right of the program from the usage graph, and analyzes the possibility of attack on the instruction. At this time, the risk analyzer 140 analyzes an attack possibility when the command that generated the crash is a store series command or a branch series command. In particular, if the target address of the branch sequence command is influenced by the instruction that generated the crash, the risk analyzer 140 determines that the crash is attackable.

Meanwhile, the risk analyzer 140 further performs a memory analysis process of subdividing a memory region when the instruction generating the crash is a store sequence command, and analyzing an area that can be stored in the register and the memory for each instruction . In order to perform the memory analysis process, the risk analyzer 140 classifies the stack memory area into a heap memory area and a stack memory area, The heap memory is detected by using the fact that the return value is the address of the heap area allocated after the function call, and the stack memory is detected using the register information initialized at the function start point.

2 is a schematic flowchart of a crash risk analysis method according to an embodiment of the present invention. 1 and 2, a risk analysis method according to an embodiment of the present invention is as follows.

First, in step S100, the disassembler 110 disassembles the binary program into a machine language. In particular, the disassembler 110 disassembles and translates a binary program (for example, an ARM binary program), which is a crash hazard analysis target, into a machine language.

In step S200, the disassembler 110 obtains control flow information from the machine language. At this time, the control flow information can be used as a reference for deriving the arrival point of each instruction or the actual point of use in the risk analysis step (S500) performed subsequently.

In step S300, the intermediate language converter 120 converts the machine language into an intermediate language. For example, the intermediate language converter 120 converts the machine language into an intermediate language called REIL (Reverse Engineering Intermediate Language). In this case, converting the machine language into an intermediate language as described above is intended to provide convenience of static analysis by reducing the number of commands in excess. For example, if about 300 ARM instructions are entered, it can be reduced to 17 when converted to an intermediate language called REIL.

In step S400, the crash generator 130 intentionally generates a crash. To this end, the crash generator 130 incorporates a pre-built crash-inducing program for intentionally generating a plurality of crashes, and generates a plurality of crashes by the crash-inducing program (for example, a Fuzzer program). In general, hackers use a crash-inducing program such as Fuzzer to generate a lot of cranks in the target program, analyze the crashes one by one, and then, if there is an attack possibility, It is intended to reverse the attack pattern of creating and attacking. That is, it is for automatically analyzing the attack possibility (that is, the risk level) for each of the deliberately generated crashes.

In step S500, the crash risk analyzer 140 analyzes the risk of the corresponding crash based on the instructions converted into the intermediate language in step S300 and the crash information generated in step S400. That is, the crash risk analyzer 140 statically analyzes all the commands affected by each of the instructions that have generated the plurality of crashes among the instructions converted into the intermediate language, and analyzes the risk of the corresponding crash.

At this time, an example of a more detailed process of the risk analysis process of step S500 is illustrated in FIG.

Referring to FIGS. 1 and 3, the risk analysis process (S500) will now be described.

First, in step S510, the crash risk analyzer 140 analyzes the memory. To this end, the crash risk analyzer 140 performs a series of processing for classifying a memory region and analyzing a region that can be stored in a register and a memory for each instruction, wherein the instruction generating the crash is a store sequence The above-described step S510 is performed. FIG. 4 is a diagram for explaining the memory analysis process (S510) of FIG. 3. FIG. 4 shows an example of a structure for storing registers and memory areas, and storing a memory state that each instruction can have. 7 to 12 illustrate a more detailed example of the step S510, the step S510 will be described again with reference to FIGS.

In step S520, the crash risk analyzer 140 identifies the arrival points of the instructions for each of the instructions that generated the plurality of crashes. To this end, in step S520, a Reaching Definition analysis is applied, and the Reaching Definition analysis is used to determine the extent to which a command for defining a variable can be affected, that is, how far it reaches. FIG. 5 is a view for explaining the arrival point identification process (S520) of FIG. 3, and shows the results of the analysis of the reaching definition in a block form.

In step S530, the crash risk analyzer 140 finds a point at which the corresponding instruction is actually used among the arrival points, and derives the result as a usage point graph. That is, if the instruction list reached for each instruction is obtained as a result of the Reaching Definition analysis, it is determined in step S530 whether to actually use the data defined by the instruction through the Def-Use Chaining analysis. At this time, the result of the Def-Use Chaining analysis can be obtained in the form of a graph. FIG. 6 is a diagram for explaining the actual usage point derivation process (S530). In FIG. 6, arrows indicate commands that actually use data defined by a specific command.

Finally, in step S540, the crash risk analyzer 140 identifies an instruction that can transfer control of the program from the use point graph, and analyzes the possibility of attack. In particular, the crash risk analyzer 140 analyzes an attack possibility when the command that generated the crash is a store series command or a branch series command. You can not change the value of a register that points directly to a command to be executed in the case of a store sequence command, but you can use the function return address, IAT (import address table), address of a function in the EAT (Export Address Table) So that control can be transferred. On the other hand, a branch sequence instruction can transfer control by changing the value of a register pointing to a command to be executed literally, since the execution flow can be changed. Examples of such branch sequence commands are function calls, branching, and conditional branching.

On the other hand, in the case of the branch sequence command, if the target address is influenced by the command that generated the crash, it can be determined that the corresponding crash is attackable.

FIG. 7 is a schematic processing flowchart of the memory analysis process of FIG. 3. FIG. Referring to FIGS. 1 and 7, the memory analysis step S510 is as follows.

First, in step S512, the crash risk analyzer 140 distinguishes between a heap memory area and a stack memory area. To this end, the crash risk analyzer 140 detects the heap memory using the fact that the return value is the address of the allocated heap area after the dynamic memory allocation function call, Can be used to detect the stack memory. FIG. 8 is a diagram for explaining a memory area dividing process of FIG. 7. Referring to FIG. 8, a stack memory area is derived by storing an address of a heap area allocated to a local variable test, + 4), heap memory area is obtained by storing Oxabcd (43981 in decimal) in heap + 16 memory. If the stack and heap areas are set differently, it can be seen that the contaminated information is not propagated to each other.

Meanwhile, in step S514, the crash risk analyzer 140 refines the stack memory area. This is because the code contents are very short in the stack, and even in the simple function that puts the value in the heap area, there is a lot of analysis about the stack memory at a ratio of about 12.6: 1. FIGS. 9 to 12 are diagrams for explaining a stack memory region refinement process of FIG. 7, wherein FIG. 9 shows a stack memory region 10 and a heap memory region 20, In particular, it indicates that the stack memory area 10 is elaborated as the specific point 1 ((R1) (11), specific point 2 (R2) 12). Figure 10 is a schematic diagram of the heap memory area 20 as well as the memory area 20 when the specific point 1 (R1) 11 of the refined stack memory area 10 is tainted And it is not propagated to the specific point 2 (R2) (12). As described above, according to the present invention, by analyzing and refining the memory, it is possible to obtain more accurate analysis results than the conventional case where the memory is viewed and analyzed as one large storage space. FIG. 11 shows an example in which the result of the refinement process is shown as a memory location table. Meanwhile, FIG. 12 is a view showing an example of a screen outputting a memory area analysis result according to an embodiment of the present invention.

In the above-described exemplary system, the methods are described on the basis of a flowchart as a series of steps or blocks, but the present invention is not limited to the order of the steps, and some steps may occur in different orders .

It will also be understood by those skilled in the art that the steps shown in the flowchart are not exclusive and that other steps may be included or that one or more steps in the flowchart may be deleted without affecting the scope of the invention.

Claims

A crash risk analysis apparatus comprising:
A disassembler for disassembling the binary program into a machine language and obtaining control flow information from the machine language;
An intermediate language converter for converting the machine language into an intermediate language;
A crash generator for generating a plurality of crashes by a crash-inducing program previously created to intentionally cause a crash; And
And a crash risk analyzer for statically analyzing all the commands affected by each of the instructions that have generated the plurality of crashes among the instructions converted into the intermediate language and analyzing the risk of the corresponding crash,
The risk analyzer
Identifying arrival points of the instructions for each of the instructions that generated the plurality of crashes, finding a point at which the instruction is actually used among the arrival points, deriving the result as a usage point graph,
And analyzing an attack possibility when the instruction causing the crash is a store series instruction or a branch series instruction word after identifying a command capable of transferring the control right of the program from the usage point graph,
Further comprising the steps of: if the instruction causing the crash is a store sequence instruction, further performing a memory analysis process of analyzing a memory region and an area that can be stored in a register and a memory for each instruction,
In order to perform the memory analysis process, a heap memory area and a stack memory area are separated from each other,
The heap memory is detected by using the fact that the return value after the dynamic memory allocation function call is the address of the allocated heap area and the stack memory is detected using the register information initialized at the function start point Wherein the crash risk analysis device is characterized in that:

delete

The apparatus of claim 1, wherein the risk analyzer
Wherein when the target address of the branch sequence command is influenced by the instruction that generated the crash, the crash determination unit determines that the crash is attackable.

delete

In a crash risk analysis method,
Disassembling the binary program into a machine language;
Obtaining control flow information from the machine language;
Converting the machine language into an intermediate language;
Generating a plurality of crashes by a crash-inducing program previously created to intentionally cause a crash; And
Analyzing all the commands affected by each of the plurality of commands generated in the intermediate language and analyzing the risk of the corresponding crash;
The risk analysis step
Identifying arrival points of the instructions for each of the instructions that generated the plurality of crashes;
Finding a point at which the corresponding instruction is actually used among the reaching points and deriving the result as a usage point graph;
Analyzing an attack possibility by identifying a command capable of transferring control of the program from the use point graph; And
And a memory analyzing step of segmenting the memory area when the instruction causing the crash is a store sequence command and analyzing an area that can be stored in the register and the memory for each instruction,
The memory analysis step
And separating a heap memory area and a stack memory area,
The segmentation step
The heap memory is detected by using the fact that the return value after the dynamic memory allocation function call is the address of the allocated heap area and the stack memory is detected using the register information initialized at the function start point The crash risk analysis method comprising the steps of:

delete

9. The method of claim 8, wherein the attack potential analysis step
And analyzing the possibility of an attack if the command causing the crash is a store series command or a branch series command.

11. The method of claim 10, wherein the attack potential analysis step
Wherein when the target address of the branch sequence command is influenced by the command that generated the crash, the crash is determined to be attackable.

delete

A computer-readable recording medium having recorded thereon a program for performing the method according to any one of claims 8, 10 and 11.