Analysis device, analysis method, and analysis program

Abstract

An analysis device (10): creates a correspondence table on the basis of an argument, which is a value output by executing a known operation included in the same program as or a similar program to an analysis target program, an identifier of the known operation, and an intermediate code variable ID for identifying an intermediate code variable that holds the same value as the argument; acquires the intermediate code variable ID corresponding to a predetermined operation executed by the analysis target program; reads the argument identified by the intermediate code variable ID on the basis of the correspondence table; and uses the argument read by a read unit (133) to extract information in any one of or both of a register of a virtual CPU on which the analysis target program operates and a memory.

Description

[Technical Field]

[0001] The present invention relates to an analysis device, an analysis method, and an analysis program. [Background technology]

[0002] When analyzing a program, a known method is to run the program to be analyzed using an emulator or virtual machine, sequentially execute the instructions of the program to be analyzed, or hook the execution of specific parts of the program, and perform behavior monitoring or behavior analysis, which outputs the status of registers, memory, etc. when predetermined conditions are met.

[0003] QEMU is known as an example of an emulator used in such a behavior monitoring method (for example, Non-Patent Document 1). QEMU is an emulator that emulates CPUs and devices of various architectures, and can emulate programs compiled for various architectures regardless of the architecture of the host that is the execution environment in which QEMU runs.

[0004] Specifically, QEMU reads the instructions (guest code) of the program to be analyzed and converts them into architecture-independent code called intermediate code (for example, "Tiny Code Generator Intermediate Representation, i.e., TCG IR"). QEMU then converts the converted intermediate code into an instruction sequence (host code) that can be executed on the host, and executes it on the host. This host code is then executed on the physical CPU.

[0005] In the case of QEMU, a method is known in which a plug-in (analysis module) is created using an interface called TCG I / F (Tiny Code Generator Interface) to analyze the behavior of the target program (for example, Non-Patent Document 2). The TCG I / F operates in the intermediate code layer and can intervene in the emulation process of guest code and the process of executing host code.

[0006] The advantage of performing analysis on intermediate code, such as with an analysis module using the TCG I / F, is that behavior can be monitored regardless of the architecture of the program being analyzed. QEMU can emulate approximately 30 architectures. By using the TCG I / F to create an analysis module that runs on a single intermediate code layer, it is possible to analyze the behavior of programs being analyzed on a variety of architectures, without having to create an analysis module for each of the approximately 30 architectures mentioned above. This makes it possible to efficiently create modules that can analyze multiple architectures. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] Fabrice Bellard, QEMU, a Fast and Portable Dynamic Translator, 2005 USENIX Annual Technical Conference (USENIX ATC 05), 2005. [Non-patent document 2] Emilio G. Cota and Luca P. Carloni, Cross-ISA Machine Instrumentation using Fast and Scalable Dynamic Binary Translation, Proceedings of the 15th ACM SIGPLAN / SIGOPS International Conference on Virtual Execution Environments, 2019. Summary of the Invention [Problem to be solved by the invention]

[0008] However, the conventional technology has a problem in that it is not possible to identify intermediate code variables corresponding to registers of a virtual CPU in the architecture of the program to be analyzed, and it is not easy to extract information such as registers and memory.

[0009] Specifically, the analysis module in the intermediate code layer can intervene in the execution of the program being analyzed without depending on the architecture, but it may be necessary to be aware of registers and pointers specific to each architecture when dumping (acquiring values) the state of registers, memory, etc. In other words, the analysis module in the intermediate code layer can intervene in the execution of each instruction without depending on the architecture of the program being analyzed, but in order to obtain information such as system call arguments (for example, register values ​​or memory values ​​pointed to by registers), it is necessary to be aware of the architecture of the program being analyzed, identify the location where information about the virtual CPU of that architecture is stored, and extract information about registers, memory, etc. [Means for solving the problem]

[0010] In order to solve the above problems and achieve the object, the analysis device of the present invention is characterized by having: a creation unit that creates a correspondence table based on arguments, which are values ​​output by executing a known operation included in a program that is the same as or similar to the program to be analyzed, an identifier of the known operation, and an intermediate code variable ID that identifies an intermediate code variable that holds the same value as the argument; a reading unit that acquires the intermediate code variable ID that corresponds to a predetermined operation executed by the program to be analyzed and reads out the argument identified by the intermediate code variable ID based on the correspondence table; and an extraction unit that uses the argument read by the reading unit to extract either one or both of information from a register or memory of a virtual CPU on which the program to be analyzed runs. [Effects of the Invention]

[0011] The present invention has the effect of making it possible to identify intermediate code variables corresponding to registers of a virtual CPU in the architecture of a program to be analyzed, and facilitating the extraction of information about registers and memories. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram illustrating an example of a sample program according to the first embodiment. [Figure 2] FIG. 2 is a table illustrating an example of information stored in the intermediate code variable storage unit according to the first embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of the device configuration of the analysis system according to the first embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of a program to be analyzed according to the first embodiment. [Figure 5] FIG. 5 is a diagram illustrating an example of a flowchart of the analysis method according to the first embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of a flowchart of the analysis method according to the second embodiment. [Figure 7] FIG. 7 is a diagram showing an example of a flowchart of the analysis method according to the third embodiment. [Figure 8]FIG. 8 is a diagram illustrating an example of a computer in which the analysis device and the emulator according to the embodiment are realized. DETAILED DESCRIPTION OF THE INVENTION

[0013] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention (hereinafter referred to as "embodiments") will be described with reference to the drawings. Note that the embodiments are not limited to the following description.

[0014] [1. Overview of analysis method] In this embodiment, before executing the analysis target program, the emulator 200 executes known operations (for example, system calls, library calls, etc.) included in a sample program of the same architecture as the analysis target program, which is prepared in advance. Next, the analysis device 100 associates and stores information (for example, a system call number or a library call address, etc.) that identifies the known operation obtained by executing the known operation of the sample program, arguments obtained by executing the sample program, and intermediate code variable IDs that identify intermediate code variables that hold the same values ​​as the arguments, and creates a correspondence table.

[0015] When the analysis device 100 captures the occurrence of a predetermined operation (e.g., a system call, a library call, etc.) of the program to be analyzed by the emulator 200, it monitors the behavior of the program to be analyzed in more detail by reading each register value, memory value, etc. passed as an argument from the corresponding intermediate code variable based on the created correspondence table.

[0016] In the following description, each embodiment will be described on the assumption that a general emulator such as QEMU or Bochs is used. However, the present embodiment is not limited to implementations such as QEMU or Bochs, and can be applied to any virtual machine that uses intermediate code. Furthermore, the form of emulation (system emulation, process emulation, etc.) is not limited, and the present embodiment can also be applied to process-level virtual machines such as Java (registered trademark) and Android (registered trademark).

[0017] 2. Embodiment 1: Creation and Analysis of Correspondence Table Based on System Call Arguments Next, the creation of a correspondence table based on system call arguments and the analysis of a program to be analyzed, which are realized by the analysis system 1 as the first embodiment, will be described. Note that the correspondence table in the first embodiment is referred to as a "VA-Map (Variable Argument Mapping)." In the following description, the VA-Map is created first, followed by the analysis of the program to be analyzed. However, the procedures performed by the analysis system 1 are not limited to the above-described order, and other orders or procedures may be used. For example, the analysis device 100 may perform a procedure such as temporarily terminating the process after creating the VA-Map, and then analyzing the program to be analyzed in a different time series. Note that when analyzing a program with the same architecture, a correspondence table created in the past may be used.

[0018] First, the emulator 200 compiles (e.g., cross-compiles) sample code that includes a system call (known operation) whose system call number that identifies the system call is known, and generates a sample program (e.g., a binary program) with the same architecture as the program to be analyzed.

[0019] For example, the emulator 200 generates a sample program 2201 based on sample code 2201a as shown in FIG. 1. The sample code 2201a in FIG. 1 includes system call 1 (sys_call1) and system call 2 (sys_call2). System call 1 (sys_call1) passes three arguments ("0x12345678", "0xabcdefg", and "0xdeadbeef") and invokes the system call with system call number 1. On the other hand, system call 2 (sys_call2) passes two arguments ("0x8badf00d" and "0x87654321") and invokes the system call with system call number 2. In this embodiment, multiple sample programs (one or more) that invoke specific system calls as described above are prepared.

[0020] Next, the emulator 200 executes the above-mentioned sample program 2201. Specifically, the emulator 200 executes a known system call included in the sample code, and outputs an identifiable value as an argument of the known system call.

[0021] Next, the analysis device 100 captures the execution of a system call by the emulator 200. Note that the method of capturing the execution of a system call in this embodiment is not particularly limited. For example, the analysis device 100 may capture the execution of a system call based on a virtual address, or may capture the execution of a system call triggered by the execution of an arbitrary instruction or the reference to a value.

[0022] Then, the acquisition unit 131 of the analysis device 100 acquires the value of the intermediate code variable. The intermediate code variables have an intermediate code variable ID as an identifier that can uniquely distinguish each of them. For example, when system call 1 (sys_call1) included in the sample code 2201a in FIG. 1 is executed, the intermediate code variable storage unit 121 of the analysis device 100 stores the "intermediate code variable ID", "intermediate code variable name", and "value" as shown in FIG.

[0023] Next, the creation unit 132 of the analysis device 100 identifies an intermediate code variable ID that holds the same value as the value of the argument, using the system call number of the system call described in the sample program 2201 and the argument obtained by executing the sample program 2201. Then, the creation unit 132 of the analysis device 100 uses the identified intermediate code variable ID to create a correspondence between the system call number and the intermediate code variable IDs that correspond to the n arguments associated with it.

[0024] Furthermore, the creation unit 132 uses the identified intermediate code variable ID to create a constraint corresponding to the system call number and the n arguments associated therewith. Specifically, when creating a constraint, if the same argument value is included in multiple intermediate code variables, the creation unit 132 links the respective constraints. For example, when executing system call 1 (sys_call1) included in sample code 2201a shown in FIG. 1, the creation unit 132 creates the constraint "system call number=ID0 and (arg0=ID1 or arg0=ID4) and arg1=ID2." Then, the creation unit 132 performs the above-described procedure for multiple system calls to create a set of constraints.

[0025] Furthermore, the creation unit 132 performs allocation by solving the collected set of constraints using an SMT (Satisfiability Modulo Theories) solver, and creates a VA-Map. For example, the creation unit 132 of the analysis device 100 creates a VA-Map up to the third argument in the format of "system call number=ID0, arg0=ID1, arg1=ID2,...". Note that the allocation method using the SMT solver is the same in the first, second, and third embodiments described below, and therefore further description will be omitted.

[0026] Next, the emulator 200 executes the analysis target program. Then, when the emulator 200 captures the invocation of a system call issued by the analysis target program, the reading unit 133 of the analysis device 100 acquires "the intermediate code variable ID in which the system call number is stored, the intermediate code variable ID in which arg0 is stored, ..., the intermediate code variable ID in which argN is stored" from the VA-Map, and reads out the target argument from the intermediate code variable identified by the intermediate code variable ID.

[0027] Then, the extracting unit 134 of the analysis device 100 uses the arguments read by the reading unit 133 to extract information such as register or memory information of the virtual CPU on which the analysis target program runs.

[0028] [2-1. Configuration of analysis device and emulator] From here, the configuration of the analysis system 1 in the first embodiment will be described with reference to Fig. 3. The analysis system 1 in the first embodiment is configured to include an analysis device 100 and an emulator 200. The functional units of each device will be described in detail in the following sections.

[0029] (Analysis device 100) First, the configuration of analysis device 100 will be described with reference to FIG. 3. As shown in FIG. 3, analysis device 100 has a communication unit 110, a storage unit 120, and a control unit 130. Although not shown, analysis device 100 may also have an input unit (e.g., a keyboard, a mouse, etc.) that accepts various operations and a display unit (e.g., a display, etc.) that displays various information. Furthermore, analysis device 100 may be a desktop personal computer, a notebook PC, a virtual PC, a smartphone, a tablet, a PDA (Personal Digital Assistant), etc., and the form of the information processing device is not limited. Next, the detailed functions of each unit will be described below.

[0030] (Communication unit 110) The communication unit 110 exchanges various types of information with the emulator 200. Note that, in this embodiment, the description is given on the assumption that the analysis device 100 exchanges information with the emulator 200 via the communication unit 110, but information may be exchanged without going through the communication unit 110. Furthermore, the communication unit 110 may control communication via a telecommunications line such as a LAN (Local Area Network) or the Internet as necessary, and may send and receive information bidirectionally with an external information processing device or the like.

[0031] (Storage unit 120) The storage unit 120 stores data and programs necessary for various processes performed by the control unit 130. The storage unit 120 has an intermediate code variable storage unit 121 and a correspondence information storage unit 122. The storage unit 120 is realized by a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk.

[0032] (Intermediate code variable storage unit 121) The intermediate code variable storage unit 121 stores information related to intermediate code variables. For example, as shown in Fig. 2, it stores information such as "intermediate code variable ID", "intermediate code variable name", and "value". Note that the intermediate code variable storage unit 121 is not limited to the information described above, and may store information related to other intermediate code variables.

[0033] (Corresponding information storage unit 122) From here, we will return to Fig. 3 and continue the explanation. The correspondence information storage unit 122 stores a correspondence table created by the creation unit 132 of the analysis device 100. Specifically, the correspondence information storage unit 122 stores a VA-Map (embodiments 1 and 2) and a VR-Map (embodiment 3). Note that the correspondence information storage unit 122 is not limited to the above-mentioned correspondence tables, VA-Map and VR-Map, and may store other correspondence tables. Furthermore, the correspondence information storage unit 122 may store correspondence tables in a format other than a tabular format.

[0034] (control unit 130) The control unit 130 has an acquisition unit 131, a creation unit 132, a reading unit 133, and an extraction unit 134. The control unit 130 has an internal memory for temporarily storing programs that define various processing procedures and processing data, and may be realized by electronic circuits such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), or integrated circuits such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array). Note that the CPU and internal memory described above are not limited to a physical CPU and physical memory, and may be a virtual CPU and virtual memory.

[0035] (Acquisition part 131) The acquisition unit 131 executes a system call as a known operation, and acquires a system call argument that is an output argument and a system call number that is an identifier that identifies the system call. Specifically, the acquisition unit 131 executes a system call whose system call number is known, and acquires the known system call number and the system call argument identified by the known system call number.

[0036] Furthermore, the acquisition unit 131 of the analysis device 100 acquires the values ​​of intermediate code variables when an existing operation (such as a system call or a library call) is performed. Note that the information acquired by the acquisition unit 131 is not limited to the above-mentioned system call arguments, and information about other arguments may be acquired.

[0037] (Creation Department 132) The creation unit 132 creates a correspondence table based on the value of an argument output by executing a known operation included in a program that is the same as or similar to the analysis target program, an identifier of the known operation, and an intermediate code variable ID that identifies an intermediate code variable that holds the same value as the argument. Specifically, the creation unit 132 creates a VA-Map as a correspondence table based on a system call argument, a system call number, and an intermediate code variable ID that identifies an intermediate code variable that holds the same value as the system call argument. Note that the creation unit 132 may create a correspondence table in a format other than the VA-Map described above.

[0038] Then, the creating unit 132 identifies the intermediate code variable ID to be targeted (that is, the intermediate code variable ID that holds the same value as the acquired system call argument) based on the acquired system call number and system call argument.

[0039] (readout section 133) The reading unit 133 acquires an intermediate code variable ID corresponding to a predetermined operation (a system call in the first embodiment) executed by the analysis target program, and reads out an argument identified by the intermediate code variable ID based on the correspondence table (VA-Map). Note that the reading unit 133 may read out other information as necessary.

[0040] The reading unit 133 may determine the size of the argument to be acquired and how many bytes to trace forward, depending on the type of the variable. For example, when the type of the first argument is a character string type (the argument type is char*), the reading unit 133 may interpret the value of the intermediate code variable corresponding to the first argument as a pointer, and output the byte sequence from the memory area pointed to by that value until a null byte appears as the argument. Furthermore, the reading unit 133 may output the information obtained above to a file, standard output, or error output, as necessary.

[0041] (Removal section 134) The fetching unit 134 fetches either one or both of the register and memory information of the virtual CPU on which the analysis target program runs, using the argument read by the reading unit 133. Note that the fetching unit 134 may fetch information other than the above-mentioned register or memory information.

[0042] (Emulator 200) Next, the emulator 200 will be described. The emulator 200 is configured with a virtual CPU, virtual memory, etc., and in this embodiment has the function of executing a sample program, a program to be analyzed, etc. The emulator 200 is realized by a physical PC, and the sample program, the program to be analyzed, etc. run on this emulator.

[0043] The configuration of the emulator 200 will now be described with reference to Fig. 3. The emulator 200 includes a communication unit 210, a storage unit 220, and an execution unit 230, as shown in Fig. 3.

[0044] (Communication unit 210) The communication unit 210 exchanges various types of information with the analysis device 100. Note that, in this embodiment, the emulator 200 will be described on the assumption that it exchanges information with the analysis device 100 via the communication unit 210, but information may be exchanged without going through the communication unit 210.

[0045] (Storage unit 220) The storage unit 220 stores data and programs necessary for various processes performed by the execution unit 230. Specifically, the storage unit 220 stores a sample program 2201 and an analysis target program 2202. Note that the storage unit 220 may store programs other than the above-mentioned programs as needed.

[0046] (Sample program 2201) The sample program 2201 stored in the storage unit 220 is a program with the same architecture as the analysis target program 2202, and is generated based on the sample code 2201a shown in FIG.

[0047] (Analysis target program 2202) The analysis target program 2202 stored in the storage unit 220 is a program that is the target of analysis by the analysis system 1. For example, the analysis target program 2202 is expressed as guest code 2202a as shown in Fig. 4. Fig. 4 shows how the execution unit 230 of the emulator 200 converts the guest code 2202a into intermediate code.

[0048] The "mov eax,0x3f" included in the guest code 2202a shown in FIG. 4 is converted into two intermediate codes, "mov_i64 tmp0,$0x3f" and "ext32u_i64 rax,tmp0". The "eax" in the guest code 2202a shown in FIG. 4 represents the eax register in the virtual CPU. On the other hand, the "rax" and "tmp0" that appear in the intermediate code represent the names of intermediate code variables. The guest code 2202a indicates that before the "syscall1" instruction that executes the system call is executed, the system call number (03xf in this case) is stored in an intermediate code variable named "rax", which is different from the rax register of the virtual CPU.

[0049] (execution unit 230) 3, the description will be continued. The execution unit 230 executes the programs stored in the storage unit 220. The execution unit 230 includes a virtual CPU 231 and a virtual memory 232.

[0050] (Virtual CPU 231) The virtual CPU 231 has the functions of a central processing unit (CPU) in a virtualized PC that runs an OS (Operating System), application software, etc. As shown in Fig. 3, the virtual CPU 231 has a plurality of registers, including a register 2310, a register 2311, a register 2312, and a register 231n. Note that while four registers are shown in Fig. 3, the number of registers that the virtual CPU 231 has is not limited to four, and the virtual CPU 231 may have any other number of registers.

[0051] (Virtual Memory 232) The virtual memory 232 is a memory area to which virtual addresses are assigned by the OS, and a running program accesses the virtual memory via the OS.

[0052] [2-2. Processing Procedure] Next, the procedure of the analysis method according to the first embodiment will be described with reference to Fig. 5. First, the emulator 200 cross-compiles the sample code to generate a sample program with the same or similar architecture as the program to be analyzed (step S100). Next, the emulator 200 executes the generated sample program (step S101). Then, the acquisition unit 131 of the analysis device 100 detects the execution of a known system call (step S102). Next, the acquisition unit 131 of the analysis device 100 acquires the system call number and the system call argument (step S103).

[0053] The creation unit 132 of the analysis device 100 identifies the intermediate code variable ID of the target (i.e., the variable that holds the same value as the acquired system call argument) based on the system call number and the system call argument (step S104). Next, the creation unit 132 of the analysis device 100 creates a constraint using the identified intermediate code variable ID (step S105). When the analysis device 100 determines that the execution of the system call remains, it returns to the previous step and continues processing (Yes in step S106).

[0054] After executing all system calls, the analysis device 100 determines that there are no system calls remaining to be executed (No in step S106). In this case, the creation unit 132 of the analysis device 100 performs allocation using an SMT solver based on the created constraints and creates a VA-Map (step S107).

[0055] The emulator 200 executes the program to be analyzed (step S108). Then, the reading unit 133 of the analysis device 100 detects the execution of a system call by the program to be analyzed (step S109). Next, the reading unit 133 of the analysis device 100 reads an argument from an intermediate code variable that holds the system call number of the executed system call (step S110). The extraction unit 134 of the analysis device 100 uses the read argument to extract information from a register or memory, etc. (step S111), and the process ends.

[0056] 3. Embodiment 2: Creation of a correspondence table based on library call arguments Next, as a second embodiment, the creation of a correspondence table based on library call arguments and the analysis of a program to be analyzed, which are realized by the analysis system 1, will be described. Note that the correspondence table in the second embodiment will also be referred to as a "VA-Map (Variable Argument Mapping)" as in the first embodiment. Note that only the differences in the procedure for creating a VA-Map will be described.

[0057] Sample code 2201a used in the second embodiment is similar to sample code 2201a in the first embodiment, but is a program that implements a library call rather than a system call. In the second embodiment, the emulator 200 executes the sample program 2201 that implements the library call. Then, the acquisition unit 131 of the analysis device 100 acquires the address of the library call, which is an identifier that identifies the library call, and the library call argument.

[0058] Furthermore, in the second embodiment, when the value of an argument held by an intermediate code variable indicates a referenceable memory area, the acquisition unit 131 of the analysis device 100 also acquires the memory value at the offset ±m bytes of the corresponding memory area together with the offset value. Then, the creation unit 132 of the analysis device 100 creates a constraint including the intermediate code variable ID and the offset based on the value of each argument of the library call.

[0059] Next, the reading unit 133 of the analysis device 100 reads the VA-Map when it captures the execution of a library call of the analysis target program by the emulator 200. Then, when the value of the VM-MAP includes an offset, the reading unit 133 of the analysis device 100 calculates an address by adding the offset to the memory area pointed to by the value of the argument held by the intermediate code variable identified by the intermediate code variable ID, and outputs the value at that address as the value of the argument.

[0060] [3-1. Configuration of analysis device and emulator] From here, the configuration of the analysis system 1 in the second embodiment will be described with reference to Fig. 3 again. The analysis system 1 in the second embodiment has a device configuration including an analysis device 100 and an emulator 200. Note that the device configuration in the second embodiment is the same as that in the first embodiment, and in this section, only the additional functions of the acquisition unit 131 and creation unit 132 will be described as differences, and detailed description of the other functions will be omitted.

[0061] (Acquisition part 131) The acquisition unit 131 of the second embodiment executes a library call as a known operation, and acquires a library call argument that is an output argument, a library call address that is an identifier that identifies the library call, and, if a predetermined condition is satisfied, a value in memory and its offset. Note that the information acquired by the acquisition unit 131 of the second embodiment is not limited to the library call arguments described above, and information about other arguments may be acquired.

[0062] Additionally, when the value of the argument held by the intermediate code variable points to a referenceable memory area, the acquiring unit 131 of the second embodiment also acquires the value in memory at the offset ±m bytes of the corresponding memory area.

[0063] (Creation Department 132) The creation unit 132 of the second embodiment creates a correspondence table (VA-Map in the second embodiment) based on the library call argument, the address of the library call, the intermediate code variable ID that identifies the intermediate code variable that holds the same value as the library call argument, and the offset. Note that the creation unit 132 of the second embodiment may create a correspondence table in a format other than the VA-Map described above.

[0064] Furthermore, based on the address of the acquired library call and the library call argument, the creation unit 132 identifies the target intermediate code variable ID (i.e., the intermediate code variable that holds the same value as the acquired library call argument) and, if the intermediate code variable indicates a memory area where the variable is located, also identifies its offset. For example, with respect to a certain argument of a library call, if the intermediate code variable ID=X and a value the same as the argument is found at a position where the memory address is X+Y (offset is +Y), the creation unit 132 of the second embodiment creates a constraint such as "arg1=(X,+Y)".

[0065] (readout section 133) When the reading unit 133 of the analysis device 100 of the second embodiment captures the execution of a library call of the analysis target program by the emulator 200, it reads the first argument of the target using the VA-Map. For example, when the argument is "arg1=(X,+Y)", the reading unit 133 of the analysis device 100 calculates the offset +Y from the memory area pointed to by the value of the argument held by the intermediate code variable identified by the intermediate code variable ID=X, and outputs the value at that address as the value of the first argument.

[0066] [3-2. Processing Procedure] Next, the procedure of the analysis method according to the second embodiment will be described with reference to Fig. 6. First, the emulator 200 cross-compiles the sample code to generate a sample program with the same or similar architecture as the program to be analyzed (step S200). Next, the emulator 200 executes the generated sample program (step S201). Then, the acquisition unit 131 of the analysis device 100 detects the execution of a known library call (step S202). Next, the acquisition unit 131 of the analysis device 100 acquires the library call argument and the address of the library call (step S203).

[0067] The creation unit 132 of the analysis device 100 identifies the target intermediate code variable ID (i.e., the intermediate code variable ID that holds the same value as the acquired library call argument) based on the address of the library call and the library call argument (step S204). If there is no intermediate code variable that matches the argument value, the analysis device 100 treats the value of the intermediate code variable as a pointer and searches for the corresponding value at a position ±m bytes in memory. Next, the creation unit 132 of the analysis device 100 creates a constraint using the identified intermediate code variable ID and the acquired offset (step S205). Then, when the analysis device 100 determines that execution of the library call remains, it returns to the previous step and continues processing (Yes in step S206).

[0068] After executing all the library calls, the analysis device 100 determines that there are no more library calls to be executed (No in step S206). In this case, the creation unit 132 of the analysis device 100 performs allocation using an SMT solver based on the created constraints and creates a VA-Map (step S207).

[0069] The emulator 200 executes the program to be analyzed (step S208). Then, the reading unit 133 of the analysis device 100 detects the execution of a library call by the program to be analyzed (step S209). Next, the reading unit 133 of the analysis device 100 calculates a memory address from the memory area and offset indicated by the value of the intermediate code variable, and reads the argument at the corresponding address (step S210). The fetching unit 134 of the analysis device 100 uses the read argument to fetch register or memory information, etc. (step S211), and the process ends.

[0070] 4. Embodiment 3: Creation of a Correspondence Table Based on Virtual CPU Register Values Next, as a third embodiment, the creation of a correspondence table based on register values ​​of a virtual CPU and the analysis of a program to be analyzed, which are realized by the analysis system 1, will be described. Note that the correspondence table in the third embodiment is called a "VR-Map (Variable Register Mapping)." Note that only the differences in the procedure for creating a VR-Map will be described.

[0071] The sample code 2201a used in the third embodiment is similar to the sample code 2201a of the first embodiment, but is not a system call, but a program including a function that outputs information (hereinafter referred to as "register value") held in a register of an emulator on which the analysis target program runs. Then, the acquisition unit 131 of the analysis device 100 acquires the register value output when the emulator 200 executes the sample program 2201 compiled from the sample code 2201a used in the third embodiment. Next, the creation unit 132 of the analysis device 100 extracts values ​​having the register value from the values ​​held by the intermediate code variables, and creates a constraint using the ID of the intermediate code variable.

[0072] Then, the creation unit 132 of the analysis device 100 identifies an intermediate code variable ID having the same value as the register value output from the sample program 2201, and creates a VR-Map. After that, the reading unit 133 of the analysis device 100 obtains the value of the specific register from the corresponding intermediate code variable using the VR-Map.

[0073] [4-1. Configuration of analysis device and emulator] From here, the configuration of the analysis system 1 in the third embodiment will be described with reference to Fig. 3 again. The analysis system 1 in the third embodiment has a device configuration including an analysis device 100 and an emulator 200. The device configuration in the third embodiment is basically the same as that in the first embodiment, and in this section, only the additional functions of the acquisition unit 131 and creation unit 132 will be described as differences, and detailed description of the other functions will be omitted.

[0074] (Acquisition part 131) The acquiring unit 131 of the third embodiment executes a program that is the same as or similar to the analysis target program, which outputs register values ​​held in registers of a virtual CPU, as a known operation, and acquires the register values. Note that the information acquired by the acquiring unit 131 of the third embodiment is not limited to the register values ​​described above, and the acquiring unit 131 may acquire information related to other arguments.

[0075] (Creation Department 132) The creation unit 132 of the third embodiment creates a correspondence table (a VR-Map in the third embodiment) based on a register value and an intermediate code variable ID that identifies an intermediate code variable that holds the same value as the register value. Note that the creation unit 132 of the third embodiment may create a correspondence table in a format other than the VR-Map described above.

[0076] Furthermore, the creation unit 132 of the third embodiment identifies an intermediate code variable ID having the same value as the acquired register value. Also, the creation unit 132 of the analysis device 100 of the third embodiment extracts the register value from the argument held by the intermediate code variable, and creates a constraint.

[0077] [4-2. Processing Procedure] Next, the procedure of the analysis method according to the third embodiment will be described with reference to Fig. 7. First, the emulator 200 cross-compiles the sample code to generate a sample program with the same or similar architecture as the program to be analyzed (step S300). Next, the emulator 200 executes the generated sample program (step S301). Then, the acquisition unit 131 of the analysis device 100 detects the execution of the sample program (step S302). Next, the acquisition unit 131 of the analysis device 100 acquires all register values ​​of the virtual CPU obtained by the execution of the sample program (step S303).

[0078] The creation unit 132 of the analysis device 100 identifies an intermediate code variable ID having the same value as the acquired register value (step S304). Subsequently, the creation unit 132 of the analysis device 100 searches for the register value from the values ​​held by the intermediate code variables and creates a constraint (step S305). The creation unit 132 of the analysis device 100 performs allocation using an SMT solver based on the created constraint and creates a VR-Map (step S306).

[0079] The emulator 200 executes the program to be analyzed (step S307). Then, the reading unit 133 of the analysis device 100 detects the execution of a system call or a library call by the program to be analyzed (step S308). The reading unit 133 of the analysis device 100 reads the target register value from the corresponding intermediate code variable (step S309). The extraction unit 134 of the analysis device 100 extracts register or memory information, etc. (step S310), and the process ends.

[0080] [5. Effects] In conventional technology, when using an emulator such as QEMU, the analysis module in the intermediate code layer can intervene in the execution of the program being analyzed regardless of the architecture, but when dumping the state of registers, memory, etc., it was sometimes necessary to be aware of registers and pointers specific to each architecture.As a concrete example, we will explain the case where an x86 (a general term for the instruction set architecture of the Intel 8086 and its backward compatible microprocessors) program being analyzed issues a system call using "sysenter."

[0081] For example, when a program being analyzed executes sysenter, the system call number, which indicates the type of system call, is stored in the "rax" register. The arguments passed to this system call are stored in the corresponding order in "rdi," "rsi," "rdx," "rcx," "r8," and "r9." When the analysis module in the intermediate code layer captures the execution of sysenter, it needs to know the value of the rax register to determine the type of system call. The number of arguments passed is also determined based on the type of system call, and these values ​​are stored in "rdi," "rsi," "rdx," "rcx," "r8," and "r9," respectively. Therefore, to obtain more detailed information about the system call, it is necessary to know the values ​​stored in these registers and the memory values ​​they point to.

[0082] In addition, when the emulator converts the instructions of the program to be analyzed into intermediate code, in order to eliminate dependency on each architecture, the values ​​of each register are stored and used in variables (intermediate code variables) defined during the execution of the intermediate code. Therefore, the rax register, rdi register, etc. of the virtual CPU cannot be directly accessed from the intermediate code layer.

[0083] In other words, the analysis module in the intermediate code layer can intervene in the execution of each instruction without depending on the architecture of the program being analyzed, but in order to obtain information such as system call arguments (for example, register values ​​or memory values ​​pointed to by registers), it is necessary to be aware of the architecture of the program being analyzed, identify where the information of the virtual CPU of that architecture is stored, and extract the register values.

[0084] To summarize the above-mentioned problems, although the analysis module in the intermediate code layer can access intermediate code variables, it does not know the correspondence between the virtual CPU registers of each architecture and the intermediate code variables, and therefore it is not possible to know which intermediate code variable holds the desired register value.

[0085] Therefore, the analysis device 100 and emulator 200 according to this embodiment are characterized in that they create a correspondence table based on arguments, which are values ​​output by executing a known operation included in a program that is the same as or similar to the program to be analyzed, an identifier of the known operation, and an intermediate code variable ID that identifies an intermediate code variable that holds the same value as the argument, obtain an intermediate code variable ID that corresponds to a predetermined operation executed by the program to be analyzed, read out the argument identified by the intermediate code variable ID based on the correspondence table, and extract one or both of information about the register and memory of the virtual CPU on which the program to be analyzed runs, using the argument read out by the reading unit 133. Therefore, this embodiment provides the following effects.

[0086] The analysis device 100 has the effect of enabling identification of intermediate code variables that hold register values ​​of a virtual CPU in the architecture of a program to be analyzed, and facilitating extraction of register and memory information, etc. In other words, the analysis device 100 provides the effect of being able to create an analysis module that is independent of the architecture of the program to be analyzed, and to obtain more detailed information such as register and memory information.

[0087] [6. Hardware Configuration] The components of each device shown in the figure are conceptual functional units and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown, and all or part of each device can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc. Furthermore, all or any part of the processing functions performed by each device can be realized by a CPU and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic.

[0088] Furthermore, among the processes described in this embodiment, all or part of the processes described as being performed automatically can also be performed manually using known methods. In addition, the information including the processing procedures, control procedures, specific names, various data, and parameters shown in the drawings can be changed as desired unless otherwise specified.

[0089] [program] In one embodiment, the various devices constituting analysis device 100 and emulator 200 can be implemented by installing an analysis program that performs the above-described analysis as package software or online software on a desired computer. For example, by executing the above-described analysis program on an information processing device, the various devices constituting analysis device 100 and emulator 200 can function. The information processing device referred to here includes desktop and notebook personal computers. Other information processing devices also include mobile communication terminals such as smartphones, mobile phones, and PHS (Personal Handyphone Systems), as well as slate terminals such as PDAs (Personal Digital Assistants).

[0090] 8 is a diagram showing an example of a computer in which the various devices constituting analysis device 100 and emulator 200 are realized. Computer 1000 has, for example, memory 1010 and CPU 1020. Computer 1000 also has hard disk drive interface 1030, disk drive interface 1040, serial port interface 1050, video adapter 1060, and network interface 1070. These components are connected by bus 1080.

[0091] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores, for example, 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 1100. A removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120. The video adapter 1060 is connected to, for example, a display 1130.

[0092] The hard disk drive 1090 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the programs that define the processes of the various devices that constitute the analysis device 100 and the emulator 200 are implemented as program modules 1093 in which computer-executable code is written. The program modules 1093 are stored, for example, in the hard disk drive 1090. For example, the program modules 1093 for executing processes similar to those of the functional configurations of the various devices that constitute the analysis device 100 and the emulator 200 are stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD (Solid State Drive).

[0093] Furthermore, setting data used in the processing of the above-described embodiment is stored as program data 1094, for example, in the memory 1010 or the hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 or the program data 1094 stored in the memory 1010 or the hard disk drive 1090 into the RAM 1012 as necessary, and executes the processing of the above-described embodiment.

[0094] The program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may also be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (such as a LAN or a WAN (Wide Area Network)). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

[0095] [7. Other] Although the present embodiment has been described above, the present embodiment is not limited by the descriptions and drawings that form part of the disclosure. In other words, other embodiments, examples, operational techniques, etc. that are made by those skilled in the art based on the present embodiment are all included in the scope of the present embodiment. [Explanation of symbols]

[0096] 1. Analysis system 100 Analyzer 110 Communications Department 120 Storage section 121 Intermediate code variable storage 122 Correspondence information storage unit 130 Control Unit 131 Acquisition Department 132 Creation Department 133 Reading section 134 Removal part 200 emulators 210 Communications Department 220 Storage section 2201 Sample Program 2201a Sample Code 2202 Analysis target program 2202a Guest Code 230 Executive Department 231 virtual CPUs 2310 Register 2311 Register 2312 Register 231n Register 232 Virtual Memory 1000 computers 1010 memory 1011 ROM 1012 RAM 1020 CPU 1030 hard disk drive interface 1040 disk drive interface 1050 serial port interface 1060 video adapter 1070 Network Interface 1080 Bus 1090 hard disk drive 1091 OS 1092 Application Program 1093 Program Module 1094 Program Data 1100 disk drive 1110 Mouse 1120 keyboard

Claims

1. a creation unit that creates a correspondence table based on arguments that are values ​​output by executing known operations included in a program that is the same as or similar to the analysis target program, identifiers of the known operations, and intermediate code variable IDs that identify intermediate code variables that hold the same values ​​as the arguments; a reading unit that acquires the intermediate code variable ID corresponding to a predetermined operation executed by the analysis target program, and reads the argument identified by the intermediate code variable ID based on the correspondence table; an extracting unit that extracts either or both of register information and memory information of a virtual CPU on which the analysis target program runs, using the arguments read by the reading unit; An analysis device comprising:

2. an acquisition unit that executes a system call as the known operation and acquires a system call argument that is the argument that is output and a system call number that is an identifier that identifies the system call; the creation unit creates a correspondence table based on the system call arguments, the system call numbers, and intermediate code variable IDs that identify intermediate code variables that hold the same values ​​as the system call arguments.

2. The analysis device according to claim 1 .

3. an acquisition unit that executes a library call as the known operation, and acquires a library call argument that is the argument that is output, an address of the library call that is an identifier that identifies the library call, and a memory address if a predetermined condition is satisfied; the creation unit creates a correspondence table based on the library call arguments, the addresses of the library calls, intermediate code variable IDs that identify intermediate code variables that hold the same values ​​as the library call arguments, and the memory addresses.

2. The analysis device according to claim 1 .

4. an acquisition unit that executes a program that is identical to or similar to the analysis target program and outputs a register value held in a register of a virtual CPU as the known operation, and acquires the register value; the creation unit creates a correspondence table based on the register values ​​and intermediate code variable IDs that identify the intermediate code variables that hold the same values ​​as the register values.

2. The analysis device according to claim 1 .

5. An analysis method executed by an analysis device, comprising: a step of creating a correspondence table based on arguments, which are values ​​output by executing known operations included in a program that is the same as or similar to the analysis target program, identifiers of the known operations, and intermediate code variable IDs that identify intermediate code variables that hold the same values ​​as the arguments; a step of acquiring the intermediate code variable ID corresponding to a predetermined operation executed by the analysis target program, and reading out the argument identified by the intermediate code variable ID based on the correspondence table; extracting, by using the arguments read by a reading unit, either one or both of register information and memory information of a virtual CPU on which the analysis target program runs; An analysis method comprising:

6. An analysis program for causing a computer to function as the analysis device according to claims 1 to 4.

Images