Analyzer, analysis method, and analysis program
The analysis device effectively extracts the original code from packed malware by acquiring memory dumps, dividing them into code fragments, and comparing statistical scores to restore the original code, addressing the challenges posed by Type VI runtime packers.
Patent Information
- Application Number
- JP2023170862
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-09-29
- Publication Date
- 2025-04-10
AI Technical Summary
Existing methods struggle to properly retrieve the original code for packed malware, particularly when using Type VI runtime packers, as the selection function based on a preset index fails to work effectively.
The analysis device acquires multiple memory dumps, divides them into code fragments, compares statistical scores of byte sequences to identify original code fragments, and then restores the original code using these fragments.
This approach allows for the proper extraction of the original code from malware packed by Type VI packers, overcoming the limitations of prior art by accurately identifying and restoring the original code from memory dumps.
Smart Images

Figure 2025060248000001_ABST
Abstract
Description
[Technical field]
[0001] The present invention relates to an analysis device, an analysis method, and an analysis program. [Background technology]
[0002] In recent years, malicious programs such as malware may use runtime packers to make analysis difficult and to avoid pattern detection by antivirus software. A runtime packer takes an executable file (original code) as input, encodes all or part of the executable file, and outputs an executable file with a decoder that restores the encoded byte sequence at runtime.
[0003] Therefore, in order to analyze packed malware, a process of extracting the original code before it is encoded (unpacking) is performed. A commonly known unpacking technique is to run the packed malware on a dynamic analysis framework and select the memory area that is written by the malware and is considered to be closest to the original code based on a preset index from among the executed memory areas. [Prior art documents] [Non-patent literature]
[0004] [Non-Patent Document 1] “X. Ugarte-Pedrero, D. Balzarotti, I. Santos and PG Bringas, “SoK: Deep Packer Inspection: A Longitudinal Study of the Complexity of Run-Time Packers,” 2015 IEEE Symposium on Security and Privacy, San Jose, CA, USA, 2015, pp. 659-673, doi: 10.1109 / SP.2015.46. Summary of the Invention [Problem to be solved by the invention]
[0005] However, in the conventional technology, there are cases where the original code cannot be properly extracted from packed malware. For example, in the conventional technology, when a packer belonging to the Type VI category (see Non-Patent Document 1) is used, the selection function based on a preset index does not work, and the original code cannot be properly selected. [Means for solving the problem]
[0006] In order to solve the above-mentioned problems and achieve the object, the analysis device of the present invention is characterized by having an acquisition unit that acquires multiple memory dumps, a division unit that divides each memory dump acquired by the acquisition unit into code fragments, a determination unit that determines whether each code fragment is a code fragment of original code by comparing statistical scores of byte sequences calculated for each of the code fragments divided by the division unit, and a restoration unit that restores the original code using the multiple code fragments determined by the determination unit to be code fragments of original code. Effect of the Invention
[0007] According to the present invention, it is possible to appropriately extract original code from packed malware. [Brief description of the drawings]
[0008] [Figure 1] FIG. 1 is a diagram showing a system including an analysis device according to an embodiment. [Diagram 2] FIG. 2 is a block diagram illustrating an example of the configuration of the analysis device according to the embodiment. [Diagram 3] FIG. 3 is a diagram illustrating an example of data stored in the analysis device according to the embodiment. [Figure 4] FIG. 4 is a diagram illustrating a specific example of the memory dump division process according to the embodiment. [Diagram 5] FIG. 5 is a diagram for explaining a specific example of the determination process and the original code restoration process according to the embodiment. [Figure 6] FIG. 6 is a flowchart showing an example of a process flow of the analysis device according to the embodiment. [Figure 7] FIG. 7 is a diagram illustrating an example of a computer that executes an analysis program. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0009] Hereinafter, an embodiment of an analysis device, an analysis method, and an analysis program according to the present application will be described in detail with reference to the drawings. Note that the analysis device, the analysis method, and the analysis program according to the present application are not limited to the embodiment.
[0010] 1. Introduction First, an overview of the prior art related to program packing by a runtime packer and general unpacking in the present embodiment will be described. As described above, recent malicious programs such as malware use runtime packers to avoid pattern detection by antivirus software.
[0011] Here, we will provide an overview of the packing method used by a general runtime packer. A runtime packer first receives an executable file such as malware as input. The runtime packer then performs processing such as compression and encryption (hereinafter referred to as encoding) on the code and data of the received file (hereinafter referred to as original code). After that, the runtime packer adds a decoder for decoding at runtime, and generates an executable file (packed executable file) with appropriate settings such as header address permissions so that the decoder is executed at startup.
[0012] When the packed executable file generated by the above-mentioned series of processes is launched, the original code encoded by the decoder is all decoded, a jump is made to the entry point of the original code, and the original code is then executed. As a result, the encoded and packed executable file is different from the original executable file format until the executable file is launched, and therefore it is possible to avoid antivirus pattern detection, etc.
[0013] Therefore, in order to analyze malicious programs such as packed malware, a process of extracting the original code from the packed executable file (unpacking) is performed. Here, we will explain the outline of the Write-and-then Execution process, which is an example of a general unpacking method.
[0014] First, the packed malware etc. is run on a dynamic analysis framework such as a virtual machine or emulator, and all memory writes and executions are monitored. Then, the memory areas written by the packed malware etc. are marked and managed in specially provided memory or disk areas. Next, when a marked memory area is executed, it is determined that the area written by the malware etc. (≒ decoded original code) has been executed, and the memory area or the entire memory area is dumped to a file to obtain a memory dump.
[0015] Then, from among the obtained memory dumps, the memory dump that is closest to the original code is selected based on a preset index. The index may be entropy, the ratio of code to data, or the distribution of byte sequences or n-grams of byte sequences. This makes it possible to extract the decoded original code for packed malware, etc.
[0016] However, when a file is packed by a runtime packer belonging to the Type VI category (see Non-Patent Document 1), which is one type of runtime packer, the above-mentioned Write-and-then Execution process may not be able to properly unpack the file. Here, the characteristics of the Type VI packer process will be described.
[0017] The Type VI packer decodes the minimum necessary units, such as functions, to be executed at the time of execution and executes the original code. After the original code is executed, the decoded original code is re-encoded and overwritten. This ensures that the entire original code is never loaded into the memory area at any time during execution of malware packed by Type VI.
[0018] Therefore, in the above-mentioned Write-and-then Execution process, no matter when a memory dump is acquired, it is composed of a part of the original code and a large part of the encoded code, so the process of selecting a memory dump close to the original code using a preset index does not work properly.In addition, since there is no memory dump that contains the entire original code in the first place, the original code cannot be extracted even if a memory dump is selected.
[0019] Therefore, an object of the analysis device according to this embodiment is to properly extract original code from malicious programs such as malware packed by the above-mentioned Type VI packer.
[0020] 2. Overall Structure The overall configuration of a system including an analysis device 100 according to the present embodiment will be described. Fig. 1 is a diagram showing a system including an analysis device according to the embodiment. In the system shown in Fig. 1, analysis device 100 and external device 200 are shown, and packed malware is transmitted from external device 200, and analysis device 100 receives it to perform analysis processing.
[0021] Analysis device 100 is an information processing device that extracts original code from packed malware, etc., and is realized by a computer, etc. Analysis device 100 is connected to external device 200 via wired or wireless communication to transmit and receive information. Analysis device 100 also has a function as a dynamic analysis device that monitors the execution of packed malware, etc., for example.
[0022] The external device 200 is, for example, a malware collection device that collects malicious programs such as malware to be analyzed, and is configured by a server device, etc. For example, the external device 200 transmits malicious programs such as packed malware to be analyzed to an analysis device, and receives original code transmitted from the analysis device 100.
[0023] Analysis device 100 acquires a plurality of memory dumps and divides each memory dump into code fragments. Analysis device 100 then compares the statistical scores of byte sequences calculated for each of the code fragments to determine whether each of the code fragments is a fragment of original code, and restores the original code using the plurality of code fragments determined to be fragments of original code.
[0024] First, the analysis device 100 acquires multiple memory dumps. For example, the analysis device 100 executes an executable file of the packed malware, and at the same time monitors writing to and execution in memory, and when it detects behavior that triggers acquisition of a memory dump, such as write-and-then execution or a system call / library call call, acquires multiple memory dumps of the memory area that was the target of writing to memory or execution, or of the entire virtual memory space.
[0025] Next, analysis device 100 divides each memory dump into code fragments. For example, analysis device 100 compares byte values from the first byte for each of the acquired memory dumps, generates groups of memory dumps having the same byte values, and divides each memory dump into code fragments by dividing them by points where changes have occurred in the components of the group.
[0026] Next, the analysis device 100 compares the statistical scores of the byte sequences calculated for each code fragment to determine whether each code fragment is a code fragment of original code. For example, the analysis device 100 calculates a statistical score such as entropy or a ratio of code to data for each code fragment, and determines, from among the code fragments at the same offset, the one that is most likely to be original code based on the score, as the original code fragment.
[0027] Then, analysis device 100 restores the original code using the multiple code fragments determined to be the code fragments of the original code. For example, analysis device 100 restores the original code by locating the code fragments determined to be the code fragments of the original code at the corresponding offsets.
[0028] Through the series of processes described above, analysis device 100 can restore original code from code fragments of memory dumps obtained by executing packed malware, etc., and thereby properly extract original code even in cases of packing by a Type VI packer.
[0029] 3. Configuration of analysis device 100 Next, the configuration of the analysis device 100 shown in Fig. 1 will be described with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the configuration of the analysis device according to the embodiment. Analysis device 100 has a communication unit 110, a control unit 120, and a storage unit 130, and is connected to an external device 200 via a network N so as to be able to communicate with each other.
[0030] The communication unit 110 is realized by, for example, a network interface card (NIC) or the like. The communication unit 110 is connected to a network N and transmits and receives information to and from the external device 200. For example, the communication unit 110 receives a malicious program such as a packed malware to be analyzed from the external device 200, and transmits to the external device 200 an original code restored by a restoration unit 124 described later.
[0031] The storage unit 130 is realized by a storage device such as a RAM (Random Access Memory) or a hard disk. The storage unit 130 stores data and programs necessary for various processes by the control unit 120. The storage unit 130 of the analysis device 100 has a memory dump information storage unit 131 and a code fragment information storage unit 132, which are closely related to the present invention.
[0032] The memory dump information storage unit 131 assigns a number to each memory dump acquired by the acquisition unit 121 (described later), and stores information on the behavior of a trigger related to the timing at which the memory dump was acquired.
[0033] The code fragment information storage unit 132 stores information about each code fragment divided by the division unit 122 described later. Here, data stored in the code fragment information storage unit 132 will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of data stored in the analysis device according to the embodiment.
[0034] 3, the code fragment information storage unit 132 is composed of the items "memory dump number," "offset," and "score." Here, "memory dump number" stores the number of the memory dump to which the corresponding code fragment belonged. "Offset" stores offset information in the memory dump of the corresponding code fragment. "Score" stores the statistical score value of the byte sequence calculated for the corresponding code fragment.
[0035] For example, the code fragment information storage unit 132 stores "offset: 0 to 7" and "score: 0.30" for "memory dump number: Dump#1."
[0036] Returning to the explanation of Fig. 2, the control unit 120 is realized by a CPU (Central Processing Unit), MPU (Micro Processing Unit), etc., executing various programs stored in a storage device inside the device using a RAM as a working area. The control unit 120 is also realized by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). The control unit 120 has an acquisition unit 121, a division unit 122, a determination unit 123, and a restoration unit 124.
[0037] The acquisition unit 121 acquires a plurality of memory dumps. For example, the acquisition unit 121 acquires a memory dump when, by using the function as the dynamic analysis device described above, a behavior that triggers acquisition of a memory dump is detected when packed malware is executed for a certain period of time.
[0038] Examples of behaviors that trigger the taking of a memory dump include write-and-then execution, the invocation of a system call or library call, transitions in user or kernel space, the occurrence of an interrupt, or the occurrence of a context switch.
[0039] The acquisition unit 121 also acquires a memory dump of a memory area that has been written to by malware and is the target of execution of the malware. The acquisition unit 121 then assigns an identification number to the acquired memory dump and stores it in the memory dump information storage unit 131.
[0040] For example, the acquisition unit 121 monitors writing to all memories and marks the memory area where writing has been performed. After that, the acquisition unit 121 checks whether the memory area to be executed is marked by, for example, monitoring all executions, and if it is marked, it determines that the decoded original code is about to be executed, and acquires a memory dump.
[0041] Here, the acquisition unit 121 can, for example, acquire memory dumps by execution in units of basic blocks or pages (4 KB) in order to limit the number of memory dumps to be acquired, or acquire memory dumps at the timing of transitions in layers or stages (see non-patent document 1) of the memory area where writing is performed.
[0042] The division unit 122 divides each memory dump acquired by the acquisition unit 121 into code fragments. Then, the division unit 122 stores information about the code fragments generated by the division process in the code fragment information storage unit 132. For example, the division unit 122 compares each memory dump stored in the memory dump information storage 131 in order from the first byte, generates groups of memory dumps having the same byte values, and divides each memory dump into code fragments by dividing them by points where changes have occurred in the components of the group.
[0043] Here, the processing contents of the division unit 122 will be described with reference to Fig. 4. Fig. 4 is a diagram for explaining a specific example of memory dump division processing according to the embodiment. In the example of Fig. 4, it is shown that four memory dumps "Dump#1 to Dump#4" are acquired by the acquisition unit 121, and the memory dumps include "Function#1" and "Function#2". Also, a byte string from "Offset 0" to "Offset f" is shown for each dump file, with cells with a white background containing part of the original code and cells with a gray background containing part of the encoded code.
[0044] The dividing unit 122, for example, compares the byte value of the first byte "offset 0" for each dump file "Dump#1 to Dump#4". Then, the dividing unit 122 generates a group of "Dump#1" and "Dump#4" having a byte value of "00" at "offset 0", and a group of "Dump#2" and "Dump#3" having a byte value of "f0" at "offset 0", and manages each group by a variable called ValueIdMap. For example, the group of "offset 0" is managed as "ValueIdMap[0]=set((#1,#4),(#2,#3))".
[0045] Thereafter, the dividing unit 122 similarly compares the byte values for offsets after "offset 0", generates groups, and manages them by ValueIdMap. As a result, the components of the group from "ValueIdMap[0]" to "ValueIdMap[7]" are "set((#1,#4),(#2,#3))", while the components of the group from "ValueIdMap[8]" to "ValueIdMap[f]" are "set((#1,#3),(#2,#4))".
[0046] That is, since the ValueIdMap from "offset 0" to "offset 7" is the same, "set((#1,#4),(#2,#3))", no change occurs in the components. In contrast, since the ValueIdMap of "offset 7" is "set((#1,#4),(#2,#3))" and the ValueIdMap of "offset 8" is "set((#1,#3),(#2,#4))", a change occurs in the components (combination of sets) managed by the ValueIdMap between "offset 7" and "offset 8". Therefore, the division unit 122 divides each of the dump files "Dump#1 to Dump#4" into two code fragments, with the section between "offset 7" and "offset 8" as the delimiter.
[0047] As a result, the division unit 122 can divide each dump file into the decoded original code portion and the encoded code portion, and can select only the decoded original code to restore the original code. If no change occurs in the ValueIdMap until the end of the memory dump, the compared memory dump files are considered to be the same, and the division process is not performed.
[0048] The determination unit 123 determines whether each code fragment is a code fragment of original code or not by comparing the statistical scores of byte sequences calculated for each code fragment divided by the division unit 122. Then, the determination unit 123 notifies the restoration unit 124 (described later) of information on the code fragment determined to be a code fragment of original code.
[0049] For example, the determination unit 123 calculates the entropy for each code fragment stored in the code fragment information storage unit 132, and determines that the code fragment with the lowest entropy among the code fragments at the corresponding offsets is the code fragment of the original code.
[0050] Here, the processing contents of the determination unit 123 will be described with reference to Fig. 5. Fig. 5 is a diagram for explaining a specific example of the determination processing and the original code restoration processing according to the embodiment. Fig. 5 shows an example in which the entropy is calculated for each of the code fragments divided by the division processing shown in Fig. 4 described above, and the code fragment of the original code is determined by comparing the entropies.
[0051] First, the determination unit 123 calculates the entropy, which is one of the statistical scores of a byte sequence, for each code fragment stored in the code fragment information storage unit 132. Then, the determination unit 123 refers to the offset information stored in the code fragment information storage unit 132, and selects the code fragment with the lowest entropy from among the code fragments having the same offset.
[0052] Generally, an encoded code has a tendency to be calculated with a high entropy due to a high amount of information, so the determination unit 123 can determine that a code fragment with low entropy is a code fragment of an original code that has not been encoded (decoded).
[0053] 5, the determination unit 123 compares the entropy of a code fragment with byte values of "00-07" and a code fragment with byte values of "f0-f7" for "offset 0-7." As a result, the determination unit 123 determines that the code fragment with byte values of "00-07" (cells with a white background), which has the lowest entropy among the compared code fragments, is the code fragment of the original code.
[0054] The determination unit 123 also performs the same process for "offsets 8 to f" and determines that the code fragment with the byte value of "08 to 0f" is a code fragment of the original code. This allows the determination unit 123 to select code fragments that are determined to be code fragments of the original code for all offsets in the memory dump.
[0055] 5 shows an example of calculating entropy as a statistical score of a byte string, but the present invention is not limited to this, and the determination process may be performed, for example, by disassembling the byte string and using the ratio of parts (code) that are recognized as continuous instructions and parts (data) that are not recognized, or the score of the byte string or the n-gram distribution of the byte string, etc. Also, the present invention is not limited to this, and the original code determination process may be performed, for example, by using the presence or absence of a specific byte pattern, the occurrence rate, signature matching, or other methods.
[0056] The restoration unit 124 restores the original code using a plurality of code fragments determined to be code fragments of the original code by the determination unit 123. For example, the restoration unit 124 receives information on the code fragments of the original code from the determination unit 123, and connects the code fragments of the original code by placing them at corresponding offset positions, thereby restoring the entire original code.
[0057] Now, the restoration process of the original code will be described with reference to Fig. 5. As described above, the process of the determination unit 123 determines that the code fragment with byte values "00-07" for "offsets 0-7" and the code fragment with byte values "08-0f" for "offsets 8-f" are the code fragments of the original code, and notifies the restoration unit 124 of this information.
[0058] Therefore, the restoration unit 124 places a code fragment with byte values "00-07" at "offsets 0-7" and places a code fragment with byte values "08-0f" at "offsets 8-f," thereby splicing together the two fragments. This allows the restoration unit 124 to restore the entire original code including "Function#1" and "Function#2" for the entire "offsets 0-f."
[0059] 4. Example of Processing by Analysis Device 100 Next, a process flow by the analysis device 100 will be described with reference to Fig. 6. Fig. 6 is a flowchart showing an example of a process flow of the analysis device according to the embodiment. First, the analysis device 100 receives packed malware or the like to be analyzed from the external device 200 (S101).
[0060] When the analysis device 100 receives packed malware (S101; Yes), the acquisition unit 121 acquires multiple memory dumps at a predetermined timing when the packed malware is executed (S102). Then, the division unit 122 compares each memory dump in order from the first byte, generates groups of memory dumps having the same byte value, and divides each memory dump into code fragments by dividing them by the points where changes have occurred in the components of the group (S103).
[0061] Next, the determination unit 123 compares the statistical scores of the byte sequences calculated for each code fragment, and determines whether each code fragment is a code fragment of the original code (S104). After that, the restoration unit 124 restores the entire original code using the code fragment of the original code (S105), and the analysis device 100 ends the process.
[0062] 5. Effects of the embodiment As described above, the analysis device 100 according to this embodiment includes the acquisition unit 121, the division unit 122, the determination unit 123, and the restoration unit 124. The acquisition unit 121 acquires a plurality of memory dumps. The division unit 122 divides each memory dump acquired by the acquisition unit 121 into code fragments.
[0063] The determination unit 123 determines whether each code fragment is a code fragment of the original code by comparing the statistical scores of byte sequences calculated for each code fragment divided by the division unit 122. The restoration unit 124 restores the original code by using the multiple code fragments determined by the determination unit 123 to be code fragments of the original code.
[0064] This allows analysis device 100 to apply statistical scores of byte sequences to appropriately delimited code fragments rather than on a memory dump basis, thereby clearly producing differences in the distribution of byte values between code and data, and enabling the recovery of the entire original code from fragments of the original code.
[0065] In other words, the analysis device 100 has the effect of being able to properly extract original code from malware packed by a Type VI packer, which has the characteristic of re-encoding the original code and overwriting the decoded code when execution of the original code is completed.
[0066] Furthermore, acquisition unit 121 of analysis device 100 acquires a memory dump of a memory area that has been written to by malware and is the target of execution of the malware. This allows analysis device 100 to appropriately acquire a memory dump of a memory area in which a part of the memory area is decoded and contains the original code being executed.
[0067] Furthermore, the division unit 122 of the analysis device 100 compares each memory dump sequentially from the first byte, generates groups of memory dumps having the same byte values, and divides each memory dump into code fragments by dividing the portions where changes have occurred in the components of the group. This allows the analysis device 100 to appropriately divide each dump file into portions of the decoded original code and portions of the encoded code.
[0068] [6. System configuration, etc.] Of the processes described in the above embodiments, some of the processes described as being performed automatically can be performed manually. Alternatively, all or some of the processes described as being performed manually can be performed automatically by a known method. In addition, the information including the processing procedures, specific names, various data and parameters shown in the above documents and drawings can be changed arbitrarily unless otherwise specified. For example, the various information shown in each drawing is not limited to the illustrated information.
[0069] In addition, each component of each device shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or a part of it can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions. Furthermore, each processing function performed by each device can be realized in whole or in any part by a CPU and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic.
[0070] 2 may be held in a storage server or the like, rather than being held by analysis device 100. In this case, analysis device 100 acquires various pieces of information by accessing the storage server.
[0071] [7. Hardware Configuration] 7 is a diagram showing an example of a hardware configuration. The analysis device 100 according to the embodiment described above is realized by a computer 1000 having a configuration as shown in FIG.
[0072] 7 is a diagram showing an example of a computer that executes an analysis program. The computer 1000 includes, for example, a memory 1010 and a CPU 1020. The computer 1000 also includes 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 components are connected by a bus 1080.
[0073] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1041. A removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1041. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.
[0074] The hard disk drive 1090 stores, for example, an OS (Operating System) 1091, an application program 1092, a program module 1093, and program data 1094. That is, a program that defines each process of the analysis device 100 is implemented as a program module 1093 in which code executable by the computer 1000 is written. The program module 1093 is stored, for example, in the hard disk drive 1090. For example, a program module 1093 for executing the same process as the functional configuration of the analysis device 100 is stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
[0075] Furthermore, setting data used in the processing of the above-described embodiment is stored as program data 1094, for example, in memory 1010 or hard disk drive 1090. Then, CPU 1020 reads out program module 1093 or program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as necessary, and executes the program.
[0076] Note that the program module 1093 and the program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1041 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (LAN, WAN, etc.). Then, the program module 1093 and the program data 1094 may be read by the CPU 1020 from the other computer via the network interface 1070. [Explanation of symbols]
[0077] 100 Analyzer 110 Communications Department 120 Control section 121 Acquisition Department 122 Division 123 Judgment section 124 Restoration Department 130 Storage section 131 Memory dump information storage unit 132 Code fragment information storage unit 200 External device
Claims
1. an acquisition unit for acquiring a plurality of memory dumps; a division unit that divides each memory dump acquired by the acquisition unit into code fragments; a determination unit that determines whether each code fragment is a code fragment of an original code by comparing statistical scores of byte sequences calculated for each of the code fragments divided by the division unit; a restoration unit that restores original code by using the plurality of code fragments that are determined by the determination unit to be code fragments of the original code; An analysis device comprising:
2. The acquisition unit acquires a memory dump of a memory area that has been written to by malware and that is a target of execution of the malware.
2. The analysis device according to claim 1 .
3. The dividing unit compares each of the memory dumps in order from the first byte, generates groups of memory dumps having the same byte value, and divides each of the memory dumps into code fragments by dividing the memory dumps by points where changes have occurred in components of the group.
2. The analysis device according to claim 1 .
4. An analysis method performed by an analysis device, comprising: an acquisition step of acquiring a plurality of memory dumps; a dividing step of dividing each memory dump acquired by the acquiring step into code fragments; a determining step of determining whether each code fragment is a code fragment of an original code by comparing statistical scores of byte sequences calculated for each of the code fragments divided by the dividing step; a restoration step of restoring the original code using the plurality of code fragments determined to be the code fragments of the original code by the determination step; An analysis method comprising:
5. The procedure for acquiring multiple memory dumps, a division step of dividing each memory dump acquired by the acquisition step into code fragments; a determination step of determining whether each code fragment is a code fragment of the original code by comparing statistical scores of byte sequences calculated for each code fragment divided by the division step; a restoration step of restoring the original code using the plurality of code fragments determined to be the code fragments of the original code by the determination step; An analysis program for running the above on a computer.