WO2023067668A1 - 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム - Google Patents

解析機能付与方法、解析機能付与装置及び解析機能付与プログラム Download PDF

Info

Publication number
WO2023067668A1
WO2023067668A1 PCT/JP2021/038502 JP2021038502W WO2023067668A1 WO 2023067668 A1 WO2023067668 A1 WO 2023067668A1 JP 2021038502 W JP2021038502 W JP 2021038502W WO 2023067668 A1 WO2023067668 A1 WO 2023067668A1
Authority
WO
WIPO (PCT)
Prior art keywords
instruction
analysis
branch
virtual machine
execution
Prior art date
Application number
PCT/JP2021/038502
Other languages
English (en)
French (fr)
Inventor
利宣 碓井
知範 幾世
裕平 川古谷
誠 岩村
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to PCT/JP2021/038502 priority Critical patent/WO2023067668A1/ja
Publication of WO2023067668A1 publication Critical patent/WO2023067668A1/ja

Links

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. 29 is a diagram showing a code fragment showing an example of anti-analysis.
  • 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 capable of providing a script engine with an execution function that suppresses the execution stop due to an exception by skipping the basic block that caused the exception.
  • An object of the present invention is to provide a method, 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 point pointed to by the virtual program counter is the basic block immediately after the basic block where the exception occurred. and an imparting step of imparting an analysis function by applying a hook including processing to change to the beginning.
  • 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 the control flow graph construction process.
  • FIG. 14 is a diagram for explaining basic block skip processing.
  • FIG. 15 is a flow chart showing a processing procedure of analysis function imparting processing according to the embodiment.
  • FIG. 16 is a flowchart of the execution trace acquisition process shown in FIG. 17 is a flow chart showing a processing procedure of the hook/tap point detection processing shown in FIG. 15.
  • FIG. FIG. 18 is a flow chart showing the procedure of the VM instruction boundary detection process shown in FIG. FIG.
  • FIG. 19 is a flow chart showing the processing procedure of the virtual program counter detection process shown in FIG.
  • FIG. 20 is a diagram explaining processing of the dispatcher detection unit.
  • FIG. 21 is a flowchart of a processing procedure of a VM execution trace acquisition process shown in FIG. 15;
  • FIG. 22 is a flowchart showing a processing procedure of branch VM instruction detection processing shown in FIG.
  • FIG. 23 is a flow chart showing the procedure of the hook inserting process shown in FIG.
  • FIG. 24 is a flowchart illustrating the processing procedure of VM branch trace construction processing.
  • FIG. 25 is a flow chart showing the processing procedure of the control flow graph construction processing.
  • FIG. 26 is a flowchart showing the procedure of basic block skip processing.
  • FIG. 21 is a flowchart of a processing procedure of a VM execution trace acquisition process shown in FIG. 15
  • FIG. 22 is a flowchart showing a processing procedure of branch VM instruction detection processing shown in FIG.
  • FIG. 23 is a flow
  • FIG. 27 is a flow chart showing the procedure of the exception handler insertion process shown in FIG.
  • FIG. 28 is a diagram showing an example of a computer that implements the analysis function imparting device by executing a program.
  • FIG. 29 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 inserts a hook into the hook point of the script engine using the hook handler. 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 basic block in which the exception occurred by changing the point pointed to by the VPC to the beginning of the basic block immediately after the basic block in which the exception occurred.
  • the analysis function imparting device shifts processing to the VM area and skips the basic block in which the exception occurred as instructed in the hook handler, thereby stopping execution due to the exception. Suppress.
  • 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 basic block 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 a stop.
  • 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 input of test scripts and script engine binaries, 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, see 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) and a branch VM instruction detection unit 1222 (first detection unit).
  • 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 branch VM instruction detection unit 1222 determines which of the branch VM instructions is a conditional branch VM instruction in order to construct a precise control flow graph. At the time of conditional branching, the conditional branch flag is always accessed in order to determine the branch destination. Therefore, the conditional branch VM instruction can be determined by verifying whether the conditional branch flag is accessed when executing each branch VM instruction. In other words, when executing the branch VM instruction, if the conditional branch flag is accessed, it can be determined that it is a conditional branch VM instruction, and if not, it can be determined that it is not a conditional branch VM instruction. Therefore, based on the VM execution trace and the memory access trace, the branch VM instruction detection unit 1222 determines a branch VM instruction that involves accessing the conditional branch flag as a conditional branch VM instruction.
  • the branch VM instruction detection unit 1222 also determines call and return VM instructions. Branching by a call VM instruction saves the address immediately after the bytecode of the calling source, and after execution of the called subroutine, the return VM instruction returns to the saved address. Therefore, the branch VM instruction detection unit 1222 sets a certain branch VM instruction as instruction 1, sets another branch VM instruction after that as instruction 2, and when instruction 2 returns to the address immediately after instruction 1 on the bytecode, A pair of instruction 1 and instruction 2 is determined as a call and return VM instruction.
  • 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 processing to change the point pointed to by the VPC to the beginning of the basic block immediately after the basic block in which the exception occurred.
  • 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 processing for changing the destination pointed by the VPC to the beginning of the basic block immediately after the basic block in which the exception occurred in the VM area.
  • the hook inserting unit 1231 causes the hook handler to skip the VM branch trace construction process (first process), the control flow graph construction process (second process), and the basic block in which the exception occurred.
  • Basic block skip processing (third processing) is added.
  • the hook is added with a function to change the destination pointed by the VPC to the beginning of the basic block immediately following the basic block in which the exception occurred, and to skip the basic block in which the exception occurred.
  • a VM branch trace is constructed in which the VPCs before and after execution of the branch VM instruction are associated with each other.
  • the VM branch trace is used to construct a control flow graph with basic blocks as nodes and branches as edges due to the execution of branch VM instructions.
  • 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, or the like, 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 VPC detection.
  • 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 method.
  • 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 (in the example of FIG. 11, VM instruction handler 3) with variations in the progress of the VPC 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 control flow graph construction process for constructing a control flow graph, and a basic block for skipping a basic block where an exception has occurred. Add skip processing.
  • 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 control flow graph construction process.
  • the VM branch trace 43 constructed in the VM branch trace construction process is used to construct a control flow graph with basic blocks as nodes and branches of the VM branch trace 43 as edges (see FIG. 13). (1)).
  • the branch shown in row R61 of the VM branch trace 43 is assumed to be edge E61
  • the basic block of the branch source of edge E61 is assumed to be node N61
  • the basic block of the branch destination of edge E61 is assumed to be node Let it be N62.
  • the branch shown in row R71 of the VM branch trace 43 be edge E71
  • the branch source small block of edge 71 be node N71
  • the branch destination basic block of edge E71 be node N72.
  • the node N71 has a branch indicated by the edge E72 in addition to the edge E71, and the basic block of this branch destination is indicated by the node N73.
  • FIG. 14 is a diagram explaining basic block skip processing.
  • the VPC is constantly traced, and when an exception occurs, it is determined which part of the control flow graph constructed in the control flow graph construction processing corresponds to this exception.
  • the VPC points to the beginning of the basic block immediately after the basic block in which the exception occurred, thereby skipping the basic block in which the exception occurred ((1) in FIG. 14). ).
  • the destination pointed by the VPC is changed to the top node N71 immediately after the node in which the exception occurred. Then, depending on the execution content of the node N71, the process proceeds by branching to the edge E71 or the edge E72.
  • the function adding unit 123 can add an exception skip function to the script to be analyzed by inserting an exception handler into the script to be analyzed and adding basic block skip processing to the hook handler.
  • FIG. 15 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 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 S8).
  • 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 S9). Then, the exception handler inserting 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 S10). Then, the output unit 124 outputs the script engine binary provided with the exception skip function (step S11).
  • FIG. 16 is a flowchart of the execution trace acquisition process 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. 17 is a flow chart showing a processing procedure of the hook/tap point detection processing shown in FIG. 15.
  • FIG. 15 is a flow chart showing a processing procedure of the hook/tap point detection processing shown in FIG. 15.
  • 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. 18 is a flow chart showing the procedure of the VM instruction boundary detection process shown in FIG. 15 .
  • 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. 19 is a flow chart showing the processing procedure of the virtual program counter detection process 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. 20 is a flow chart showing a processing procedure of dispatcher detection processing shown in FIG.
  • 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. 21 is a flowchart of a processing procedure of a VM execution trace acquisition process shown in FIG. 15;
  • 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. 22 is a flowchart showing a processing procedure of branch VM instruction detection processing shown in FIG. 15 .
  • 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. 23 is a flow chart showing the procedure of the hook inserting process shown in FIG.
  • 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 control flow graph construction processing to the hook handler (step S104).
  • the hook insertion unit 1231 adds basic block skip processing to the hook handler (step S105).
  • the hook insertion unit 1231 inserts a hook using the hook handler at the hook point (step S106).
  • FIG. 24 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 if all entries in the VM execution trace have been processed (step S115: Yes), a hook using a hook handler is inserted at the hook point (step S117).
  • FIG. 25 is a flow chart showing the processing procedure of the control flow graph construction processing.
  • a VM branch trace is received as an input (step S121)
  • an entry of the VM branch trace is extracted (step S122).
  • control flow graph construction process a basic block starting from the branch destination address is added as a node to the control flow graph (step S123).
  • an edge from the branch source address to the branch destination address is added to the control flow graph (step S124).
  • step S125 if all entries in the VM branch trace have not been processed (step S125: No), the next entry in the VM execution trace is taken out (step S126). Then, in the control flow graph construction process, the process returns to step S123, and for the next entry, the basic block starting from the branch destination address is added as a node to the control flow graph.
  • step S125 when all entries in the VM branch trace have been processed (step S125: Yes), the constructed control flow graph is output (step S127).
  • FIG. 26 is a flowchart showing the procedure of basic block skip processing.
  • the control flow graph constructed in the control flow graph construction processing is received as input (step S131).
  • the node currently pointed to by the VPC (when an exception occurs) is confirmed (step S132).
  • the edge is traced from the currently pointed node to extract the next node (step S133).
  • step S134 it is determined whether or not there are multiple next nodes. In the basic block skip processing, if there are a plurality of next nodes (step S134: Yes), one node is selected as the next node, and the other nodes are selected at the next execution (step S135). Selection rules for the next node are preset.
  • step S134 if there are no multiple next nodes (step S134: No), or after the process of step S135 ends, the VPC value is changed to point to the beginning of the next node (step S136).
  • FIG. 27 is a flow chart showing the procedure of the exception handler insertion process shown in FIG.
  • the exception handler insertion unit 1232 receives the script to be analyzed as an input (step S141).
  • the exception handler insertion unit 1232 analyzes the analysis target script by a predetermined method and extracts the entry point (step S142).
  • the exception handler insertion unit 1232 extracts one entry point (step S143).
  • 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 S144).
  • the exception handler insertion unit 1232 determines whether exception handlers have been added to all entry points (step S145). If exception handlers have not been added to all entry points (step S145: No), the exception handler insertion unit 1232 extracts the next entry point (step S146), proceeds to step S144, and adds exception handler code. do.
  • step S145: Yes When the exception handler insertion unit 1232 has added exception handlers to all entry points (step S145: Yes), the process ends.
  • 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 in the hook point of the script engine, changes the point pointed to by the VPC to the basic block immediately after the basic block in which the exception occurred. Apply a hook that includes processing to change to the beginning of the , and add an analysis function that includes 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.
  • an exception handler that forcibly transfers processing to the VM area when an exception is caught.
  • a hook is applied using a hook handler including processing for changing the point pointed to by the VPC to the beginning of the basic block immediately after the basic block in which the exception occurred.
  • the analysis function imparting device 10 skips the basic block in which the exception has occurred, 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.
  • exception handling functions can be provided without the need for individual design and implementation. 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. 28 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

Abstract

解析機能付与装置（１０）は、スクリプトエンジンのＶＭを解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行されるＶＭの命令を指し示す変数であるＶＰＣを取得する仮想機械解析部（１２１）と、ＶＭの命令の体系である命令セットアーキテクチャを解析して、分岐を発生させるＶＭ命令である分岐ＶＭ命令を取得する命令セットアーキテクチャ解析部（１２２）と、仮想機械解析部（１２１）及び命令セットアーキテクチャ解析部（１２２）による解析によって得られたアーキテクチャ情報である、ＶＰＣ及び分岐ＶＭ命令に基づいて、スクリプトエンジンのフックポイントに、例外が発生した場合には、ＶＰＣの指す先を、例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含むフックを施して解析機能を付与する機能付与部（１２３）と、を有する。

Description

解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
　本発明は、解析機能付与方法、解析機能付与装置及び解析機能付与プログラムに関する。
　マルウェアを用いたスパム（マルスパム）やファイルレスマルウェアなどの多様な攻撃の形態が生じるにともなって、悪性な挙動を示すスクリプト（悪性スクリプト）による攻撃の脅威が顕在化している。
　悪性スクリプトとは、悪意のある挙動を持ったスクリプトであり、スクリプトエンジンの提供する機能を悪用して攻撃を実現するプログラムである。一般に、オペレーティングシステム（Operating　System：ＯＳ）がデフォルトで有するスクリプトエンジンや、Webブラウザや文書ファイルのビューアなど、特定のアプリケーションが有するスクリプトエンジンを用いて攻撃が実施される。
　こうしたスクリプトエンジンの多くは、ユーザの許可が必要な場合もあるものの、ファイル操作やネットワーク通信、プロセスの起動など、システムを介した挙動も実現可能である。したがって、悪性スクリプトを用いた攻撃は、実行ファイルのマルウェアを用いた攻撃と同様に、ユーザに対しての脅威となる。
　この悪性スクリプトによる攻撃に対策を講じるためには、スクリプトの持つ挙動を正確に把握する必要がある。したがって、スクリプトを解析することで、その挙動を明らかにする技術が希求される。
　悪性スクリプトを解析する際に生じる問題として、コードの難読化がある。悪性スクリプトの多くは、難読化と呼ばれる、解析を妨害する処理が施されている。難読化は、故意にコードの複雑さを高めることで、コードの表層的な情報に基づく解析を困難にする。すなわち、スクリプトを実行せずに、コードから得られる情報で解析する、静的解析と呼ばれる解析方法を妨害する。
　特に、実行するコードの一部を外部から動的に取得する場合は、そのコードは実行しなければ得られないため、静的には解析できない。したがって、静的解析はその原理上、不可能となる。
　一方で、スクリプトを実行し、その振る舞いを監視することで挙動を知る動的解析と呼ばれる手法は、前述のような難読化の影響を受けない。このため、悪性スクリプトの解析においては、動的解析に基づく手法が主に用いられている。
　一般的な動的解析では、解析環境で悪性スクリプトを実行し、その挙動を監視することにより、悪性スクリプト中で実行された単一の実行経路の挙動のみが得られる。このため、解析環境で実行されなかった経路の挙動は得ることができないという問題がある。
　言い換えると、特定の条件下でしか実行されない経路を有する悪性スクリプトについては、動的解析によっても、全ての挙動を解析しきれないという問題がある。
　特定の条件下でしか実行されない経路がある場合として、例えば、指令サーバからの指令によってその先の実行経路が決まる場合や、解析妨害によって解析環境では悪性な挙動を示さないようになっている場合がある。
　前者は、指令サーバからの指令がなければ、その先の実行経路が決定されず、悪性な挙動を持った経路が実行されない場合である。悪性スクリプトを検出して解析する際には、既に攻撃者が撤退して指令サーバがなくなっている場合も少なくないため、そのような場合には、悪性な挙動を観測できない。
　後者は、悪性スクリプトが、自身が実行されている環境の情報を取得し、それが特定の条件を満たしていなければ、悪性な挙動を示さないという解析妨害である。例えば、解析環境に高頻度に見られる特徴が見られた場合には、自分が解析されていると判断して、実行を中断するという解析妨害に用いられる。
　図２９は、解析妨害の一例を示すコード片を示す図である。このコード片は、実行されている環境のＣＰＵ（Central　Processing　Unit）のコア数を取得し、それが２以上かつ８以下でなければ、解析環境の可能性が高いと判断して、実行を終了するという解析妨害を持つ。さもなければ、解析環境ではないと判断して、悪性な挙動を示す。
　このような特定の条件下でしか実行されない経路の挙動を捉えるためには、複数の実行経路を実行するマルチパス実行が必要となる。
　マルチパス実行では、実行が条件分岐に到達した際に、実行状態を分岐させ、分岐した各々の実行状態が、分岐のそれぞれの実行経路を辿るようにする。これにより、条件分岐で発生する二つの実行経路の両方を実行する。
　マルチパス実行の実現について、例えば、非特許文献１には、JavaScript（登録商標）に対して、マルチパス実行の一種であるシンボリック実行を実現する手法が記載されている。この手法によれば、JavaScriptのスクリプトの条件分岐において、実行可能な経路を網羅的に辿り、挙動を観測できる。
　また、非特許文献２には、JavaScriptに対して、マルチパス実行の一種である経路強制実行を実現する手法が記載されている。この手法によれば、JavaScriptのスクリプトの条件分岐において、全ての経路を網羅的に辿り、挙動を観測できる。
　非特許文献３には、スクリプトエンジンに予め手動で改造を施した上で、そのスクリプトエンジンをバイナリ向けのシンボリック実行基盤の上で実行することで、スクリプトエンジン上で実行されているスクリプトに対して、スクリプトエンジン越しにシンボリック実行を実現する手法が記載されている。この手法によれば、手動で改造を施せるスクリプトエンジンがあれば、どのようなスクリプト言語でも汎用的にシンボリック実行を実現し、実行可能な経路を網羅的に辿って、挙動を観測できる。
　そして、非特許文献４には、マルウェアが自身のプログラムの難読化にしばしば用いる仮想機械（Virtual　Machine：ＶＭ）を解析する手法が記載されている。この手法によれば、ＶＭを解析することで、そのアーキテクチャの情報を取得できる。スクリプトエンジンにおいてスクリプトの実行を司るのはＶＭであるため、この手法の考え方を一部転用できる。
　非特許文献５には、スクリプトエンジンを解析し、得られたアーキテクチャの情報に基づいて、マルチパス実行機能を実現するコードを追加することにより、スクリプトのマルチパス実行を可能にしている。この手法によれば、多様なスクリプトの言語やエンジンに対して、マルチパス実行を実現できる。
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.
　ここで、攻撃者が意図的に例外を起こすことで、解析の実行を停止させて、解析を妨害する場合がある。また、経路強制実行によるマルチパス実行では、実行経路を強制することによって、通常の実行では発生し得ない例外が発生し、実行が停止する場合が見受けられる。例外が発生すると解析の実行が停止するため、例外が発生した場合であっても、解析の実行を継続することができる技術が要望されている。
　そのためには、例外の発生時に、例外を引き起こす箇所を強制的にスキップして実行を継続する必要がある。このとき、どの程度の範囲をスキップするべきか、たとえば、現在実行中の命令をスキップするべきか、基本ブロックをスキップするべきか、関数をスキップするべきか、という点は、発生した例外によって異なる。
　したがって、例外による実行の停止を抑制する技術の一つとして、例外を引き起こした基本ブロックをスキップして実行を継続する技術が必要となる。
　本発明は、上記に鑑みてなされたものであって、スクリプトエンジンに対して、例外を引き起こした基本ブロックをスキップすることで例外による実行の停止を抑制した実行機能の付与を実現できる解析機能付与方法、解析機能付与装置及び解析機能付与プログラムを提供することを目的とする。
　上述した課題を解決し、目的を達成するために、本発明の解析機能付与方法は、解析機能付与装置が実行する解析機能付与方法であって、スクリプトエンジンの仮想機械を解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行される仮想機械の命令を指し示す変数である仮想プログラムカウンタを取得する第１の解析工程と、仮想機械の命令の体系である命令セットアーキテクチャを解析して、分岐を発生させる仮想機械命令である分岐仮想機械命令を取得する第２の解析工程と、第１の解析工程及び第２の解析工程における解析によって得られたアーキテクチャ情報である、仮想プログラムカウンタ及び分岐仮想機械命令に基づいて、スクリプトエンジンのフックポイントに、例外が発生した場合には、仮想プログラムカウンタの指す先を、例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含むフックを施して解析機能を付与する付与工程と、を含んだことを特徴とする。
　本発明によれば、スクリプトエンジンに対して、例外による実行の停止を抑制した実行機能の付与を実現できる。
図１は、例外ハンドラの一例を説明する図である。 図２は、スクリプトＡＰＩのフックを用いたハイパーバイザコールの一例を示す図である。 図３は、実施の形態に係る解析機能付与装置の構成の一例を説明する図である。 図４は、仮想プログラムカウンタ（ＶＰＣ）の検出に用いるテストスクリプトの一例を示す図である。 図５は、分岐ＶＭ命令検出に用いるテストスクリプトの一例を示す図である。 図６は、実行トレースの一例を示す図である。 図７は、ＶＭ実行トレースの一例を示す図である。 図８は、ＶＭ命令境界検出部の処理を説明する図である。 図９は、仮想プログラムカウンタ検出部の処理を説明する図である。 図１０は、ディスパッチャ検出部の処理を説明する図である。 図１１は、分岐ＶＭ命令検出部の処理を説明する図である。 図１２は、ＶＭブランチトレース構築処理を説明する図である。 図１３は、制御フローグラフ構築処理を説明する図である。 図１４は、基本ブロックスキップ処理を説明する図である。 図１５は、実施の形態に係る解析機能付与処理の処理手順を示すフローチャートである。 図１６は、図１５に示す実行トレース取得処理の処理手順を示すフローチャートである。 図１７は、図１５に示すフック・タップポイント検出処理の処理手順を示すフローチャートである。 図１８は、図１５に示すＶＭ命令境界検出処理の処理手順を示すフローチャートである。 図１９は、図１５に示す仮想プログラムカウンタ検出処理の処理手順を示すフローチャートである。 図２０は、ディスパッチャ検出部の処理を説明する図である。 図２１は、図１５に示すＶＭ実行トレース取得処理の処理手順を示すフローチャートである。 図２２は、図１５に示す分岐ＶＭ命令検出処理の処理手順を示すフローチャートである。 図２３は、図１５に示すフック挿入処理の処理手順を示すフローチャートである。 図２４は、ＶＭブランチトレース構築処理の処理手順を示すフローチャートである。 図２５は、制御フローグラフ構築処理の処理手順を示すフローチャートである。 図２６は、基本ブロックスキップ処理の処理手順を示すフローチャートである。 図２７は、図１５に示す例外ハンドラ挿入処理の処理手順を示すフローチャートである。 図２８は、プログラムが実行されることにより、解析機能付与装置が実現されるコンピュータの一例を示す図である。 図２９は、解析妨害の一例を示すコード片を示す図である。
　以下に、本願に係る解析機能付与方法、解析機能付与装置及び解析機能付与プログラムの実施形態を図面に基づいて詳細に説明する。また、本発明は、以下に説明する実施形態により限定されるものではない。
［実施の形態］
　実施の形態に係る解析機能付与装置は、スクリプトエンジンに適用できる解析機能付与装置である。
　本実施の形態に係る解析機能付与装置は、スクリプトエンジンのバイナリを監視しながらテストスクリプトを実行して、ブランチトレースとメモリアクセストレースとを実行トレースとして取得する。
　そして、解析機能付与装置は、この実行トレースに基づいて仮想機械を解析し、フックポイント、タップポイント、次に実行されるＶＭ命令を指し示す変数である仮想プログラムカウンタ（ＶＰＣ）、ＶＭ命令の境界、ディスパッチャのアーキテクチャ情報を取得する。なお、これらはいずれも、スクリプトエンジンの構成要素であり、アーキテクチャに関する情報であって、アーキテクチャ情報ＤＢ１３２（後述）に格納される。
　さらに、解析機能付与装置は、テストスクリプトを実行してＶＭ実行トレースを取得し、このＶＭ実行トレースを用いて命令セットアーキテクチャを解析する。これによって、解析機能付与装置は、スクリプト内で分岐を発生させるＶＭ命令である分岐ＶＭ命令を、アーキテクチャ情報として取得する。
　そして、解析機能付与装置は、取得したアーキテクチャ情報を基に、スクリプトエンジンのフックポイントに、フックハンドラを用いてフックを挿入する。さらに、解析機能付与装置は、解析対象のスクリプトに、例外ハンドラを挿入し、例外処理機能を付与する。例外ハンドラは、例外の発生を捕捉した場合に、ＶＭ領域に強制的に処理を移す機能を有する。そして、フックハンドラには、ＶＰＣの指す先を、例外が発生した基本ブロックの直後の基本ブロックの先頭に変更することで、例外の発生した基本ブロックをスキップする機能が追加される。これによって、解析機能付与装置は、例外が発生した場合にはＶＭ領域に処理を移行し、フックハンドラにおいて指示された、例外が発生した基本ブロックのスキップを行うことで、例外による実行の停止を抑制する。
　図１は、例外ハンドラの一例を説明する図である。図２は、スクリプトＡＰＩのフックを用いたハイパーバイザコールの一例を示す図である。解析機能付与装置は、図１に示すように、解析対象のスクリプトのエントリーポイントに対し、Ｅ１～Ｅ３の枠部分の内容を実行前に静的に追加する（図１の（１），（２））。
　具体的には、解析機能付与装置は、図１に示すように、解析対象のスクリプトのエントリーポイントに対し、「try」及び「catch」のコードを追加し（枠Ｅ１，Ｅ２）、枠Ｅ３の３行目のように、例外が発生した場合には、スクリプトＡＰＩをフックする「hooked_script_API(e)」コードを追加する。これによって、例外時には、スクリプトＡＰＩをフックしハイパーバイザコールとして利用して例外のスキップを行う（図１の（３））。すなわち、解析機能付与装置は、図２に示すように、スクリプトＡＰＩのフックによってハイパーバイザコール相当を実現する（図２の（１））ことで、例外が発生した場合にはＶＭ領域に処理を移行し、フックハンドラにおいて指示された、例外が発生した基本ブロックのスキップを行う。
　このように、解析機能付与装置は、例外を捕捉し、解析対象のスクリプトに例外ハンドラを挿入することで、例外の発生した箇所の先に強制的に実行を進めさせることで、意図しない実行の停止を防ぎつつ、解析を継続する。
［解析機能付与装置の構成］
　続いて、図３を参照して、実施の形態に係る解析機能付与装置１０の構成について具体的に説明する。図３は、実施の形態に係る解析機能付与装置の構成の一例を説明する図である。
　図３に示すように、解析機能付与装置１０は、入力部１１、制御部１２、記憶部１３、出力部１４を有する。そして、解析機能付与装置１０は、テストスクリプト、スクリプトエンジンバイナリ及び解析対象スクリプトの入力を受け付ける。
　入力部１１は、キーボードやマウス等の入力デバイスで構成され、外部からの情報の入力を受け付け、制御部１２に入力する。また、入力部１１は、有線接続、或いは、ネットワーク等を介して接続された他の装置との間で、各種情報を送受信する通信インタフェースを有し、他の装置から送信された情報の入力を受け付ける。入力部１１は、テストスクリプト及びスクリプトエンジンバイナリの入力を受け付け、制御部１２に出力する。テストスクリプトは、スクリプトエンジンを動的解析して実行トレース及びＶＭ実行トレースを取得する際に、入力されるスクリプトである。なお、テストスクリプトの詳細は後述する。スクリプトエンジンバイナリは、スクリプトエンジンを構成する実行可能ファイルである。スクリプトエンジンバイナリは、複数の実行可能ファイルによって構成される場合がある。解析対象スクリプトは、解析対象のスクリプトである。
　制御部１２は、各種の処理手順などを規定したプログラム及び所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する。例えば、制御部１２は、ＣＰＵ（Central　Processing　Unit）やＭＰＵ（Micro　Processing　Unit）などの電子回路である。制御部１２は、仮想機械解析部１２１（第１の解析部）、命令セットアーキテクチャ解析部１２２（第２の解析部）及び機能付与部１２３（付与部）を有する。
　仮想機械解析部１２１は、スクリプトエンジンのＶＭを解析する。仮想機械解析部１２１は、実行時の条件を変えて複数の実行トレースを取得し、差分実行解析を用いて複数の実行トレースを解析し、フックポイント、タップポイント、ＶＰＣを取得する。また、仮想機械解析部１２１は、スクリプトエンジンバイナリを解析して、ＶＭ命令の境界およびディスパッチャを取得する。仮想機械解析部１２１は、実行トレース取得部１２１１、フック・タップポイント検出部１２１２、ＶＭ命令境界検出部１２１３、仮想プログラムカウンタ検出部１２１４、ディスパッチャ検出部１２１５を有する。
　実行トレース取得部１２１１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け付ける。実行トレース取得部１２１１は、スクリプトエンジンバイナリの実行を監視しながら、テストスクリプトを実行することで、実行トレースを取得する。
　実行トレースは、ブランチトレースとメモリアクセストレースとによって構成される。ブランチトレースは、実行の際の分岐命令の種類と、分岐元アドレスと分岐先アドレスを記録する。メモリアクセストレースは、メモリ操作の種類と、操作対象のメモリアドレスを記録する。ブランチトレース及びメモリアクセストレースは、命令フックによって取得可能であることが知られている。実行トレース取得部１２１１が取得した実行トレースは、実行トレースＤＢ１３１に格納される。
　フック・タップポイント検出部１２１２は、実行トレース取得部１２１１によって取得された実行トレースに基づいて仮想機械を解析し、フックポイント、タップポイントを検出する。ここで、フックポイントとは、フックを施して解析用コードを挿入する箇所である。実施の形態においては、スクリプトエンジンの内部実装が持つ関数（内部関数と呼ぶ）を単位とし、フックはこの内部関数の先頭に施されるものとする。また、タップポイントとは、解析用コードによってログ出力するメモリ監視箇所であり、内部関数の引数のいずれかであるとする。
　フック・タップポイント検出部１２１２は、実行トレースＤＢ１３１に格納された実行トレースを取り出して解析し、フックポイントの候補を発見する。フック・タップポイント検出部１２１２は、実行トレースに対して、解析対象に関連したシステムＡＰＩの呼び出しを探索し、そこからのバックトレースによってフックポイント候補を検出する。フック・タップポイント検出部１２１２は、解析対象の言語要素（たとえば、スクリプトＡＰＩ）に対応したシステムＡＰＩからのバックトレースを適用してフックポイントを検出する。
　フック・タップポイント検出部１２１２は、取得条件の異なる複数の実行トレースの差分を抽出し、特定の条件を満たす部分を発見することでフックポイント候補を検出する。フック・タップポイント検出部１２１２は、複数の条件を変えた実行トレースの間に見られる差分に基づいてフックポイントを検出する。この際、フック・タップポイント検出部１２１２は、相同性の高い系列が特定の回数出現することを検出するアルゴリズム（例えば、Smith-Watermanアルゴリズム）を用いてフックポイントを検出する。
　フック・タップポイント検出部１２１２は、得られたフックポイント候補にフックを施し、そのフックが施された関数の引数のメモリを探索することで、タップポイントを検出する。フック・タップポイント検出部１２１２は、フックポイントでの監視に基づいて、解析用コードによってログ出力するメモリ監視箇所であるタップポイントを検出する。また、フック・タップポイント検出部１２１２は、タップポイントを持ったフックポイント候補を、フックポイントとして確定する。なお、フック・タップポイント検出部１２１２の処理の詳細は、国際公開２０２０／０７５３３５を参照されたい。
　ＶＭ命令境界検出部１２１３は、実行トレースをクラスタリングして、各ＶＭ命令の境界を検出する。ＶＭ命令境界検出部１２１３は、実行トレースをクラスタリングして、実行回数が閾値以上のクラスタをＶＭ命令として検出する。クラスタリングでは、複数回実行される連続したコード領域を検出する。これには、例えば、実行された命令間のコード上の距離が近いものをまとめてもよいし、実行されたコードブロックの共通部分列を探してもよいし、他の方法によってもよい。解析機能付与装置１０は、検出したＶＭ命令を構成する連続した命令列の開始点と終了点とを境界として検出する。ここで検出したＶＭ命令の境界は、ＶＰＣ検出、ディスパッチャ検出において用いられる。
　仮想プログラムカウンタ検出部１２１４は、実行トレースＤＢ１３１に格納された第１のテストスクリプトに対する実行トレースを取り出して解析し、ＶＰＣを検出する。仮想プログラムカウンタ検出部１２１４は、メモリの読み込み回数に着目した差分実行解析とＶＭ命令境界検出部１２１３によって検出された各ＶＭ命令の境界とを用いて複数の実行トレースを解析し、ＶＰＣを検出する。仮想プログラムカウンタ検出部１２１４は、各ＶＭ命令の実行後には、必ずＶＰＣを保持するメモリへの読み込みが発生することを利用し、この読み込み先を発見することで、ＶＰＣを検出する。
　このため、仮想プログラムカウンタ検出部１２１４は、ＶＰＣの検出として、メモリの読み込み回数に着目した差分実行解析を用いる。仮想プログラムカウンタ検出部１２１４は、テストスクリプトを用いて取得された複数のテストスクリプトの実行トレースを比較し、メモリ読み込み回数が、繰り返される回数及び繰り返される文の数との双方の増減に比例して変化するメモリを発見する。そして、仮想プログラムカウンタ検出部１２１４は、ＶＭ命令境界検出部１２１３によって検出された各ＶＭ命令の境界を参照して、読み込んだメモリの値が常にＶＭ命令の開始点を指しているものに絞り込む。仮想プログラムカウンタ検出部１２１４は、このメモリをＶＰＣとして検出する。
　ディスパッチャ検出部１２１５は、ＶＭ命令境界検出部１２１３が検出したＶＭ命令の境界を基に、スクリプトエンジンバイナリから各ＶＭ命令部分を切り出し、各ＶＭ命令間で類似度が高い部分をディスパッチャとして検出する。前提として、ディスパッチャは、ポインタキャッシュの参照と次のＶＭ命令ハンドラのポインタへのジャンプで実現される。ディスパッチャは、各々のＶＭ命令ハンドラの後部に分散的に配置されており、一般にそれらのコードの同一性は高い。こうしたＶＭ命令ハンドラの後部に存在し、同一性の高いコードを探すことで、解析機能付与装置は、所定の方法でディスパッチャを検出する。類似度の高い部分の検出には、たとえば系列アライメントアルゴリズムを用いてもよく、その他の方法によってもよい。
　命令セットアーキテクチャ解析部１２２は、ＶＭの命令の体系である命令セットアーキテクチャを解析する。命令セットアーキテクチャ解析部１２２は、ＶＭ実行トレース取得部１２２１（第１の取得部）及び分岐ＶＭ命令検出部１２２２（第１の検出部）を有する。
　ＶＭ実行トレース取得部１２２１は、実行トレース取得部１２１１と同じく、テストスクリプト及びスクリプトエンジンバイナリを入力として受け付ける。ＶＭ実行トレース取得部１２２１は、ＶＰＣの監視と、ディスパッチャがディスパッチするＶＭ命令ハンドラのポインタの監視により、ＶＭ実行トレースを取得する。ＶＭ実行トレース取得部１２２１は、スクリプトエンジンバイナリの実行を監視しながら、テストスクリプトを実行することで、ＶＭ上で実行された実行トレースであるＶＭ実行トレースを取得する。ＶＭ実行トレース取得部１２２１は、分岐ＶＭ命令の検出において、多数のテストスクリプトを実行して、ＶＭ実行トレースを取得する。ＶＭ実行トレース取得部１２２１は、ＶＭ命令へのポインタとＶＭ命令とを紐づけ、各々に識別子としてＶＭオペコードを仮想的に割り振る。
　ＶＭ実行トレースは、実行されたＶＭ命令ハンドラのポインタと、ＶＰＣを記録したものである。具体的には、ＶＭ実行トレースは、実行されたＶＭ命令ごとのＶＰＣとＶＭオペコードで構成される。ＶＰＣの記録は、仮想プログラムカウンタ検出部１２１４で検出されたＶＰＣのメモリを監視することで実現できる。ＶＭオペコードは、ＶＭ命令へのポインタとＶＭ命令とを紐づけた各々に仮想的に割り振られた識別子である。ＶＭ実行トレース取得部１２２１が取得したＶＭ実行トレースは、ＶＭ実行トレースＤＢ１３３に格納される。
　分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースＤＢ１３３に格納されたＶＭ実行トレースを取り出して解析し、分岐ＶＭ命令を検出する。分岐ＶＭ命令検出部１２２２は、識別子として割り振られたＶＭオペコードごとに、その実行の前後でのＶＰＣの変化量を収集する。ＶＭオペコードが分岐ＶＭ命令以外のものの場合、ＶＰＣの変化量は、ほぼ一定である。一方、ＶＭオペコードが分岐ＶＭ命令のものの場合、ＶＰＣは分岐先によってばらつきが生じる。
　そこで、分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースのＶＭオペコードごとの仮想プログラムカウンタの変化量のばらつきによって、分岐ＶＭ命令を検出する。分岐ＶＭ命令検出部１２２２は、分岐ＶＭ命令とそれ以外のＶＭ命令とではＶＰＣの値のばらつきの大きさが異なることに着目し、閾値を決めて、よりＶＰＣの値のばらつきの大きいものを分岐ＶＭ命令として検出する。具体的には、分岐ＶＭ命令検出部１２２２は、ＶＭオペコードごとＶＰＣの変化量のばらつきを分散で評価し、分散が一定の閾値以上のものを、分岐ＶＭ命令として検出する。
　また、分岐ＶＭ命令検出部１２２２は、精緻な制御フローグラフの構築のために、分岐ＶＭ命令のうち、条件分岐ＶＭ命令であるものを判定する。条件分岐の際には、分岐先を決定するために、必ず条件分岐フラグへのアクセスが発生する。そのため、各分岐ＶＭ命令の実行の際に、条件分岐フラグにアクセスしているかを検証することで、条件分岐ＶＭ命令を判定できる。言い換えると、分岐ＶＭ命令の実行の際に、条件分岐フラグにアクセスしていれば条件分岐ＶＭ命令であり、アクセスしていなければ、条件分岐ＶＭ命令ではないと判定できる。そこで、分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースとメモリアクセストレースに基づいて、分岐ＶＭ命令のうち、条件分岐フラグへのアクセスを伴うものを、条件分岐ＶＭ命令と判定する。
　さらに、分岐ＶＭ命令検出部１２２２は、コールおよびリターンのＶＭ命令も判定する。コールＶＭ命令による分岐では、呼び出し元のバイトコード上での直後のアドレスが保存され、呼び出されたサブルーチンの実行後には、リターンＶＭ命令によって、その保存されたアドレスに戻ってくる特徴がある。そこで、分岐ＶＭ命令検出部１２２２は、ある分岐ＶＭ命令を命令１とし、以後の他の分岐ＶＭ命令を命令２として、命令２によって命令１のバイトコード上での直後のアドレスに戻る場合に、命令１と命令２の組を、コールおよびリターンのＶＭ命令と判定する。
　機能付与部１２３は、取得したアーキテクチャ情報を基に、スクリプトエンジンにフックを挿入し、解析対象のスクリプトに、例外ハンドラを挿入し、例外処理機能を付与する。機能付与部１２３は、仮想機械解析部１２１及び命令セットアーキテクチャ解析部１２２による解析によって得られたアーキテクチャ情報である、ＶＰＣ及び分岐ＶＭ命令に基づいて、スクリプトエンジンのフックポイントに、例外が発生した場合には、ＶＰＣの指す先を、例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含むフックを施して解析機能を付与する。機能付与部１２３は、フック挿入部１２３１及び例外ハンドラ挿入部１２３２を有する。
　フック挿入部１２３１は、スクリプトエンジンにフックを挿入する。フック挿入部１２３１は、仮想機械解析部１２１及び命令セットアーキテクチャ解析部１２２による解析によって得られたアーキテクチャ情報に基づいて、スクリプトエンジンにフックを施す。フック挿入部１２３１は、フックポイント及びタップポイントを受け取り、フックポイント及びタップポイントに基づいて、スクリプトエンジンに、フックハンドラを用いてフックを挿入して解析機能を付与する。フックハンドラは、ＶＭ領域において、ＶＰＣの指す先を、例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含む。
　具体的には、フック挿入部１２３１は、フックハンドラに、ＶＭブランチトレース構築処理（第１の処理）、制御フローグラフ構築処理（第２の処理）、及び、例外の発生した基本ブロックをスキップする基本ブロックスキップ処理（第３の処理）を追加する。これによって、フックには、ＶＰＣの指す先を、例外が発生した基本ブロックのこの基本ブロックの直後の基本ブロックの先頭に変更し、例外の発生した基本ブロックをスキップする機能が追加される。ＶＭブランチトレース構築処理では、分岐ＶＭ命令の実行前後のＶＰＣを対応付けたＶＭブランチトレースを構築する。制御フローグラフ構築処理では、ＶＭブランチトレースを用いて、基本ブロックをノードとし、分岐ＶＭ命令の実行による分岐をエッジとした制御フローグラフを構築する。
　例外ハンドラ挿入部１２３２は、解析対象のスクリプトに、例外ハンドラを挿入し、例外処理機能を付与する。例外ハンドラは、例外の発生を捕捉した場合に、ＶＭ領域に強制的に処理を移す機能を有する。例外ハンドラ挿入部１２３２は、解析対象のスクリプトを解析し、各エントリーポイントに、エントリーポイント以降のコードでの例外を捕捉できるようして例外ハンドラのコード（例えば、図１参照）を追加することで、例外ハンドラを挿入する。
　記憶部１３は、ＲＡＭ（Random　Access　Memory）、フラッシュメモリ（Flash　Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、解析機能付与装置１０を動作させる処理プログラムや、処理プログラムの実行中に使用されるデータなどが記憶される。記憶部１３は、実行トレースデータベース（ＤＢ）１３１、ＶＭ実行トレースＤＢ１３３、及び、仮想機械解析部１２１及び命令セットアーキテクチャ解析部１２２によって取得されたアーキテクチャ情報を記憶するアーキテクチャ情報ＤＢ１３２を有する。
　実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３は、それぞれ実行トレース取得部１２１１及びＶＭ実行トレース取得部１２２１によって取得された実行トレース及びＶＭ実行トレースを格納する。実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３は、解析機能付与装置１０によって管理される。もちろん、実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３は、他の装置（サーバ等）によって管理されていてもよく、この場合には、実行トレース取得部１２１１及びＶＭ実行トレース取得部１２２１は、出力部１４の通信インタフェースを介して、取得した実行トレース及びＶＭ実行トレースを、実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３の管理サーバ等に出力して、実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３に記憶させる。
　出力部１４は、例えば、液晶ディスプレイやプリンタ等であって、解析機能付与装置１０に関する情報を含む各種情報を出力する。また、出力部１４は、外部装置との間で、各種データの入出力を司るインタフェースであってもよく、外部装置に各種情報を出力してもよい。
［テストスクリプトの構成］
　テストスクリプトについて説明する。テストスクリプトは、スクリプトエンジンを動的解析する際に入力されるスクリプトである。このテストスクリプトは、分岐命令の実行やメモリ読み書きの回数に着目し、異なる回数のテストスクリプトを実行したときに生じるスクリプトエンジンの挙動の差分を捉えるために用いられる。このテストスクリプトは、解析の事前に準備するものであり、手動で作成するものである。この作成には、対象のスクリプト言語の仕様に関する知識が必要となる。
　図４は、ＶＰＣの検出に用いるテストスクリプト（第１のテストスクリプト）の一例を示す図である。第１のテストスクリプトでは、繰り返し処理を用いる（２行目）。第１のテストスクリプトでは、テストスクリプト内の繰り返し回数（２行目）や繰り返される文の数（３行目から５行目）を増減させることで、実行時の条件を変更し、差分を発生させる。
　図５は、分岐ＶＭ命令検出に用いるテストスクリプト（第２のテストスクリプト）の一例を示す図である。第２のテストスクリプトでは、複数回の条件分岐を用いる（４行目から８行目）。第２のテストスクリプトにおいて、この複数回の条件分岐では、特定の順序のパターンで分岐がなされたり、なされなかったりするように、分岐条件を制御する（１行目、５行目）。第２のテストスクリプトでは、条件分岐の回数や、分岐の成否の順序パターンを変更し、差分を発生させる。
［実行トレースの構成］
　次に、実行トレースについて説明する。図６は、実行トレースの一例を示す図である。実行トレースは、前述の通り、ブランチトレースとメモリアクセストレースによって構成されている。図６は、実行トレースの一部を切り出したものである。以降、図６を用いて実行トレースの構成を示す。
　実行トレースは、traceという要素を有する。traceには、そのログ行がブランチトレースか、メモリアクセストレースかが示される。
　ブランチトレースのログ行は、例えば、図６の１行目から１０行目に記載の書式になっており、type、src、dstの三つの要素からなる。typeは、実行された分岐命令がcall命令によるものか、jmp命令によるものか、ret命令によるものかを示す。また、srcは、分岐元のアドレスを示し、dstは、分岐先のアドレスを示す。
　メモリアクセストレースのログ行は、たとえば、図６の１１行目から１３行目に記載の書式になっており、type、target、valueの三つの要素からなる。typeは、メモリアクセスが読み込みか書き込みかを示す。targetは、メモリアクセスの対象となるメモリアドレスを示す。また、valueには、メモリアクセスの結果の値が格納される。
［ＶＭ実行トレースの構成］
　次に、ＶＭ実行トレースについて説明する。図７は、ＶＭ実行トレースの一例を示す図である。ＶＭ実行トレースは、前述の通り、ＶＭオペコードとＶＰＣとを記録したものである。図７は、ＶＭ実行トレースの一部を切り出したものである。以降、図７を用いてＶＭ実行トレースの構成を示す。
　ＶＭ実行トレースのログ行は、たとえば、図７に記載の書式になっており、vpc及びvmop（vm　opcode）の二つの要素からなる。vpcは、ＶＰＣの値を示す。また、vmopは、ポインタキャッシュから取得された、実行されるＶＭ命令ハンドラの先頭を指すポインタごとに仮想的に割り振られたＶＭオペコードの値を示す。
［ＶＭ命令境界検出部の処理］
　次に、ＶＭ命令境界検出部１２１３の処理について説明する。図８は、ＶＭ命令境界検出部１２１３の処理を説明する図である。
　ＶＭ命令境界検出部１２１３は、各ＶＭ命令の境界を検出する。この時、ＶＭ命令境界検出部１２１３は、インタプリタループを持たないためにＶＭ命令の境界の把握が難しいスレッデッドコード型ＶＭのために、ＶＭ命令とその境界の検出を行う。具体的には、ＶＭ命令境界検出部１２１３は、実行トレースＤＢ１３１から実行トレースを取り出す。そして、図８に示すように、ＶＭ命令境界検出部１２１３は、実行トレースを、所定の方法でクラスタリングして、実行回数が閾値以上のクラスタをＶＭ命令（例えば、ＶＭ命令ハンドラ１～３）として検出する。ＶＭ命令境界検出部１２１３は、ＶＭ命令を構成する連続した命令列の開始点と終了点とを境界として検出する。
［仮想プログラムカウンタ検出部の処理］
　次に、仮想プログラムカウンタ検出部１２１４の処理について説明する。仮想プログラムカウンタ検出部１２１４は、ＶＰＣ、ポインタキャッシュの検出を行う。仮想プログラムカウンタの検出は、取得した実行トレースのメモリアクセストレースのログを解析することで実現される。仮想プログラムカウンタ検出部１２１４は、メモリの読み込み回数に着目した差分実行解析を用いる。図９は、仮想プログラムカウンタ検出部１２１４の処理を説明する図である。
　仮想プログラムカウンタ検出部１２１４は、実行トレースＤＢ１３１から第１のテストスクリプトによる実行トレースを一つ取り出す。ＶＰＣの読み込みの回数は、テストスクリプト内の繰り返し回数及び、繰り返し処理の中の文の数に比例する。繰り返しの回数をＮ、繰り返される文の数をＭとしたとき、概ねＭＮ程度のＶＰＣの読み込みが発生する。このため、仮想プログラムカウンタ検出部１２１４は、Ｎ及びＭをそれぞれ２Ｎと２Ｍ、３Ｎと３Ｍと増やした第１のテストスクリプトに対する実行トレースにおいて、４ＭＮ、９ＭＮという増え方をしたメモリを抽出する。具体的には、図９に示すように、仮想プログラムカウンタ検出部１２１４は、１ＶＭ命令実行毎にRead／Writeがあり、単調増加するメモリ領域を抽出する（図９の（１））。
　そして、仮想プログラムカウンタ検出部１２１４は、読み込んだメモリの値が常にＶＭ命令の開始点を指しているものを、ＶＰＣとして検出する。具体的には、仮想プログラムカウンタ検出部１２１４は、ＶＰＣの指し先とＶＭ命令ハンドラのアドレスとを照合して、一致するメモリ領域に絞り込む（図９の（２））。
［ディスパッチャ検出部の処理］
　次に、ディスパッチャ検出部１２１５の処理について説明する。ディスパッチャ検出部１２１５は、スクリプトエンジンのバイナリを所定の手法で解析することで、ディスパッチャを検出する。図１０は、ディスパッチャ検出部１２１５の処理を説明する図である。
　ディスパッチャ検出部１２１５は、ディスパッチャの検出を行う。ディスパッチャ検出部１２１５は、ＶＭ命令境界検出部１２１３が検出したＶＭ命令の境界を基に、スクリプトエンジンバイナリから各ＶＭ命令部分を切り出す。そして、ディスパッチャ検出部１２１５は、ディスパッチャのコードの類似性は高いとした仮定の基（図１０の（１））、各ＶＭ命令間でコード間の類似度を算出し、全ＶＭ命令間で類似度が高い部分を、ディスパッチャとして検出する。ディスパッチャ検出部１２１５は、ＶＭ命令の後半部で共通的に実行されるコードを、ディスパッチャとして検出できる（図１０の（１））。
［分岐ＶＭ命令検出部の処理］
　次に、分岐ＶＭ命令検出部１２２２の処理について説明する。分岐ＶＭ命令検出部１２２２は、取得したＶＭ実行トレースのログを解析することで分岐ＶＭ命令を検出する。ここでのテストスクリプトは、分岐ＶＭ命令が含まれていればよいため、分岐の制御構文を含むスクリプトでありさえすればどのようなものでもよい。例えば、インターネット上から収集したり、公式ドキュメントから取得したりしてテストスクリプトを準備する。
　まず、分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースＤＢ１３３の各ＶＭ実行トレースに対し、ＶＭ命令へのポインタとＶＭ命令とを紐づけ、各々に識別子として、ＶＭオペコードを仮想的に割り振る。図１１は、分岐ＶＭ命令検出部１２２２の処理を説明する図である。
　ここで、あるＶＭ命令が分岐命令のとき、ＶＰＣの進みは、分岐先に依存して変化する。一方、分岐命令以外のときは、ＶＰＣの進みは、ＶＭ命令のサイズに依存して変化する。このため、ＶＭ命令のオペコードとＶＭ命令へのポインタとの組を収集し、オペコードごとにＶＰＣの進みを見たとき、分岐命令であれば分岐先によってＶＰＣの進みにばらつきがみられる。
　したがって、分岐ＶＭ命令検出部１２２２は、このＶＭ命令へのポインタのばらつきを評価するため、分散を用いる。分岐ＶＭ命令検出部１２２２は、ＶＭオペコード毎にＶＰＣの変化量の分散を算出し、算出した分散が閾値よりも大きいＶＭオペコードのみに絞り込む。これによって、分岐ＶＭ命令検出部１２２２は、ポインタとＶＭ命令を対応付けつつ、ＶＰＣの進みにばらつきのあるＶＭ命令（図１１の例では、ＶＭ命令ハンドラ３）を、分岐ＶＭ命令として検出する（図１１の（１））。
　あるオペコードに対するＶＰＣの進みの集合ＯをＯ＝｛ｏ０，ｏ１，・・・，ｏＮ｝（ＶＰＣｏの平均は（１）式を参照）とし、ｔを閾値としたとき、分岐命令か否かは、分散ｓ（（２）式を参照）を基に、（３）式のように判定される。これによって、分岐ＶＭ命令検出部１２２２は、分岐ＶＭ命令を検出する。
Figure JPOXMLDOC01-appb-M000001
Figure JPOXMLDOC01-appb-M000002
Figure JPOXMLDOC01-appb-M000003
　なお、分岐以外のＶＭ命令では、ばらつきがほとんど見られず、分岐ＶＭ命令とそれ以外のＶＭ命令との境界は明確であることが多い。このため、閾値として、例えば、得られた分散の値を数直線上にプロットして、できた二つの群を分割可能な値が設定される。
［フック挿入部の処理］
　次に、フック挿入部１２３１の処理を説明する。フック挿入部１２３１は、スクリプトエンジンバイナリと、ここまでの処理で検出されたフックポイント及びタップポイントを入力として受け付ける。フック挿入部１２３１は、スクリプトエンジンに対して、フックポイントにフックハンドラを用いたフックを挿入する。
　ここで、フック挿入部１２３１は、フック時に、フックに対応したスクリプトＡＰＩが実行された際に、ＶＭ領域でのフックハンドラの処理に実行が遷移するように、解析用のコードを挿入する。この解析用のコードは、フックポイントとタップポイントとが判明していれば、容易に生成できる。これによって、フックしたスクリプトＡＰＩをスクリプトから呼び出すことで、ＶＭ領域に実装されたフックハンドラの機能をハイパーバイザコールとして呼び出せるようになり、解析機能の付与が実現される。
　この際、フック挿入部１２３１は、フックハンドラに、ＶＭブランチトレースを構築するＶＭブランチトレース構築処理、制御フローグラフを構築する制御フローグラフ構築処理、及び、例外の発生した基本ブロックをスキップする基本ブロックスキップ処理を追加する。
　図１２は、ＶＭブランチトレース構築処理を説明する図である。ＶＭブランチトレース構築処理では、図１２に示すように、実行されたＶＭ命令のオペコードと、ＶＰＣを記録したＶＭ実行トレース４１から分岐ＶＭ命令を検出する（図１２の（１））。分岐ＶＭ命令は、分岐ＶＭ命令検出部１２２２によって検出された分岐ＶＭ命令リスト４２を参照することで認識することができる。
　そして、ＶＭブランチトレース構築処理では、検出した分岐ＶＭ命令の実行前後のＶＰＣを対応付けたＶＭブランチトレース４３を構築する（図１２の（２））。ＶＭブランチトレース構築処理では、例えば、ＶＭ実行トレースの行Ｒ４１から分岐ＶＭ命令「0x1f」を検出し、行Ｒ４１及び行Ｒ４２の次の行Ｒ４２を基に、行Ｒ６１に示すＶＭブランチトレースを構築する。すなわち、ＶＭブランチトレース構築処理では、行Ｒ４１の分岐元のＶＰＣ「0x555c7e48」と、行Ｒ４２の分岐元のＶＰＣ「0x555c82a0」とを対応付ける。
　同様に、ＶＭブランチトレース構築処理では、ＶＭ実行トレースの行Ｒ５１から分岐ＶＭ命令「0x21」を検出すると、この行Ｒ５１及び次の行Ｒ５２を基に、行Ｒ５１のＶＰＣ「0x555c832c」と、行Ｒ５２のＶＰＣ「0x555c7514」とを対応付ける（行Ｒ７１）。
　図１３は、制御フローグラフ構築処理を説明する図である。制御フローグラフ構築処理では、ＶＭブランチトレース構築処理において構築したＶＭブランチトレース４３を用いて、基本ブロックをノードとし、ＶＭブランチトレース４３の各分岐をエッジとした制御フローグラフを構築する（図１３の（１））。
　具体的には、制御フローグラフ構築処理では、ＶＭブランチトレース４３の行Ｒ６１に示す分岐をエッジＥ６１とし、エッジＥ６１の分岐元の基本ブロックをノードＮ６１とし、エッジＥ６１の分岐先の基本ブロックをノードＮ６２とする。
　そして、ＶＭブランチトレース４３の行Ｒ７１に示す分岐をエッジＥ７１とし、エッジ７１の分岐元の小本ブロックをノードＮ７１とし、エッジＥ７１の分岐先の基本ブロックをノードＮ７２とする。なお、図１３の制御フローグラフの例では、ノードＮ７１には、エッジＥ７１のほかにエッジＥ７２に示す分岐があり、この分岐先の基本ブロックはノードＮ７３で示されている。このように、制御フローグラフ構築処理では、ＶＭブランチトレースを基に、基本ブロックの分岐をグラフ構造で表現した制御フローグラフを構築する。
　図１４は、基本ブロックスキップ処理を説明する図である。基本ブロックスキップ処理では、定常的にＶＰＣを追跡し、例外が発生した場合に、この例外が、制御フローグラフ構築処理において構築した制御フローグラフのどの箇所に該当するかを判別する。そして、基本ブロックスキップ処理では、ＶＰＣの指す先を、例外が発生した基本ブロックの直後の基本ブロックの先頭に変更することで、例外の発生した基本ブロックをスキップする処理（図１４の（１））。具体的には、基本ブロックスキップ処理では、図１４の例では、ＶＰＣの指す先を、例外が発生したノードの直後の先頭のノードＮ７１に変更する。そして、ノードＮ７１の実行内容に応じて、エッジＥ７１またはエッジＥ７２に分岐して処理が進む。
　したがって、機能付与部１２３は、例外ハンドラを解析対象のスクリプトに挿入し、フックハンドラに基本ブロックスキップ処理を追加することで、解析対象のスクリプトに、例外スキップ機能を付与することができる。
［解析機能付与装置の処理手順］
　次に、解析機能付与装置１０による解析機能付与処理の処理手順について説明する。図１５は、実施の形態に係る解析機能付与処理の処理手順を示すフローチャートである。
　まず、入力部１１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け取る（ステップＳ１）。
　そして、実行トレース取得部１２１１は、スクリプトエンジンのバイナリを監視しながらテストスクリプトを実行してブランチトレースとメモリアクセストレースを取得する実行トレース取得処理を行う（ステップＳ２）。
　フック・タップポイント検出部１２１２は、実行トレース取得部１２１１によって取得された実行トレースに基づいて仮想機械を解析し、フックポイント、タップポイントを検出するフック・タップポイント検出処理を行う（ステップＳ３）。
　ＶＭ命令境界検出部１２１３は、ＶＭ命令を検出し、ＶＭ命令の境界を検出するＶＭ命令境界検出処理を行う（ステップＳ４）。仮想プログラムカウンタ検出部１２１４は、実行トレースＤＢ１３１に格納された第１のテストスクリプトに対する実行トレースを取り出して解析し、ＶＰＣを発見する仮想プログラムカウンタ検出処理を行う（ステップＳ５）。
　ディスパッチャ検出部１２１５は、スクリプトエンジンバイナリから各ＶＭ命令部分を切り出し、各ＶＭ命令間で類似度が高い部分をディスパッチャとして検出するディスパッチャ検出処理を行う（ステップＳ６）。
　ＶＭ実行トレース取得部１２２１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け付け、スクリプトエンジンバイナリの実行を監視しながら、テストスクリプトを実行することで、ＶＭ実行トレースを取得するＶＭ実行トレース取得処理を行う（ステップＳ７）。分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースＤＢ１３３に格納されたＶＭ実行トレースを取り出して解析し、分岐ＶＭ命令を検出する分岐ＶＭ命令検出処理を行う（ステップＳ８）。
　フック挿入部１２３１は、ステップＳ１～ステップＳ６の処理において取得されたアーキテクチャ情報を基に、スクリプトエンジンにフックを挿入するフック挿入処理を行う（ステップＳ９）。そして、例外ハンドラ挿入部１２３２は、解析対象のスクリプトに、例外ハンドラを挿入し、例外処理機能を付与する例外ハンドラ挿入処理を行う（ステップＳ１０）。そして、出力部１２４は、例外スキップ機能が付与されたスクリプトエンジンバイナリを出力する（ステップＳ１１）。
［実行トレース取得処理の処理手順］
　次に、図１５に示す実行トレース取得処理の流れについて説明する。図１６は、図１５に示す実行トレース取得処理の処理手順を示すフローチャートである。
　まず、実行トレース取得部１２１１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け取る（ステップＳ２１）。そして、実行トレース取得部１２１１は、受け取ったスクリプトエンジンに対して、ブランチトレースを取得するためのフックを施す（ステップＳ２２）。また、実行トレース取得部１２１１は、受け取ったスクリプトエンジンに対して、メモリアクセストレースを取得するためのフックも施す（ステップＳ２３）。
　そして、実行トレース取得部１２１１は、その状態で受け取ったテストスクリプトをスクリプトエンジンに入力して実行させ（ステップＳ２４）、それによって取得される実行トレースを実行トレースＤＢ１３１に格納する（ステップＳ２５）。
　実行トレース取得部１２１１は、入力されたテストスクリプトを全て実行し終えているか否かを判定する（ステップＳ２６）。実行トレース取得部１２１１は、入力されたテストスクリプトを全て実行し終えている場合（ステップＳ２６：Ｙｅｓ）、処理を終了する。これに対し、実行トレース取得部１２１１は、入力されたテストスクリプトを全て実行していない場合（ステップＳ２６：Ｎｏ）、ステップＳ２４のテストスクリプトの実行に戻って処理を続ける。
［フック・タップポイント検出処理の処理手順］
　図１７は、図１５に示すフック・タップポイント検出処理の処理手順を示すフローチャートである。
　図１７に示すように、フック・タップポイント検出処理において、フック・タップポイント検出部１２１２は、フックポイント候補を検出する（ステップＳ３１）。フック・タップポイント検出部１２１２は、フックポイント候補が検出された場合（ステップＳ３２：Ｙｅｓ）、ステップＳ３５に進む。一方、フックポイント候補が検出されなかった場合（ステップＳ３２：Ｎｏ）、フック・タップポイント検出部１２１２は、複数の条件を変えた実行トレースの間に見られる差分に基づいてフックポイントを検出する差分実行解析処理を実施する（ステップＳ３３）。
　そして、フック・タップポイント検出部１２１２１０は、フックポイント候補が検出されなかった場合（ステップＳ３４：Ｎｏ）、フックポイント候補がないため、処理を終了する。一方、フック・タップポイント検出部１２１２は、フックポイント候補が検出された場合（ステップＳ３４：Ｙｅｓ）、ステップＳ３５に進む。フック・タップポイント検出部１２１２は、タップポイントを検出する（ステップＳ３５）。
［ＶＭ命令境界検出処理の処理手順］
　次に、図１５に示すＶＭ命令境界検出処理の流れについて説明する。図１８は、図１５に示すＶＭ命令境界検出処理の処理手順を示すフローチャートである。
　まず、ＶＭ命令境界検出部１２１３は、実行トレースＤＢ１３１から実行トレースを取り出す（ステップＳ４１）。ＶＭ命令境界検出部１２１３は、実行トレースを所定の方法でクラスタリングする（ステップＳ４２）。クラスタリングは、いずれの手法を用いてもよい。
　ＶＭ命令境界検出部１２１３は、実行回数が閾値以上のクラスタをＶＭ命令として検出する（ステップＳ４３）。そして、ＶＭ命令境界検出部１２１３は、ＶＭ命令を構成する連続した命令列の開始点と終了点とを境界とする（ステップＳ４４）。ＶＭ命令境界検出部１２１３は、ＶＭ命令の境界を返り値として出力して（ステップＳ４５）、ＶＭ命令境界検出処理を終了する。
［仮想プログラムカウンタ検出処理の処理手順］
　次に、図１５に示す仮想プログラムカウンタ検出処理の流れについて説明する。図１９は、図１５に示す仮想プログラムカウンタ検出処理の処理手順を示すフローチャートである。
　まず、仮想プログラムカウンタ検出部１２１４は、実行トレースＤＢ１３１から第１のテストスクリプトによる実行トレースを一つ取り出す（ステップＳ５１）。続いて、仮想プログラムカウンタ検出部１２１４は、実行トレースのうちのメモリアクセストレースに着目し、メモリ読み込み先ごとに読み込み回数を数え上げる（ステップＳ５２）。
　仮想プログラムカウンタ検出部１２１４は、実行トレースの取得に用いた第１のテストスクリプトを入力として受け取り（ステップＳ５３）、その第１のテストスクリプトを解析して繰り返しの回数と繰り返される文の数とを取得する（ステップＳ５４）。
　続いて、仮想プログラムカウンタ検出部１２１４は、実行トレースＤＢ１３１から、繰り返し回数や繰り返される文の数の異なる第１のテストスクリプトによる実行トレースを、さらに一つ取り出す（ステップＳ５５）。そして、仮想プログラムカウンタ検出部１２１４は、メモリアクセストレースに着目し、メモリ読み込み先ごとに読み込み回数を数え上げる（ステップＳ５６）。また、仮想プログラムカウンタ検出部１２１４は、実行トレースの取得に用いた第１のテストスクリプトを入力として受け取り（ステップＳ５７）、テストスクリプトを解析して、繰り返しの回数と繰り返される文の数とを取得する（ステップＳ５８）。
　ここで、仮想プログラムカウンタ検出部１２１４は、繰り返し回数や繰り返される文の増減に比例して読み込み回数が変化するメモリ読み込み先のみに絞り込む（ステップＳ５９）。さらに、仮想プログラムカウンタ検出部１２１４は、ステップＳ５９において絞り込んだメモリ読み込み先を、読み込んだメモリの値が常にＶＭ命令の開始点を指しているものに絞り込む（ステップＳ６０）。
　そして、仮想プログラムカウンタ検出部１２１４は、メモリ読み込み先を一つのみに絞り込めたか否かを判定する（ステップＳ６１）。仮想プログラムカウンタ検出部１２１４は、メモリ読み込み先を一つのみに絞り込めていない場合（ステップＳ６１：Ｎｏ）、ステップＳ５５に戻り、次の実行トレースを一つ取り出して処理を継続する。一方、仮想プログラムカウンタ検出部１２１４は、メモリ読み込み先を一つのみに絞り込めた場合（ステップＳ６１：Ｙｅｓ）、絞り込まれたメモリ読み込み先を仮想プログラムカウンタとしてアーキテクチャ情報ＤＢ１３２に格納して（ステップＳ６２）、処理を終了する。
［ディスパッチャ検出処理の処理手順］
　次に、図１５に示すディスパッチャ検出処理の流れについて説明する。図２０は、図１５に示すディスパッチャ検出処理の処理手順を示すフローチャートである。
　まず、ディスパッチャ検出部１２１５は、スクリプトエンジンバイナリを入力として受け取る（ステップＳ７１）。ディスパッチャ検出部１２１５は、ＶＭ命令境界検出部１２１３から、ＶＭ命令の境界を受け取る（ステップＳ７２）。
　ディスパッチャ検出部１２１５は、ＶＭ命令境界検出部１２１３から受け取ったＶＭ命令の境界を基に、スクリプトエンジンバイナリから各ＶＭ命令部分を切り出す（ステップＳ７３）。ディスパッチャ検出部１２１５は、各ＶＭ命令間でコード間の類似度を所定の方法で算出する（ステップＳ７４）。類似度の算出手法は、コード間の類似度を算出できる手法であれば、どの手法でもよい。
　ディスパッチャ検出部１２１５は、ステップＳ７４において算出した類似度を基に、全ＶＭ命令間で類似度が高い部分を取り出す（ステップＳ７５）。そして、ディスパッチャ検出部１２１５は、ＶＭ命令の終端部分であるかを判定する（ステップＳ７６）。
　ＶＭ命令の終端部分でない場合（ステップＳ７６：Ｎｏ）、ディスパッチャ検出部１２１５は、ステップＳ７５に戻り処理を続ける。また、ＶＭ命令の終端部分である場合（ステップＳ７６：Ｙｅｓ）、ディスパッチャ検出部１２１５は、取り出した部分をディスパッチャとして出力して（ステップＳ７７）、処理を終了する。
［ＶＭ実行トレース取得処理の処理手順］
　次に、図１５に示すＶＭ実行トレース取得処理の流れについて説明する。図２１は、図１５に示すＶＭ実行トレース取得処理の処理手順を示すフローチャートである。
　まず、ＶＭ実行トレース取得部１２２１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け取る（ステップＳ８１）。そして、ＶＭ実行トレース取得部１２２１は、受け取ったスクリプトエンジンに対して、ＶＰＣ及びＶＭオペコードを記録するためのフックを施す（ステップＳ８２）。
　ＶＭ実行トレース取得部１２２１は、その状態で受け取ったテストスクリプトをスクリプトエンジンに入力して実行させ（ステップＳ８３）、それによって取得されるＶＭ実行トレースをＶＭ実行トレースＤＢ１３３に格納する（ステップＳ８４）。
　ＶＭ実行トレース取得部１２２１は、入力されたテストスクリプトを全て実行したか否かを判定する（ステップＳ８５）。ＶＭ実行トレース取得部１２２１は、入力されたテストスクリプトを全て実行し終えている場合（ステップＳ８５：Ｙｅｓ）、処理を終了する。ＶＭ実行トレース取得部１２２１は、入力されたテストスクリプトを全て実行し終えていない場合（ステップＳ８５：Ｎｏ）、ステップＳ８３のテストスクリプトの実行に戻って処理を続ける。
［分岐ＶＭ命令検出処理の処理手順］
　次に、図１５に示す分岐ＶＭ命令検出処理の流れについて説明する。図２２は、図１５に示す分岐ＶＭ命令検出処理の処理手順を示すフローチャートである。
　まず、分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースＤＢ１３３から、ＶＭ実行トレースを一つ取り出す（ステップＳ９１）。分岐ＶＭ命令検出部１２２２は、ＶＭ命令へのポインタとＶＭ命令を紐付け、各々に識別子としてＶＭオペコードを割り振る（ステップＳ９２）。そして、分岐ＶＭ命令検出部１２２２は、ＶＭオペコードごとに、実行の前後でのＶＰＣの変化量を集計する（ステップＳ９３）。
　分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースＤＢ１３３の全てのＶＭ実行トレースを処理し終えたか否かを判定する（ステップＳ９４）。ＶＭ実行トレースＤＢ１３３の全てのＶＭ実行トレースを処理し終えていない場合（ステップＳ９４：Ｎｏ）、分岐ＶＭ命令検出部１２２２は、ステップＳ９１に戻り、次のＶＭ実行トレースを一つ取り出して処理する。
　ＶＭ実行トレースＤＢ１３３の全てのＶＭ実行トレースを処理し終えている場合（ステップＳ９４：Ｙｅｓ）、分岐ＶＭ命令検出部１２２２は、ＶＭオペコードごとにＶＰＣの変化量の分散を算出する（ステップＳ９５）。そして、分岐ＶＭ命令検出部１２２２は、閾値を入力として受け取る（ステップＳ９６）。分岐ＶＭ命令検出部１２２２は、分散が閾値よりも大きいＶＭオペコードのみに絞り込み（ステップＳ９７）、それらを分岐ＶＭ命令としてアーキテクチャ情報ＤＢ１３２に格納して（ステップＳ９８）、処理を終了する。
［フック挿入処理］
　次に、図１５に示すフック挿入処理の流れについて説明する。図２３は、図１５に示すフック挿入処理の処理手順を示すフローチャートである。
　まず、フック挿入部１２３１は、フック・タップポイント検出部１２１２によって検出されたフックポイント及びタップポイントを入力として受け取り、（ステップＳ１０１）、フックハンドラを準備する（ステップＳ１０２）。
　フック挿入部１２３１は、フックハンドラにＶＭブランチトレース構築処理を追加する（ステップＳ１０３）。フック挿入部１２３１は、フックハンドラに制御フローグラフ構築処理を追加する（ステップＳ１０４）。フック挿入部１２３１は、フックハンドラに基本ブロックスキップ処理を追加する（ステップＳ１０５）。フック挿入部１２３１は、フックポイントにフックハンドラを用いたフックを挿入する（ステップＳ１０６）。
［ＶＭブランチトレース構築処理］
　図２４は、ＶＭブランチトレース構築処理の処理手順を示すフローチャートである。ＶＭブランチトレース構築処理では、ＶＭ実行トレースとＶＭ分岐命令リストとを入力として受け取る（ステップＳ１１１）。
　ＶＭブランチトレース構築処理では、ＶＭ実行トレースのエントリを取り出す（ステップＳ１１２）。ＶＭブランチトレース構築処理では、ＶＭオペコードがＶＭ分岐命令リストに存在するか判定する（ステップＳ１１３）。
　ＶＭブランチトレース構築処理では、ＶＭオペコードがＶＭ分岐命令リストに存在する場合（ステップＳ１１３：Ｙｅｓ）、ＶＰＣを分岐元とし、次のエントリのＶＰＣを分岐先としてＶＭブランチトレースに保存する（ステップＳ１１４）。
　ＶＭブランチトレース構築処理では、ＶＭオペコードがＶＭ分岐命令リストに存在しない場合（ステップＳ１１３：Ｎｏ）、または、ステップＳ１１４終了後、ＶＭ実行トレースの全てのエントリを処理したか否かを判定する（ステップＳ１１５）。
　ＶＭブランチトレース構築処理では、ＶＭ実行トレースの全てのエントリを処理していない場合（ステップＳ１１５：Ｎｏ）、ＶＭ実行トレースの次のエントリを取り出す（ステップＳ１１６）。そして、ＶＭブランチトレース構築処理では、ステップＳ１１３に戻り、次のエントリについて、ＶＭオペコードがＶＭ分岐命令リストに存在するか判定する。
　一方、ＶＭブランチトレース構築処理では、ＶＭ実行トレースの全てのエントリを処理した場合（ステップＳ１１５：Ｙｅｓ）、フックポイントにフックハンドラを用いたフックを挿入する（ステップＳ１１７）。
［制御フローグラフ構築処理］
　図２５は、制御フローグラフ構築処理の処理手順を示すフローチャートである。制御フローグラフ構築処理では、ＶＭブランチトレースを入力として受け取ると（ステップＳ１２１）、ＶＭブランチトレースのエントリを取り出す（ステップＳ１２２）。
　制御フローグラフ構築処理では、分岐先アドレスを起点とする基本ブロックをノードとして制御フローグラフに追加する（ステップＳ１２３）。制御フローグラフ構築処理では、分岐元アドレスから分岐先アドレスへのエッジを制御フローグラフに追加する（ステップＳ１２４）。制御フローグラフ構築処理では、ＶＭブランチトレースの全てのエントリを処理したか否かを判定する（ステップＳ１２５）。
　制御フローグラフ構築処理では、ＶＭブランチトレースの全てのエントリを処理していない場合（ステップＳ１２５：Ｎｏ）、ＶＭ実行トレースの次のエントリを取り出す（ステップＳ１２６）。そして、制御フローグラフ構築処理では、ステップＳ１２３に戻り、次のエントリについて、分岐先アドレスを起点とする基本ブロックをノードとして制御フローグラフに追加する。
　制御フローグラフ構築処理では、ＶＭブランチトレースの全てのエントリを処理した場合（ステップＳ１２５：Ｙｅｓ）、構築した制御フローグラフを出力する（ステップＳ１２７）。
［基本ブロックスキップ処理］
　図２６は、基本ブロックスキップ処理の処理手順を示すフローチャートである。基本ブロックスキップ処理では、制御フローグラフ構築処理において構築された制御フローグラフを入力として受け取る（ステップＳ１３１）。
　基本ブロックスキップ処理では、ＶＰＣが現在（例外発生時）に指しているノードを確認する（ステップＳ１３２）。基本ブロックスキップ処理では、現在指しているノードからエッジを辿り、次のノードを取り出す（ステップＳ１３３）。
　基本ブロックスキップ処理では、次のノードが複数存在するか否かを判定する（ステップＳ１３４）。基本ブロックスキップ処理では、次のノードが複数存在する場合（ステップＳ１３４：Ｙｅｓ）、一つのノードを次のノードとして選択し、他のノードは次回実行時に選択する対象とする（ステップＳ１３５）。次のノードに対する選択ルールは、予め設定される。
　基本ブロックスキップ処理では、次のノードが複数存在しない場合（ステップＳ１３４：Ｎｏ）、または、ステップＳ１３５処理終了後、ＶＰＣの値を、次のノードの先頭を指すように変更する（ステップＳ１３６）。
［例外ハンドラ挿入処理］
　図１５に示す例外ハンドラ挿入処理の流れについて説明する。図２７は、図１５に示す例外ハンドラ挿入処理の処理手順を示すフローチャートである。
　例外ハンドラ挿入部１２３２は、解析対象のスクリプトを入力として受け取る（ステップＳ１４１）。例外ハンドラ挿入部１２３２は、解析対象のスクリプトを所定の方法で解析し、エントリーポイントを取り出す（ステップＳ１４２）。
　例外ハンドラ挿入部１２３２は、エントリーポイントを一つ取り出す（ステップＳ１４３）。例外ハンドラ挿入部１２３２は、エントリーポイント以降のコードでの例外を捕捉できるようにして例外ハンドラのコード（例えば、図１参照）を追加する（ステップＳ１４４）。
　例外ハンドラ挿入部１２３２は、全てのエントリーポイントに例外ハンドラを追加したか否かを判定する（ステップＳ１４５）。全てのエントリーポイントに例外ハンドラを追加していない場合（ステップＳ１４５：Ｎｏ）、例外ハンドラ挿入部１２３２は、次のエントリーポイントを取り出し（ステップＳ１４６）、ステップＳ１４４に進んで、例外ハンドラのコードを追加する。
　例外ハンドラ挿入部１２３２は、全てのエントリーポイントに例外ハンドラを追加した場合（ステップＳ１４５：Ｙｅｓ）、処理を終了する。
［実施の形態の効果］
　このように、実施の形態に係る解析機能付与装置１０は、スクリプトエンジンのバイナリを監視しながらテストスクリプトを実行し、ブランチトレースとメモリアクセストレースを実行トレースとして取得する。解析機能付与装置１０は、その実行トレースに基づいて仮想機械を解析し、フックポイント、タップポイント、ＶＰＣ、ＶＭ命令境界、ディスパッチャのアーキテクチャ情報を取得する。さらに、解析機能付与装置１０は、テストスクリプトを実行してＶＭ実行トレースを取得し、そのＶＭ実行トレースを用いて命令セットアーキテクチャを解析して分岐ＶＭ命令をアーキテクチャ情報として取得する。
　そして、解析機能付与装置１０は、得られたアーキテクチャ情報を基に、スクリプトエンジンのフックポイントに、例外が発生した場合には、ＶＰＣの指す先を、例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含むフックを施して、例外処理機能を含む解析機能を付与する。
　具体的には、解析機能付与装置１０では、解析対象のスクリプトに、例外の発生を捕捉した場合に、ＶＭ領域に強制的に処理を移す例外ハンドラを挿入することで例外処理機能を付与する。解析機能付与装置１０では、ＶＭ領域において、ＶＰＣの指す先を、例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含むフックハンドラを用いて、フックを施す。これによって、解析機能付与装置１０は、例外の発生した基本ブロックをスキップすることで、例外による実行の停止を抑制する。
　これによって、解析機能付与装置１０は、バイナリのみしか手に入らないプロプライエタリなスクリプトエンジンに対しても、実行トレース及びＶＭ実行トレースの取得に基づく解析により、各種アーキテクチャ情報を検出し、人手でのリバースエンジニアリングを要することなく、例外処理機能の付与を実現できる。
　また、解析機能付与装置１０では、多様なスクリプトエンジンに対して、テストスクリプトさえ用意すれば自動で例外処理機能を付与できるため、個別の設計や実装を要することなく、例外処理機能の付与を実現できる。
　上述したように、解析機能付与装置１０は、多種多様なスクリプト言語で記述される悪性スクリプトの挙動の解析に有用であり、解析の途上で例外によって実行が停止してしまう悪性スクリプトに対して、その影響を受けずに、挙動を解析することに適している。このため、解析機能付与装置１０を用いて、様々なスクリプトエンジンに例外処理機能を付与することで、例外があった場合であっても、例外による実行の停止を抑制しながら、悪性スクリプトの挙動を解析できるため、検知などの対策に生かすことが可能である。
　なお、解析機能付与装置１０は、実行経路の強制によるマルチパス実行においても同様に、例外を捕捉し、意図しない実行の停止を防ぎつつ解析を継続することが可能である。
［実施形態のシステム構成について］
　図３に示す解析機能付与装置１０の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、解析機能付与装置１０の機能の分散及び統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散または統合して構成することができる。
　また、解析機能付与装置１０においておこなわれる各処理は、全部または任意の一部が、ＣＰＵ及びＣＰＵにより解析実行されるプログラムにて実現されてもよい。また、解析機能付与装置１０においておこなわれる各処理は、ワイヤードロジックによるハードウェアとして実現されてもよい。
　また、実施の形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的に行うこともできる。もしくは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述及び図示の処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて適宜変更することができる。
［プログラム］
　図２８は、プログラムが実行されることにより、解析機能付与装置１０が実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
　ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、解析機能付与装置１０の各処理を規定するプログラムは、コンピュータ１０００により実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、解析機能付与装置１０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid　State　Drive）により代替されてもよい。
　また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local　Area　Network）、ＷＡＮ（Wide　Area　Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　以上、本発明者によってなされた発明を適用した実施の形態について説明したが、本実施の形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例及び運用技術等はすべて本発明の範疇に含まれる。
　１０　解析機能付与装置
　１１　入力部
　１２　制御部
　１３　記憶部
　１４　出力部
　１２１　仮想機械解析部
　１２２　命令セットアーキテクチャ解析部
　１２３　機能付与部
　１３１　実行トレースデータベース（ＤＢ）
　１３２　アーキテクチャ情報ＤＢ
　１３３　ＶＭ実行トレースＤＢ
　１２１１　実行トレース取得部
　１２１２　フック・タップポイント検出部
　１２１３　ＶＭ命令境界検出部
　１２１４　仮想プログラムカウンタ検出部
　１２１５　ディスパッチャ検出部
　１２２１　ＶＭ実行トレース取得部
　１２２２　分岐ＶＭ命令検出部
　１２３１　フック挿入部
　１２３２　例外ハンドラ挿入部

Claims (7)

  1. 　解析機能付与装置が実行する解析機能付与方法であって、
    　スクリプトエンジンの仮想機械を解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行される前記仮想機械の命令を指し示す変数である仮想プログラムカウンタを取得する第１の解析工程と、
    　前記仮想機械の命令の体系である命令セットアーキテクチャを解析して、分岐を発生させる仮想機械命令である分岐仮想機械命令を取得する第２の解析工程と、
    　前記第１の解析工程及び前記第２の解析工程における解析によって得られたアーキテクチャ情報である、前記仮想プログラムカウンタ及び前記分岐仮想機械命令に基づいて、前記スクリプトエンジンの前記フックポイントに、例外が発生した場合には、前記仮想プログラムカウンタの指す先を、前記例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含むフックを施して解析機能を付与する付与工程と、
    　を含んだことを特徴とする解析機能付与方法。
  2. 　前記付与工程は、
    　解析対象のスクリプトに、例外の発生を捕捉した場合に、仮想機械領域に処理を移す機能を有する例外ハンドラを挿入する第１の挿入工程と、
    　前記スクリプトエンジンの前記フックポイントに、前記仮想機械領域において、前記仮想プログラムカウンタの指す先を、前記例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含むフックハンドラを用いてフックを挿入する第２の挿入工程と、
    　を含んだことを特徴とする請求項１に記載の解析機能付与方法。
  3. 　前記第２の解析工程は、
    　前記仮想機械において実行された実行トレースである仮想機械実行トレースであって、識別子として仮想機械オペコードが仮想的に割り振られ、実行された仮想機械命令ハンドラのポインタと前記仮想プログラムカウンタとを記録した仮想機械実行トレースを取得する第１の取得工程と、
    　前記仮想機械実行トレースの仮想機械オペコードごとの仮想プログラムカウンタの変化量のばらつきによって、前記分岐仮想機械命令を検出する第１の検出工程と、
    　を含み、
    　前記フックハンドラは、
    　前記第１の検出工程によって検出された前記分岐仮想機械命令の一覧を参照し、前記仮想機械実行トレースから分岐仮想機械命令を検出し、該検出した分岐仮想機械命令の実行前後の前記仮想プログラムカウンタを対応付けた仮想機械ブランチトレースを構築する第１の処理と、
    　前記仮想機械ブランチトレースを用いて、前記基本ブロックをノードとし、前記仮想機械ブランチトレースの分岐をエッジとした制御フローグラフを構築する第２の処理と、
    　前記例外が発生した場合に、前記例外が前記制御フローグラフのどの箇所に該当するかを判別し、前記仮想プログラムカウンタの指す先を、前記例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する第３の処理と、
    　を含むことを特徴とする請求項２に記載の解析機能付与方法。
  4. 　前記第１の解析工程は、
    　実行時の条件を変えて複数の実行トレースを取得する第２の取得工程と、
    　前記実行トレースを解析し、前記フックポイントを検出する第２の検出工程と、
    　前記実行トレースをクラスタリングして、各仮想機械命令の境界を検出する第３の検出工程と、
    　メモリの読み込み回数に着目した差分実行解析と前記第３の検出工程において検出された各仮想機械命令の境界とを用いて前記複数の実行トレースを解析し、前記仮想プログラムカウンタを検出する第４の検出工程と、
    　前記第１の検出工程において検出された各仮想命令の境界を基に、スクリプトエンジンのバイナリを解析し、ディスパッチャを検出する第５の検出工程と、
    　を含んだことを特徴とする請求項３に記載の解析機能付与方法。
  5. 　前記第１の解析工程及び前記第２の解析工程は、テスト用のスクリプトを用いた解析を実施することを特徴とする請求項１～４のいずれか一つに記載の解析機能付与方法。
  6. 　スクリプトエンジンの仮想機械を解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行される前記仮想機械の命令を指し示す変数である仮想プログラムカウンタを取得する第１の解析部と、
    　前記仮想機械の命令の体系である命令セットアーキテクチャを解析して、分岐を発生させる仮想機械命令である分岐仮想機械命令を取得する第２の解析部と、
    　前記第１の解析部及び前記第２の解析部による解析によって得られたアーキテクチャ情報である、前記仮想プログラムカウンタ及び前記分岐仮想機械命令に基づいて、前記スクリプトエンジンの前記フックポイントに、例外が発生した場合には、前記仮想プログラムカウンタの指す先を、前記例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含むフックを施して解析機能を付与する付与部と、
    　を有することを特徴とする解析機能付与装置。
  7. 　スクリプトエンジンの仮想機械を解析し、フックを施して解析用コードを挿入する箇所であるフックポイント、及び、次に実行される前記仮想機械の命令を指し示す変数である仮想プログラムカウンタを取得する第１の解析ステップと、
    　前記仮想機械の命令の体系である命令セットアーキテクチャを解析して、分岐を発生させる仮想機械命令である分岐仮想機械命令を取得する第２の解析ステップと、
    　前記第１の解析ステップ及び前記第２の解析ステップにおける解析によって得られたアーキテクチャ情報である、前記仮想プログラムカウンタ及び前記分岐仮想機械命令に基づいて、前記スクリプトエンジンの前記フックポイントに、例外が発生した場合には、前記仮想プログラムカウンタの指す先を、前記例外が発生した基本ブロックの直後の基本ブロックの先頭に変更する処理を含むフックを施して解析機能を付与する付与ステップと、
    　をコンピュータに実行させるための解析機能付与プログラム。
PCT/JP2021/038502 2021-10-18 2021-10-18 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム WO2023067668A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/038502 WO2023067668A1 (ja) 2021-10-18 2021-10-18 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/038502 WO2023067668A1 (ja) 2021-10-18 2021-10-18 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム

Publications (1)

Publication Number Publication Date
WO2023067668A1 true WO2023067668A1 (ja) 2023-04-27

Family

ID=86058896

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/038502 WO2023067668A1 (ja) 2021-10-18 2021-10-18 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム

Country Status (1)

Country Link
WO (1) WO2023067668A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210390183A1 (en) * 2018-10-11 2021-12-16 Nippon Telegraph And Telephone Corporation Analysis function imparting device, analysis function imparting method, and recording medium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020075335A1 (ja) * 2018-10-11 2020-04-16 日本電信電話株式会社 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
WO2021070393A1 (ja) * 2019-10-11 2021-04-15 日本電信電話株式会社 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210390183A1 (en) * 2018-10-11 2021-12-16 Nippon Telegraph And Telephone Corporation Analysis function imparting device, analysis function imparting method, and recording medium

Similar Documents

Publication Publication Date Title
Alsaheel et al. {ATLAS}: A sequence-based learning approach for attack investigation
WO2022180702A1 (ja) 解析機能付与装置、解析機能付与プログラム及び解析機能付与方法
JP7287480B2 (ja) 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
Carmony et al. Extract Me If You Can: Abusing PDF Parsers in Malware Detectors.
JP7115552B2 (ja) 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
US8316448B2 (en) Automatic filter generation and generalization
JP6708781B2 (ja) 選択装置、選択方法及び選択プログラム
RU2665911C2 (ru) Система и способ анализа файла на вредоносность в виртуальной машине
CN107004088B (zh) 确定装置、确定方法及记录介质
CN109101815B (zh) 一种恶意软件检测方法及相关设备
EP3547121B1 (en) Combining device, combining method and combining program
EP2881877A1 (en) Program execution device and program analysis device
KR101645019B1 (ko) 소프트웨어 보안취약점 검출을 위한 규칙명세언어
RU2649794C1 (ru) Система и способ формирования журнала в виртуальной машине для проведения антивирусной проверки файла
WO2023067668A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
US20230141948A1 (en) Analysis and Testing of Embedded Code
WO2023067663A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
KR20210045122A (ko) 기호 실행을 사용하는 소프트웨어 테스트 입력 생성 장치 및 방법
US20160188664A1 (en) Rapid Searching and Matching of Data to a Dynamic Set of Signatures Facilitating Parallel Processing and Hardware Acceleration
WO2023067667A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067665A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
US20220335135A1 (en) Vulnerability analysis and reporting for embedded systems
JP2022518659A (ja) エクスプロイト・キット検出
WO2024079794A1 (ja) 解析機能付与装置、解析機能付与方法および解析機能付与プログラム
Chen et al. Dynamic Taint Analysis with Control Flow Graph for Vulnerability Analysis

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: 21961321

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023553920

Country of ref document: JP

Kind code of ref document: A