JP5437913B2 - Code area identification device, code area identification method, and code area identification program - Google Patents

Description

  The present invention relates to a code area identification device, a code area identification method, and a code area identification program.

  Malicious computer programs such as computer viruses and spyware are known. Such a malicious computer program is called “malware” and adversely affects the internal resources of the computer. In recent years, as a countermeasure against malware, it is a common practice to analyze a program code that forms malware.

  By the way, in order to make it difficult to analyze the program code, malware is often packed by a tool called a runtime packer to conceal the program code. More specifically, when an executable malware is input, the runtime packer generates an executable file while hiding the program code. Malware that has been packed by the runtime packer performs unpacking that restores the program code at the time of execution, and link processing of a dynamic link library that is normally performed by a loader such as an OS (Operating System). After that, the process is passed to the entry point. In the following, the program code forming the malware before the packing process is performed may be referred to as “original code”.

  That is, when analyzing the malware, the original code is extracted from the malware after being packed by the runtime packer. As an original code extraction method, for example, it is conceivable to extract an original code from unpacked malware using an unpacker corresponding to a runtime packer. In addition, for example, when malware is executed in a state where all memory accesses are monitored, and execution access occurs for a memory area where write access occurs, the data in the memory area is extracted to extract malware in the memory area. It is possible to extract the original code.

JP 2009-193161 A

Min Gyung Kang, Pongsin Poosankam, Heng Yin, “Renovo: a hidden code extractor for packed executables”, In Proceedings of the 2007 ACM workshop on Recurring malcode, pages 46-53, 2007 Paul Royal, Mitch Halpin, David Dagon, Robert Edmonds, Wenke Lee, “PolyUnpack: Automating the Hidden-Code Extraction of Unpack-Executing Malware”, In Proceedings of the 22nd Annual Computer Security Applications Conference on Annual Computer Security Applications Conference, pages 289 -300, 2006 Makoto Iwamura, Mitsunori Ito, Yoichi Muraoka, “Unpacking Method Based on Likelihood of Compiler Output Code Model”, MWS2008 Makoto Iwamura, Mitsuaki Ito, Yoichi Muraoka, "New Disassembly Method Based on Hidden Markov Model", In Proceedings of the 2008 IEICE General Conference.

  However, the above prior art has a problem that the man-hours for analyzing the original code increase. Specifically, in the conventional technique using an unpacker, the man-hour for developing the unpacker increases, and as a result, the man-hour for analyzing the original code increases. Specifically, since there are so many types of runtime packers, it takes a lot of development man-hours and development costs to develop an unpacker for each runtime packer. Furthermore, since there are undisclosed runtime packers such as a runtime packer originally developed by the malware creator, it is not realistic to develop unpackers that correspond to all runtime packers in the first place.

  Further, in the conventional technique for extracting data written in the memory, there is a high possibility of extracting program codes other than the original code. For example, in such a conventional technique, it is considered that the program code is extracted from the memory area secured at the time of executing the malware using the base address of the memory specified at the time of securing the memory after executing the malware and the size from the base point address. It is done. In the following description, an area from the base address at the time of memory allocation to the allocated size may be referred to as “memory region”. In the following, the code written in the memory area when executing malware may be referred to as “dynamically generated code”.

  Here, some runtime packers pack a malware so that a plurality of continuous memory regions are secured in advance, and dynamically generated code is expanded in the secured memory regions. In such a case, the dynamically generated code should be extracted from a plurality of consecutive memory regions. However, the extracted dynamically generated code may include a dynamic link library other than the original code. is there. This is because, as described above, malware that has been subjected to packing processing by the runtime packer performs link processing of the dynamic link library at the time of execution. That is, when the memory region storing the original code and the memory region storing the dynamic link library are adjacent to each other, the original code, the dynamic link library, etc. are extracted from a plurality of consecutive memory regions. It will be. If the original code and the dynamic link library are extracted in this way, not only the original code but also the dynamic link library and the like are to be analyzed, so the number of man-hours for analyzing the original code increases.

  The present invention has been made in view of the above, and an object of the present invention is to provide a code area identification device, a code area identification method, and a code area identification program capable of reducing the man-hours for analyzing an original code.

  In order to solve the above-described problems and achieve the object, the code area identification device according to the present invention has a program code that develops the program at the time of program execution in a storage area divided for each predetermined storage space. A storage area group that is continuously adjacent to and in use each time execution access is made to a storage space included in the storage area. An acquisition unit that acquires the program code stored in the storage unit, a branch source storage space that includes a branch instruction that specifies an instruction by a relative address by analyzing the program code acquired by the acquisition unit, and the relative address is The frequency at which a branch area sandwiched between the branch destination storage space including the instruction to be specified is specified and the boundary is included in the branch area for each storage space boundary The calculation unit to calculate, and the boundary where the frequency calculated by the calculation unit is equal to or less than a predetermined threshold is a program boundary in which a program code forming the program and a program code different from the program code are expanded And a determination unit for determining.

  The code area identification method according to the present invention is a code area identification method for identifying a storage space in which a program code forming the program is expanded during execution of a program among storage areas divided for each predetermined storage space. Each time execution access is made to the storage space included in the storage area, the computer obtains a program code stored in the storage space group that is continuously adjacent to the storage space and in use. An acquisition step, a branch source storage space including a branch instruction that specifies an instruction by a relative address by analyzing the program code acquired by the acquisition step, and a branch destination storage space including an instruction indicated by the relative address A calculation step of identifying a branching area sandwiched between the two and calculating a frequency at which the boundary is included in the branching area for each boundary of the storage space A determination step for determining that a boundary whose frequency calculated by the calculation step is equal to or less than a predetermined threshold is a program boundary in which a program code forming the program and a program code different from the program code are expanded; It is characterized by including.

  A code area identification program according to the present invention causes a computer to function as the code area identification device.

  The code area identification device, the code area identification method, and the code area identification program according to the present invention have an effect that the man-hours for analyzing the original code can be reduced.

FIG. 1 is a diagram for explaining an overview of processing performed by the original code extraction apparatus according to the first embodiment. FIG. 2 is a block diagram illustrating a configuration example of the original code extraction apparatus according to the first embodiment. FIG. 3 is a diagram illustrating an example of a memory monitoring process performed by the memory access monitoring unit. FIG. 4 is a diagram illustrating an example of a program code candidate determination process performed by the program code candidate determination unit. FIG. 5 is a diagram illustrating an example of the score list storage unit. FIG. 6 is a diagram illustrating an example of original code extraction processing by the program code extraction unit. FIG. 7 is a flowchart of a process procedure performed by the program code extraction apparatus according to the first embodiment. FIG. 8 is a flowchart showing a memory monitoring processing procedure by the memory access monitoring unit. FIG. 9 is a flowchart showing a program code candidate determination processing procedure by the program code candidate determination unit. FIG. 10 is a flowchart showing a program code extraction processing procedure by the program code extraction unit. FIG. 11 is a block diagram illustrating a configuration example of the original code extraction apparatus according to the second embodiment. FIG. 12 is a diagram illustrating an example of a branch establishment probability calculation process by the branch establishment probability calculation unit. FIG. 13 is a diagram illustrating an example of the score list storage unit. FIG. 14 is a diagram illustrating an example of a program boundary determination process performed by the program code extraction device according to the third embodiment. FIG. 15 is a diagram showing that information processing by the code area identification program is specifically realized using a computer.

  Hereinafter, embodiments of a code area identification device, a code area identification method, and a code area identification program according to the present invention will be described in detail with reference to the drawings. In addition, this invention is not limited by this Example.

[Outline of Original Code Extraction Apparatus According to Embodiment 1]
First, the outline of the process performed by the original code extraction apparatus according to the first embodiment will be described with reference to FIG. FIG. 1 is a diagram for explaining an overview of processing performed by the original code extraction apparatus according to the first embodiment.

  The original code extraction apparatus according to the first embodiment executes malware to be analyzed in, for example, a verification environment. It is assumed that the malware to be executed has been packed by the runtime packer. Further, when such malware is executed, a plurality of memory regions 11 to 19 are assigned as shown in FIG. Note that “region N” shown in the drawing corresponds to the memory region N.

  Here, only the program code (original code) forming the malware is not necessarily written in the memory regions 11 to 19 assigned to the malware. For example, the original code of the malware is written in the memory regions 13 to 15, and the dynamic link library called by the original code of the malware may be written in the other memory regions 11, 12, and 16 to 19. That is, when all the dynamically generated codes written in the memory regions 11 to 19 assigned to the malware are extracted, the extracted dynamically generated code may include a program code other than the original code. In the malware analysis work, it is only necessary to analyze the original code. Therefore, extracting the program code other than the original code causes a problem that the number of analysis steps increases. Therefore, the original code extraction apparatus according to the first embodiment performs a process of extracting the original code from the memory regions 11 to 19 assigned when the malware is executed.

  Specifically, the original code extraction apparatus according to the first embodiment acquires the program code written in the memory regions 11 to 19 assigned to the malware after executing the malware, and disassembles the acquired program code. Analyze with. Then, the original code extraction apparatus according to the first embodiment specifies a memory region in which a branch instruction for calling another instruction is stored using a relative address, and a memory region indicated by the relative address. In the following, a memory region that stores a branch instruction that calls another instruction by specifying a relative address is referred to as a “branch source memory region”, and a memory region indicated by the relative address is referred to as a “branch destination memory region” There is.

  Then, the original code extraction apparatus according to the first embodiment specifies a combination of a branch source memory region and a branch destination memory region for each branch instruction by relative address specification, and sandwiches between the branch source memory region and the branch destination memory region. Memory region to be stored as a “branch area”. For example, in the example shown in FIG. 1, when the branch source memory region in which the branch instruction by relative address designation is stored is the memory region 13, and the branch destination memory region indicated by the relative address is the memory region 15, The original code extraction apparatus according to the first embodiment holds the memory regions 13 to 15 as one “branch area”.

  Then, the original code extraction apparatus according to the first embodiment specifies the branch area for each branch instruction by relative address specification, and then calculates the frequency at which each boundary is included in the branch area for each boundary between memory regions. For example, the original code extraction apparatus according to the first embodiment calculates the number of each boundary between memory regions included in the branch area, and the program code having different boundaries where the number included in the branch area is equal to or less than a predetermined threshold is calculated. It is determined that the boundary is stored. Specifically, in the original code extraction apparatus according to the first embodiment, the boundary in which the number included in the branch area is equal to or less than a predetermined threshold includes a memory region in which the original code is stored and a program code other than the original code. Judged as the boundary with the stored memory region. In the following, a boundary where different program codes are stored may be referred to as a “program boundary”.

  In the example illustrated in FIG. 1, the original code extraction apparatus according to the first embodiment determines that the boundary between the memory region 12 and the memory region 13 is a “program boundary”, and The boundary is determined to be a “program boundary”. Then, the original code extraction apparatus according to the first embodiment acquires the original code of the malware by extracting data from the memory regions 13 to 15 sandwiched between program boundaries. The reason for determining that the original code of the malware is stored in the memory regions 13 to 15 will be described later.

  Here, the reason why it is determined that a boundary whose number included in the branch area is equal to or less than a predetermined threshold is a program boundary. Generally, when an executable file or a dynamic link library calls a function in another dynamic link library, the call destination cannot be determined at the time of compile link. Therefore, in such a case, a branch instruction with absolute address specification using a memory reference is used. On the other hand, when calling a function in the same executable file or the same dynamic link library, the offset from the caller to the call target is fixed at the time of compile linking, so a branch instruction with a relative address is used. . Therefore, it is considered that the branch instruction with the relative address and the branch destination of the branch instruction are included in the same execution file. In other words, it can be assumed that the branch instruction with relative address and the branch destination of the branch instruction are not divided into different execution files.

  For this reason, the original code extraction apparatus according to the first embodiment specifies a branch area for each branch instruction of relative address specification, and the number included in the branch area among the boundaries between the memory regions is a predetermined threshold value. It is determined that the following boundary is a “program boundary”. In other words, the original code extraction device according to the first embodiment determines that the same program code is stored in the memory regions located at both ends of the boundary where the number included in the branch area is larger than the predetermined threshold. .

  As described above, the original code extracting apparatus according to the first embodiment specifies a branch area based on a branch instruction based on relative addressing, and calculates a frequency at which each boundary is included in the branch area for each boundary between memory regions. Then, the program boundary is determined. As a result, the original code extraction apparatus according to the first embodiment can determine the boundary between the memory regions in which different program codes are stored, so that the original code can be extracted from the memory region assigned at the time of executing the malware. it can. As a result, the original code extraction apparatus according to the first embodiment can reduce the man-hours for analyzing the original code.

[Configuration of Original Code Extraction Device According to Embodiment 1]
Next, the original code extracting apparatus according to the first embodiment will be described with reference to FIG. FIG. 2 is a block diagram illustrating a configuration example of the original code extraction apparatus according to the first embodiment. The program code extraction apparatus 100 shown in FIG. 2 is an apparatus to which the code area identification apparatus disclosed in the present application is applied, and identifies and identifies a memory area in which program codes forming the same executable file are stored. The program code is also extracted from the memory area.

  As shown in FIG. 2, the program code extracting apparatus 100 according to the first embodiment includes a memory 110, an execution module storage unit 121, a memory region group list storage unit 122, a score list storage unit 123, and a program code storage unit. 124, a program activation unit 131, a memory access monitoring unit 132, a program code candidate determination unit 133, and a program code extraction unit 134.

  The memory 110 is a storage device such as a RAM (Random Access Memory). In the memory 110, for example, a predetermined area is allocated to each process when the program is executed.

  The execution module storage unit 121 stores various execution modules. In the first embodiment, it is assumed that the execution module storage unit 121 stores executable malware that has been subjected to packing processing by the runtime packer.

  In the memory region group list storage unit 122, the score list storage unit 123, and the program code storage unit 124, various types of information are stored or referred to by a memory access monitoring unit 132 described later. The memory region group list storage unit 122 and the like will be described together with the memory access monitoring unit 132 and the like.

  The program activation unit 131 activates malware stored in the execution module storage unit 121 to generate a process to be monitored. Then, the program activation unit 131 notifies the memory access monitoring unit 132 that the monitored process has been activated.

  The memory access monitoring unit 132 monitors accesses to all the memory regions allocated to the monitoring target process notified from the program activation unit 131 in the memory 110. The memory access monitoring unit 132 is continuously adjacent to the memory region to be accessed and the memory region to be accessed and is in use every time execution access occurs to the memory region to which write access has occurred. Get the memory region. At this time, the memory access monitoring unit 132 acquires the data itself stored in the memory region. In the following, the memory region in use acquired by the memory access monitoring unit 132 may be referred to as a “memory region group”. Then, the memory access monitoring unit 132 stores the memory region group acquired from the memory 110 and the execution access destination address in the memory region group list storage unit 122.

  Here, the memory monitoring process by the memory access monitoring unit 132 will be described with reference to FIG. FIG. 3 is a diagram illustrating an example of a memory monitoring process performed by the memory access monitoring unit 132. In the example illustrated in FIG. 3, it is assumed that the monitoring target of the memory access monitoring unit 132 is the memory regions 11 to 19. First, the memory access monitoring unit 132 monitors whether or not a write access occurs for the memory regions 11 to 19.

  Subsequently, as shown in the second row of FIG. 3, it is assumed that a write access having an access destination address “A13” occurs in the memory region 13. In such a case, the memory access monitoring unit 132 changes the memory region 13 in which the write access has occurred from “write monitoring target” to “execution monitoring target”. Here, “write monitoring target” indicates a memory region in which whether or not write access occurs is monitored, and “execution monitoring target” indicates whether or not execution access occurs in memory. Indicates the region.

  Then, as shown in the third row of FIG. 3, when an execution access occurs to the memory region 13 subject to execution monitoring, the memory access monitoring unit 132 continues from the memory region 13 and the memory region 13. Get the memory region that is in use. For example, as shown in the third row of FIG. 3, it is assumed that the memory regions 11 to 16 and 19 are in use and the memory regions 17 and 18 are not in use. In this example, the memory regions that are continuously adjacent to the memory region 13 to be accessed for execution and are in use are the memory regions 11, 12, and 14-16. Although the memory region 19 is in use, the memory region 17 is not in use, and thus does not correspond to a memory region that is continuously used from the memory region 13.

  Therefore, in the example shown in the third row of FIG. 3, the memory access monitoring unit 132 acquires the memory region group G10 including the memory regions 11-16. Then, the memory access monitoring unit 132 stores the acquired memory region group G10 and the access destination address “A13” in the memory region group list storage unit 122. Then, the memory access monitoring unit 132 returns the memory region 13 from “execution monitoring target” to “write monitoring target”.

  Subsequently, as shown in the fourth row of FIG. 3, when a write access having an access destination address “A18” occurs in the memory region 18 to be monitored for writing, the memory access monitoring unit 132 The memory region 18 is changed from “write monitoring target” to “execution monitoring target”. As shown in the fifth row of FIG. 3, when an execution access occurs to the memory region 18 subject to execution monitoring, the memory region 18 and the memory region 19 that is continuously used from the memory region 18 are displayed. A memory region group G20 including these is acquired. Then, the memory access monitoring unit 132 stores the acquired memory region group G20 and the access destination address “A18” in the memory region group list storage unit 122. Then, the memory access monitoring unit 132 returns the memory region 18 from “execution monitoring target” to “write monitoring target”.

  In this way, the memory access monitoring unit 132 acquires the memory region group and the memory region group and the access destination address when the execution access occurs after the write access occurs for the monitored memory region. Is stored in the memory region group list storage unit 122.

  Returning to the description of FIG. 2, the program code candidate determination unit 133 stores the program codes forming the same executable file by analyzing each memory region group stored in the memory region group list storage unit 122. Determine the candidate memory region.

  Specifically, the program code candidate determination unit 133 performs the following processing one by one for the memory region group stored in the memory region group list storage unit 122. First, the program code candidate determination unit 133 disassembles the entire memory region group extracted from the memory region group list storage unit 122, and specifies a branch instruction that designates another instruction using a relative address. Then, the program code candidate determination unit 133 determines a branch area sandwiched between the branch source memory region and the branch destination memory region for each branch instruction by relative address designation.

  Then, the program code candidate determination unit 133 calculates the frequency with which each boundary belongs to the branch area for each boundary between the memory regions. For example, for each boundary between memory regions, the program code candidate determination unit 133 counts the number of such boundaries included in the branch area. Then, the program code candidate determination unit 133 stores the number included in the branch area in the score list storage unit 123 for each boundary between the memory regions. The program code candidate determination unit 133 performs the above processing on all the memory region groups stored in the memory region group list storage unit 122. In the following, the number of boundaries between memory regions included in the branch area may be referred to as “score”.

  Here, the program code candidate determination process by the program code candidate determination unit 133 will be described with reference to FIG. FIG. 4 is a diagram illustrating an example of a program code candidate determination process performed by the program code candidate determination unit 133. 4 illustrates an example in which the program code candidate determination unit 133 acquires the memory region group G10 including the memory regions 11 to 16 from the memory region group list storage unit 122.

  In the example shown in FIG. 4, the program code candidate determining unit 133 first disassembles the entire memory region group G10. Then, the program code candidate determination unit 133 specifies a memory region including a branch instruction with relative address designation based on the result of the disassembly. In the example shown in FIG. 4, the memory region 13 includes two branch instructions with relative address designation, and the memory region 12 includes one branch instruction with relative address designation. Specifically, the memory region 13 includes a branch instruction whose branch destination is the memory region 11 and a branch instruction whose branch destination is the memory region 15. The memory region 12 includes a branch instruction whose branch destination is the memory region 11.

  In such a case, the program code candidate determination unit 133 specifies the memory regions 11 to 13 as one branch section T11. Further, the program code candidate determination unit 133 specifies the memory regions 13 to 15 as the branch section T12 and specifies the memory regions 11 to 12 as the branch section T13.

  The program code candidate determining unit 133 sets the score of the boundary B11 to “1” because the boundary B11 between the memory region 11 and the memory region 12 is included in the branch section T11. Similarly, the program code candidate determining unit 133 sets the score of the boundary B12 to “1” because the boundary B12 between the memory region 12 and the memory region 13 is included in the branch section T11. Further, the program code candidate determination unit 133 sets the score of the boundary B13 to “1” because the boundary B13 between the memory region 13 and the memory region 14 is included in the branch section T12. Similarly, since the boundary B14 between the memory region 14 and the memory region 15 is included in the branch section T12, the program code candidate determination unit 133 sets the score of the boundary B14 to “1”. Further, since the boundary B11 is included in the branch section T12, the program code candidate determination unit 133 increments the score of the boundary B11 to “2”. In this way, the program code candidate determination unit 133 calculates a score for each boundary between memory regions. Then, the program code candidate determination unit 133 stores the calculated score in the score list storage unit 123.

  FIG. 5 shows an example of the score list storage unit 123. In the example illustrated in FIG. 5, the score list storage unit 123 includes items such as “boundary”, “memory region information”, and “score”. “Boundary” indicates a boundary between memory regions. In the example illustrated in FIG. 5, it is assumed that the “boundary” of the score list storage unit 123 stores a code attached to the boundary illustrated in FIG. 4.

  “Memory region information” indicates information on memory regions forming a boundary. In the example illustrated in FIG. 5, the “memory region information” in the score list storage unit 123 stores the codes attached to the memory regions and the like illustrated in FIG. 4 in the “NM” format. . Specifically, when “NM” is stored in the “memory region information”, it indicates that the corresponding boundary is the boundary between the memory region N and the memory region M. “Score” indicates the number of boundaries belonging to the branch area.

  For example, the score list storage unit 123 illustrated in FIG. 5 indicates that the score of the boundary B11 between the memory region 11 and the memory region 12 is “4”. Further, for example, the score list storage unit 123 illustrated in FIG. 5 indicates that the score of the boundary B12 between the memory region 12 and the memory region 13 is “1”.

  Returning to the description of FIG. 2, the program code extraction unit 134 refers to the score stored in the score list storage unit 123 and extracts the original code. Specifically, the program code extraction unit 134 compares the score stored in the score list storage unit 123 with a predetermined threshold value. Then, when the score is equal to or less than a predetermined threshold, the program code extraction unit 134 determines that the boundary corresponding to the score is a program boundary.

  Subsequently, the program code extraction unit 134 selects the dynamically generated code developed in the memory region included between the access destination address and the program boundary among the memory region groups stored in the memory region group list storage unit 122. Extracted and stored in the program code storage unit 124. In this way, the program code extracted by the program code extraction unit 134 is highly likely to be a program code that forms the same executable file, dynamic link library, or the like.

  Here, the original code extraction processing by the program code extraction unit 134 will be described with reference to FIG. FIG. 6 is a diagram illustrating an example of original code extraction processing by the program code extraction unit 134. In addition, the score of each boundary shall be the value memorize | stored in the score of the score list memory | storage part 123 shown in FIG. Here, it is assumed that the score threshold is “1”.

  In the example illustrated in FIG. 6, the program code extraction unit 134 determines that the boundary B11 is not a program boundary because the score of the boundary B11 is “4” and is larger than the threshold value “1”. Similarly, the program code extraction unit 134 determines that the boundaries B13 and B14 are not program boundaries. On the other hand, the program code extraction unit 134 determines that the boundary B12 is a program boundary because the score of the boundary B12 is “1” and is equal to or less than the threshold value “1”. Similarly, the program code extraction unit 134 determines that the boundary B15 is a program boundary.

  Here, in the example illustrated in FIG. 6, the memory regions included from the access destination address “A13” to the program boundary are the memory regions 13 to 15. Therefore, the program code extraction unit 134 acquires the dynamically generated code from the memory regions 13 to 15 to extract the program code that forms the same execution file, dynamic link library, and the like. Then, the program code extraction unit 134 stores the extracted program code in the program code storage unit 124.

  In the example shown in FIG. 6, since the boundary B11 is not a program boundary, the memory regions 11 and 12 are considered to store program codes that form the same executable file, dynamic link library, and the like. However, since the boundary B12 is a program boundary, it is unlikely that the memory region 12 and the memory region 13 store program codes that form the same executable file. Therefore, the program code extraction unit 134 acquires the program code from the memory regions 13-15.

[Processing Procedure by Program Code Extraction Apparatus 100 According to Embodiment 1]
Next, a processing procedure performed by the program code extraction apparatus 100 according to the first embodiment will be described with reference to FIG. FIG. 7 is a flowchart of a process procedure performed by the program code extracting apparatus 100 according to the first embodiment.

  As illustrated in FIG. 7, the program activation unit 131 of the program code extraction device 100 activates malware stored in the execution module storage unit 121 (step S101), thereby generating a process to be monitored (step S102). ).

  Subsequently, the memory access monitoring unit 132 performs a memory monitoring process for monitoring accesses to all the memory regions assigned to the monitoring target process generated by the program activation unit 131 (step S103). The memory monitoring process performed by the memory access monitoring unit 132 will be described later with reference to FIG.

  Subsequently, the program code candidate determination unit 133 determines a memory region candidate in which program codes forming the same executable file are stored from each memory region group stored in the memory region group list storage unit 122. Program code candidate determination processing is performed (step S104). The program code candidate determination process by the program code candidate determination unit 133 will be described later with reference to FIG.

  Subsequently, the program code extraction unit 134 extracts the program code that forms the same executable file, dynamic link library, and the like based on the result of the program code candidate determination process by the program code candidate determination unit 133. Is performed (step S105). The program code extraction process performed by the program code extraction unit 134 will be described later with reference to FIG.

[Memory monitoring process]
Next, the memory monitoring process in step S103 shown in FIG. 7 will be described with reference to FIG. FIG. 8 is a flowchart showing a memory monitoring processing procedure by the memory access monitoring unit 132.

  As shown in FIG. 8, when an access occurs to the monitored memory region (Yes in step S201), the memory access monitoring unit 132 determines whether the access is a read access (step S202). ).

  If the access to the memory region is a read access (Yes at Step S202), the memory access monitoring unit 132 returns to Step S201. On the other hand, if the access to the memory region is not a read access (No at Step S202), the memory access monitoring unit 132 determines whether the access is a write access (Step S203).

  If the access to the memory region is a write access (Yes at Step S203), the memory access monitoring unit 132 determines whether the memory region to be accessed is a write monitoring target (Step S204). If the memory region to be accessed is a write monitoring target (Yes at step S204), the memory access monitoring unit 132 sets the memory region to be accessed as an execution monitoring target (step S205), and returns to step S201. On the other hand, when the memory region to be accessed is not the write monitoring target (No at Step S204), the memory access monitoring unit 132 returns to Step S201.

  Further, if the access to the memory region is not a write access (No at Step S203), the memory access monitoring unit 132 determines whether or not the memory region to be accessed is an execution monitoring target because the access is an execution access. Determination is made (step S206). When the memory region to be accessed is not the execution monitoring target (No at Step S206), the memory access monitoring unit 132 returns to Step S201.

  On the other hand, when the memory region to be accessed is an execution monitoring target (Yes at Step S206), the memory access monitoring unit 132 acquires a memory region group that is continuously used from the memory region to be accessed (Step S206). S207). Then, the memory access monitoring unit 132 returns the memory region to be accessed to the write monitoring target (step S208), and returns to step S201.

[Program code candidate decision processing]
Next, the program code candidate determination process in step S104 shown in FIG. 7 will be described with reference to FIG. FIG. 9 is a flowchart showing a program code candidate determination processing procedure by the program code candidate determination unit 133.

  As shown in FIG. 9, the program code candidate determination unit 133 takes out one memory region group from the memory region group list storage unit 122 (step S301). Subsequently, the program code candidate determination unit 133 disassembles the entire memory region group extracted from the memory region group list storage unit 122 (step S302).

  Subsequently, the program code candidate determination unit 133 specifies a branch instruction with a relative address based on the result of the disassembly (step S303). Then, the program code candidate determination unit 133 determines a branch area sandwiched between the branch source memory region and the branch destination memory region for each branch instruction with relative address designation (step S304).

  Subsequently, the program code candidate determination unit 133 calculates, for each boundary between memory regions, the number (score) at which the boundary is included in the branch area (step S305). The program code candidate determination unit 133 stores the score calculated in step S305 in the score list storage unit 123 for each boundary between memory regions (step S306).

  When there is an unprocessed memory region group among the memory region groups stored in the memory region group list storage unit 122 (No in step S307), the program code candidate determination unit 133 returns to step S301, One unprocessed memory region group is extracted from the region group list storage unit 122 (step S301). Thereafter, the program code candidate determination unit 133 performs the processes in steps S302 to S306. If the program code candidate determination unit 133 has performed processing on all the memory region groups stored in the memory region group list storage unit 122 (Yes in step S307), the program code candidate determination unit 133 ends the processing.

[Program code extraction processing]
Next, the program code extraction process in step S105 shown in FIG. 7 will be described with reference to FIG. FIG. 10 is a flowchart showing a program code extraction processing procedure by the program code extraction unit 134.

  As shown in FIG. 10, the program code extraction unit 134 acquires the score of each boundary from the score list storage unit 123 (step S401), and compares the acquired score with a predetermined threshold (step S402).

  When the score is larger than the predetermined threshold (Yes at Step S402), the program code extracting unit 134 determines that the boundary corresponding to the score is not a program boundary (Step S403). On the other hand, when the score is equal to or less than the predetermined threshold (No at Step S402), the program code extracting unit 134 determines that the boundary corresponding to the score is a program boundary (Step S404).

  Then, the program code extraction unit 134 extracts the program code developed in the memory region included between the access destination address and the program boundary from the memory region group stored in the memory region group list storage unit 122 ( Step S405).

[Effect of Example 1]
As described above, the program code extraction apparatus 100 according to the first embodiment performs the execution access destination memory region each time execution access is performed to the memory 110 divided for each memory region which is a predetermined storage space. And a memory region group that is continuously adjacent and in use is acquired. Then, the program code extracting apparatus 100 identifies a branch area sandwiched between the branch source memory region including the branch instruction by the relative address designation and the branch destination memory region indicated by the relative address in the acquired memory region group, For each boundary between memory regions, the frequency at which the boundary is included in the branch area is calculated. Then, the program code extracting apparatus 100 determines that the boundary where the frequency of the boundary included in the branch area is equal to or less than a predetermined threshold is the program boundary.

  Thereby, the program code extracting apparatus 100 according to the first embodiment can determine in which memory region group the program code forming the same executable file is stored.

  Then, the program code extracting apparatus 100 according to the first embodiment extracts the dynamically generated code developed in the memory region included from the access destination address to the program boundary. Thereby, the program code extracting apparatus 100 according to the first embodiment can extract each program code that forms the same executable file, dynamic link library, or the like. That is, since the program code extraction apparatus 100 according to the first embodiment can provide the original code of the malware to the user, the man-hour for analyzing the original code can be reduced.

  In the first embodiment, an example is shown in which the number of boundaries between memory regions included in the branch area is calculated as a score, and the program boundary is determined based on the score. However, the method for determining the program boundary is limited to this. Not. Therefore, in the second embodiment, an example will be described in which the probability that the data stored in the memory is an instruction is calculated and the program boundary is determined using the probability.

[Configuration of Original Code Extraction Apparatus According to Second Embodiment]
First, the original code extracting apparatus according to the second embodiment will be described with reference to FIG. FIG. 11 is a block diagram illustrating a configuration example of the original code extraction apparatus according to the second embodiment. In the following, parts having the same functions as the constituent parts shown in FIG. 2 are denoted by the same reference numerals, and detailed description thereof is omitted.

  As illustrated in FIG. 11, the program code extraction apparatus 200 according to the second embodiment includes a score list storage unit 223 and a branch establishment probability calculation unit 233. In the score list storage unit 223, various types of information are stored or referred to by a branch establishment probability calculation unit 233 described later. The score list storage unit 223 will be described together with the branch establishment probability calculation unit 233.

  The branch establishment probability calculation unit 233 specifies a branch instruction with relative address designation from the memory region group stored in the memory region group list storage unit 122, and also determines the probability that the branch instruction is a machine language instruction and the relative address. The probability that the branch destination indicated by is a machine language instruction is calculated.

  Specifically, the branch establishment probability calculation unit 233 performs the following process for each memory region group stored in the memory region group list storage unit 122. First, the branch establishment probability calculation unit 233 disassembles the entire memory region group extracted from the memory region group list storage unit 122.

  When the branch establishment probability calculation unit 233 detects a branch instruction that designates an instruction by a relative address based on the result of the disassembly, the branch establishment probability calculation unit 233 calculates a probability x that the branch instruction is the head of the machine language instruction. The probability y that the instruction indicated by the relative address is the head of the machine language instruction is calculated. Then, the branch establishment probability calculating unit 233 multiplies the probability x that the instruction indicated by the branch source address is a machine language instruction and the probability y that the instruction indicated by the branch destination address is a machine language instruction. The establishment probability xy is calculated. Then, the branch establishment probability calculation unit 233 calculates the sum of the branch establishment probabilities xy for each boundary, and stores the calculated sum of the branch establishment probabilities xy as a score in the score list storage unit 223.

  The reason for calculating the branch establishment probability will be described. In general, it is difficult to reliably determine whether each byte value in the disassembled program code indicates a machine language instruction. Therefore, the branch establishment probability calculation unit 233, for example, models an executable file using a hidden Markov model and uses the Forward / Backward algorithm, so that each byte value in the disassembled memory region group is the head of the machine language instruction. The probability is calculated (see Non-Patent Document 3 and Non-Patent Document 4). Then, the branch establishment probability calculation unit 233 calculates an expected value indicating whether or not the branch instruction is a machine language instruction by calculating a branch establishment probability for each branch instruction with a relative address. In other words, the branch establishment probability calculation unit 233 can weight each branch instruction by the branch establishment probability.

  Here, the branch establishment probability calculation processing by the branch establishment probability calculation unit 233 will be described with reference to FIG. FIG. 12 is a diagram illustrating an example of a branch establishment probability calculation process by the branch establishment probability calculation unit 233. FIG. 12 illustrates an example in which the branch establishment probability calculation unit 233 acquires the memory region group G10 including the memory regions 11 to 16 from the memory region group list storage unit 122.

  In the example shown in FIG. 12, the branch establishment probability calculation unit 233 first disassembles the entire memory region group G10. Here, the branch establishment probability calculation unit 233 detects two relative address-designated branch instructions in the memory region 13 based on the result of the disassembly, and creates a relative address-designated branch instruction in the memory region 12. One is detected.

  In such a case, the branch establishment probability calculation unit 233 specifies the memory regions 11 to 13 as one branch section T11. Further, the branch establishment probability calculation unit 233 has a probability (x1) that the instruction indicated by the branch source address of the branch section T11 is a machine language instruction and a probability (y1) that the instruction indicated by the branch destination address is a machine language instruction. The branch establishment probability (x1) · (y1), which is the result of multiplying and is calculated. Similarly, the branch establishment probability calculation unit 233 calculates the branch establishment probability (x2) · (y2) of the branch section T12, and calculates the branch establishment probability (x3) · (y3) of the branch section T13.

  Subsequently, the branch establishment probability calculation unit 233 adds the branch establishment probability (x1) · (y1) of the branch section T11 and the branch establishment probability (x3) · (y3) of the branch section T13 to thereby add the boundary B11 Calculate the score. Then, the branch establishment probability calculating unit 233 stores the calculated score in the score list storage unit 223 in association with the boundary B11. Similarly, the branch establishment probability calculation unit 233 stores the branch establishment probability (x1) · (y1) as the score of the boundary B12 in the score list storage unit 223, and the branch establishment probability (x2) · (( y2) is stored in the score list storage unit 223, and branch establishment probabilities (x2) and (y2) are stored in the score list storage unit 223 as the score of the boundary B14.

  FIG. 13 shows an example of the score list storage unit 223. In the example illustrated in FIG. 13, the score list storage unit 223 includes items such as “boundary”, “memory region information”, and “score”. “Boundary” indicates a boundary between memory regions, and “Memory region information” indicates information of a memory region forming the boundary. "Score" is the result of multiplying the probability x that the instruction indicated by the branch source address of the branch instruction across the corresponding boundary is a machine language instruction and the probability y that the instruction indicated by the branch destination address is a machine language instruction The sum of branch establishment probabilities xy is

[Effect of Example 2]
As described above, the program code extraction apparatus 200 according to the second embodiment includes a branch source probability that a branch instruction by relative address specification is a machine language instruction, and a branch destination probability that an instruction indicated by the relative address is a machine language instruction. And whether or not the boundary for each boundary between memory regions is a program boundary is determined based on the branch establishment probability that is the result of multiplying the branch source probability and the branch destination probability.

  Thereby, the program code extracting apparatus 200 according to the second embodiment can determine that a boundary belonging to a branch instruction having a higher branch establishment probability is not a program boundary, and a program belonging to a branch instruction having a lower branch establishment probability is assigned to a program. It can be determined that it is a boundary. That is, the program code extraction apparatus 200 according to the second embodiment can determine a highly accurate program boundary.

  In the second embodiment, an example is shown in which the program boundary is determined in units of memory regions using the branch establishment probability. However, the program boundary may be determined in units of byte values in the memory region group. Therefore, in the third embodiment, an example in which a program boundary is determined in byte value units will be described.

  First, the reason for determining the program boundary in byte value units will be described. For example, in the example illustrated in FIG. 2, the malware stored in the execution module storage unit 121 is activated, and the start point or end point (the beginning or end portion of the program code) of the program code developed in the memory 110 is branched. It may not fit within the area. Specifically, there is a low probability that a process for calling another function is performed at the start point or the end point of the original code, and the probability that the branch instruction becomes the branch source or branch destination of the branch instruction may be low. That is, in the example shown in FIG. 6, for example, the start point of the original code may be stored in the memory region 12 and the end point of the original code may be stored in the memory region 16. Therefore, in the third embodiment, it is possible to extract the start point and the end point of the original code by determining the program boundary not in units of memory regions but in units of byte values.

  An example of determining a program boundary in byte value units will be described with reference to FIG. FIG. 14 is a diagram illustrating an example of a program boundary determination process performed by the program code extraction device 300 according to the third embodiment. Note that the configuration of the program code extraction apparatus 300 according to the third embodiment is the same as that shown in FIG.

  Similar to the program code extracting apparatus 200 according to the second embodiment, the program code extracting apparatus 300 according to the third embodiment receives a branch instruction with a relative address from the memory region group stored in the memory region group list storage unit 122. At the same time, the probability that the branch instruction is a machine language instruction and the probability that the instruction indicated by the relative address is a machine language instruction are calculated. Then, the program code extraction apparatus 300 calculates, for each byte value, the total sum of branch establishment probabilities of branch instructions that cross the byte value.

  Here, it is assumed that the program code extracting apparatus 300 calculates the sum of branch establishment probabilities for each byte value as in the example shown in FIG. In the example shown in FIG. 14, the vertical axis En is the total sum of branch establishment probabilities, showing the expected value of the number of branch areas to which each byte value belongs, and the horizontal axis showing the offset in the memory region group. Further, ε represents a “predetermined threshold value” compared with the total sum of branch establishment probabilities in the second embodiment. Further, k is an access destination address (for example, “A13” or the like) where the execution access has occurred.

  Here, it is considered that the program code forming the same executable file is stored in an area where the expected value En is sufficiently large. That is, in the example shown in FIG. 14, program codes that form the same executable file are stored in the memory areas “o” to “q”, and the same executable file is formed in the memory areas “p” to “r”. It is considered that the program code is stored, and the program codes forming the same executable file are stored in the memory areas “s” to “t”.

  On the other hand, in the memory areas “q” to “p”, the end points of the program codes stored in the memory areas “o” to “q” and the program codes stored in the memory areas “p” to “r” are stored. It is thought that the starting point of is stored. Similarly, the end points of the program codes stored in the memory areas “p” to “r” and the programs stored in the memory areas “s” to “t” are stored in the memory areas “r” to “s”. It is considered that the start point of the code is stored. This is because, as described above, at the start point or end point of the program code, since there is a low possibility of performing a process called with another function, there is a high possibility that the program code does not fall within the branch area.

  Therefore, the program code extracting apparatus 300 according to the third embodiment uses “X” near the midpoint between “q” and “p” as a program boundary, and “Y” near the midpoint between “r” and “s”. Is determined as a program boundary. Then, the program code extracting apparatus 300 extracts the original code from the region “X” to “Y”. That is, the program code extraction apparatus 300 determines that the start point or end point of the original code is stored in the memory areas “X” to “p” and the memory areas “r” to “Y”.

  Thereby, the program code extracting apparatus 300 according to the third embodiment can extract the original code without omission. Specifically, the program code extraction apparatus 300 can also extract program codes included at the start point and end point of the original code.

  By the way, the code area identification device, the code area identification method, and the code area identification program disclosed in the present application may be implemented in various different forms other than the above-described embodiments. Therefore, in the fourth embodiment, another embodiment of the code area identification device, the code area identification method, and the code area identification program disclosed in the present application will be described.

[Memory Region]
In the first to third embodiments, the memory region and the byte value are shown as examples of the predetermined storage space for dividing the memory 110. However, the predetermined storage space for dividing the memory 110 is not limited to this. For example, the memory access monitoring unit 132 in the first to third embodiments may monitor the memory 110 in units of pages, in units of sections defined by the OS memory management mechanism, or the like. The memory access monitoring unit 132 can speed up the memory monitoring process by monitoring using, for example, a page unit defined by a CPU (Central Processing Unit).

[System configuration, etc.]
Further, in the above-described embodiment, each component of each illustrated apparatus is functionally conceptual and does not necessarily need to be physically configured as illustrated. In other words, the specific form of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured. For example, the program code candidate determination unit 133 illustrated in FIG. 2 may be distributed to a processing unit that specifies a branch area and a processing unit that calculates a score.

[program]
The various processes described in the above embodiments can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. Therefore, in the following, an example of a computer that executes a code area identification program having the same function as that of the program code extraction apparatus 100 shown in FIG. 2 will be described with reference to FIG.

  FIG. 15 is a diagram illustrating that information processing by the code area identification program according to the disclosed technology is specifically realized using a computer. As illustrated in FIG. 15, the computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These units are connected by a bus 1080.

  The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM (Random Access Memory) 1012 as illustrated in FIG. The ROM 1011 stores a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1031 as illustrated in FIG. The disk drive interface 1040 is connected to the disk drive 1041 as illustrated in FIG. For example, a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive. The serial port interface 1050 is connected to, for example, a mouse 1051 and a keyboard 1052 as illustrated in FIG. The video adapter 1060 is connected to a display 1061, for example, as illustrated in FIG.

  Here, as illustrated in FIG. 15, the hard disk drive 1031 stores, for example, an OS, an application program, a program module, and program data. That is, the code area identification program according to the disclosed technology is stored in, for example, the hard disk drive 1031 as a program module in which an instruction to be executed by the computer 1000 is described. Specifically, a program startup procedure for executing information processing similar to that of the program startup unit 131 described in the above embodiment, a memory access monitoring procedure for executing information processing similar to that of the memory access monitoring unit 132, and program code candidates A program module describing a program code candidate determination procedure for executing information processing similar to that of the determination unit 133 and a program code extraction procedure for executing information processing similar to that of the program code extraction unit 134 is stored in the hard disk drive 1031. The

  Further, like the data stored in the execution module storage unit 121, the memory region group list storage unit 122, the score list storage unit 123, and the program code storage unit 124 described in the above embodiment, the information is processed by the code area identification program. The data to be used is stored in the hard disk drive 1031 as program data, for example. Then, the CPU 1020 reads the program module and program data stored in the hard disk drive 1031 to the RAM 1012 as necessary, and executes a program activation procedure, a memory access monitoring procedure, a program code candidate determination procedure, and a program code extraction procedure.

  Note that the program module and program data related to the code area identification program are not limited to being stored in the hard disk drive 1031, but may be stored in, for example, a removable storage medium and read out by the CPU 1020 via the disk drive or the like. Good. Alternatively, a program module and program data relating to the transfer program are stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.), and the CPU 1020 via the network interface 1070. May be read.

DESCRIPTION OF SYMBOLS 100 Program code extraction apparatus 110 Memory 121 Execution module memory | storage part 122 Memory region group list memory | storage part 123 Score list memory | storage part 124 Program code memory | storage part 131 Program start-up part 132 Memory access monitoring part 133 Program code candidate determination part 134 Program code extraction part 200 Program code extraction device 223 Score list storage unit 233 Branch establishment probability calculation unit 300 Program code extraction device

Claims (6)

A code area identification device for identifying a storage space in which a program code forming the program is expanded during execution of a program among storage areas divided for each predetermined storage space,
An acquisition unit that obtains a program code stored in a storage space group that is continuously adjacent to the storage space and in use each time execution access is made to the storage space included in the storage area;
A branch area sandwiched between a branch source storage space including a branch instruction that specifies an instruction by a relative address and a branch destination storage space including an instruction indicated by the relative address by analyzing the program code acquired by the acquisition unit And calculating a frequency at which the boundary is included in the branch area for each boundary of the storage space;
A determination unit that determines that a boundary whose frequency calculated by the calculation unit is equal to or less than a predetermined threshold is a program code forming the program and a program boundary in which a program code different from the program code is expanded. A code area identification device comprising: The calculation unit analyzes the program code acquired by the acquisition unit, so that the branch source probability that the branch instruction is a machine language instruction, and the branch destination probability that the instruction indicated by the relative address is a machine language instruction, To calculate
The determination unit calculates a branch establishment probability that is a multiplication result of the branch source probability and the branch destination probability calculated by the calculation unit, and based on the sum of the branch establishment probabilities regarding the branch across the boundary, the boundary of the storage space The code area identification device according to claim 1, wherein it is determined whether or not the boundary is the program boundary every time. The determination unit includes a storage space indicated by an address in the vicinity of the center between addresses in which the sum of the branch establishment probabilities is equal to or less than the threshold among storage spaces including a branch instruction in which the sum of the branch establishment probabilities is equal to or less than a predetermined threshold The code area identification device according to claim 2, wherein the code area is determined to be the program boundary. 2. The method according to claim 1, further comprising: an extracting unit that extracts a program code expanded in the storage space from the storage space where the execution access has been made to a boundary determined to be a program boundary by the determination unit. The code area identification device according to any one of? A code area identification method for identifying, by a computer, a storage space in which a program code forming the program is expanded during program execution among storage areas divided for each predetermined storage space,
Each time the computer performs execution access to the storage space included in the storage area , the computer obtains a program code stored in a storage space group that is continuously adjacent to the storage space and is in use. Acquisition process;
The computer analyzes the program code obtained by the obtaining step, so that a branch source storage space including a branch instruction specifying an instruction by a relative address and a branch destination storage space including an instruction indicated by the relative address A calculation step of identifying a branching area to be sandwiched and calculating a frequency at which the boundary is included in the branching area for each boundary of the storage space;
The computer determines that a boundary whose frequency calculated by the calculation step is equal to or less than a predetermined threshold is a program boundary in which a program code forming the program and a program code different from the program code are expanded A code region identification method comprising: a determination step.   A code area identification program for causing a computer to function as the code area identification device according to any one of claims 1 to 4.

Images