KR20210084873A - Method for constructing patched source code from assembly code and apparatus therefor - Google Patents

Abstract

Disclosed are a method and a device for constructing a source code patched from an assembly code. A method for constructing a source code patched in an assembly code according to an embodiment of the present invention includes the steps of: assembling the source code of a first function to obtain the assembly code of the first function, when the first function is changed to a second function; extracting a change based on a difference between the assembly code of the first function and the assembly code of the second function; converting changes in the assembly code into a pseudo code by mapping the extracted change to the pseudo code; and constructing the source code of the second function by patching the source code of the first function using the converted pseudo code.

Description

{Method for constructing patched source code from assembly code and apparatus therefor}

The present invention relates to techniques for constructing patched source code from assembly code, and more particularly to extracting meaningful changes from assembly instructions, mapping them to their pseudocode, and resolving source code changes from previous versions. It relates to a method and apparatus for patching new source code by stitching.

As part of the software development process, vulnerabilities are continuously discovered and quickly patched. Knowing the cause of a vulnerability is essential for many open source software that will likely be used in other projects. One such open source software is the Apple XNU kernel. The release dates of binary patches and source code patches have a large time gap, and knowing the cause of a vulnerability is only possible with binary analysis. However, interpreting code changes at the assembly level is error prone due to optimization practices, and assembly code is not human friendly.

After binary patches are released for some vulnerabilities, you can get updated binaries, but no updated source code. The research question is how to better represent the updated binary at the source code level. Binary files can be decomposed into assembly code, but analyzing changes at the assembly level is error-prone due to compiler optimizations (during source code to assembly code conversion) and unfriendly nature of the assembly. To better solve the representation problem, all previous studies have suggested that the decompiler convert the assembly code into pseudocode.

The focus of the decompiler is to generate compilable pseudocode. A decompiler such as Hex-ray can transform the assembly code of a function into pseudocode that is functionally equivalent to the original source code. Assembly code loses definitions of variable names, structures, and typedefs, so the generated pseudocode has the same flaws. To cope with this limitation, the decompiler randomly generates variable name and type information. For large projects such as the XNU kernel with many structures, typedefs, etc., the pseudo code generated by the decompiler looks structurally different from the original source code. Although the pseudocode resembles 65-75% of the source code, it is not a better representation for generating source code patches. So far, pseudocode is considered to be the best representation of assembly code after conversion.

Embodiments of the present invention provide a method and apparatus for patching into new source code by extracting meaningful changes from assembly instructions, mapping them to their pseudo-code, and stitching changes to the source code of previous versions. provides

Embodiments of the present invention provide a method and apparatus for expressing binary updates at the source code level.

The method for constructing a source code patched from assembly code according to an embodiment of the present invention includes: when a first function is changed to a second function, assembly processing the source code of the first function to obtain the assembly code of the first function; ; extracting a change based on a difference between the assembly code of the first function and the assembly code of the second function; converting the changes in assembly code into pseudo code by mapping the extracted changes to pseudo code; and constructing the source code of the second function by patching the source code of the first function using the converted pseudo code.

In the extracting of the changes, only the actually changed changes are extracted by filtering the extracted changes based on optimization, and the converting into the pseudo code may convert only the actually changed changes into the pseudo code.

The extracting of the change may include extracting the change for each line of the assembly code by using text-based diffing of the assembly code of the first function and the assembly code of the second function.

In the step of constructing the source code of the second function, by searching the converted pseudo code in an abstract syntax tree for the source code of the first function, the index to the patch position is identified, The source code of the second function may be configured by patching the source code of the first function by stitching the index.

The step of constructing the source code of the second function includes a structural matching based search for finding the structural similarity between the transformed pseudo code and the abstract syntax tree and selecting an index having the largest code similarity ratio; By sliding a preset window over the abstract syntax tree in depth-first search, the patch position based on an aggressive search that calculates the pseudocode similarity ratio and then selects the maximum ratio node of the abstract syntax tree as a match You can check the index for .

The apparatus for constructing a source code patched from assembly code according to an embodiment of the present invention obtains the assembly code of the first function by assembling the source code of the first function when the first function is changed to the second function part; an extractor configured to extract a change based on a difference between the assembly code of the first function and the assembly code of the second function; a conversion unit that maps the extracted changes to pseudo code and converts the changes in assembly code into pseudo code; and a component configured to configure the source code of the second function by patching the source code of the first function using the converted pseudo code.

The extractor may extract only the actually changed changes by filtering the extracted changes based on optimization, and the converter may convert only the actually changed changes into pseudo code.

The extractor may extract the change for each line of the assembly code by using text-based diffing of the assembly code of the first function and the assembly code of the second function.

The constructing unit checks the index for the patch position by searching for the converted pseudo code in an abstract syntax tree for the source code of the first function, and stitches the identified index to the first function By patching the source code of , it is possible to configure the source code of the second function.

The constructing unit finds the structural similarity between the transformed pseudo code and the abstract syntax tree, and selects an index having the largest code similarity ratio above the abstract syntax tree in a structural matching based search and a depth-first search. By sliding the preset window, it is possible to check the index for the patch position based on an aggressive search that selects the maximum ratio node of the abstract syntax tree as a match after calculating the similarity ratio of the pseudo code.

According to embodiments of the present invention, it is possible to patch to new source code by extracting meaningful changes from assembly instructions, mapping them to their pseudo-code, and stitching changes to the source code of the previous version. Also, the present invention can better represent binary updates at the source code level.

Stitching a single function is not so simple and involves many difficulties, and the code stitching technique of the present invention can efficiently process and organize the patched source code.

The present invention is useful for open source software whose source code is widely used depending on other software products. We can consider a scenario where some vulnerabilities are found in the dependent software and a binary update is released to patch this vulnerability, but the source code release is delayed and there is no updated source code available to patch the dependent software. For rapid security patching, you need to configure the source code of the updated version (binaries before and after the update) and the source code of the previous version. Otherwise, the dependent software remains vulnerable to the discovered vulnerability. The code stitching technique of the present invention can handle this scenario and efficiently construct an updated version of the source code, which can be used by the dependent software.

The present invention can be practiced in the Apple XNU kernel, which is an open source kernel and is widely used in many academic/military research projects. When some vulnerabilities are discovered, Apple releases binary patches quickly, but deliberately delays source code releases. When both binary and source code of XNU are used before the update, the technology of the present invention can constitute an updated version of source code of XNU.

1 shows a code stitching method according to an embodiment of the present invention.
2 shows an exemplary diagram of an extracted change object, and shows an exemplary diagram of a pseudo code version of the change object.
3 shows a flow diagram of one embodiment for a structural matching based search algorithm.
4 shows a flow diagram of one embodiment for an aggressive search algorithm.
5 shows an exemplary view of a result according to the method of the present invention for a case in which the code is deleted.
6 shows an exemplary view of a result according to the method of the present invention when a new code is added.
7 shows an exemplary view of a result according to the method of the present invention for a case where deletion and addition are combined.

Advantages and features of the present invention and methods of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but will be embodied in various different forms, and only these embodiments allow the disclosure of the present invention to be complete, and common knowledge in the art to which the present invention pertains It is provided to fully inform those who have the scope of the invention, and the present invention is only defined by the scope of the claims.

The terminology used herein is for the purpose of describing the embodiments, and is not intended to limit the present invention. As used herein, the singular also includes the plural unless specifically stated otherwise in the phrase. As used herein, "comprises" and/or "comprising" refers to the presence of one or more other components, steps, operations and/or elements mentioned. or addition is not excluded.

Unless otherwise defined, all terms (including technical and scientific terms) used herein may be used with the meaning commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in a commonly used dictionary are not to be interpreted ideally or excessively unless specifically defined explicitly.

Hereinafter, preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings. The same reference numerals are used for the same components in the drawings, and repeated descriptions of the same components are omitted.

Embodiments of the present invention are directed to patching new source code by extracting meaningful changes from assembly instructions, mapping them to their pseudo-code, and stitching source code changes from previous versions.

In this case, the present invention can better represent the binary update at the source code level.

It is an object of the present invention to better represent binary updates at the source code level. Pseudocode does not meet this requirement for the following reasons:

structural difference

The source code and pseudocode of a function are functionally similar, but structurally different. Control flow graphs (CFGs) are often different due to compiler optimizations. For example, the CFG structure is often changed by converting an "If" block into an "If... else" block. In addition to CFG, the statements in the source code and pseudo code are very different due to the missing variable names and type definitions. Such structural differences make analysis difficult and error-prone.

Macro functions and function inlining

In the compilation preprocessing stage, macro functions and inline function calls are replaced by their definitions. The compiler does this to optimize assembly code and reduce the cost of calling functions. As a result, the pseudocode generated from the assembly code is structurally identical to the compiler preprocessing stage source code. So the pseudocode looks different from the original source code and it is difficult to distinguish the original changes after the security patch from the optimization base.

The present invention will be described in detail as follows.

Suppose we have a function A that is modified after some update and causes the modified function to be denoted by A'. The present invention has only the function A source code and assembly code, and the function A' assembly code. It is an object of the present invention to represent function A' at the source code level, which is a modified version of the function A source code.

As noted above, pseudocode is not the best representation of function A at the source code level. So the present invention needs a better representation. Observations have shown that changes to a function after an update are usually very small compared to the size of the function. So, rather than adopting complete function pseudocode, it is better to focus on small changes and stitch these small change pseudocode into function A's source code to get A' source code. It is a feasible solution and the present invention calls it code stitching.

The code stitching of the present invention is patching the source code by using the pseudo code of the change extracted from the assembly code difference. Code stitching is not as simple as it sounds and it must follow 3 main requirements:

First, the editable form of the function A source code can be precisely modified at any position (index). Since direct text search is an error-prone and inaccurate technique, the present invention cannot perform direct text search. An abstract syntax tree (AST) is a representation of the source code that can precisely meet these requirements.

Second, the change of the function after update is often small compared to the overall function. The purpose of code stitching is to stitch only the changed parts, but the binary diffing output is assembly code, not the source code. We need to map assembly code to pseudo code to translate assembly changes into pseudo code.

Third, once the pseudocode is changed, the pseudocode is searched in the source code AST to find the patch location. The pseudocode is not an exact copy of the source code and is structurally different. There must be an efficient algorithm that can provide the best match and return node index in the AST.

The above requirements have special challenges that need to be addressed properly. In consideration of such challenges, the present invention provides a code stitching method as shown in FIG. 1 . The coordinating stitching method of the present invention can be divided into an assembly processing module, a source code, and a stitching step according to an input domain.

Each configuration is modular, and the details of each module function are as follows.

Editable AST (source code):

To modify the function A source code, it must be in an editable format such as AST. A popular utility that can parse and generate ASTs is clang (clang.cindex), but the clang parser does not generate complete ASTs. For nested loops or nested if blocks, clang does not include nested blocks in the AST, so the generated AST is incomplete. clang can analyze source code files that cannot be compiled. This seems like an advantage, but in the case of the present invention it is lacking. According to the present invention, a source file equivalent to the assembly code should be prepared by preprocessing the function source code including the MACRO function and inline function definition. A parser that takes source code preprocessed by a compiler and then generates a complete AST is a requirement of the present invention.

1) Challenges

For parsers, completeness is guaranteed when the source code is compiled. The binary dipping output is a list of functions, with function names only if you specifically want to parse the source code. Given a single function, it can use macro functions, typedefs, structures, and other user-defined data types that are not defined in the function source code. This missing information makes a single function uncompiled, and parsing such a function will result in incomplete AST. clang does not guarantee completeness as it can parse functions that cannot be compiled. There is another popular parser, "pycparser", which guarantees completeness and only parses compilable functions.

In order to make a single function compilable when there is a lot of missing information, the present invention should include all missing definitions, and provides a framework capable of automatically preparing missing definitions and compiling a single function.

Parsing Framework

The invention parses a single function and makes it compileable. Both tasks require the definition of efficient and fast XNU kernel functions, structures, typedefs, etc. This efficient solution parses and extracts all definitions from the database and later exceeds them via SQL queries. The present invention may include a "source code parsing" module using clang to extract all definitions of the XNU kernel from a single database.

1 shows a code stitching method according to an embodiment of the present invention, which can be divided into three main blocks: 1) operation in assembly code, 2) source code parsing of a single function and AST generation , 3) the final stitching that changes the object in pseudo code. Create a modified version through final stitching. The procedure is as follows.

If a function name is given, the source code is fetched from the database (DB). Splits and extracts keyword lists of data types, macro calls from, into source code. Recursively fetch missing keyword list definitions from database. Write all missing definitions to a separate header file. If you include all the missing definitions, the function is compilable. Finally, the function source is parsed through a parser eg "pycparser". The output is a nice, nice editable AST that you can edit and rewrite as source code.

Assembly diffing

The binary dipping output is a list of partially modified functions, and the present invention can "diff" their assembly code to extract the modification details. In the present invention, there are assembly codes of function A and function A', and by using text-based dipping, it is possible to extract changes for each line of assembly code. The present invention may use the "difflib" python module to obtain a unified diff output. This text-based dipping process is error-prone, and certain changes are detected in the assembly code and not reflected at the source code level. These minor changes are usually based on optimizations, and assembly instructions differ only in register names, etc. From the integrated diff output, the present invention performs the following operations.

(1) Extract changes with context

(2) Filter/classify changes based on actual vs. optimization

(3) process only actual changes

1) What are the changes?

In the integrated diff output, the present invention shows three line types: 1) starting with '+', 2) starting with '-', and 3) starting with ' ' (space). The negative and positive lines are clearly modified lines, and the lines starting with a space are common to functions A and A'. The present invention uses common lines as context, and these lines can be used to find modifications in the final stitching step. Thus, the change object is in the following order: type (+, -, !), upper context, negative assembly line (if any), positive assembly line (if present), sub-context.

Diffing Framework

The dipping framework can extract changes from the consolidated diff output regardless of the relevance of the changes in practice and optimization.

Given two function assemblies,

(1) Obtain the integrated diff to obtain the line-by-line difference.

(2) iterate over the merged diff lines.

1) When a change line (+, -) is detected, the upper context (up to 12 lines) is extracted. At this time, the number of lines should be 10 or more. The reason is that these assembly lines are mapped to pseudo code, and usually three or more lines make up one pseudo code line. Searching in the AST requires 3-5 lines of pseudo-code in the context. The present invention can select 12 assembly lines as a context.

2) After the parent context, extract all change lines until the next line starts with a blank.

3) After extracting the change line, extract the sub-context. Here, the number of lines of the lower context may be 12.

4) After extracting the context and change line, determine the type of change object according to the following criteria. Here, the condition is that the type is '-' if the positive list is empty and only the negative list is empty, the type is '+' if there is only a positive list and the negative list is empty, and both lists are not empty. The case type can be '~', and there can be both add and delete cases.

Repeat the above process for the combined diff output.

2 shows an exemplary diagram of an extracted change object, and shows an exemplary diagram of a pseudo code version of the change object. As shown in FIG. 2 , it can be seen that the change object has a structure including a positive change, a negative change, and an upper context and a lower context. These change objects are initially staged in a diff file, and there can be many such objects in a single diff file depending on the number of changes. Later, each change object can be transformed into the corresponding pseudo-code using the map.

Filtration

The consolidated diff output has many unrelated changes by default due to optimizations or compiler transformations etc. In each change line, the mnemonics are the same, but the register names are different and in some cases have different offsets. Using different data registers does not mean that the instructions are semantically different. These commands are semantically identical and the present invention can use the word2vec-based inst2vec similarity check to cope with this, which is described in Binary Dipping. At this time, although inf2vec may look structurally different, it guarantees semantic similarity.

The filtration framework of the present invention is as follows.

(1) The input is a change object.

(2) Check the semantic similarity between positive and negative changes.

(3) If the meaning is the same, the corresponding assembly line is deleted.

(4) After deletion, if the positive and negative lists of change objects are empty, the entire change object is deleted.

This filtering process removes all irrelevant change objects, and success depends on ML-based semantic similarity. Thus, the end result of the filtering process is a clean and relevant list of change objects that correspond to actual changes in the source code.

The change object is made up of assembly lines, and the purpose of the present invention is to stitch the changes in the source code AST. Assembly instructions are not at all suitable for stitching operations. The present invention should represent the change object in source code or close to the source code representation. Pseudocode is a good candidate and a viable option.

Assembly to Pseudocode Mapping

The dipping framework output is a list of change objects, and a single change object consists of the context (top and bottom) and changes (add and delete) of assembly instructions. In the present invention, in order to perform stitching, it is necessary to stitch positive and negative changes in the index found by searching the context in the source code of the function A. This cannot be achieved with assembly code, and the present invention presents assembly instructions in equivalent pseudo-code lines.

Since the change object contains only a fraction of the function assembly instructions, we need to find a mapping from the assembly instructions to the pseudo-code. IDA Pro (7.0) basic functionality is contrary to the requirements of the present invention. That is, it can only generate full function pseudocode. So, the present invention creates a custom map using the IDA API function, and the steps are as follows.

(1) Decompile the given function and get the returned pointer to decompile the object.

(2) IDA Pro decompiled object structure has "eamap" which is a map of instruction address and pseudo code line address.

(3) Get the assembly instruction using GetDisasm().

(4) Similarly, use idaapi.qstring_printer_t() to obtain pseudo code lines.

(5) Finally, we get the assembly instructions and pseudo-code lines to create a custom map.

These steps are repeated for each function in the database, and the map is stored in "JSON" format in the SQlite database so that it can be easily accessed later in the code stitching steps. Simply put, there is a mapping between function A and function A'.

In the present invention, when there is an assembly instruction for a pseudo code map, the dipping framework change objects in assembly can be directly converted to their pseudo code. An example of the transformed change object is shown in FIG. 2 . Since the upper and lower contexts exist in both function A and function A', we can use either a function A map or a function A' map for transformations. However, the deleted assembly instruction can only be used in the function A map, and the added assembly instruction exists in the function A' map. So, in the conversion process, the present invention can use a map corresponding to the availability. The end result can be a nice pseudocode representation of the change object.

Context retrieval from EAST

The present invention can retrieve the pseudo-code context from the AST (source code) if it has a pseudo-code version of the change object. Detecting the context is not straightforward as the pseudocode and source code are not 100% consistent. The similarity is usually between 60 and 80%. It is an object of the present invention to find the exact index or location of a context in the AST and to find similar parts of the pseudocode in the AST (source code).

1) Challenges

The pseudocode is not an exact copy of the source code due to missing types, real name information of variables, etc.

Macro function calls are replaced by their definitions in pseudocode.

Similarly, function calls to inline functions are replaced with pseudocode definitions.

For structural matching, the function source code must be preprocessed.

In order to solve such a search problem, the present invention provides two algorithms: a structural matching based search and an aggressive search.

Structural Match-Based Search

Structural matching is to find the structural similarity between the context pseudo code and the source code AST, for example, the structural similarity between the context pseudo code and the source code AST by the sliding window method, and finally select the index with the highest code similarity ratio. . The second level of similarity is essential, as the same structure can exist in multiple indexes of the function source code.

1) Tokenization of pseudocode

Context pseudo-code lines are randomly selected according to the change location, and may be part of an "if" block or a line of source code, such as the beginning of a block, without ending block parentheses, etc. The compile probability of these lines is very low or almost impossible. However, if the context is compilable, the present invention can simply convert it to an AST and the problem can be a simple AST-AST search. To enable this, the present invention provides a parsing framework for extracting AST-like features from pseudo-code lines. One pseudo-code line can be converted to the following structure.

(1) Type: if, else, assign, loop, etc.

(2) Spelling: String version of type or variable name

(3) Src: the pseudo-code line itself

(4) Children: If there is a subline in the pseudocode line, tokenize it recursively.

The tokenization framework of the present invention may prepare a token object for each pseudo-code line in the context.

2 ) Algorithm:

The structural matching-based search algorithm is a search algorithm that searches the pseudocode context in the AST, based on the matching structural features. Structural matching-based search algorithms match the structural features in the first step and, if successful, calculate the similarity ratio between the pseudocode context and the indexed source code found in the AST. If the similarity ratio exceeds 0.9, it is declared as a matching node. A detailed flowchart of the algorithm is shown in FIG. 3 .

(1) Given an AST of a function, build a list of node types. The present invention iterates through the AST using a depth-first search to obtain the node type and return at each iteration (or node). The result is a list of node types in depth-first order.

(2) Repeat (1) above for the context of the pseudo code. The difference is that for source code we use a properly parsed AST, and for pseudocode we use tokenization framework output.

(3) The size difference between the source code list and the context pseudo code list will be large. It is an object of the present invention to retrieve pseudo-code structural information from source code.

(4) For this purpose the present invention may adopt a sliding window process. Step by step sliding the context pseudocode list over the source code list. The result of this process is the index position of the matching point. It can be a single match, multiple matches, or none as the same structure is repeated in a function.

(5) Once we have the index, the present invention uses the context pseudocode to compute the text-based similarity of the source code at that index. The present invention may use a "difflib" sequence matching algorithm to find text-based similarities.

(6) If the similarity ratio of some indices is greater than 0.9, it is considered as a final node, otherwise it cannot be found.

3) limit

Pseudocode and source code are not structurally similar. This search algorithm operates on small functions and functions whose pseudocode is close to the source code. However, in most cases this algorithm will fail. The present invention requires another alternative algorithm to retrieve the context of the source code.

Aggressive Search

For complex functions, the pseudocode is structurally different from the source code, and structure-based matching is unlikely to work. In order to overcome this limitation, the present invention provides a new algorithm called aggressive search driven by the characteristics of the algorithm. The aggressive algorithm is shown in FIG. 4 . By sliding a window over the AST in a depth-first search, the aggressive algorithm computes the similarity ratio of the context pseudocode, traversing each node up to the leaf nodes of the AST. The result is a list of similarity ratios, after which the maximum ratio node can be chosen as a match.

1) Algorithm

This algorithm is completely different between a structure-based search algorithm and a text-based similarity ratio. The algorithm traverses each node in a depth-first search and computes the similarity of the pseudo-code context and sliding window. The step-by-step approach is as follows.

(1) Define the length of the queue to store the source code. The length of the queue depends on the number of lines of pseudocode in the context. Since the present invention approaches based on text similarity, the length of the queue may be equal to the length of the pseudocode for fair comparison.

(2) The search starts from the first children of the AST root node and ends iteratively in a depth-first pattern. Simply put, the search will traverse through every line of source code by sliding the window. At each iteration, the source code of the current node may be pushed to the queue.

(3) For each push, the similarity ratio of the source code is compared with the fixed-length pseudo code (context), calculated and stored in the output list.

(4) Step (3) above is repeated for each iteration, similarity is calculated, and finally a list of ratios and corresponding nodes is displayed.

(5) The above steps (1) to (4) are repeated for both the upper and lower contexts, and the present invention has a list of two similarity ratios.

(6) Later find the maximum ratio node in the upper and lower contexts.

(7) If the maximum ratio node distance range is within 10 indices, it means that a match is found. In other cases, the next maximum rate node is found and the same rules apply. This recursive maximal ratio finding process can only be executed up to 4 iterations, which can guarantee a safe recursive constraint.

Search Strategy

Pseudocode CFG is often different from the original source code, it introduces a structural difference between the pseudocode and the source code. In such a scenario, the structural-based search algorithm fails and the indexes found are unreliable. In contrast, an aggressive search algorithm is based on text similarity and finds the maximum similarity ratio to find the stitching index. Since the text similarity perspective pseudo code is 70-80% similar to the source code, it is highly likely to find the maximum similarity node in other CFGs as well. In the test environment of the present invention, the aggressive search algorithm performs better than the structure-based search algorithm. However, considering the complexity and nature of the pseudocode compared to the source code, a combination of the two algorithms can be used.

The purpose of the search algorithm is to find the context and find an index where changes can be added or deleted. The next and final step is to patch the source code of function A to generate the source code of function A'. Before moving on to the details of the final stitching, we can first consider the types of possible changes, which in general can be of three types.

(1) Delete only (-) in function A code

(2) Add only (+) in function A code

(3) both add and delete (!) in function A code

Strategies for stitching all kinds of changes are pretty much the same, and could be:

(1) Given a change object (pseudocode representation), input the upper context and lower context as input to the search algorithm and find the patch index?z.

(2) only deletion: The index of the node (between the upper context and the lower context) that has been changed through step (1) is secured. Deleting a node is sensitive and it is necessary to delete the node correctly, so first find the code similarity ratio of the (1)-level index node with the pseudo-code of the deletion. If the similarity ratio exceeds 0.9, it is regarded as a perfect match, the node is safely deleted from the AST, and the last modified node is written as the source code to obtain the source code of the function A'.

(3) only addition: addition is simpler than the deletion case. In the present invention, it is enough to find the index after the upper index and before the lower index. Therefore, the index found in step (1) is also reliable, and a positive change pseudo code can be added to the found index. In the present invention, the pseudo code cannot be directly inserted into the AST, and the pseudo code must be converted into an AST node and then simply inserted into the found index. To transform the pseudocode into AST nodes, you can use "pycparser" similar to the source code AST steps.

(4) Combining deletions and additions: Combining deletions and additions is a little more complex than the individual ones. In the general case, step (1) is used to find the position after the upper context and before the lower context. Changes are made at the same time as deletion and addition. First, delete the node similar to the delete case, and later add new code to the same index. The above strategy works well for regular cases where deletion and addition are independent of each other. However, there are cases where the deleted code is added again. In this case, the deleted code is matched and replaced in the positive pseudocode, and then the change is added as simple as normal addition. This is to minimize the use of pseudo code in the present invention.

A single function can have all three types of changes, so in the case of a full function patch, the whole process is repeated for every change object, and the final AST is written to the source code file. The end result may be a modified version of the source code before the update.

An example showing the effect of the solution of the present invention for various attack scenarios will be described as follows.

Case 1: Only deleted code

Consider a case function in high sierra where some lines of code are deleted in the updated version. Fig. 5 shows an exemplary view of the result according to the method of the present invention for the case where the code is deleted, the left side showing the original source and the right side showing the stitched version. As shown in Fig. 5, the code stitching for the deletion case is considerably simpler and more accurate than all other cases. The code stitching process is initiated by binary dipping of assembly functions, extracting change objects along with their contexts from a consolidated diff file, and later these change objects are converted into their pseudocode equivalent versions. In the case of stitching, the search algorithm of the present invention is used to find the upper and lower contexts from the spurious code in the AST, and when a matching context is found, the deleted pseudocode between the found context nodes is also matched with the AST node. If a node matches, simply delete the found matching node with -ve change pseudocode. The final output is a new AST that can be converted to source code. In Figure 5, the output of the code stitching for the deletion case is shown on the right and is 100% source code. This example provides strong motivation to show why the present invention favors code stitching over pure pseudo-sword.

Case 2: Only added code

Consider another example of a function that is changed by the addition of new code. The goal of code stitching is to prepare function A' by looking for changes at the binary level, stitching the index into the AST of function A, and adding a new node to the AST. The detailed procedure is described in detail in the above-mentioned search algorithm. 6 shows an exemplary view of a result according to the method of the present invention when a new code is added. The left side shows the original source code of the function A, and the right side shows the stitched version, that is, the function A'. . As shown in Figure 6, the green line on the right is the modified (or added) part stitched between the block and the function call IOCPURunPlatformQuiesceActions(). The stitch code is structurally similar to the function A source code of xnu-4570.71.2, with small differences highlighted in the green section. In the original version, the green section is pure c code, but in the stitched version, the green section is pseudocode. Of course, this is only an example, and depending on the situation, the stitched version may also be a c code.

Case 3: Combine delete and append

Consider other functions when there is a deletion along with the addition of new code. There are two main possibilities that the deleted code and the added code are independent of each other, or the deleted code is partially included in the added code. In the first case, a simple delete appended to the same index in the AST is sufficient to obtain a new AST. Subsequent cases may also be stitched with the same strategy, that is, after deletion. However, what the present invention is doing is deleting the original source code and adding the new pseudo code. The goal of the present invention is to stitch the pseudocode as little as possible and create a new version close to C equivalent. Therefore, if the deleted source code partially exists in the added code, the deleted source code is matched with the corresponding source code and replaced. Using this method, the added code becomes a combination of source code and pseudocode.

An example of a later case is as shown in FIG. 7 , which is a source-source diff version for a function and shows the original change of the source code. As shown in Fig. 7, it shows a complex case including both deletion and addition, the while block is moved to a new if block and another else block is added. From a binary point of view, the code is first deleted and then added back. If the deleted code exists in the added pseudo-code, that pseudo-code can be replaced by the source code. For example, when the clock_continuoustime_interval_to_deadline() function is moved, it moves into a new if block, and another function is added in the new block. In terms of text-based dipping, first delete the clock_continuoustime_interval_to_deadline() function and then add it inside the if block. In the present invention, the new code must be reconstructed in consideration of the dipping point of view.

As such, the method according to an embodiment of the present invention extracts meaningful changes from assembly instructions, maps them to their pseudocode, and stitches the changes to the source code of the previous version so that it can be patched to the new source code. have. Also, the present invention can better represent binary updates at the source code level.

In addition, the method according to the embodiment of the present invention can efficiently process and configure the patched source code, and efficiently configure the updated version source code, which can be used by dependency software.

That is, in the method according to an embodiment of the present invention, when the first function is changed to the second function based on the above description, the process of assembling the source code of the first function to obtain the assembly code of the first function; extracting a change based on a difference between the assembly code of the first function and the assembly code of the second function, mapping the extracted change to pseudo code and converting the change of the assembly code into pseudo code; and constructing the source code of the second function by patching the source code of the first function using the converted pseudo code. Of course, each process may include all of the above contents, and this method may be implemented through an apparatus including functional configuration means.

For example, the apparatus according to an embodiment of the present invention includes an acquisition unit configured to obtain an assembly code of the first function by assembling the source code of the first function when the first function is changed to the second function, An extraction unit for extracting changes based on a difference between the assembly code and the assembly code of the second function, a conversion unit for mapping the extracted changes to pseudo code to convert the changes in the assembly code into pseudo code, and the converted and fetching the source code of the first function by using the pseudo code, thereby configuring the source code of the second function. Of course, each component of the device may include all the contents described in the above-described code stitching method, which will be apparent to those skilled in the art.

The device described above may be implemented as a hardware component, a software component, and/or a combination of the hardware component and the software component. For example, the devices and components described in the embodiments may include a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), and a programmable logic unit (PLU). It may be implemented using one or more general purpose or special purpose computers, such as a logic unit, microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For convenience of understanding, although one processing device is sometimes described as being used, one of ordinary skill in the art will recognize that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that can include For example, the processing device may include a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as parallel processors.

The software may comprise a computer program, code, instructions, or a combination of one or more thereof, which configures a processing device to operate as desired or is independently or collectively processed You can command the device. The software and/or data may be any kind of machine, component, physical device, virtual equipment, computer storage medium or device, to be interpreted by or to provide instructions or data to the processing device. can be embodied in The software may be distributed over networked computer systems, and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

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 in a computer-readable medium. In this case, the medium may be to continuously store a program executable by a computer, or to temporarily store it for execution or download. In addition, the medium may be various recording means or storage means in the form of a single or several hardware combined, it is not limited to a medium directly connected to any computer system, and may exist distributed on a network. Examples of the medium include a hard disk, a magnetic medium such as a floppy disk and a magnetic tape, an optical recording medium such as CD-ROM and DVD, a magneto-optical medium such as a floppy disk, and those configured to store program instructions, including ROM, RAM, flash memory, and the like. In addition, examples of other media may include recording media or storage media managed by an app store that distributes applications, sites that supply or distribute various other software, and servers.

As described above, although the embodiments have been described with reference to the limited embodiments and drawings, various modifications and variations are possible for those skilled in the art from the above description. For example, the described techniques are performed in a different order than the described method, and/or the described components of the system, structure, apparatus, circuit, etc. are combined or combined in a different form than the described method, or other components Or substituted or substituted by equivalents may achieve an appropriate result.

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

Claims (10)

when the first function is changed to the second function, assembly processing the source code of the first function to obtain the assembly code of the first function;
extracting a change based on a difference between the assembly code of the first function and the assembly code of the second function;
converting the changes in assembly code into pseudo code by mapping the extracted changes to pseudo code; and
constructing the source code of the second function by patching the source code of the first function using the converted pseudo code;
How to construct patched source code from assembly code containing
According to claim 1,
The step of extracting the changes is
By filtering the extracted changes based on optimization, only the actual changed changes are extracted,
The step of converting to the pseudo code is
A method of constructing a patched source code from assembly code, characterized in that only the actually changed changes are converted into pseudo code.
According to claim 1,
The step of extracting the changes is
The method for constructing patched source code from assembly code, characterized in that the change of each line of the assembly code is extracted by using text-based diffing of the assembly code of the first function and the assembly code of the second function.
According to claim 1,
The step of composing the source code of the second function is
By searching the converted pseudo-code in an abstract syntax tree for the source code of the first function, an index for a patch position is identified, and the identified index is stitched to the source code of the first function By patching the source code, the method for constructing the source code patched from assembly code, characterized in that the source code of the second function is configured.
5. The method of claim 4,
The step of composing the source code of the second function is
A window preset above the abstract syntax tree in a structural matching based search and depth-first search that finds structural similarity between the transformed pseudo code and the abstract syntax tree and selects an index with the largest code similarity ratio By sliding , the index for the patch location is checked based on an aggressive search that calculates the similarity ratio of the pseudo code and then selects the maximum ratio node of the abstract syntax tree as a match. How to configure the source code patched in .
an acquisition unit configured to obtain an assembly code of the first function by assembling the source code of the first function when the first function is changed to the second function;
an extractor configured to extract a change based on a difference between the assembly code of the first function and the assembly code of the second function;
a conversion unit that maps the extracted changes to pseudo code and converts the changes in assembly code into pseudo code; and
A component that configures the source code of the second function by patching the source code of the first function using the converted pseudo code
A source code component that is patched from assembly code containing
7. The method of claim 6,
The extraction unit
By filtering the extracted changes based on optimization, only the actual changed changes are extracted,
the conversion unit
An apparatus for constructing a source code patched from assembly code, characterized in that only the actually changed changes are converted into pseudo code.
7. The method of claim 6,
The extraction unit
The apparatus for constructing a source code patched from assembly code, characterized in that the change of each line of the assembly code is extracted by using text-based diffing of the assembly code of the first function and the assembly code of the second function.
7. The method of claim 6,
the component part
By searching the converted pseudo-code in an abstract syntax tree for the source code of the first function, an index for a patch position is identified, and the identified index is stitched to the source code of the first function By patching, the apparatus for constructing a source code patched from assembly code, characterized in that the source code of the second function is configured.
10. The method of claim 9,
the component part
A window preset above the abstract syntax tree in a structural matching based search and depth-first search that finds structural similarity between the transformed pseudo code and the abstract syntax tree and selects an index with the largest code similarity ratio By sliding , the index for the patch location is checked based on an aggressive search that calculates the similarity ratio of the pseudo code and then selects the maximum ratio node of the abstract syntax tree as a match. Source code configuration device patched from .

Images