WO2023067663A1 - 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム - Google Patents
解析機能付与方法、解析機能付与装置及び解析機能付与プログラム Download PDFInfo
- Publication number
- WO2023067663A1 WO2023067663A1 PCT/JP2021/038492 JP2021038492W WO2023067663A1 WO 2023067663 A1 WO2023067663 A1 WO 2023067663A1 JP 2021038492 W JP2021038492 W JP 2021038492W WO 2023067663 A1 WO2023067663 A1 WO 2023067663A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- analysis
- instruction
- virtual machine
- branch
- execution
- Prior art date
Links
- 238000004458 analytical method Methods 0.000 title claims abstract description 175
- 238000000034 method Methods 0.000 title claims description 183
- 238000013515 script Methods 0.000 claims abstract description 198
- 230000006870 function Effects 0.000 claims abstract description 141
- 238000012545 processing Methods 0.000 claims abstract description 121
- 230000015654 memory Effects 0.000 claims abstract description 72
- 238000001514 detection method Methods 0.000 claims description 184
- 230000008569 process Effects 0.000 claims description 104
- 238000012360 testing method Methods 0.000 claims description 65
- 230000008859 change Effects 0.000 claims description 19
- 238000010586 diagram Methods 0.000 description 34
- 238000003780 insertion Methods 0.000 description 31
- 230000037431 insertion Effects 0.000 description 31
- 230000006399 behavior Effects 0.000 description 22
- 238000010276 construction Methods 0.000 description 22
- 239000000284 extract Substances 0.000 description 20
- 238000012544 monitoring process Methods 0.000 description 13
- 206010047289 Ventricular extrasystoles Diseases 0.000 description 6
- 238000005129 volume perturbation calorimetry Methods 0.000 description 6
- 238000004422 calculation algorithm Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 239000012634 fragment Substances 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 239000000725 suspension Substances 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000006185 dispersion Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000009191 jumping Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000003211 malignant effect Effects 0.000 description 1
- 238000007634 remodeling Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000002864 sequence alignment Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
Definitions
- the present invention relates to an analysis function imparting method, an analysis function imparting device, and an analysis function imparting program.
- a malicious script is a script that behaves maliciously, and is a program that exploits the functions provided by the script engine to carry out attacks. In general, attacks are carried out using the default script engine of the operating system (OS), or the script engine of specific applications such as web browsers and document file viewers.
- OS operating system
- specific applications such as web browsers and document file viewers.
- script engines may require user permission, but they can also implement actions via the system, such as file operations, network communication, and process startup. Therefore, attacks using malicious scripts pose a threat to users in the same way as attacks using malware in executable files.
- Code obfuscation is a problem that arises when analyzing malicious scripts. Many malicious scripts are subjected to a process called obfuscation, which hinders analysis. Obfuscation deliberately increases the complexity of the code, making it difficult to analyze the code superficially. That is, it interferes with an analysis method called static analysis, which analyzes information obtained from the code without executing the script.
- the latter is an analysis obstruction in which a malicious script acquires information about the environment in which it is executed, and does not exhibit malicious behavior unless it meets certain conditions. For example, if a feature that is frequently seen in the analysis environment is found, it is determined that the user is being analyzed, and is used to interrupt analysis by interrupting execution.
- FIG. 31 is a diagram showing a code fragment showing an example of analysis obstruction.
- This code fragment acquires the number of cores of the CPU (Central Processing Unit) of the environment being executed, and if it is not 2 or more and 8 or less, it judges that the analysis environment is highly likely and terminates execution. It has an anti-analysis attack. Otherwise, it judges that it is not an analysis environment and shows malignant behavior.
- CPU Central Processing Unit
- Non-Patent Document 1 describes a technique for realizing symbolic execution, which is a type of multipath execution, for JavaScript (registered trademark). According to this method, in the conditional branching of a JavaScript script, it is possible to comprehensively follow the executable paths and observe the behavior.
- Non-Patent Document 2 describes a method for realizing route forced execution, which is a type of multipath execution, for JavaScript. According to this method, in the conditional branching of JavaScript scripts, all paths can be exhaustively traced and the behavior can be observed.
- Non-Patent Document 3 after manually remodeling the script engine in advance, by executing the script engine on the symbolic execution infrastructure for binary, the script executed on the script engine , describes a technique for realizing symbolic execution through a script engine. According to this technique, if there is a script engine that can be modified manually, any script language can be used to achieve general-purpose symbolic execution, exhaustively trace executable paths, and observe behavior.
- Non-Patent Document 4 describes a method of analyzing a virtual machine (VM) that malware often uses to obfuscate its own programs. According to this technique, by analyzing the VM, it is possible to obtain information on its architecture. Since it is the VM that controls script execution in the script engine, the concept of this method can be partly diverted.
- VM virtual machine
- Non-Patent Document 5 multipath execution of scripts is enabled by analyzing the script engine and adding code to realize the multipath execution function based on the obtained architecture information. According to this method, multipath execution can be realized for various script languages and engines.
- an attacker may intentionally cause an exception to stop analysis execution and interfere with analysis.
- multipath execution by path forced execution there are cases where forcing an execution path causes an exception that cannot occur in normal execution, and execution stops. Since the execution of analysis stops when an exception occurs, there is a demand for a technology that can continue the execution of analysis even when an exception occurs.
- the present invention has been made in view of the above, and provides an analysis function imparting method capable of imparting to a script engine an execution function that suppresses the execution stop due to an exception by skipping the function that caused the exception. , an analysis function imparting device and an analysis function imparting program.
- the analysis function imparting method of the present invention is an analysis function imparting method executed by an analysis function imparting device, in which a virtual machine of a script engine is analyzed and a hook is applied.
- a first analysis step of acquiring a hook point, which is a location where analysis code is inserted, and a virtual program counter, which is a variable that indicates the next virtual machine instruction to be executed, and a system of virtual machine instructions.
- a second analysis step of analyzing an instruction set architecture to obtain a branch virtual machine instruction that is a virtual machine instruction that causes a branch, and architecture information obtained by the analyzes in the first analysis step and the second analysis step.
- the pointer pointer in memory is set to the return destination of the function immediately before the pointer. and a provision step of providing an analysis function by applying a hook including a process of changing to.
- FIG. 1 is a diagram illustrating an example of an exception handler.
- FIG. 2 is a diagram illustrating an example of a hypervisor call using script API hooks.
- FIG. 3 is a diagram illustrating an example of the configuration of the analysis function imparting device according to the embodiment.
- FIG. 4 is a diagram showing an example of a test script used for detecting a virtual program counter (VPC).
- FIG. 5 is a diagram showing an example of a test script used for branch VM instruction detection.
- FIG. 6 is a diagram showing an example of an execution trace.
- FIG. 7 is a diagram illustrating an example of a VM execution trace.
- FIG. 8 is a diagram explaining processing of the VM instruction boundary detection unit.
- FIG. 9 is a diagram for explaining processing of the virtual program counter detection unit.
- FIG. 1 is a diagram illustrating an example of an exception handler.
- FIG. 2 is a diagram illustrating an example of a hypervisor call using script API hooks.
- FIG. 3 is
- FIG. 10 is a diagram explaining processing of the dispatcher detection unit.
- FIG. 11 is a diagram explaining processing of the branch VM instruction detection unit.
- FIG. 12 is a diagram explaining the VM branch trace construction process.
- FIG. 13 is a diagram for explaining call stack reconstruction processing.
- FIG. 14 is a diagram for explaining the virtual stack/virtual stack pointer detection process.
- FIG. 15 is a diagram for explaining the virtual stack unwinding process.
- FIG. 16 is a flow chart showing a processing procedure of analysis function imparting processing according to the embodiment.
- FIG. 19 is a flowchart of the procedure of the VM instruction boundary detection process shown in FIG. 16;
- FIG. 20 is a flowchart showing a processing procedure of virtual program counter detection processing shown in FIG.
- FIG. 21 is a flow chart showing a processing procedure of dispatcher detection processing shown in FIG.
- FIG. 22 is a flowchart of a procedure of a VM execution trace acquisition process shown in FIG. 16;
- FIG. 23 is a flowchart showing a processing procedure of the branch VM instruction detection process shown in FIG. 16;
- FIG. 24 is a flow chart showing the procedure of the hook inserting process shown in FIG.
- FIG. 25 is a flowchart illustrating the processing procedure of VM branch trace construction processing.
- FIG. 26 is a flowchart showing the procedure of call stack reconstruction processing.
- FIG. 27 is a flow chart showing a processing procedure of virtual stack/virtual stack pointer detection processing.
- FIG. 28 is a flowchart showing a processing procedure of virtual stack unwinding processing.
- FIG. 29 is a flowchart showing the procedure of the exception handler insertion process shown in FIG. 16;
- FIG. 30 is a diagram showing an example of a computer that implements the analysis function imparting device by executing a program.
- FIG. 31 is a diagram showing a code fragment showing an example of anti-analysis.
- An analysis function imparting device is an analysis function imparting device that can be applied to a script engine.
- the analysis function imparting device executes a test script while monitoring the binary of the script engine, and acquires branch traces and memory access traces as execution traces.
- the analysis function imparting device analyzes the virtual machine based on this execution trace, hook points, tap points, a virtual program counter (VPC) which is a variable indicating the VM instruction to be executed next, a boundary of the VM instruction, Get dispatcher architecture information. All of these are components of the script engine, are information about architecture, and are stored in the architecture information DB 132 (described later).
- VPC virtual program counter
- the analysis function imparting device executes the test script to obtain a VM execution trace, and uses this VM execution trace to analyze the instruction set architecture. As a result, the analysis function imparting device acquires a branch VM instruction, which is a VM instruction that causes a branch within the script, as architecture information.
- the analysis function imparting device executes the test script to acquire the VM execution trace, and uses this VM execution trace to detect the amount of change (offset) of the VPC. As a result, the analysis function imparting device acquires the amount of change in the VPC as architecture information.
- the analysis function imparting device inserts a hook using a hook handler based on the hook point of the script engine. Furthermore, the analysis function imparting device inserts an exception handler into the script to be analyzed and imparts an exception handling function.
- the exception handler has a function of forcibly transferring processing to the VM area when an exception is caught.
- the hook handler is added with a function of skipping the function in which the exception occurred by changing the pointer in memory to the return destination of the function immediately before the pointer.
- the analysis function imparting device shifts the process to the VM area and skips the function in which the exception occurred as instructed in the hook handler, thereby suppressing the execution stop due to the exception. do.
- FIG. 1 is a diagram explaining an example of an exception handler.
- FIG. 2 is a diagram illustrating an example of a hypervisor call using script API hooks.
- the analysis function imparting device statically adds the contents of the frames E1 to E3 to the entry point of the script to be analyzed before execution ((1), (2 )).
- the analysis function imparting device adds "try” and “catch” codes to the entry point of the script to be analyzed (frames E1 and E2), and adds the code of frame E3. As in the third line, add the "hooked_script_API(e)" code that hooks the script API when an exception occurs. As a result, in the event of an exception, the script API is hooked and used as a hypervisor call to skip the exception ((3) in FIG. 1). That is, as shown in FIG. 2, the analysis function imparting device implements a hypervisor call equivalent by a script API hook ((1) in FIG. 2), so that when an exception occurs, processing is performed in the VM area. Go to and skip the function where the exception occurred as indicated in the hook handler.
- the analysis function imparting device catches an exception and inserts an exception handler into the script to be analyzed, thereby forcibly advancing the execution beyond the location where the exception occurred, thereby preventing unintended execution. Continue analysis while preventing stoppage.
- FIG. 3 is a diagram illustrating an example of the configuration of the analysis function imparting device according to the embodiment.
- the analysis function imparting device 10 has an input unit 11, a control unit 12, a storage unit 13, and an output unit . Then, the analysis function imparting device 10 receives inputs of the test script, the script engine binary, and the script to be analyzed.
- the input unit 11 is composed of input devices such as a keyboard and a mouse, receives input of information from the outside, and inputs the information to the control unit 12 . Further, the input unit 11 has a communication interface for transmitting and receiving various information to and from another device connected via a wired connection or a network, etc., and receives input of information transmitted from the other device. accept.
- the input unit 11 receives inputs of test scripts, script engine binaries, and scripts to be analyzed, and outputs them to the control unit 12 .
- a test script is a script input when dynamically analyzing a script engine to acquire an execution trace and a VM execution trace. Details of the test script will be described later.
- Script engine binaries are the executable files that make up the script engine.
- a script engine binary may consist of multiple executable files.
- An analysis target script is a script to be analyzed.
- the control unit 12 has an internal memory for storing programs defining various processing procedures and required data, and executes various processing using these.
- the control unit 12 is an electronic circuit such as a CPU (Central Processing Unit) or MPU (Micro Processing Unit).
- the control unit 12 has a virtual machine analysis unit 121 (first analysis unit), an instruction set architecture analysis unit 122 (second analysis unit), and a function addition unit 123 (addition unit).
- the virtual machine analysis unit 121 analyzes the VM of the script engine.
- the virtual machine analysis unit 121 acquires a plurality of execution traces by changing execution conditions, analyzes the plurality of execution traces using differential execution analysis, and acquires hook points, tap points, and VPCs. Also, the virtual machine analysis unit 121 analyzes the script engine binary to acquire the boundaries and dispatchers of VM instructions.
- the virtual machine analysis unit 121 has an execution trace acquisition unit 1211 , a hook/tap point detection unit 1212 , a VM instruction boundary detection unit 1213 , a virtual program counter detection unit 1214 , and a dispatcher detection unit 1215 .
- the execution trace acquisition unit 1211 accepts the test script and script engine binary as input.
- the execution trace acquisition unit 1211 acquires an execution trace by executing the test script while monitoring execution of the script engine binary.
- An execution trace consists of a branch trace and a memory access trace.
- the branch trace records the type of branch instruction, the branch source address, and the branch destination address at the time of execution.
- a memory access trace records the type of memory operation and the memory address of the operation target. Branch traces and memory access traces are known to be obtainable by instruction hooks.
- the execution trace acquired by the execution trace acquisition unit 1211 is stored in the execution trace DB 131 .
- the hook/tap point detection unit 1212 analyzes the virtual machine based on the execution trace acquired by the execution trace acquisition unit 1211 and detects hook points and tap points.
- a hook point is a place where a hook is applied and an analysis code is inserted.
- a function (referred to as an internal function) possessed by the internal implementation of the script engine is used as a unit, and the hook is applied at the beginning of this internal function.
- a tap point is a memory monitoring location where a log is output by the analysis code, and is assumed to be one of the arguments of an internal function.
- the hook/tap point detection unit 1212 extracts and analyzes the execution traces stored in the execution trace DB 131 to discover hook point candidates.
- the hook/tap point detection unit 1212 searches the execution trace for system API calls related to the analysis target, and detects hook point candidates by back tracing from there.
- the hook/tap point detection unit 1212 detects a hook point by applying a backtrace from a system API corresponding to a language element to be analyzed (for example, a script API).
- the hook/tap point detection unit 1212 detects hook point candidates by extracting differences between a plurality of execution traces with different acquisition conditions and finding portions that satisfy specific conditions.
- the hook/tap point detection unit 1212 detects a hook point based on differences observed between execution traces with a plurality of conditions changed.
- the hook/tap point detection unit 1212 detects hook points using an algorithm (for example, the Smith-Waterman algorithm) that detects occurrences of sequences with high homology a specific number of times.
- the hook/tap point detection unit 1212 detects the tap point by hooking the obtained hook point candidate and searching the memory for the argument of the hooked function.
- the hook/tap point detection unit 1212 detects a tap point, which is a memory monitoring location whose log is output by the analysis code, based on the monitoring at the hook point. Also, the hook/tap point detection unit 1212 determines a hook point candidate having a tap point as a hook point. For details of the processing of the hook/tap point detection unit 1212, refer to International Publication No. 2020/075335.
- the VM instruction boundary detection unit 1213 clusters the execution traces and detects the boundary of each VM instruction.
- the VM instruction boundary detection unit 1213 clusters the execution traces and detects clusters whose number of executions is equal to or greater than a threshold value as VM instructions. Clustering finds contiguous code regions that are executed multiple times. This may be done, for example, by grouping together code distances between executed instructions, by finding common subsequences of executed code blocks, or by other methods.
- the analysis function imparting device 10 detects the start point and the end point of the continuous instruction string forming the detected VM instruction as boundaries.
- the VM instruction boundary detected here is used in VPC detection and dispatcher detection.
- the virtual program counter detection unit 1214 extracts and analyzes the execution trace for the first test script stored in the execution trace DB 131 to detect the VPC.
- the virtual program counter detection unit 1214 analyzes a plurality of execution traces using differential execution analysis focusing on the number of times of memory reading and the boundary of each VM instruction detected by the VM instruction boundary detection unit 1213, and detects a VPC. .
- the virtual program counter detection unit 1214 utilizes the fact that reading into the memory holding the VPC always occurs after execution of each VM instruction, and detects the VPC by finding the reading destination.
- the virtual program counter detection unit 1214 uses differential execution analysis focusing on the number of times of memory reading for VPC detection.
- the virtual program counter detection unit 1214 compares the execution traces of a plurality of test scripts acquired using the test scripts, and finds that the number of memory reads is proportional to both the number of repetitions and the number of statements to be repeated. Discover changing memory. Then, the virtual program counter detection unit 1214 refers to the boundary of each VM instruction detected by the VM instruction boundary detection unit 1213, and narrows down the read memory values to those that always point to the starting point of the VM instruction. The virtual program counter detector 1214 detects this memory as a VPC.
- the dispatcher detection unit 1215 cuts out each VM instruction part from the script engine binary based on the VM instruction boundary detected by the VM instruction boundary detection unit 1213, and detects a part with a high degree of similarity between each VM instruction as a dispatcher.
- the dispatcher is implemented by referring to the pointer cache and jumping to the pointer of the next VM instruction handler.
- Dispatchers are distributed behind each VM instruction handler and generally their code is highly identical. By looking for highly identical code that resides behind these VM instruction handlers, the analyzer detects the dispatcher in a predetermined manner.
- a sequence alignment algorithm for example, may be used to detect portions with a high degree of similarity, or other methods may be used.
- the instruction set architecture analysis unit 122 analyzes the instruction set architecture, which is the system of VM instructions.
- the instruction set architecture analysis unit 122 has a VM execution trace acquisition unit 1221 (first acquisition unit), a branch VM instruction detection unit 1222 (first detection unit), and a VPC offset detection unit 1223 .
- the VM execution trace acquisition unit 1221 accepts test scripts and script engine binaries as inputs.
- the VM execution trace acquisition unit 1221 acquires the VM execution trace by monitoring the VPC and the pointer of the VM instruction handler dispatched by the dispatcher.
- the VM execution trace acquisition unit 1221 acquires the VM execution trace, which is the execution trace executed on the VM, by executing the test script while monitoring execution of the script engine binary.
- the VM execution trace acquisition unit 1221 acquires a VM execution trace by executing a large number of test scripts upon detection of a branch VM instruction.
- the VM execution trace acquisition unit 1221 associates a pointer to a VM instruction with a VM instruction, and virtually assigns a VM opcode to each as an identifier.
- a VM execution trace is a record of pointers to executed VM instruction handlers and VPCs.
- a VM execution trace consists of a VPC and a VM opcode for each executed VM instruction. Recording of the VPC can be realized by monitoring the memory of the VPC detected by the virtual program counter detection unit 1214 .
- a VM opcode is an identifier virtually assigned to each linking a pointer to a VM instruction and a VM instruction.
- the VM execution trace acquired by the VM execution trace acquisition unit 1221 is stored in the VM execution trace DB 133 .
- the branch VM instruction detection unit 1222 extracts and analyzes the VM execution trace stored in the VM execution trace DB 133 to detect branch VM instructions.
- the branch VM instruction detection unit 1222 collects the amount of change in VPC before and after the execution of each VM opcode assigned as an identifier. If the VM opcode is anything other than a branch VM instruction, the amount of change in VPC is approximately constant. On the other hand, if the VM opcode is for a branch VM instruction, the VPC varies depending on the branch destination.
- the branch VM instruction detection unit 1222 detects branch VM instructions based on variations in the amount of change in the virtual program counter for each VM opcode in the VM execution trace.
- the branch VM instruction detection unit 1222 pays attention to the fact that the magnitude of variation in the VPC value is different between the branch VM instruction and the other VM instructions, and determines a threshold value to branch the one with the larger variation in the VPC value. Detect as a VM instruction.
- the branch VM instruction detection unit 1222 evaluates variations in the amount of change in the VPC for each VM opcode in terms of variance, and detects a branch VM instruction whose variance is greater than or equal to a certain threshold.
- the VPC offset detection unit 1223 extracts the VM execution trace acquired by the VM execution trace acquisition unit and stored in the VM execution trace DB 133 and analyzes the VM execution trace log.
- the VPC offset detection unit 1223 acquires the operation code of the VM instruction and the VPC change amount before and after the execution of the VM instruction as a set from the VM execution trace.
- the function adding unit 123 inserts a hook into the script engine, inserts an exception handler into the script to be analyzed, and adds an exception processing function.
- the function provision unit 123 Based on the VPC and the branch VM instruction, which are the architecture information obtained by the analysis by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122, the function provision unit 123 detects an exception at the hook point of the script engine. is provided with an analysis function by applying a hook including a process of changing the point pointed to by the pointer in memory to the return point of the function immediately before the pointed point.
- the function imparting unit 123 has a hook inserting unit 1231 and an exception handler inserting unit 1232 .
- the hook insertion unit 1231 inserts hooks into the script engine.
- the hook insertion unit 1231 hooks the script engine based on the architecture information obtained by the analysis by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122 .
- the hook insertion unit 1231 receives hook points and tap points, and based on the hook points and tap points, inserts hooks into the script engine using hook handlers to provide analysis functions.
- the hook handler includes a process of changing the point of a pointer in memory (VSP: virtual stack pointer) to the return destination of the function immediately before the point of interest in the VM area.
- VSP virtual stack pointer
- the hook insertion unit 1231 causes the hook handler to perform VM branch trace construction processing (first processing), call stack reconstruction processing (second processing), virtual stack/virtual stack pointer detection processing (third process) and virtual stack pointer unwinding process (fourth process) are added.
- the hook is added with a function of changing the point pointed to by the pointer (VSP) in memory to the return point of the function immediately before the pointed point and skipping the function in which the exception occurred.
- VSP point pointed to by the pointer
- the VM branch trace construction process constructs a VM branch trace that associates VPCs before and after execution of a branch VM instruction.
- the call stack reconstruction process builds a call stack from virtual machine branch traces.
- the virtual stack/virtual stack pointer detection process detects a memory area that satisfies a predetermined condition regarding commonality with the call stack as a virtual stack, and further detects a memory area pointing to the virtual stack as a virtual stack pointer.
- the virtual stack pointer unwinding process changes the pointer of the virtual stack pointer to the return destination of the function immediately before the pointer.
- the exception handler insertion unit 1232 inserts an exception handler into the script to be analyzed, and gives it an exception handling function.
- the exception handler has a function of forcibly transferring processing to the VM area when an exception is caught.
- the exception handler insertion unit 1232 analyzes the script to be analyzed, and adds exception handler code (for example, see FIG. 1) to each entry point so that exceptions in the code after the entry point can be caught. , to insert an exception handler.
- the storage unit 13 is implemented by a semiconductor memory device such as RAM (Random Access Memory) and flash memory, or a storage device such as a hard disk and an optical disk, and stores a processing program for operating the analysis function imparting device 10, a processing Data used during program execution is stored.
- the storage unit 13 has an execution trace database (DB) 131 , a VM execution trace DB 133 , and an architecture information DB 132 storing architecture information acquired by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122 .
- DB execution trace database
- the execution trace DB 131 and VM execution trace DB 133 store execution traces and VM execution traces acquired by the execution trace acquisition unit 1211 and VM execution trace acquisition unit 1221, respectively.
- the execution trace DB 131 and VM execution trace DB 133 are managed by the analysis function imparting device 10 .
- the execution trace DB 131 and the VM execution trace DB 133 may be managed by another device (server or the like). Via the communication interface, the acquired execution trace and VM execution trace are output to the management server of the execution trace DB 131 and VM execution trace DB 133 and stored in the execution trace DB 131 and VM execution trace DB 133 .
- the output unit 14 is, for example, a liquid crystal display, a printer, etc., and outputs various information including information about the analysis function imparting device 10 . Further, the output unit 14 may be an interface that controls input/output of various data with an external device, and may output various information to the external device.
- test script is a script that is input when dynamically analyzing the script engine. This test script focuses on the execution of branch instructions and the number of memory read/writes, and is used to capture the difference in behavior of the script engine that occurs when the test script is executed a different number of times. This test script is prepared in advance for analysis and is created manually. This creation requires knowledge of the specifications of the target script language.
- FIG. 4 is a diagram showing an example of a test script (first test script) used for detecting a virtual program counter (VPC).
- the first test script uses iteration (line 2).
- line 2 the number of repetitions
- lines 3 to 5 the number of sentences to be repeated
- FIG. 5 is a diagram showing an example of a test script (second test script) used for branch VM instruction detection.
- the second test script uses conditional branching multiple times (lines 4 to 8). In the second test script, this multiple conditional branching controls the branching conditions so that branches are taken or not taken in a particular pattern of order (lines 1, 5). In the second test script, the number of conditional branches and the order pattern of success/failure of branching are changed to generate a difference.
- FIG. 6 is a diagram showing an example of an execution trace.
- the execution trace consists of a branch trace and a memory access trace, as described above.
- FIG. 6 is a cutout of a portion of the execution trace.
- the configuration of the execution trace will be shown using FIG.
- trace indicates whether the log line is a branch trace or a memory access trace.
- a branch trace log line for example, has the format described in lines 1 to 10 in Figure 6, and consists of three elements: type, src, and dst.
- type indicates whether the executed branch instruction is a call instruction, a jmp instruction, or a ret instruction. Also, src indicates a branch source address, and dst indicates a branch destination address.
- the memory access trace log line for example, has the format described in lines 11 to 13 in Figure 6, and consists of three elements: type, target, and value. type indicates whether the memory access is read or write. target indicates a memory address to be accessed. In addition, the value of the result of memory access is stored in value.
- FIG. 7 is a diagram illustrating an example of a VM execution trace.
- a VM execution trace is a record of VM opcodes and VPCs, as described above.
- FIG. 7 is a cutout of a portion of the VM execution trace.
- the configuration of the VM execution trace will be shown using FIG.
- a VM execution trace log line for example, has the format shown in Fig. 7 and consists of two elements: vpc and vmop (vm opcode).
- vpc indicates the value of VPC.
- vmop indicates the value of the VM opcode virtually allocated to each pointer pointing to the head of the VM instruction handler to be executed, which is obtained from the pointer cache.
- FIG. 8 is a diagram for explaining the processing of the VM instruction boundary detection unit 1213. As shown in FIG.
- the VM instruction boundary detection unit 1213 detects the boundary of each VM instruction. At this time, the VM instruction boundary detection unit 1213 detects the VM instruction and its boundary for the threaded code type VM which is difficult to grasp the boundary of the VM instruction because it does not have an interpreter loop. Specifically, the VM instruction boundary detection unit 1213 extracts an execution trace from the execution trace DB 131 . Then, as shown in FIG. 8, the VM instruction boundary detection unit 1213 clusters the execution trace by a predetermined method, and sets clusters whose execution count is equal to or greater than a threshold as VM instructions (for example, VM instruction handlers 1 to 3). To detect. The VM instruction boundary detection unit 1213 detects a start point and an end point of a continuous instruction string forming a VM instruction as a boundary.
- the virtual program counter detection unit 1214 detects VPCs and pointer caches. The detection of the virtual program counter is realized by analyzing the memory access trace log of the acquired execution trace. The virtual program counter detection unit 1214 uses differential execution analysis that focuses on the number of times the memory is read.
- FIG. 9 is a diagram for explaining the processing of the virtual program counter detection unit 1214. As shown in FIG.
- the virtual program counter detection unit 1214 extracts one execution trace by the first test script from the execution trace DB 131.
- the number of VPC reads is proportional to the number of iterations in the test script and the number of statements in the iteration.
- N the number of repetitions
- M approximately MN VPC reads occur. Therefore, the virtual program counter detection unit 1214 extracts memories increased by 4MN and 9MN in the execution trace for the first test script in which N and M are increased by 2N and 2M, and 3N and 3M, respectively.
- the virtual program counter detection unit 1214 extracts a memory area that has read/write for each execution of one VM instruction and monotonically increases ((1) in FIG. 9).
- the virtual program counter detection unit 1214 detects as a VPC that the read memory value always points to the starting point of the VM instruction. Specifically, the virtual program counter detection unit 1214 collates the destination of the VPC with the address of the VM instruction handler, and narrows down to a matching memory area ((2) in FIG. 9).
- the dispatcher detection unit 1215 detects the dispatcher by analyzing the binary of the script engine using a predetermined technique.
- FIG. 10 is a diagram for explaining the processing of the dispatcher detection unit 1215. As shown in FIG.
- the dispatcher detection unit 1215 detects dispatchers.
- the dispatcher detection unit 1215 cuts out each VM instruction part from the script engine binary based on the VM instruction boundary detected by the VM instruction boundary detection unit 1213 . Then, the dispatcher detection unit 1215 calculates the similarity between the codes of each VM instruction based on the assumption that the similarity of the dispatcher code is high ((1) in FIG. 10), and calculates the similarity between all the VM instructions. Detect the high degree part as a dispatcher.
- the dispatcher detection unit 1215 can detect code commonly executed in the second half of VM instructions as a dispatcher ((1) in FIG. 10).
- the branch VM instruction detection unit 1222 detects the branch VM instruction by analyzing the acquired VM execution trace log. Since the test script here only needs to include a branch VM instruction, any script that includes branch control syntax may be used. For example, prepare a test script by collecting from the Internet or from official documents.
- the branch VM instruction detection unit 1222 associates a pointer to a VM instruction with a VM instruction for each VM execution trace in the VM execution trace DB 133, and virtually assigns a VM opcode to each as an identifier.
- FIG. 11 is a diagram for explaining the processing of the branch VM instruction detection unit 1222. As shown in FIG.
- the branch VM instruction detector 1222 uses variance to evaluate the dispersion of pointers to this VM instruction.
- the branch VM instruction detection unit 1222 calculates the variance of the VPC change amount for each VM opcode, and narrows down only the VM opcodes with the calculated variance larger than the threshold.
- the branch VM instruction detection unit 1222 detects a VM instruction (VM instruction handler 3 in the example of FIG. 11) with variation in VPC change amount as a branch VM instruction while associating the pointer with the VM instruction. ((1) in FIG. 11).
- the threshold is set to a value that can divide the resulting two groups by plotting the obtained variance values on a number line, for example.
- the hook inserting unit 1231 receives as inputs the script engine binary and the hook points and tap points detected in the processing up to this point.
- the hook inserting unit 1231 inserts a hook using a hook handler at a hook point to the script engine.
- the hook inserting unit 1231 inserts analysis code so that execution transitions to hook handler processing in the VM area when the script API corresponding to the hook is executed during hooking.
- Code for this analysis can be easily generated if the hook points and tap points are known.
- the function of the hook handler implemented in the VM area can be called as a hypervisor call, thereby providing the analysis function.
- the hook inserting unit 1231 provides the hook handler with a VM branch trace construction process for constructing a VM branch trace, a call stack reconstruction process for constructing a call stack, a virtual stack and a virtual stack for detecting a virtual stack and a virtual stack pointer.
- a pointer detection process and a virtual stack pointer rewind process for rewinding (skipping) the virtual stack pointer are added.
- FIG. 12 is a diagram explaining the VM branch trace construction process.
- a branch VM instruction is detected from the VM execution trace 41 recording the operation code of the executed VM instruction and the VPC ((1) in FIG. 12).
- a branch VM instruction can be recognized by referring to the branch VM instruction list 42 detected by the branch VM instruction detection unit 1222 .
- a VM branch trace 43 is constructed in which the VPCs before and after execution of the detected branch VM instruction are associated ((2) in FIG. 12).
- the branch VM instruction "0x1f" is detected from line R41 of the VM execution trace, and the VM branch trace shown in line R61 is constructed based on line R41 and line R42 next to line R42. . That is, in the VM branch trace construction process, the branch source VPC “0x555c7e48” on line R41 is associated with the branch source VPC “0x555c82a0” on line R42.
- FIG. 13 is a diagram explaining the call stack reconstruction process. As shown in FIG. 3, the call stack reconstruction process reconstructs the call stack from the VM branch traces. The inferred call stack in FIG. 13 corresponds to the reconstructed call stack.
- the call stack reconstruction process calculates the next VM instruction address "0x555c7e4c" from the branch source address "src: 0x555c7e48" and the VM instruction offset "+4".
- FIG. 14 is a diagram explaining the virtual stack/virtual stack pointer detection process.
- the virtual stack/virtual stack pointer detection process detects a memory area having high commonality with the estimated call stack as a virtual stack ((1) in FIG. 14). For example, the virtual stack/virtual stack pointer detection process detects, as a virtual stack, an area in which the ratio of the part common to the estimated call stack is equal to or greater than a predetermined value.
- the virtual stack/virtual stack pointer detection process detects the memory area that continues to point to the virtual stack as a virtual stack pointer (VSP) ((2) in FIG. 14).
- VSP virtual stack pointer
- the memory area that continues to point to the virtual stack can be said to be the area for the function being executed.
- FIG. 15 is a diagram explaining the virtual stack unwinding process. As shown in FIG. 15, the virtual stack unwinding process unwinds the virtual stack by changing the destination indicated by the detected virtual stack pointer to the return destination of the previous function. This will skip the running function.
- FIG. 16 is a flow chart showing a processing procedure of analysis function imparting processing according to the embodiment.
- the input unit 11 receives a test script and a script engine binary as input (step S1).
- the execution trace acquisition unit 1211 performs an execution trace acquisition process of executing the test script while monitoring the binary of the script engine and acquiring a branch trace and a memory access trace (step S2).
- the hook/tap point detection unit 1212 analyzes the virtual machine based on the execution trace acquired by the execution trace acquisition unit 1211, and performs hook/tap point detection processing for detecting hook points and tap points (step S3).
- the VM instruction boundary detection unit 1213 detects VM instructions and performs VM instruction boundary detection processing to detect the boundaries of VM instructions (step S4).
- the virtual program counter detection unit 1214 extracts and analyzes the execution trace for the first test script stored in the execution trace DB 131, and performs virtual program counter detection processing for discovering the VPC (step S5).
- the dispatcher detection unit 1215 extracts each VM instruction part from the script engine binary, and performs dispatcher detection processing to detect a part with a high degree of similarity between each VM instruction as a dispatcher (step S6).
- the VM execution trace acquisition unit 1221 receives a test script and a script engine binary as inputs, and performs VM execution trace acquisition processing for acquiring a VM execution trace by executing the test script while monitoring the execution of the script engine binary. (Step S7).
- the VPC offset detection unit 1223 performs VPC offset detection processing for acquiring, as a set, the operation code of the VM instruction and the VPC change amount before and after execution of the instruction from the VM execution trace (step S8).
- the branch VM instruction detection unit 1222 extracts and analyzes the VM execution trace stored in the VM execution trace DB 133, and performs branch VM instruction detection processing for detecting the branch VM instruction (step S9).
- the hook insertion unit 1231 performs hook insertion processing for inserting a hook into the script engine based on the architecture information acquired in the processing of steps S1 to S6 (step S10).
- the exception handler insertion unit 1232 inserts an exception handler into the script to be analyzed, and performs exception handler insertion processing for adding an exception handling function (step S11). Then, the output unit 14 outputs the script engine binary provided with the exception skip function (step S12).
- FIG. 17 is a flow chart showing a processing procedure of execution trace acquisition processing shown in FIG.
- the execution trace acquisition unit 1211 receives the test script and the script engine binary as inputs (step S21).
- the execution trace acquisition unit 1211 hooks the received script engine to acquire a branch trace (step S22).
- the execution trace acquisition unit 1211 also hooks the received script engine to acquire a memory access trace (step S23).
- the execution trace acquisition unit 1211 inputs the test script received in that state to the script engine to execute it (step S24), and stores the execution trace acquired thereby in the execution trace DB 131 (step S25).
- the execution trace acquisition unit 1211 determines whether all the input test scripts have been executed (step S26). If the execution trace acquisition unit 1211 has finished executing all the input test scripts (step S26: Yes), it ends the process. On the other hand, if the execution trace acquisition unit 1211 has not executed all of the input test scripts (step S26: No), it returns to execution of the test scripts in step S24 and continues processing.
- FIG. 18 is a flow chart showing a processing procedure of the hook/tap point detection processing shown in FIG. 16.
- FIG. 16 is a flow chart showing a processing procedure of the hook/tap point detection processing shown in FIG. 16.
- the hook/tap point detection unit 1212 detects hook point candidates (step S31). If a hook point candidate is detected (step S32: Yes), the hook/tap point detection unit 1212 proceeds to step S35. On the other hand, if no hook point candidate is detected (step S32: No), the hook/tap point detection unit 1212 detects a hook point based on the difference observed between the execution traces with a plurality of conditions changed. An execution analysis process is performed (step S33).
- step S34: No the hook/tap point detection unit 121210 terminates the process because there is no hook point candidate.
- step S34: Yes the hook/tap point detection unit 1212 proceeds to step S35.
- the hook/tap point detection unit 1212 detects a tap point (step S35).
- FIG. 19 is a flowchart of the procedure of the VM instruction boundary detection process shown in FIG. 16;
- the VM instruction boundary detection unit 1213 extracts an execution trace from the execution trace DB 131 (step S41).
- the VM instruction boundary detection unit 1213 clusters the execution traces by a predetermined method (step S42). Any method may be used for the clustering.
- the VM instruction boundary detection unit 1213 detects clusters whose number of executions is equal to or greater than the threshold as VM instructions (step S43). Then, the VM instruction boundary detection unit 1213 sets the start point and the end point of the continuous instruction string forming the VM instruction as the boundary (step S44). The VM instruction boundary detection unit 1213 outputs the VM instruction boundary as a return value (step S45), and ends the VM instruction boundary detection process.
- FIG. 20 is a flowchart showing a processing procedure of virtual program counter detection processing shown in FIG.
- the virtual program counter detection unit 1214 extracts one execution trace by the first test script from the execution trace DB 131 (step S51). Subsequently, the virtual program counter detection unit 1214 focuses on the memory access trace in the execution trace, and counts the number of times of reading for each memory reading destination (step S52).
- the virtual program counter detection unit 1214 receives as an input the first test script used to acquire the execution trace (step S53), analyzes the first test script, and detects the number of repetitions and the number of sentences to be repeated. Acquire (step S54).
- the virtual program counter detection unit 1214 extracts from the execution trace DB 131 one more execution trace of the first test script with a different repetition count and number of repeated sentences (step S55). Then, the virtual program counter detection unit 1214 pays attention to the memory access trace and counts the number of readings for each memory reading destination (step S56). In addition, the virtual program counter detection unit 1214 receives as an input the first test script used to acquire the execution trace (step S57), analyzes the test script, and acquires the number of repetitions and the number of repeated sentences. (step S58).
- the virtual program counter detection unit 1214 narrows down only memory read destinations whose read count changes in proportion to the number of repetitions and the increase or decrease in the number of repeated sentences (step S59). Furthermore, the virtual program counter detection unit 1214 narrows down the memory reading destinations narrowed down in step S59 to those in which the read memory value always points to the start point of the VM instruction (step S60).
- the virtual program counter detection unit 1214 determines whether or not the memory reading destination has been narrowed down to only one (step S61). If the virtual program counter detection unit 1214 cannot narrow down the memory reading destination to only one (step S61: No), the process returns to step S55, extracts the next execution trace, and continues the process. On the other hand, if the virtual program counter detection unit 1214 narrows down the memory reading destination to only one (step S61: Yes), it stores the narrowed down memory reading destination in the architecture information DB 132 as a virtual program counter (step S62). ) and terminate the process.
- FIG. 21 is a flow chart showing a processing procedure of dispatcher detection processing shown in FIG. 16
- the dispatcher detection unit 1215 receives the script engine binary as an input (step S71).
- the dispatcher detector 1215 receives the VM instruction boundary from the VM instruction boundary detector 1213 (step S72).
- the dispatcher detection unit 1215 cuts out each VM instruction part from the script engine binary based on the boundary of the VM instruction received from the VM instruction boundary detection unit 1213 (step S73).
- the dispatcher detection unit 1215 calculates the code similarity between each VM instruction by a predetermined method (step S74). Any similarity calculation method can be used as long as it can calculate the similarity between codes.
- the dispatcher detection unit 1215 extracts a portion with a high degree of similarity among all VM instructions based on the degree of similarity calculated in step S74 (step S75). Then, the dispatcher detection unit 1215 determines whether it is the end part of the VM instruction (step S76).
- step S76: No If it is not the end portion of the VM instruction (step S76: No), the dispatcher detection unit 1215 returns to step S75 and continues processing. If it is the end part of the VM instruction (step S76: Yes), the dispatcher detection unit 1215 outputs the extracted part as the dispatcher (step S77), and ends the process.
- FIG. 22 is a flowchart of a procedure of a VM execution trace acquisition process shown in FIG. 16;
- the VM execution trace acquisition unit 1221 receives the test script and the script engine binary as input (step S81). Then, the VM execution trace acquisition unit 1221 hooks the received script engine to record the VPC and VM operation code (step S82).
- the VM execution trace acquisition unit 1221 inputs the test script received in that state to the script engine to execute it (step S83), and stores the VM execution trace acquired thereby in the VM execution trace DB 133 (step S84).
- the VM execution trace acquisition unit 1221 determines whether all the input test scripts have been executed (step S85). If the VM execution trace acquisition unit 1221 has finished executing all the input test scripts (step S85: Yes), the process ends. If the VM execution trace acquisition unit 1221 has not finished executing all of the input test scripts (step S85: No), it returns to execution of the test scripts in step S83 and continues processing.
- FIG. 23 is a flowchart showing a processing procedure of the branch VM instruction detection process shown in FIG. 16;
- the branch VM instruction detection unit 1222 extracts one VM execution trace from the VM execution trace DB 133 (step S91).
- the branch VM instruction detection unit 1222 associates the pointer to the VM instruction with the VM instruction, and assigns a VM opcode to each as an identifier (step S92).
- the branch VM instruction detection unit 1222 aggregates the amount of change in VPC before and after execution for each VM opcode (step S93).
- the branch VM instruction detection unit 1222 determines whether or not all VM execution traces in the VM execution trace DB 133 have been processed (step S94). If all VM execution traces in the VM execution trace DB 133 have not been processed (step S94: No), the branch VM instruction detection unit 1222 returns to step S91 to extract and process the next VM execution trace.
- step S94 the branch VM instruction detection unit 1222 calculates the variance of the VPC variation for each VM opcode (step S95).
- the branch VM instruction detection unit 1222 receives the threshold as an input (step S96).
- the branch VM instruction detection unit 1222 narrows down to only VM opcodes whose variance is larger than the threshold (step S97), stores them as branch VM instructions in the architecture information DB 132 (step S98), and ends the process.
- FIG. 24 is a flow chart showing the procedure of the hook inserting process shown in FIG. 16
- the hook insertion unit 1231 receives as input the hook points and tap points detected by the hook/tap point detection unit 1212 (step S101), and prepares the hook handler (step S102).
- the hook insertion unit 1231 adds VM branch trace construction processing to the hook handler (step S103).
- the hook insertion unit 1231 adds call stack reconstruction processing to the hook handler (step S104).
- the hook insertion unit 1231 adds virtual stack/virtual stack pointer detection processing to the hook handler (step S105).
- the hook insertion unit 1231 adds virtual stack pointer unwinding processing to the hook handler (step S106).
- the hook insertion unit 1231 inserts a hook using the hook handler at the hook point (step S107).
- FIG. 25 is a flowchart illustrating the processing procedure of VM branch trace construction processing.
- a VM execution trace and a VM branch instruction list are received as inputs (step S111).
- a VM execution trace entry is taken out (step S112).
- step S113 if the VM opcode exists in the VM branch instruction list (step S113: Yes), the VPC is set as the branch source, and the VPC of the next entry is set as the branch destination and saved in the VM branch trace (step S114). .
- step S115 if the VM opcode does not exist in the VM branch instruction list (step S113: No), or after step S114 ends, it is determined whether or not all entries of the VM execution trace have been processed (step S115).
- step S115 if all entries in the VM execution trace have not been processed (step S115: No), the next entry in the VM execution trace is taken out (step S116). Then, in the VM branch trace construction process, the process returns to step S113 to determine whether the VM opcode exists in the VM branch instruction list for the next entry.
- step S115 when all the entries of the VM execution trace have been processed (step S115: Yes), the VM branch trace is output (step S117).
- FIG. 26 is a flowchart showing the procedure of call stack reconstruction processing.
- the call stack reconstruction process receives the VM branch trace as input (step S141).
- the call stack reconstruction process prepares the call stack to be reconstructed (step S142).
- the call stack reconstruction process takes out the first entry of the VM branch trace (step S143).
- the call stack reconstruction process calculates the address of the next VM instruction from the branch source address and the VM instruction offset (for example, +4) (step S144).
- the call stack reconstruction process pushes the calculated address onto the call stack (step S145).
- step S146 if all entries in the VM branch trace have not been processed (step S146: No), the next entry in the VM branch trace is taken out (step S147).
- step S146 When all entries in the VM branch trace have been processed (step S146: Yes), the call stack reconstruction process outputs the estimated call stack (step S148).
- FIG. 27 is a flowchart showing the processing procedure of virtual stack/virtual stack pointer detection processing.
- the virtual stack/virtual stack pointer detection process receives the estimated call stack as an input (step S151).
- the memory space is searched for a memory area having high commonality with the call stack by a predetermined method, and detected as a virtual stack (step S152).
- the virtual stack/virtual stack pointer detection process detects the memory area that continues to point to the virtual stack as the virtual stack pointer (step S153). Subsequently, the virtual stack/virtual stack pointer detection process outputs the virtual stack and the virtual stack pointer (step S154).
- FIG. 28 is a flowchart showing the processing procedure of the virtual stack unwinding process.
- the virtual stack pointer unwinding process receives the estimated call stack, virtual stack, and virtual stack pointer as inputs (step S161).
- the virtual stack pointer unwinding process confirms the current (at the time of exception occurrence) pointing to the virtual stack pointer (step S162).
- the virtual stack pointer unwinding process refers to the estimated call stack and confirms the return destination of the function immediately before the current pointer (step S163).
- the virtual stack pointer unwinding process traces back the virtual stack and detects the position where the return destination of the previous function is stored (step S164). Then, the virtual stack pointer unwinding process changes the value of the virtual stack pointer so as to point to the detected position (step S165).
- FIG. 29 is a flowchart showing the procedure of the exception handler insertion process shown in FIG. 16;
- the exception handler insertion unit 1232 receives the script to be analyzed as an input (step S171).
- the exception handler insertion unit 1232 analyzes the analysis target script by a predetermined method and extracts the entry point (step S172).
- the exception handler insertion unit 1232 extracts one entry point (step S173).
- the exception handler inserting unit 1232 adds exception handler code (eg, see FIG. 1) so that an exception can be caught in the code after the entry point (step S174).
- the exception handler insertion unit 1232 determines whether exception handlers have been added to all entry points (step S175). If exception handlers have not been added to all entry points (step S175: No), the exception handler insertion unit 1232 extracts the next entry point (step S176), proceeds to step S174, and adds exception handler code. do.
- step S175 Yes
- the analysis function imparting apparatus 10 executes the test script while monitoring the binary of the script engine, and acquires the branch trace and memory access trace as execution traces.
- the analysis function imparting device 10 analyzes the virtual machine based on the execution trace, and acquires hook points, tap points, VPC, VM instruction boundaries, and architecture information of the dispatcher. Furthermore, the analysis function imparting device 10 executes the test script to acquire the VM execution trace, analyzes the instruction set architecture using the VM execution trace, and acquires the branch VM instruction as architecture information.
- the analysis function imparting device 10 when an exception occurs at the hook point of the script engine, changes the pointer in the memory to the function immediately before the pointer. Apply a hook that includes processing to change the return destination of , and add an analysis function including an exception handling function.
- the analysis function imparting device 10 imparts an exception handling function to the script to be analyzed by inserting an exception handler that forcibly transfers processing to the VM area when an exception is caught.
- a hook is applied using a hook handler that includes a process of changing the point pointed to by the pointer in the memory to the return point of the function immediately preceding the point pointed to.
- the analysis function imparting device 10 skips the function in which the exception occurs, thereby suppressing the stoppage of execution due to the exception.
- the analysis function imparting device 10 can detect various architectural information by analyzing based on the acquisition of the execution trace and the VM execution trace even for a proprietary script engine that can only be obtained in binary, and perform manual reverse processing. It is possible to add an exception handling function without requiring engineering.
- the analysis function providing device 10 can automatically provide exception handling functions to various script engines as long as test scripts are prepared. Therefore, exception handling functions can be provided without the need for individual design and execution. can.
- the analysis function imparting device 10 is useful for analyzing the behavior of malicious scripts written in a wide variety of script languages. It is suitable for analyzing behavior without being affected by it. Therefore, by using the analysis function imparting device 10 to impart exception handling functions to various script engines, even if there is an exception, the behavior of the malicious script can be suppressed while suppressing the execution stop due to the exception. can be analyzed, it can be used for countermeasures such as detection.
- analysis function imparting device 10 can similarly catch exceptions and continue analysis while preventing unintended termination of execution even in multipath execution by forcing an execution path.
- Each component of the analysis function imparting apparatus 10 shown in FIG. 3 is functionally conceptual, and does not necessarily need to be physically configured as shown. That is, the specific form of distributing and integrating the functions of the analysis function imparting device 10 is not limited to the illustrated one, and all or part of it can be functionally or It can be physically distributed or integrated.
- each process performed in the analysis function imparting device 10 may be realized by a CPU and a program that is analyzed and executed by the CPU. Further, each process performed in the analysis function imparting device 10 may be realized as hardware by wired logic.
- FIG. 30 is a diagram showing an example of a computer that implements the analysis function imparting device 10 by executing a program.
- the computer 1000 has a memory 1010 and a CPU 1020, for example.
- 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 units are connected by a bus 1080 .
- the memory 1010 includes a ROM 1011 and a RAM 1012.
- the ROM 1011 stores a boot program such as BIOS (Basic Input Output System).
- BIOS Basic Input Output System
- Hard disk drive interface 1030 is connected to hard disk drive 1090 .
- a disk drive interface 1040 is connected to the disk drive 1100 .
- a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100 .
- Serial port interface 1050 is connected to mouse 1110 and keyboard 1120, for example.
- Video adapter 1060 is connected to display 1130, for example.
- the hard disk drive 1090 stores, for example, an OS 1091, application programs 1092, program modules 1093, and program data 1094. That is, a program that defines each process of the analysis function imparting apparatus 10 is implemented as a program module 1093 in which code executable by the computer 1000 is described. Program modules 1093 are stored, for example, on hard disk drive 1090 .
- the hard disk drive 1090 stores a program module 1093 for executing processing similar to the functional configuration of the analysis function imparting apparatus 10 .
- the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).
- the setting data used in the processing of the above-described embodiment is stored as program data 1094 in the memory 1010 or the hard disk drive 1090, for example. Then, the CPU 1020 reads out the program module 1093 and the program data 1094 stored in the memory 1010 and the hard disk drive 1090 to the RAM 1012 as necessary and executes them.
- the program modules 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in a removable storage medium, for example, and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program modules 1093 and program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). Program modules 1093 and program data 1094 may then be read by CPU 1020 through network interface 1070 from other computers.
- LAN Local Area Network
- WAN Wide Area Network
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
解析機能付与装置(10)は、スクリプトエンジンのVMを解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行されるVMの命令を指し示す変数であるVPCを取得する仮想機械解析部(121)と、VMの命令の体系である命令セットアーキテクチャを解析して、分岐を発生させるVM命令である分岐VM命令を取得する命令セットアーキテクチャ解析部(122)と、仮想機械解析部(121)及び命令セットアーキテクチャ解析部(122)による解析によって得られたアーキテクチャ情報である、VPC及び分岐VM命令に基づいて、スクリプトエンジンのフックポイントに、例外が発生した場合には、メモリにおける仮想スタックポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する処理を含むフックを施して解析機能を付与する機能付与部(123)と、を有する。
Description
本発明は、解析機能付与方法、解析機能付与装置及び解析機能付与プログラムに関する。
マルウェアを用いたスパム(マルスパム)やファイルレスマルウェアなどの多様な攻撃の形態が生じるにともなって、悪性な挙動を示すスクリプト(悪性スクリプト)による攻撃の脅威が顕在化している。
悪性スクリプトとは、悪意のある挙動を持ったスクリプトであり、スクリプトエンジンの提供する機能を悪用して攻撃を実現するプログラムである。一般に、オペレーティングシステム(Operating System:OS)がデフォルトで有するスクリプトエンジンや、Webブラウザや文書ファイルのビューアなど、特定のアプリケーションが有するスクリプトエンジンを用いて攻撃が実施される。
こうしたスクリプトエンジンの多くは、ユーザの許可が必要な場合もあるものの、ファイル操作やネットワーク通信、プロセスの起動など、システムを介した挙動も実現可能である。したがって、悪性スクリプトを用いた攻撃は、実行ファイルのマルウェアを用いた攻撃と同様に、ユーザに対しての脅威となる。
この悪性スクリプトによる攻撃に対策を講じるためには、スクリプトの持つ挙動を正確に把握する必要がある。したがって、スクリプトを解析することで、その挙動を明らかにする技術が希求される。
悪性スクリプトを解析する際に生じる問題として、コードの難読化がある。悪性スクリプトの多くは、難読化と呼ばれる、解析を妨害する処理が施されている。難読化は、故意にコードの複雑さを高めることで、コードの表層的な情報に基づく解析を困難にする。すなわち、スクリプトを実行せずに、コードから得られる情報で解析する、静的解析と呼ばれる解析方法を妨害する。
特に、実行するコードの一部を外部から動的に取得する場合は、そのコードは実行しなければ得られないため、静的には解析できない。したがって、静的解析はその原理上、不可能となる。
一方で、スクリプトを実行し、その振る舞いを監視することで挙動を知る動的解析と呼ばれる手法は、前述のような難読化の影響を受けない。このため、悪性スクリプトの解析においては、動的解析に基づく手法が主に用いられている。
一般的な動的解析では、解析環境で悪性スクリプトを実行し、その挙動を監視することにより、悪性スクリプト中で実行された単一の実行経路の挙動のみが得られる。このため、解析環境で実行されなかった経路の挙動は得ることができないという問題がある。
言い換えると、特定の条件下でしか実行されない経路を有する悪性スクリプトについては、動的解析によっても、全ての挙動を解析しきれないという問題がある。
特定の条件下でしか実行されない経路がある場合として、例えば、指令サーバからの指令によってその先の実行経路が決まる場合や、解析妨害によって解析環境では悪性な挙動を示さないようになっている場合がある。
前者は、指令サーバからの指令がなければ、その先の実行経路が決定されず、悪性な挙動を持った経路が実行されない場合である。悪性スクリプトを検出して解析する際には、既に攻撃者が撤退して指令サーバがなくなっている場合も少なくないため、そのような場合には、悪性な挙動を観測できない。
後者は、悪性スクリプトが、自身が実行されている環境の情報を取得し、それが特定の条件を満たしていなければ、悪性な挙動を示さないという解析妨害である。例えば、解析環境に高頻度に見られる特徴が見られた場合には、自分が解析されていると判断して、実行を中断するという解析妨害に用いられる。
図31は、解析妨害の一例を示すコード片を示す図である。このコード片は、実行されている環境のCPU(Central Processing Unit)のコア数を取得し、それが2以上かつ8以下でなければ、解析環境の可能性が高いと判断して、実行を終了するという解析妨害を持つ。さもなければ、解析環境ではないと判断して、悪性な挙動を示す。
このような特定の条件下でしか実行されない経路の挙動を捉えるためには、複数の実行経路を実行するマルチパス実行が必要となる。
マルチパス実行では、実行が条件分岐に到達した際に、実行状態を分岐させ、分岐した各々の実行状態が、分岐のそれぞれの実行経路を辿るようにする。これにより、条件分岐で発生する二つの実行経路の両方を実行する。
マルチパス実行の実現について、例えば、非特許文献1には、JavaScript(登録商標)に対して、マルチパス実行の一種であるシンボリック実行を実現する手法が記載されている。この手法によれば、JavaScriptのスクリプトの条件分岐において、実行可能な経路を網羅的に辿り、挙動を観測できる。
また、非特許文献2には、JavaScriptに対して、マルチパス実行の一種である経路強制実行を実現する手法が記載されている。この手法によれば、JavaScriptのスクリプトの条件分岐において、全ての経路を網羅的に辿り、挙動を観測できる。
非特許文献3には、スクリプトエンジンに予め手動で改造を施した上で、そのスクリプトエンジンをバイナリ向けのシンボリック実行基盤の上で実行することで、スクリプトエンジン上で実行されているスクリプトに対して、スクリプトエンジン越しにシンボリック実行を実現する手法が記載されている。この手法によれば、手動で改造を施せるスクリプトエンジンがあれば、どのようなスクリプト言語でも汎用的にシンボリック実行を実現し、実行可能な経路を網羅的に辿って、挙動を観測できる。
そして、非特許文献4には、マルウェアが自身のプログラムの難読化にしばしば用いる仮想機械(Virtual Machine:VM)を解析する手法が記載されている。この手法によれば、VMを解析することで、そのアーキテクチャの情報を取得できる。スクリプトエンジンにおいてスクリプトの実行を司るのはVMであるため、この手法の考え方を一部転用できる。
非特許文献5には、スクリプトエンジンを解析し、得られたアーキテクチャの情報に基づいて、マルチパス実行機能を実現するコードを追加することにより、スクリプトのマルチパス実行を可能にしている。この手法によれば、多様なスクリプトの言語やエンジンに対して、マルチパス実行を実現できる。
Prateek Saxena, et al, "A Symbolic Execution Framework for JavaScript", 2010 IEEE Symposium on Security and Privacy.
Kyungtae Kim, et al, "J-Force: Forced Execution on JavaScript".
Stefan Bucur, et al, "Prototyping Symbolic Execution Engines for Interpreted Languages".
Monirul Sharif, et al, "Automatic Reverse Engineering of Malware Emulators", 2009 30th IEEE Symposium on Security and Privacy.
碓井利宣, 古川和祈, 大月勇人, 幾世知範, 川古谷裕平, 岩村誠, 三好潤, 松浦幹太, "スクリプト実行環境に対するマルチパス実行機能の自動付与手法", 2019年コンピュータセキュリティシンポジウム (CSS2019), pp.961-968, 2019.
ここで、攻撃者が意図的に例外を起こすことで、解析の実行を停止させて、解析を妨害する場合がある。また、経路強制実行によるマルチパス実行では、実行経路を強制することによって、通常の実行では発生し得ない例外が発生し、実行が停止する場合が見受けられる。例外が発生すると解析の実行が停止するため、例外が発生した場合であっても、解析の実行を継続することができる技術が要望されている。
そのためには、例外の発生時に、例外を引き起こす箇所を強制的にスキップして実行を継続する必要がある。このとき、どの程度の範囲をスキップするべきか、例えば、現在実行中の命令をスキップするべきか、基本ブロックをスキップするべきか、関数をスキップするべきか、という点は、発生した例外によって異なる。
したがって、例外による実行の停止を抑制する技術の一つとして、例外を引き起こした関数をスキップして実行を継続する技術が必要となる。
本発明は、上記に鑑みてなされたものであって、スクリプトエンジンに対して、例外を引き起こした関数をスキップすることで例外による実行の停止を抑制した実行機能の付与を実現できる解析機能付与方法、解析機能付与装置及び解析機能付与プログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明の解析機能付与方法は、解析機能付与装置が実行する解析機能付与方法であって、スクリプトエンジンの仮想機械を解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行される仮想機械の命令を指し示す変数である仮想プログラムカウンタを取得する第1の解析工程と、仮想機械の命令の体系である命令セットアーキテクチャを解析して、分岐を発生させる仮想機械命令である分岐仮想機械命令を取得する第2の解析工程と、第1の解析工程及び第2の解析工程における解析によって得られたアーキテクチャ情報である、仮想プログラムカウンタ及び分岐仮想機械命令に基づいて、スクリプトエンジンのフックポイントに、例外が発生した場合には、メモリにおけるポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する処理を含むフックを施して解析機能を付与する付与工程と、を含んだことを特徴とする。
本発明によれば、スクリプトエンジンに対して、例外による実行の停止を抑制した実行機能の付与を実現できる。
以下に、本願に係る解析機能付与方法、解析機能付与装置及び解析機能付与プログラムの実施形態を図面に基づいて詳細に説明する。また、本発明は、以下に説明する実施形態により限定されるものではない。
[実施の形態]
実施の形態に係る解析機能付与装置は、スクリプトエンジンに適用できる解析機能付与装置である。
実施の形態に係る解析機能付与装置は、スクリプトエンジンに適用できる解析機能付与装置である。
本実施の形態に係る解析機能付与装置は、スクリプトエンジンのバイナリを監視しながらテストスクリプトを実行して、ブランチトレースとメモリアクセストレースとを実行トレースとして取得する。
そして、解析機能付与装置は、この実行トレースに基づいて仮想機械を解析し、フックポイント、タップポイント、次に実行されるVM命令を指し示す変数である仮想プログラムカウンタ(VPC)、VM命令の境界、ディスパッチャのアーキテクチャ情報を取得する。なお、これらはいずれも、スクリプトエンジンの構成要素であり、アーキテクチャに関する情報であって、アーキテクチャ情報DB132(後述)に格納される。
さらに、解析機能付与装置は、テストスクリプトを実行してVM実行トレースを取得し、このVM実行トレースを用いて命令セットアーキテクチャを解析する。これによって、解析機能付与装置は、スクリプト内で分岐を発生させるVM命令である分岐VM命令を、アーキテクチャ情報として取得する。
さらに、解析機能付与装置は、テストスクリプトを実行してVM実行トレースを取得し、このVM実行トレースを用いてVPCの変化量(オフセット)を検出する。これによって、解析機能付与装置は、VPCの変化量を、アーキテクチャ情報として取得する。
そして、解析機能付与装置は、取得したアーキテクチャ情報を基に、スクリプトエンジンのフックポイントを基にフックハンドラを用いたフックを挿入する。さらに、解析機能付与装置は、解析対象のスクリプトに、例外ハンドラを挿入し、例外処理機能を付与する。例外ハンドラは、例外の発生を捕捉した場合に、VM領域に強制的に処理を移す機能を有する。そして、フックハンドラには、メモリにおけるポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更することで、例外の発生した関数をスキップする機能が追加される。これによって、解析機能付与装置は、例外が発生した場合にはVM領域に処理を移行し、フックハンドラにおいて指示された、例外が発生した関数のスキップを行うことで、例外による実行の停止を抑制する。
図1は、例外ハンドラの一例を説明する図である。図2は、スクリプトAPIのフックを用いたハイパーバイザコールの一例を示す図である。解析機能付与装置は、図1に示すように、解析対象のスクリプトのエントリーポイントに対し、E1~E3の枠部分の内容を実行前に静的に追加する(図1の(1),(2))。
具体的には、解析機能付与装置は、図1に示すように、解析対象のスクリプトのエントリーポイントに対し、「try」及び「catch」のコードを追加し(枠E1,E2)、枠E3の3行目のように、例外が発生した場合には、スクリプトAPIをフックする「hooked_script_API(e)」コードを追加する。これによって、例外時には、スクリプトAPIをフックしハイパーバイザコールとして利用して例外のスキップを行う(図1の(3))。すなわち、解析機能付与装置は、図2に示すように、スクリプトAPIのフックによってハイパーバイザコール相当を実現する(図2の(1))ことで、例外が発生した場合にはVM領域に処理を移行し、フックハンドラにおいて指示された、例外が発生した関数のスキップを行う。
このように、解析機能付与装置は、例外を捕捉し、解析対象のスクリプトに例外ハンドラを挿入することで、例外の発生した箇所の先に強制的に実行を進めさせることで、意図しない実行の停止を防ぎつつ、解析を継続する。
[解析機能付与装置の構成]
続いて、図3を参照して、実施の形態に係る解析機能付与装置10の構成について具体的に説明する。図3は、実施の形態に係る解析機能付与装置の構成の一例を説明する図である。
続いて、図3を参照して、実施の形態に係る解析機能付与装置10の構成について具体的に説明する。図3は、実施の形態に係る解析機能付与装置の構成の一例を説明する図である。
図3に示すように、解析機能付与装置10は、入力部11、制御部12、記憶部13、出力部14を有する。そして、解析機能付与装置10は、テストスクリプト、スクリプトエンジンバイナリ及び解析対象スクリプトの入力を受け付ける。
入力部11は、キーボードやマウス等の入力デバイスで構成され、外部からの情報の入力を受け付け、制御部12に入力する。また、入力部11は、有線接続、或いは、ネットワーク等を介して接続された他の装置との間で、各種情報を送受信する通信インタフェースを有し、他の装置から送信された情報の入力を受け付ける。入力部11は、テストスクリプト、スクリプトエンジンバイナリ及び解析対象スクリプトの入力を受け付け、制御部12に出力する。テストスクリプトは、スクリプトエンジンを動的解析して実行トレース及びVM実行トレースを取得する際に、入力されるスクリプトである。なお、テストスクリプトの詳細は後述する。スクリプトエンジンバイナリは、スクリプトエンジンを構成する実行可能ファイルである。スクリプトエンジンバイナリは、複数の実行可能ファイルによって構成される場合がある。解析対象スクリプトは、解析対象のスクリプトである。
制御部12は、各種の処理手順などを規定したプログラム及び所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する。例えば、制御部12は、CPU(Central Processing Unit)やMPU(Micro Processing Unit)などの電子回路である。制御部12は、仮想機械解析部121(第1の解析部)、命令セットアーキテクチャ解析部122(第2の解析部)及び機能付与部123(付与部)を有する。
仮想機械解析部121は、スクリプトエンジンのVMを解析する。仮想機械解析部121は、実行時の条件を変えて複数の実行トレースを取得し、差分実行解析を用いて複数の実行トレースを解析し、フックポイント、タップポイント、VPCを取得する。また、仮想機械解析部121は、スクリプトエンジンバイナリを解析して、VM命令の境界およびディスパッチャを取得する。仮想機械解析部121は、実行トレース取得部1211、フック・タップポイント検出部1212、VM命令境界検出部1213、仮想プログラムカウンタ検出部1214、ディスパッチャ検出部1215を有する。
実行トレース取得部1211は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け付ける。実行トレース取得部1211は、スクリプトエンジンバイナリの実行を監視しながら、テストスクリプトを実行することで、実行トレースを取得する。
実行トレースは、ブランチトレースとメモリアクセストレースとによって構成される。ブランチトレースは、実行の際の分岐命令の種類と、分岐元アドレスと分岐先アドレスを記録する。メモリアクセストレースは、メモリ操作の種類と、操作対象のメモリアドレスを記録する。ブランチトレース及びメモリアクセストレースは、命令フックによって取得可能であることが知られている。実行トレース取得部1211が取得した実行トレースは、実行トレースDB131に格納される。
フック・タップポイント検出部1212は、実行トレース取得部1211によって取得された実行トレースに基づいて仮想機械を解析し、フックポイント、タップポイントを検出する。ここで、フックポイントとは、フックを施して解析用コードを挿入する箇所である。実施の形態においては、スクリプトエンジンの内部実装が持つ関数(内部関数と呼ぶ)を単位とし、フックはこの内部関数の先頭に施されるものとする。また、タップポイントとは、解析用コードによってログ出力するメモリ監視箇所であり、内部関数の引数のいずれかであるとする。
フック・タップポイント検出部1212は、実行トレースDB131に格納された実行トレースを取り出して解析し、フックポイントの候補を発見する。フック・タップポイント検出部1212は、実行トレースに対して、解析対象に関連したシステムAPIの呼び出しを探索し、そこからのバックトレースによってフックポイント候補を検出する。フック・タップポイント検出部1212は、解析対象の言語要素(例えば、スクリプトAPI)に対応したシステムAPIからのバックトレースを適用してフックポイントを検出する。
フック・タップポイント検出部1212は、取得条件の異なる複数の実行トレースの差分を抽出し、特定の条件を満たす部分を発見することでフックポイント候補を検出する。フック・タップポイント検出部1212は、複数の条件を変えた実行トレースの間に見られる差分に基づいてフックポイントを検出する。この際、フック・タップポイント検出部1212は、相同性の高い系列が特定の回数出現することを検出するアルゴリズム(例えば、Smith-Watermanアルゴリズム)を用いてフックポイントを検出する。
フック・タップポイント検出部1212は、得られたフックポイント候補にフックを施し、そのフックが施された関数の引数のメモリを探索することで、タップポイントを検出する。フック・タップポイント検出部1212は、フックポイントでの監視に基づいて、解析用コードによってログ出力するメモリ監視箇所であるタップポイントを検出する。また、フック・タップポイント検出部1212は、タップポイントを持ったフックポイント候補を、フックポイントとして確定する。なお、フック・タップポイント検出部1212の処理の詳細は、国際公開第2020/075335号を参照されたい。
VM命令境界検出部1213は、実行トレースをクラスタリングして、各VM命令の境界を検出する。VM命令境界検出部1213は、実行トレースをクラスタリングして、実行回数が閾値以上のクラスタをVM命令として検出する。クラスタリングでは、複数回実行される連続したコード領域を検出する。これには、例えば、実行された命令間のコード上の距離が近いものをまとめてもよいし、実行されたコードブロックの共通部分列を探してもよいし、他の方法によってもよい。解析機能付与装置10は、検出したVM命令を構成する連続した命令列の開始点と終了点とを境界として検出する。ここで検出したVM命令の境界は、VPC検出、ディスパッチャ検出において用いられる。
仮想プログラムカウンタ検出部1214は、実行トレースDB131に格納された第1のテストスクリプトに対する実行トレースを取り出して解析し、VPCを検出する。仮想プログラムカウンタ検出部1214は、メモリの読み込み回数に着目した差分実行解析とVM命令境界検出部1213によって検出された各VM命令の境界とを用いて複数の実行トレースを解析し、VPCを検出する。仮想プログラムカウンタ検出部1214は、各VM命令の実行後には、必ずVPCを保持するメモリへの読み込みが発生することを利用し、この読み込み先を発見することで、VPCを検出する。
このため、仮想プログラムカウンタ検出部1214は、VPCの検出として、メモリの読み込み回数に着目した差分実行解析を用いる。仮想プログラムカウンタ検出部1214は、テストスクリプトを用いて取得された複数のテストスクリプトの実行トレースを比較し、メモリ読み込み回数が、繰り返される回数及び繰り返される文の数との双方の増減に比例して変化するメモリを発見する。そして、仮想プログラムカウンタ検出部1214は、VM命令境界検出部1213によって検出された各VM命令の境界を参照して、読み込んだメモリの値が常にVM命令の開始点を指しているものに絞り込む。仮想プログラムカウンタ検出部1214は、このメモリをVPCとして検出する。
ディスパッチャ検出部1215は、VM命令境界検出部1213が検出したVM命令の境界を基に、スクリプトエンジンバイナリから各VM命令部分を切り出し、各VM命令間で類似度が高い部分をディスパッチャとして検出する。前提として、ディスパッチャは、ポインタキャッシュの参照と次のVM命令ハンドラのポインタへのジャンプで実現される。ディスパッチャは、各々のVM命令ハンドラの後部に分散的に配置されており、一般にそれらのコードの同一性は高い。こうしたVM命令ハンドラの後部に存在し、同一性の高いコードを探すことで、解析機能付与装置は、所定の方法でディスパッチャを検出する。類似度の高い部分の検出には、たとえば系列アライメントアルゴリズムを用いてもよく、その他の方法によってもよい。
命令セットアーキテクチャ解析部122は、VMの命令の体系である命令セットアーキテクチャを解析する。命令セットアーキテクチャ解析部122は、VM実行トレース取得部1221(第1の取得部)、分岐VM命令検出部1222(第1の検出部)及びVPCオフセット検出部1223を有する。
VM実行トレース取得部1221は、実行トレース取得部1211と同じく、テストスクリプト及びスクリプトエンジンバイナリを入力として受け付ける。VM実行トレース取得部1221は、VPCの監視と、ディスパッチャがディスパッチするVM命令ハンドラのポインタの監視により、VM実行トレースを取得する。VM実行トレース取得部1221は、スクリプトエンジンバイナリの実行を監視しながら、テストスクリプトを実行することで、VM上で実行された実行トレースであるVM実行トレースを取得する。VM実行トレース取得部1221は、分岐VM命令の検出において、多数のテストスクリプトを実行して、VM実行トレースを取得する。VM実行トレース取得部1221は、VM命令へのポインタとVM命令とを紐づけ、各々に識別子としてVMオペコードを仮想的に割り振る。
VM実行トレースは、実行されたVM命令ハンドラのポインタと、VPCを記録したものである。具体的には、VM実行トレースは、実行されたVM命令ごとのVPCとVMオペコードで構成される。VPCの記録は、仮想プログラムカウンタ検出部1214で検出されたVPCのメモリを監視することで実現できる。VMオペコードは、VM命令へのポインタとVM命令とを紐づけた各々に仮想的に割り振られた識別子である。VM実行トレース取得部1221が取得したVM実行トレースは、VM実行トレースDB133に格納される。
分岐VM命令検出部1222は、VM実行トレースDB133に格納されたVM実行トレースを取り出して解析し、分岐VM命令を検出する。分岐VM命令検出部1222は、識別子として割り振られたVMオペコードごとに、その実行の前後でのVPCの変化量を収集する。VMオペコードが分岐VM命令以外のものの場合、VPCの変化量は、ほぼ一定である。一方、VMオペコードが分岐VM命令のものの場合、VPCは分岐先によってばらつきが生じる。
そこで、分岐VM命令検出部1222は、VM実行トレースのVMオペコードごとの仮想プログラムカウンタの変化量のばらつきによって、分岐VM命令を検出する。分岐VM命令検出部1222は、分岐VM命令とそれ以外のVM命令とではVPCの値のばらつきの大きさが異なることに着目し、閾値を決めて、よりVPCの値のばらつきの大きいものを分岐VM命令として検出する。具体的には、分岐VM命令検出部1222は、VMオペコードごとVPCの変化量のばらつきを分散で評価し、分散が一定の閾値以上のものを、分岐VM命令として検出する。
VPCオフセット検出部1223は、VM実行トレース取得部によって取得され、VM実行トレースDB133に格納されたVM実行トレースを取り出してVM実行トレースのログを解析する。VPCオフセット検出部1223は、VM実行トレースから、VM命令のオペコードと、VM命令の実行前後でのVPCの変化量とを、組として取得する。変化量oは、VM命令の実行前のVPCの値をpprev、実行後の値をpnextとして、o=pnext-pprevで算出される。
機能付与部123は、取得したアーキテクチャ情報を基に、スクリプトエンジンにフックを挿入し、解析対象のスクリプトに、例外ハンドラを挿入し、例外処理機能を付与する。機能付与部123は、仮想機械解析部121及び命令セットアーキテクチャ解析部122による解析によって得られたアーキテクチャ情報である、VPC及び分岐VM命令に基づいて、スクリプトエンジンのフックポイントに、例外が発生した場合には、メモリにおけるポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する処理を含むフックを施して解析機能を付与する。機能付与部123は、フック挿入部1231及び例外ハンドラ挿入部1232を有する。
フック挿入部1231は、スクリプトエンジンにフックを挿入する。フック挿入部1231は、仮想機械解析部121及び命令セットアーキテクチャ解析部122による解析によって得られたアーキテクチャ情報に基づいて、スクリプトエンジンにフックを施す。フック挿入部1231は、フックポイント及びタップポイントを受け取り、フックポイント及びタップポイントに基づいて、スクリプトエンジンに、フックハンドラを用いてフックを挿入して解析機能を付与する。フックハンドラは、VM領域において、メモリにおけるポインタの指し先(VSP:仮想スタックポインタ)を、当該指し先の一つ前の関数の戻り先に変更する処理を含む。
具体的には、フック挿入部1231は、フックハンドラに、VMブランチトレース構築処理(第1の処理)、コールスタック再構築処理(第2の処理)、仮想スタック・仮想スタックポインタ検出処理(第3の処理)、及び、仮想スタックポインタ巻き戻し処理(第4の処理)を追加する。これによって、フックには、メモリにおけるポインタの指し先(VSP)を、当該指し先の一つ前の関数の戻り先に変更し、例外の発生した関数をスキップする機能が追加される。VMブランチトレース構築処理は、分岐VM命令の実行前後のVPCを対応付けたVMブランチトレースを構築する。コールスタック再構築処理は、仮想機械ブランチトレースからコールスタックを構築する。仮想スタック・仮想スタックポインタ検出処理は、コールスタックとの共通性に関する所定の条件を満たすメモリの領域を仮想スタックとして検出し、さらに仮想スタックを指しているメモリ領域を仮想スタックポインタとして検出する。仮想スタックポインタ巻き戻し処理は、仮想スタックポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する。
例外ハンドラ挿入部1232は、解析対象のスクリプトに、例外ハンドラを挿入し、例外処理機能を付与する。例外ハンドラは、例外の発生を捕捉した場合に、VM領域に強制的に処理を移す機能を有する。例外ハンドラ挿入部1232は、解析対象のスクリプトを解析し、各エントリーポイントに、エントリーポイント以降のコードでの例外を捕捉できるようして例外ハンドラのコード(例えば、図1参照)を追加することで、例外ハンドラを挿入する。
記憶部13は、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、解析機能付与装置10を動作させる処理プログラムや、処理プログラムの実行中に使用されるデータなどが記憶される。記憶部13は、実行トレースデータベース(DB)131、VM実行トレースDB133、及び、仮想機械解析部121及び命令セットアーキテクチャ解析部122によって取得されたアーキテクチャ情報を記憶するアーキテクチャ情報DB132を有する。
実行トレースDB131及びVM実行トレースDB133は、それぞれ実行トレース取得部1211及びVM実行トレース取得部1221によって取得された実行トレース及びVM実行トレースを格納する。実行トレースDB131及びVM実行トレースDB133は、解析機能付与装置10によって管理される。もちろん、実行トレースDB131及びVM実行トレースDB133は、他の装置(サーバ等)によって管理されていてもよく、この場合には、実行トレース取得部1211及びVM実行トレース取得部1221は、出力部14の通信インタフェースを介して、取得した実行トレース及びVM実行トレースを、実行トレースDB131及びVM実行トレースDB133の管理サーバ等に出力して、実行トレースDB131及びVM実行トレースDB133に記憶させる。
出力部14は、例えば、液晶ディスプレイやプリンタ等であって、解析機能付与装置10に関する情報を含む各種情報を出力する。また、出力部14は、外部装置との間で、各種データの入出力を司るインタフェースであってもよく、外部装置に各種情報を出力してもよい。
[テストスクリプトの構成]
テストスクリプトについて説明する。テストスクリプトは、スクリプトエンジンを動的解析する際に入力されるスクリプトである。このテストスクリプトは、分岐命令の実行やメモリ読み書きの回数に着目し、異なる回数のテストスクリプトを実行したときに生じるスクリプトエンジンの挙動の差分を捉えるために用いられる。このテストスクリプトは、解析の事前に準備するものであり、手動で作成するものである。この作成には、対象のスクリプト言語の仕様に関する知識が必要となる。
テストスクリプトについて説明する。テストスクリプトは、スクリプトエンジンを動的解析する際に入力されるスクリプトである。このテストスクリプトは、分岐命令の実行やメモリ読み書きの回数に着目し、異なる回数のテストスクリプトを実行したときに生じるスクリプトエンジンの挙動の差分を捉えるために用いられる。このテストスクリプトは、解析の事前に準備するものであり、手動で作成するものである。この作成には、対象のスクリプト言語の仕様に関する知識が必要となる。
図4は、仮想プログラムカウンタ(VPC)の検出に用いるテストスクリプト(第1のテストスクリプト)の一例を示す図である。第1のテストスクリプトでは、繰り返し処理を用いる(2行目)。第1のテストスクリプトでは、テストスクリプト内の繰り返し回数(2行目)や繰り返される文の数(3行目から5行目)を増減させることで、実行時の条件を変更し、差分を発生させる。
図5は、分岐VM命令検出に用いるテストスクリプト(第2のテストスクリプト)の一例を示す図である。第2のテストスクリプトでは、複数回の条件分岐を用いる(4行目から8行目)。第2のテストスクリプトにおいて、この複数回の条件分岐では、特定の順序のパターンで分岐がなされたり、なされなかったりするように、分岐条件を制御する(1行目、5行目)。第2のテストスクリプトでは、条件分岐の回数や、分岐の成否の順序パターンを変更し、差分を発生させる。
[実行トレースの構成]
次に、実行トレースについて説明する。図6は、実行トレースの一例を示す図である。実行トレースは、前述の通り、ブランチトレースとメモリアクセストレースによって構成されている。図6は、実行トレースの一部を切り出したものである。以降、図6を用いて実行トレースの構成を示す。
次に、実行トレースについて説明する。図6は、実行トレースの一例を示す図である。実行トレースは、前述の通り、ブランチトレースとメモリアクセストレースによって構成されている。図6は、実行トレースの一部を切り出したものである。以降、図6を用いて実行トレースの構成を示す。
実行トレースは、traceという要素を有する。traceには、そのログ行がブランチトレースか、メモリアクセストレースかが示される。
ブランチトレースのログ行は、例えば、図6の1行目から10行目に記載の書式になっており、type、src、dstの三つの要素からなる。typeは、実行された分岐命令がcall命令によるものか、jmp命令によるものか、ret命令によるものかを示す。また、srcは、分岐元のアドレスを示し、dstは、分岐先のアドレスを示す。
メモリアクセストレースのログ行は、たとえば、図6の11行目から13行目に記載の書式になっており、type、target、valueの三つの要素からなる。typeは、メモリアクセスが読み込みか書き込みかを示す。targetは、メモリアクセスの対象となるメモリアドレスを示す。また、valueには、メモリアクセスの結果の値が格納される。
[VM実行トレースの構成]
次に、VM実行トレースについて説明する。図7は、VM実行トレースの一例を示す図である。VM実行トレースは、前述の通り、VMオペコードとVPCとを記録したものである。図7は、VM実行トレースの一部を切り出したものである。以降、図7を用いてVM実行トレースの構成を示す。
次に、VM実行トレースについて説明する。図7は、VM実行トレースの一例を示す図である。VM実行トレースは、前述の通り、VMオペコードとVPCとを記録したものである。図7は、VM実行トレースの一部を切り出したものである。以降、図7を用いてVM実行トレースの構成を示す。
VM実行トレースのログ行は、例えば、図7に記載の書式になっており、vpc及びvmop(vm opcode)の二つの要素からなる。vpcは、VPCの値を示す。また、vmopは、ポインタキャッシュから取得された、実行されるVM命令ハンドラの先頭を指すポインタごとに仮想的に割り振られたVMオペコードの値を示す。
[VM命令境界検出部の処理]
次に、VM命令境界検出部1213の処理について説明する。図8は、VM命令境界検出部1213の処理を説明する図である。
次に、VM命令境界検出部1213の処理について説明する。図8は、VM命令境界検出部1213の処理を説明する図である。
VM命令境界検出部1213は、各VM命令の境界を検出する。この時、VM命令境界検出部1213は、インタプリタループを持たないためにVM命令の境界の把握が難しいスレッデッドコード型VMのために、VM命令とその境界の検出を行う。具体的には、VM命令境界検出部1213は、実行トレースDB131から実行トレースを取り出す。そして、図8に示すように、VM命令境界検出部1213は、実行トレースを、所定の方法でクラスタリングして、実行回数が閾値以上のクラスタをVM命令(例えば、VM命令ハンドラ1~3)として検出する。VM命令境界検出部1213は、VM命令を構成する連続した命令列の開始点と終了点とを境界として検出する。
[仮想プログラムカウンタ検出部の処理]
次に、仮想プログラムカウンタ検出部1214の処理について説明する。仮想プログラムカウンタ検出部1214は、VPC、ポインタキャッシュの検出を行う。仮想プログラムカウンタの検出は、取得した実行トレースのメモリアクセストレースのログを解析することで実現される。仮想プログラムカウンタ検出部1214は、メモリの読み込み回数に着目した差分実行解析を用いる。図9は、仮想プログラムカウンタ検出部1214の処理を説明する図である。
次に、仮想プログラムカウンタ検出部1214の処理について説明する。仮想プログラムカウンタ検出部1214は、VPC、ポインタキャッシュの検出を行う。仮想プログラムカウンタの検出は、取得した実行トレースのメモリアクセストレースのログを解析することで実現される。仮想プログラムカウンタ検出部1214は、メモリの読み込み回数に着目した差分実行解析を用いる。図9は、仮想プログラムカウンタ検出部1214の処理を説明する図である。
仮想プログラムカウンタ検出部1214は、実行トレースDB131から第1のテストスクリプトによる実行トレースを一つ取り出す。VPCの読み込みの回数は、テストスクリプト内の繰り返し回数及び、繰り返し処理の中の文の数に比例する。繰り返しの回数をN、繰り返される文の数をMとしたとき、概ねMN程度のVPCの読み込みが発生する。このため、仮想プログラムカウンタ検出部1214は、N及びMをそれぞれ2Nと2M、3Nと3Mと増やした第1のテストスクリプトに対する実行トレースにおいて、4MN、9MNという増え方をしたメモリを抽出する。具体的には、図9に示すように、仮想プログラムカウンタ検出部1214は、1VM命令実行毎にRead/Writeがあり、単調増加するメモリ領域を抽出する(図9の(1))。
そして、仮想プログラムカウンタ検出部1214は、読み込んだメモリの値が常にVM命令の開始点を指しているものを、VPCとして検出する。具体的には、仮想プログラムカウンタ検出部1214は、VPCの指し先とVM命令ハンドラのアドレスとを照合して、一致するメモリ領域に絞り込む(図9の(2))。
[ディスパッチャ検出部の処理]
次に、ディスパッチャ検出部1215の処理について説明する。ディスパッチャ検出部1215は、スクリプトエンジンのバイナリを所定の手法で解析することで、ディスパッチャを検出する。図10は、ディスパッチャ検出部1215の処理を説明する図である。
次に、ディスパッチャ検出部1215の処理について説明する。ディスパッチャ検出部1215は、スクリプトエンジンのバイナリを所定の手法で解析することで、ディスパッチャを検出する。図10は、ディスパッチャ検出部1215の処理を説明する図である。
ディスパッチャ検出部1215は、ディスパッチャの検出を行う。ディスパッチャ検出部1215は、VM命令境界検出部1213が検出したVM命令の境界を基に、スクリプトエンジンバイナリから各VM命令部分を切り出す。そして、ディスパッチャ検出部1215は、ディスパッチャのコードの類似性は高いとした仮定の基(図10の(1))、各VM命令間でコード間の類似度を算出し、全VM命令間で類似度が高い部分を、ディスパッチャとして検出する。ディスパッチャ検出部1215は、VM命令の後半部で共通的に実行されるコードを、ディスパッチャとして検出できる(図10の(1))。
[分岐VM命令検出部の処理]
次に、分岐VM命令検出部1222の処理について説明する。分岐VM命令検出部1222は、取得したVM実行トレースのログを解析することで分岐VM命令を検出する。ここでのテストスクリプトは、分岐VM命令が含まれていればよいため、分岐の制御構文を含むスクリプトでありさえすればどのようなものでもよい。例えば、インターネット上から収集したり、公式ドキュメントから取得したりしてテストスクリプトを準備する。
次に、分岐VM命令検出部1222の処理について説明する。分岐VM命令検出部1222は、取得したVM実行トレースのログを解析することで分岐VM命令を検出する。ここでのテストスクリプトは、分岐VM命令が含まれていればよいため、分岐の制御構文を含むスクリプトでありさえすればどのようなものでもよい。例えば、インターネット上から収集したり、公式ドキュメントから取得したりしてテストスクリプトを準備する。
まず、分岐VM命令検出部1222は、VM実行トレースDB133の各VM実行トレースに対し、VM命令へのポインタとVM命令とを紐づけ、各々に識別子として、VMオペコードを仮想的に割り振る。図11は、分岐VM命令検出部1222の処理を説明する図である。
ここで、あるVM命令が分岐命令のとき、VPCの変化量は、分岐先に依存して変化する。一方、分岐命令以外のときは、VPCの変化量は、VM命令のサイズに依存して変化する。このため、VM命令のオペコードとVM命令へのポインタとの組を収集し、オペコードごとにVPCの変化量を見たとき、分岐命令であれば分岐先によってVPCの変化量にばらつきがみられる。
したがって、分岐VM命令検出部1222は、このVM命令へのポインタのばらつきを評価するため、分散を用いる。分岐VM命令検出部1222は、VMオペコード毎にVPCの変化量の分散を算出し、算出した分散が閾値よりも大きいVMオペコードのみに絞り込む。これによって、分岐VM命令検出部1222は、ポインタとVM命令を対応付けつつ、VPCの変化量にばらつきのあるVM命令(図11の例では、VM命令ハンドラ3)を、分岐VM命令として検出する(図11の(1))。
あるオペコードに対するVPCの変化量の集合OをO={o0,o1,・・・,oN}(VPCoの平均は(1)式を参照)とし、tを閾値としたとき、分岐命令か否かは、分散s((2)式を参照)を基に、(3)式のように判定される。これによって、分岐VM命令検出部1222は、分岐VM命令を検出する。
なお、分岐以外のVM命令では、ばらつきがほとんど見られず、分岐VM命令とそれ以外のVM命令との境界は明確であることが多い。このため、閾値として、例えば、得られた分散の値を数直線上にプロットして、できた二つの群を分割可能な値が設定される。
[フック挿入部の処理]
次に、フック挿入部1231の処理を説明する。フック挿入部1231は、スクリプトエンジンバイナリと、ここまでの処理で検出されたフックポイント及びタップポイントを入力として受け付ける。フック挿入部1231は、スクリプトエンジンに対して、フックポイントにフックハンドラを用いたフックを挿入する。
次に、フック挿入部1231の処理を説明する。フック挿入部1231は、スクリプトエンジンバイナリと、ここまでの処理で検出されたフックポイント及びタップポイントを入力として受け付ける。フック挿入部1231は、スクリプトエンジンに対して、フックポイントにフックハンドラを用いたフックを挿入する。
ここで、フック挿入部1231は、フック時に、フックに対応したスクリプトAPIが実行された際に、VM領域でのフックハンドラの処理に実行が遷移するように、解析用のコードを挿入する。この解析用のコードは、フックポイントとタップポイントとが判明していれば、容易に生成できる。これによって、フックしたスクリプトAPIをスクリプトから呼び出すことで、VM領域に実装されたフックハンドラの機能をハイパーバイザコールとして呼び出せるようになり、解析機能の付与が実現される。
この際、フック挿入部1231は、フックハンドラに、VMブランチトレースを構築するVMブランチトレース構築処理、コールスタックを構築するコールスタック再構築処理、仮想スタックと仮想スタックポインタを検出する仮想スタック・仮想スタックポインタ検出処理、及び、仮想スタックポインタを巻き戻す(スキップする)仮想スタックポインタ巻き戻し処理を追加する。
図12は、VMブランチトレース構築処理を説明する図である。VMブランチトレース構築処理では、図12に示すように、実行されたVM命令のオペコードと、VPCを記録したVM実行トレース41から分岐VM命令を検出する(図12の(1))。分岐VM命令は、分岐VM命令検出部1222によって検出された分岐VM命令リスト42を参照することで認識することができる。
そして、VMブランチトレース構築処理では、検出した分岐VM命令の実行前後のVPCを対応付けたVMブランチトレース43を構築する(図12の(2))。VMブランチトレース構築処理では、例えば、VM実行トレースの行R41から分岐VM命令「0x1f」を検出し、行R41及び行R42の次の行R42を基に、行R61に示すVMブランチトレースを構築する。すなわち、VMブランチトレース構築処理では、行R41の分岐元のVPC「0x555c7e48」と、行R42の分岐元のVPC「0x555c82a0」とを対応付ける。
同様に、VMブランチトレース構築処理では、VM実行トレースの行R51から分岐VM命令「0x21」を検出すると、この行R51及び次の行R52を基に、行R51のVPC「0x555c832c」と、行R52のVPC「0x555c7514」とを対応付ける(行R71)。
図13は、コールスタック再構築処理を説明する図である。図3に示すように、コールスタック再構築処理は、VMブランチトレースからコールスタックを再構築する。図13の推測されたコールスタックは、再構築されたコールスタックに相当する。
図13に示すように、例えば、コールスタック再構築処理は、分岐元アドレス「src: 0x555c7e48」とVM命令オフセット「+4」から次のVM命令のアドレス「0x555c7e4c」を計算する。
図14は、仮想スタック・仮想スタックポインタ検出処理を説明する図である。仮想スタック・仮想スタックポインタ検出処理は、推測されたコールスタックとの共通性の高いメモリ領域を仮想スタックとして検出する(図14の(1))。例えば、仮想スタック・仮想スタックポインタ検出処理は、推測されたコールスタックと共通する部分の割合が所定値以上である領域を仮想スタックとして検出する。
さらに、仮想スタック・仮想スタックポインタ検出処理は、仮想スタックを指し続けるメモリ領域を仮想スタックポインタ(VSP)として検出する(図14の(2))。仮想スタックを指し続けるメモリ領域は、実行中の関数に関する領域ということができる。
図15は、仮想スタック巻き戻し処理を説明する図である。図15に示すように、仮想スタック巻き戻し処理は、検出した仮想スタックポインタの指す先を直前の関数の戻り先に変更することで仮想スタックを巻き戻す。これにより、実行中の関数がスキップされる。
[解析機能付与装置の処理手順]
次に、解析機能付与装置10による解析機能付与処理の処理手順について説明する。図16は、実施の形態に係る解析機能付与処理の処理手順を示すフローチャートである。
次に、解析機能付与装置10による解析機能付与処理の処理手順について説明する。図16は、実施の形態に係る解析機能付与処理の処理手順を示すフローチャートである。
まず、入力部11は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け取る(ステップS1)。
そして、実行トレース取得部1211は、スクリプトエンジンのバイナリを監視しながらテストスクリプトを実行してブランチトレースとメモリアクセストレースを取得する実行トレース取得処理を行う(ステップS2)。
フック・タップポイント検出部1212は、実行トレース取得部1211によって取得された実行トレースに基づいて仮想機械を解析し、フックポイント、タップポイントを検出するフック・タップポイント検出処理を行う(ステップS3)。
VM命令境界検出部1213は、VM命令を検出し、VM命令の境界を検出するVM命令境界検出処理を行う(ステップS4)。仮想プログラムカウンタ検出部1214は、実行トレースDB131に格納された第1のテストスクリプトに対する実行トレースを取り出して解析し、VPCを発見する仮想プログラムカウンタ検出処理を行う(ステップS5)。
ディスパッチャ検出部1215は、スクリプトエンジンバイナリから各VM命令部分を切り出し、各VM命令間で類似度が高い部分をディスパッチャとして検出するディスパッチャ検出処理を行う(ステップS6)。
VM実行トレース取得部1221は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け付け、スクリプトエンジンバイナリの実行を監視しながら、テストスクリプトを実行することで、VM実行トレースを取得するVM実行トレース取得処理を行う(ステップS7)。
VPCオフセット検出部1223は、VM実行トレースから、VM命令のオペコードと、命令の実行前後でのVPCの変化量とを、組として取得するVPCオフセット検出処理を行う(ステップS8)。
分岐VM命令検出部1222は、VM実行トレースDB133に格納されたVM実行トレースを取り出して解析し、分岐VM命令を検出する分岐VM命令検出処理を行う(ステップS9)。
フック挿入部1231は、ステップS1~ステップS6の処理において取得されたアーキテクチャ情報を基に、スクリプトエンジンにフックを挿入するフック挿入処理を行う(ステップS10)。
そして、例外ハンドラ挿入部1232は、解析対象のスクリプトに、例外ハンドラを挿入し、例外処理機能を付与する例外ハンドラ挿入処理を行う(ステップS11)。そして、出力部14は、例外スキップ機能が付与されたスクリプトエンジンバイナリを出力する(ステップS12)。
[実行トレース取得処理の処理手順]
次に、図16に示す実行トレース取得処理の流れについて説明する。図17は、図16に示す実行トレース取得処理の処理手順を示すフローチャートである。
次に、図16に示す実行トレース取得処理の流れについて説明する。図17は、図16に示す実行トレース取得処理の処理手順を示すフローチャートである。
まず、実行トレース取得部1211は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け取る(ステップS21)。そして、実行トレース取得部1211は、受け取ったスクリプトエンジンに対して、ブランチトレースを取得するためのフックを施す(ステップS22)。また、実行トレース取得部1211は、受け取ったスクリプトエンジンに対して、メモリアクセストレースを取得するためのフックも施す(ステップS23)。
そして、実行トレース取得部1211は、その状態で受け取ったテストスクリプトをスクリプトエンジンに入力して実行させ(ステップS24)、それによって取得される実行トレースを実行トレースDB131に格納する(ステップS25)。
実行トレース取得部1211は、入力されたテストスクリプトを全て実行し終えているか否かを判定する(ステップS26)。実行トレース取得部1211は、入力されたテストスクリプトを全て実行し終えている場合(ステップS26:Yes)、処理を終了する。これに対し、実行トレース取得部1211は、入力されたテストスクリプトを全て実行していない場合(ステップS26:No)、ステップS24のテストスクリプトの実行に戻って処理を続ける。
[フック・タップポイント検出処理の処理手順]
図18は、図16に示すフック・タップポイント検出処理の処理手順を示すフローチャートである。
図18は、図16に示すフック・タップポイント検出処理の処理手順を示すフローチャートである。
図18に示すように、フック・タップポイント検出処理において、フック・タップポイント検出部1212は、フックポイント候補を検出する(ステップS31)。フック・タップポイント検出部1212は、フックポイント候補が検出された場合(ステップS32:Yes)、ステップS35に進む。一方、フックポイント候補が検出されなかった場合(ステップS32:No)、フック・タップポイント検出部1212は、複数の条件を変えた実行トレースの間に見られる差分に基づいてフックポイントを検出する差分実行解析処理を実施する(ステップS33)。
そして、フック・タップポイント検出部121210は、フックポイント候補が検出されなかった場合(ステップS34:No)、フックポイント候補がないため、処理を終了する。一方、フック・タップポイント検出部1212は、フックポイント候補が検出された場合(ステップS34:Yes)、ステップS35に進む。フック・タップポイント検出部1212は、タップポイントを検出する(ステップS35)。
[VM命令境界検出処理の処理手順]
次に、図16に示すVM命令境界検出処理の流れについて説明する。図19は、図16に示すVM命令境界検出処理の処理手順を示すフローチャートである。
次に、図16に示すVM命令境界検出処理の流れについて説明する。図19は、図16に示すVM命令境界検出処理の処理手順を示すフローチャートである。
まず、VM命令境界検出部1213は、実行トレースDB131から実行トレースを取り出す(ステップS41)。VM命令境界検出部1213は、実行トレースを所定の方法でクラスタリングする(ステップS42)。クラスタリングは、いずれの手法を用いてもよい。
VM命令境界検出部1213は、実行回数が閾値以上のクラスタをVM命令として検出する(ステップS43)。そして、VM命令境界検出部1213は、VM命令を構成する連続した命令列の開始点と終了点とを境界とする(ステップS44)。VM命令境界検出部1213は、VM命令の境界を返り値として出力して(ステップS45)、VM命令境界検出処理を終了する。
[仮想プログラムカウンタ検出処理の処理手順]
次に、図16に示す仮想プログラムカウンタ検出処理の流れについて説明する。図20は、図16に示す仮想プログラムカウンタ検出処理の処理手順を示すフローチャートである。
次に、図16に示す仮想プログラムカウンタ検出処理の流れについて説明する。図20は、図16に示す仮想プログラムカウンタ検出処理の処理手順を示すフローチャートである。
まず、仮想プログラムカウンタ検出部1214は、実行トレースDB131から第1のテストスクリプトによる実行トレースを一つ取り出す(ステップS51)。続いて、仮想プログラムカウンタ検出部1214は、実行トレースのうちのメモリアクセストレースに着目し、メモリ読み込み先ごとに読み込み回数を数え上げる(ステップS52)。
仮想プログラムカウンタ検出部1214は、実行トレースの取得に用いた第1のテストスクリプトを入力として受け取り(ステップS53)、その第1のテストスクリプトを解析して繰り返しの回数と繰り返される文の数とを取得する(ステップS54)。
続いて、仮想プログラムカウンタ検出部1214は、実行トレースDB131から、繰り返し回数や繰り返される文の数の異なる第1のテストスクリプトによる実行トレースを、さらに一つ取り出す(ステップS55)。そして、仮想プログラムカウンタ検出部1214は、メモリアクセストレースに着目し、メモリ読み込み先ごとに読み込み回数を数え上げる(ステップS56)。また、仮想プログラムカウンタ検出部1214は、実行トレースの取得に用いた第1のテストスクリプトを入力として受け取り(ステップS57)、テストスクリプトを解析して、繰り返しの回数と繰り返される文の数とを取得する(ステップS58)。
ここで、仮想プログラムカウンタ検出部1214は、繰り返し回数や繰り返される文の増減に比例して読み込み回数が変化するメモリ読み込み先のみに絞り込む(ステップS59)。さらに、仮想プログラムカウンタ検出部1214は、ステップS59において絞り込んだメモリ読み込み先を、読み込んだメモリの値が常にVM命令の開始点を指しているものに絞り込む(ステップS60)。
そして、仮想プログラムカウンタ検出部1214は、メモリ読み込み先を一つのみに絞り込めたか否かを判定する(ステップS61)。仮想プログラムカウンタ検出部1214は、メモリ読み込み先を一つのみに絞り込めていない場合(ステップS61:No)、ステップS55に戻り、次の実行トレースを一つ取り出して処理を継続する。一方、仮想プログラムカウンタ検出部1214は、メモリ読み込み先を一つのみに絞り込めた場合(ステップS61:Yes)、絞り込まれたメモリ読み込み先を仮想プログラムカウンタとしてアーキテクチャ情報DB132に格納して(ステップS62)、処理を終了する。
[ディスパッチャ検出処理の処理手順]
次に、図16に示すディスパッチャ検出処理の流れについて説明する。図21は、図16に示すディスパッチャ検出処理の処理手順を示すフローチャートである。
次に、図16に示すディスパッチャ検出処理の流れについて説明する。図21は、図16に示すディスパッチャ検出処理の処理手順を示すフローチャートである。
まず、ディスパッチャ検出部1215は、スクリプトエンジンバイナリを入力として受け取る(ステップS71)。ディスパッチャ検出部1215は、VM命令境界検出部1213から、VM命令の境界を受け取る(ステップS72)。
ディスパッチャ検出部1215は、VM命令境界検出部1213から受け取ったVM命令の境界を基に、スクリプトエンジンバイナリから各VM命令部分を切り出す(ステップS73)。ディスパッチャ検出部1215は、各VM命令間でコード間の類似度を所定の方法で算出する(ステップS74)。類似度の算出手法は、コード間の類似度を算出できる手法であれば、どの手法でもよい。
ディスパッチャ検出部1215は、ステップS74において算出した類似度を基に、全VM命令間で類似度が高い部分を取り出す(ステップS75)。そして、ディスパッチャ検出部1215は、VM命令の終端部分であるかを判定する(ステップS76)。
VM命令の終端部分でない場合(ステップS76:No)、ディスパッチャ検出部1215は、ステップS75に戻り処理を続ける。また、VM命令の終端部分である場合(ステップS76:Yes)、ディスパッチャ検出部1215は、取り出した部分をディスパッチャとして出力して(ステップS77)、処理を終了する。
[VM実行トレース取得処理の処理手順]
次に、図16に示すVM実行トレース取得処理の流れについて説明する。図22は、図16に示すVM実行トレース取得処理の処理手順を示すフローチャートである。
次に、図16に示すVM実行トレース取得処理の流れについて説明する。図22は、図16に示すVM実行トレース取得処理の処理手順を示すフローチャートである。
まず、VM実行トレース取得部1221は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け取る(ステップS81)。そして、VM実行トレース取得部1221は、受け取ったスクリプトエンジンに対して、VPC及びVMオペコードを記録するためのフックを施す(ステップS82)。
VM実行トレース取得部1221は、その状態で受け取ったテストスクリプトをスクリプトエンジンに入力して実行させ(ステップS83)、それによって取得されるVM実行トレースをVM実行トレースDB133に格納する(ステップS84)。
VM実行トレース取得部1221は、入力されたテストスクリプトを全て実行したか否かを判定する(ステップS85)。VM実行トレース取得部1221は、入力されたテストスクリプトを全て実行し終えている場合(ステップS85:Yes)、処理を終了する。VM実行トレース取得部1221は、入力されたテストスクリプトを全て実行し終えていない場合(ステップS85:No)、ステップS83のテストスクリプトの実行に戻って処理を続ける。
[分岐VM命令検出処理の処理手順]
次に、図16に示す分岐VM命令検出処理の流れについて説明する。図23は、図16に示す分岐VM命令検出処理の処理手順を示すフローチャートである。
次に、図16に示す分岐VM命令検出処理の流れについて説明する。図23は、図16に示す分岐VM命令検出処理の処理手順を示すフローチャートである。
まず、分岐VM命令検出部1222は、VM実行トレースDB133から、VM実行トレースを一つ取り出す(ステップS91)。分岐VM命令検出部1222は、VM命令へのポインタとVM命令を紐付け、各々に識別子としてVMオペコードを割り振る(ステップS92)。そして、分岐VM命令検出部1222は、VMオペコードごとに、実行の前後でのVPCの変化量を集計する(ステップS93)。
分岐VM命令検出部1222は、VM実行トレースDB133の全てのVM実行トレースを処理し終えたか否かを判定する(ステップS94)。VM実行トレースDB133の全てのVM実行トレースを処理し終えていない場合(ステップS94:No)、分岐VM命令検出部1222は、ステップS91に戻り、次のVM実行トレースを一つ取り出して処理する。
VM実行トレースDB133の全てのVM実行トレースを処理し終えている場合(ステップS94:Yes)、分岐VM命令検出部1222は、VMオペコードごとにVPCの変化量の分散を算出する(ステップS95)。そして、分岐VM命令検出部1222は、閾値を入力として受け取る(ステップS96)。分岐VM命令検出部1222は、分散が閾値よりも大きいVMオペコードのみに絞り込み(ステップS97)、それらを分岐VM命令としてアーキテクチャ情報DB132に格納して(ステップS98)、処理を終了する。
[フック挿入処理]
次に、図16に示すフック挿入処理の流れについて説明する。図24は、図16に示すフック挿入処理の処理手順を示すフローチャートである。
次に、図16に示すフック挿入処理の流れについて説明する。図24は、図16に示すフック挿入処理の処理手順を示すフローチャートである。
まず、フック挿入部1231は、フック・タップポイント検出部1212によって検出されたフックポイント及びタップポイントを入力として受け取り、(ステップS101)、フックハンドラを準備する(ステップS102)。
フック挿入部1231は、フックハンドラにVMブランチトレース構築処理を追加する(ステップS103)。フック挿入部1231は、フックハンドラにコールスタック再構築処理を追加する(ステップS104)。フック挿入部1231は、フックハンドラに仮想スタック・仮想スタックポインタ検出処理を追加する(ステップS105)。フック挿入部1231は、フックハンドラに仮想スタックポインタ巻き戻し処理を追加する(ステップS106)。
フック挿入部1231は、フックポイントにフックハンドラを用いたフックを挿入する(ステップS107)。
[VMブランチトレース構築処理]
図25は、VMブランチトレース構築処理の処理手順を示すフローチャートである。VMブランチトレース構築処理では、VM実行トレースとVM分岐命令リストとを入力として受け取る(ステップS111)。
図25は、VMブランチトレース構築処理の処理手順を示すフローチャートである。VMブランチトレース構築処理では、VM実行トレースとVM分岐命令リストとを入力として受け取る(ステップS111)。
VMブランチトレース構築処理では、VM実行トレースのエントリを取り出す(ステップS112)。VMブランチトレース構築処理では、VMオペコードがVM分岐命令リストに存在するか判定する(ステップS113)。
VMブランチトレース構築処理では、VMオペコードがVM分岐命令リストに存在する場合(ステップS113:Yes)、VPCを分岐元とし、次のエントリのVPCを分岐先としてVMブランチトレースに保存する(ステップS114)。
VMブランチトレース構築処理では、VMオペコードがVM分岐命令リストに存在しない場合(ステップS113:No)、または、ステップS114終了後、VM実行トレースの全てのエントリを処理したか否かを判定する(ステップS115)。
VMブランチトレース構築処理では、VM実行トレースの全てのエントリを処理していない場合(ステップS115:No)、VM実行トレースの次のエントリを取り出す(ステップS116)。そして、VMブランチトレース構築処理では、ステップS113に戻り、次のエントリについて、VMオペコードがVM分岐命令リストに存在するか判定する。
一方、VMブランチトレース構築処理では、VM実行トレースの全てのエントリを処理した場合(ステップS115:Yes)、VMブランチトレースを出力する(ステップS117)。
[コールスタック再構築処理]
図26は、コールスタック再構築処理の処理手順を示すフローチャートである。まず、コールスタック再構築処理は、VMブランチトレースを入力として受け取る(ステップS141)。次に、コールスタック再構築処理は、再構築するコールスタックを準備する(ステップS142)。
図26は、コールスタック再構築処理の処理手順を示すフローチャートである。まず、コールスタック再構築処理は、VMブランチトレースを入力として受け取る(ステップS141)。次に、コールスタック再構築処理は、再構築するコールスタックを準備する(ステップS142)。
そして、コールスタック再構築処理は、VMブランチトレースの最初のエントリを取り出す(ステップS143)。ここで、コールスタック再構築処理は、分岐元アドレスとVM命令オフセット(例えば、+4)から次のVM命令のアドレスを計算する(ステップS144)。
続いて、コールスタック再構築処理は、計算されたアドレスをコールスタックにプッシュする(ステップS145)。
コールスタック再構築処理は、VMブランチトレースの全てのエントリを処理していない場合(ステップS146:No)、VMブランチトレースの次のエントリを取り出す(ステップS147)。
コールスタック再構築処理は、VMブランチトレースの全てのエントリを処理した場合(ステップS146:Yes)、推定されたコールスタックを出力する(ステップS148)。
図27は、仮想スタック・仮想スタックポインタ検出処理の処理手順を示すフローチャートである。
まず、仮想スタック・仮想スタックポインタ検出処理は、推測されたコールスタックを入力として受け取る(ステップS151)。次に、仮想スタック・仮想スタックポインタ検出処理は、メモリ空間を探索してコールスタックと共通性の高いメモリ領域を所定の方法で探索し仮想スタックとして検出する(ステップS152)。
ここで、仮想スタック・仮想スタックポインタ検出処理は、仮想スタックを指し続けているメモリ領域を仮想スタックポインタとして検出する(ステップS153)。続いて、仮想スタック・仮想スタックポインタ検出処理は、仮想スタック、仮想スタックポインタを出力する(ステップS154)。
図28は、仮想スタック巻き戻し処理の処理手順を示すフローチャートである。まず、仮想スタックポインタ巻き戻し処理は、推定されたコールスタック、仮想スタック、仮想スタックポインタを入力として受け取る(ステップS161)。
次に、仮想スタックポインタ巻き戻し処理は、仮想スタックポインタの現在(例外発生時)の指し先を確認する(ステップS162)。また、仮想スタックポインタ巻き戻し処理は、推定されたコールスタックを参照し、現在の指し先の一つ前の関数の戻り先を確認する(ステップS163)。
ここで、仮想スタックポインタ巻き戻し処理は、仮想スタックを遡り、一つ前の関数の戻り先を格納した位置を検出する(ステップS164)。そして、仮想スタックポインタ巻き戻し処理は、検出された位置を指すように仮想スタックポインタの値を変更する(ステップS165)。
[例外ハンドラ挿入処理]
図16に示す例外ハンドラ挿入処理の流れについて説明する。図29は、図16に示す例外ハンドラ挿入処理の処理手順を示すフローチャートである。
図16に示す例外ハンドラ挿入処理の流れについて説明する。図29は、図16に示す例外ハンドラ挿入処理の処理手順を示すフローチャートである。
例外ハンドラ挿入部1232は、解析対象のスクリプトを入力として受け取る(ステップS171)。例外ハンドラ挿入部1232は、解析対象のスクリプトを所定の方法で解析し、エントリーポイントを取り出す(ステップS172)。
例外ハンドラ挿入部1232は、エントリーポイントを一つ取り出す(ステップS173)。例外ハンドラ挿入部1232は、エントリーポイント以降のコードでの例外を捕捉できるようにして例外ハンドラのコード(例えば、図1参照)を追加する(ステップS174)。
例外ハンドラ挿入部1232は、全てのエントリーポイントに例外ハンドラを追加したか否かを判定する(ステップS175)。全てのエントリーポイントに例外ハンドラを追加していない場合(ステップS175:No)、例外ハンドラ挿入部1232は、次のエントリーポイントを取り出し(ステップS176)、ステップS174に進んで、例外ハンドラのコードを追加する。
例外ハンドラ挿入部1232は、全てのエントリーポイントに例外ハンドラを追加した場合(ステップS175:Yes)、処理を終了する。
[実施の形態の効果]
このように、実施の形態に係る解析機能付与装置10は、スクリプトエンジンのバイナリを監視しながらテストスクリプトを実行し、ブランチトレースとメモリアクセストレースを実行トレースとして取得する。解析機能付与装置10は、その実行トレースに基づいて仮想機械を解析し、フックポイント、タップポイント、VPC、VM命令境界、ディスパッチャのアーキテクチャ情報を取得する。さらに、解析機能付与装置10は、テストスクリプトを実行してVM実行トレースを取得し、そのVM実行トレースを用いて命令セットアーキテクチャを解析して分岐VM命令をアーキテクチャ情報として取得する。
このように、実施の形態に係る解析機能付与装置10は、スクリプトエンジンのバイナリを監視しながらテストスクリプトを実行し、ブランチトレースとメモリアクセストレースを実行トレースとして取得する。解析機能付与装置10は、その実行トレースに基づいて仮想機械を解析し、フックポイント、タップポイント、VPC、VM命令境界、ディスパッチャのアーキテクチャ情報を取得する。さらに、解析機能付与装置10は、テストスクリプトを実行してVM実行トレースを取得し、そのVM実行トレースを用いて命令セットアーキテクチャを解析して分岐VM命令をアーキテクチャ情報として取得する。
そして、解析機能付与装置10は、得られたアーキテクチャ情報を基に、スクリプトエンジンのフックポイントに、例外が発生した場合には、メモリにおけるポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する処理を含むフックを施して、例外処理機能を含む解析機能を付与する。
具体的には、解析機能付与装置10では、解析対象のスクリプトに、例外の発生を捕捉した場合に、VM領域に強制的に処理を移す例外ハンドラを挿入することで例外処理機能を付与する。解析機能付与装置10では、メモリにおけるポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する処理を含むフックハンドラを用いて、フックを施す。これによって、解析機能付与装置10は、例外の発生した関数をスキップすることで、例外による実行の停止を抑制する。
これによって、解析機能付与装置10は、バイナリのみしか手に入らないプロプライエタリなスクリプトエンジンに対しても、実行トレース及びVM実行トレースの取得に基づく解析により、各種アーキテクチャ情報を検出し、人手でのリバースエンジニアリングを要することなく、例外処理機能の付与を実現できる。
また、解析機能付与装置10では、多様なスクリプトエンジンに対して、テストスクリプトさえ用意すれば自動で例外処理機能を付与できるため、個別の設計や実行を要することなく、例外処理機能の付与を実現できる。
上述したように、解析機能付与装置10は、多種多様なスクリプト言語で記述される悪性スクリプトの挙動の解析に有用であり、解析の途上で例外によって実行が停止してしまう悪性スクリプトに対して、その影響を受けずに、挙動を解析することに適している。このため、解析機能付与装置10を用いて、様々なスクリプトエンジンに例外処理機能を付与することで、例外があった場合であっても、例外による実行の停止を抑制しながら、悪性スクリプトの挙動を解析できるため、検知などの対策に生かすことが可能である。
なお、解析機能付与装置10は、実行経路の強制によるマルチパス実行においても同様に、例外を捕捉し、意図しない実行の停止を防ぎつつ解析を継続することが可能である。
[実施形態のシステム構成について]
図3に示す解析機能付与装置10の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、解析機能付与装置10の機能の分散及び統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散または統合して構成することができる。
図3に示す解析機能付与装置10の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、解析機能付与装置10の機能の分散及び統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散または統合して構成することができる。
また、解析機能付与装置10においておこなわれる各処理は、全部または任意の一部が、CPU及びCPUにより解析実行されるプログラムにて実現されてもよい。また、解析機能付与装置10においておこなわれる各処理は、ワイヤードロジックによるハードウェアとして実現されてもよい。
また、実施の形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的に行うこともできる。もしくは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述及び図示の処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて適宜変更することができる。
[プログラム]
図30は、プログラムが実行されることにより、解析機能付与装置10が実現されるコンピュータの一例を示す図である。コンピュータ1000は、例えば、メモリ1010、CPU1020を有する。また、コンピュータ1000は、ハードディスクドライブインタフェース1030、ディスクドライブインタフェース1040、シリアルポートインタフェース1050、ビデオアダプタ1060、ネットワークインタフェース1070を有する。これらの各部は、バス1080によって接続される。
図30は、プログラムが実行されることにより、解析機能付与装置10が実現されるコンピュータの一例を示す図である。コンピュータ1000は、例えば、メモリ1010、CPU1020を有する。また、コンピュータ1000は、ハードディスクドライブインタフェース1030、ディスクドライブインタフェース1040、シリアルポートインタフェース1050、ビデオアダプタ1060、ネットワークインタフェース1070を有する。これらの各部は、バス1080によって接続される。
メモリ1010は、ROM1011及びRAM1012を含む。ROM1011は、例えば、BIOS(Basic Input Output System)等のブートプログラムを記憶する。ハードディスクドライブインタフェース1030は、ハードディスクドライブ1090に接続される。ディスクドライブインタフェース1040は、ディスクドライブ1100に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ1100に挿入される。シリアルポートインタフェース1050は、例えばマウス1110、キーボード1120に接続される。ビデオアダプタ1060は、例えばディスプレイ1130に接続される。
ハードディスクドライブ1090は、例えば、OS1091、アプリケーションプログラム1092、プログラムモジュール1093、プログラムデータ1094を記憶する。すなわち、解析機能付与装置10の各処理を規定するプログラムは、コンピュータ1000により実行可能なコードが記述されたプログラムモジュール1093として実装される。プログラムモジュール1093は、例えばハードディスクドライブ1090に記憶される。例えば、解析機能付与装置10における機能構成と同様の処理を実行するためのプログラムモジュール1093が、ハードディスクドライブ1090に記憶される。なお、ハードディスクドライブ1090は、SSD(Solid State Drive)により代替されてもよい。
また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ1094として、例えばメモリ1010やハードディスクドライブ1090に記憶される。そして、CPU1020が、メモリ1010やハードディスクドライブ1090に記憶されたプログラムモジュール1093やプログラムデータ1094を必要に応じてRAM1012に読み出して実行する。
なお、プログラムモジュール1093やプログラムデータ1094は、ハードディスクドライブ1090に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ1100等を介してCPU1020によって読み出されてもよい。あるいは、プログラムモジュール1093及びプログラムデータ1094は、ネットワーク(LAN(Local Area Network)、WAN(Wide Area Network)等)を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール1093及びプログラムデータ1094は、他のコンピュータから、ネットワークインタフェース1070を介してCPU1020によって読み出されてもよい。
以上、本発明者によってなされた発明を適用した実施の形態について説明したが、本実施の形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例及び運用技術等はすべて本発明の範疇に含まれる。
10 解析機能付与装置
11 入力部
12 制御部
13 記憶部
14 出力部
121 仮想機械解析部
122 命令セットアーキテクチャ解析部
123 機能付与部
131 実行トレースDB
132 アーキテクチャ情報DB
133 VM実行トレースDB
1211 実行トレース取得部
1212 フック・タップポイント検出部
1213 VM命令境界検出部
1214 仮想プログラムカウンタ検出部
1215 ディスパッチャ検出部
1221 VM実行トレース取得部
1222 分岐VM命令検出部
1223 VPCオフセット検出部
1231 フック挿入部
1232 例外ハンドラ挿入部
11 入力部
12 制御部
13 記憶部
14 出力部
121 仮想機械解析部
122 命令セットアーキテクチャ解析部
123 機能付与部
131 実行トレースDB
132 アーキテクチャ情報DB
133 VM実行トレースDB
1211 実行トレース取得部
1212 フック・タップポイント検出部
1213 VM命令境界検出部
1214 仮想プログラムカウンタ検出部
1215 ディスパッチャ検出部
1221 VM実行トレース取得部
1222 分岐VM命令検出部
1223 VPCオフセット検出部
1231 フック挿入部
1232 例外ハンドラ挿入部
Claims (7)
- 解析機能付与装置が実行する解析機能付与方法であって、
スクリプトエンジンの仮想機械を解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行される前記仮想機械の命令を指し示す変数である仮想プログラムカウンタを取得する第1の解析工程と、
前記仮想機械の命令の体系である命令セットアーキテクチャを解析して、分岐を発生させる仮想機械命令である分岐仮想機械命令を取得する第2の解析工程と、
前記第1の解析工程及び前記第2の解析工程における解析によって得られたアーキテクチャ情報である、前記仮想プログラムカウンタ及び前記分岐仮想機械命令に基づいて、前記スクリプトエンジンの前記フックポイントに、例外が発生した場合には、メモリにおけるポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する処理を含むフックを施して解析機能を付与する付与工程と、
を含んだことを特徴とする解析機能付与方法。 - 前記付与工程は、
解析対象のスクリプトに、例外の発生を捕捉した場合に、仮想機械領域に処理を移す機能を有する例外ハンドラを挿入する第1の挿入工程と、
前記スクリプトエンジンの前記フックポイントに、前記仮想機械領域において、メモリにおけるポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する処理を含むフックハンドラを用いてフックを挿入する第2の挿入工程と、
を含んだことを特徴とする請求項1に記載の解析機能付与方法。 - 前記第2の解析工程は、
前記仮想機械において実行された実行トレースである仮想機械実行トレースであって、識別子として仮想機械オペコードが仮想的に割り振られ、実行された仮想機械命令ハンドラのポインタと前記仮想プログラムカウンタとを記録した仮想機械実行トレースを取得する第1の取得工程と、
前記仮想機械実行トレースの仮想機械オペコードごとの仮想プログラムカウンタの変化量のばらつきによって、前記分岐仮想機械命令を検出する第1の検出工程と、
を含み、
前記フックハンドラは、
前記第1の検出工程によって検出された前記分岐仮想機械命令の一覧を参照し、前記仮想機械実行トレースから分岐仮想機械命令を検出し、該検出した分岐仮想機械命令の実行前後の前記仮想プログラムカウンタを対応付けた仮想機械ブランチトレースを構築する第1の処理と、前記仮想機械ブランチトレースからコールスタックを構築する第2の処理と、前記コールスタックとの共通性に関する所定の条件を満たすメモリの領域を仮想スタックとして検出し、さらに前記仮想スタックを指しているメモリ領域を仮想スタックポインタとして検出する第3の処理と、前記仮想スタックポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する第4の処理と、
を含むことを特徴とする請求項2に記載の解析機能付与方法。 - 前記第1の解析工程は、
実行時の条件を変えて複数の実行トレースを取得する第2の取得工程と、
前記実行トレースを解析し、前記フックポイントを検出する第2の検出工程と、
前記実行トレースをクラスタリングして、各仮想機械命令の境界を検出する第3の検出工程と、
メモリの読み込み回数に着目した差分実行解析と前記第3の検出工程において検出された各仮想機械命令の境界とを用いて前記複数の実行トレースを解析し、前記仮想プログラムカウンタを検出する第4の検出工程と、
前記第1の検出工程において検出された各仮想命令の境界を基に、スクリプトエンジンのバイナリを解析し、ディスパッチャを検出する第5の検出工程と、
を含んだことを特徴とする請求項3に記載の解析機能付与方法。 - 前記第1の解析工程及び前記第2の解析工程は、テスト用のスクリプトを用いた解析を実施することを特徴とする請求項1~4のいずれか一つに記載の解析機能付与方法。
- スクリプトエンジンの仮想機械を解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行される前記仮想機械の命令を指し示す変数である仮想プログラムカウンタを取得する第1の解析部と、
前記仮想機械の命令の体系である命令セットアーキテクチャを解析して、分岐を発生させる仮想機械命令である分岐仮想機械命令を取得する第2の解析部と、
前記第1の解析部及び前記第2の解析部による解析によって得られたアーキテクチャ情報である、前記仮想プログラムカウンタ及び前記分岐仮想機械命令に基づいて、前記スクリプトエンジンの前記フックポイントに、例外が発生した場合には、メモリにおけるポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する処理を含むフックを施して解析機能を付与する付与部と、
を有することを特徴とする解析機能付与装置。 - スクリプトエンジンの仮想機械を解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行される前記仮想機械の命令を指し示す変数である仮想プログラムカウンタを取得する第1の解析ステップと、
前記仮想機械の命令の体系である命令セットアーキテクチャを解析して、分岐を発生させる仮想機械命令である分岐仮想機械命令を取得する第2の解析ステップと、
前記第1の解析ステップ及び前記第2の解析ステップにおける解析によって得られたアーキテクチャ情報である、前記仮想プログラムカウンタ及び前記分岐仮想機械命令に基づいて、前記スクリプトエンジンの前記フックポイントに、例外が発生した場合には、メモリにおけるポインタの指し先を、当該指し先の一つ前の関数の戻り先に変更する処理を含むフックを施して解析機能を付与する付与ステップと、
をコンピュータに実行させるための解析機能付与プログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2023553915A JPWO2023067663A1 (ja) | 2021-10-18 | 2021-10-18 | |
PCT/JP2021/038492 WO2023067663A1 (ja) | 2021-10-18 | 2021-10-18 | 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2021/038492 WO2023067663A1 (ja) | 2021-10-18 | 2021-10-18 | 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2023067663A1 true WO2023067663A1 (ja) | 2023-04-27 |
Family
ID=86058890
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2021/038492 WO2023067663A1 (ja) | 2021-10-18 | 2021-10-18 | 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム |
Country Status (2)
Country | Link |
---|---|
JP (1) | JPWO2023067663A1 (ja) |
WO (1) | WO2023067663A1 (ja) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020075335A1 (ja) * | 2018-10-11 | 2020-04-16 | 日本電信電話株式会社 | 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム |
WO2021070393A1 (ja) * | 2019-10-11 | 2021-04-15 | 日本電信電話株式会社 | 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム |
-
2021
- 2021-10-18 WO PCT/JP2021/038492 patent/WO2023067663A1/ja unknown
- 2021-10-18 JP JP2023553915A patent/JPWO2023067663A1/ja active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020075335A1 (ja) * | 2018-10-11 | 2020-04-16 | 日本電信電話株式会社 | 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム |
WO2021070393A1 (ja) * | 2019-10-11 | 2021-04-15 | 日本電信電話株式会社 | 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム |
Non-Patent Citations (1)
Title |
---|
OYAMA YOSHIHIRO, HIROTAKA KOKUBO: "Dynamic Analysis Method for Exception Raising Malware", COMPUTER SECURITY SYMPOSIUM. 21 - 24 OCTOBER 2019, 14 October 2019 (2019-10-14), pages 953 - 960, XP093058985 * |
Also Published As
Publication number | Publication date |
---|---|
JPWO2023067663A1 (ja) | 2023-04-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11423146B2 (en) | Provenance-based threat detection tools and stealthy malware detection | |
Carmony et al. | Extract Me If You Can: Abusing PDF Parsers in Malware Detectors. | |
JP7115552B2 (ja) | 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム | |
WO2022180702A1 (ja) | 解析機能付与装置、解析機能付与プログラム及び解析機能付与方法 | |
JP7287480B2 (ja) | 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム | |
US10505960B2 (en) | Malware detection by exploiting malware re-composition variations using feature evolutions and confusions | |
US10380349B2 (en) | Security analysis using relational abstraction of data structures | |
US9507933B2 (en) | Program execution apparatus and program analysis apparatus | |
WO2018159010A1 (ja) | 選択装置、選択方法及び選択プログラム | |
JP6527295B2 (ja) | 攻撃コード検知装置、攻撃コード検知方法及び攻撃コード検知プログラム | |
US9495542B2 (en) | Software inspection system | |
WO2023067668A1 (ja) | 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム | |
WO2023067665A1 (ja) | 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム | |
US20230141948A1 (en) | Analysis and Testing of Embedded Code | |
WO2023067663A1 (ja) | 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム | |
US20190205526A1 (en) | Binary image stack cookie protection | |
WO2023067667A1 (ja) | 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム | |
WO2024079794A1 (ja) | 解析機能付与装置、解析機能付与方法および解析機能付与プログラム | |
JP6599053B1 (ja) | 情報処理装置、情報処理方法及び情報処理プログラム | |
KR102670476B1 (ko) | IoT 장치 취약점 분석을 위한 오염 경로 분석 시스템 및 방법 | |
Yin et al. | Precise Discovery of More Taint-Style Vulnerabilities in Embedded Firmware | |
Wu et al. | Directed Fuzzing Based on Dynamic Taint Analysis for Binary Software | |
CA2838908A1 (en) | Security scan using entity history |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 21961316 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2023553915 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |