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

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

Info

Publication number
WO2021070393A1
WO2021070393A1 PCT/JP2019/040336 JP2019040336W WO2021070393A1 WO 2021070393 A1 WO2021070393 A1 WO 2021070393A1 JP 2019040336 W JP2019040336 W JP 2019040336W WO 2021070393 A1 WO2021070393 A1 WO 2021070393A1
Authority
WO
WIPO (PCT)
Prior art keywords
analysis
execution
unit
branch
instruction
Prior art date
Application number
PCT/JP2019/040336
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/JP2019/040336 priority Critical patent/WO2021070393A1/ja
Priority to US17/764,988 priority patent/US20230028595A1/en
Priority to JP2021551100A priority patent/JP7287480B2/ja
Publication of WO2021070393A1 publication Critical patent/WO2021070393A1/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • 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/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • 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
    • G06F21/562—Static detection
    • G06F21/563—Static detection by source code analysis
    • 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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034—Test or assess a computer or a system

Definitions

  • the present invention relates to an analysis function addition device, an analysis function addition method, and an analysis function addition program.
  • malware malware
  • fileless malware the threat of attacks by scripts that show malicious behavior (malignant scripts) has become apparent.
  • a malicious script is a script that has malicious behavior and is a program that exploits the functions provided by the script engine to implement an attack.
  • an attack is carried out using a script engine that the operating system (OS) has by default, or a script engine that a specific application has, such as a Web browser or a document file viewer.
  • OS operating system
  • a script engine that a specific application has such as a Web browser or a document file viewer.
  • the method called dynamic analysis which knows the behavior by executing a script and monitoring its behavior, is not affected by the above-mentioned obfuscation. Therefore, in the analysis of malignant scripts, a method based on dynamic analysis is mainly used.
  • the former is a case where the execution route after that is not determined without a command from the command server, and the route with malicious behavior is not executed.
  • the route with malicious behavior is not executed.
  • the latter is an analysis obstruction in which a malicious script acquires information on the environment in which it is executed and does not show malicious behavior unless it meets specific conditions. For example, when a feature that is frequently seen in the analysis environment is found, it is used to interfere with the analysis by judging that the analysis is being performed and interrupting the execution.
  • FIG. 18 is a diagram showing a code piece showing an example of analysis interference.
  • This code piece acquires the number of cores of the CPU (Central Processing Unit) of the environment in which it is being executed, and if it is not 2 or more and 8 or less, it is judged that there is a high possibility of an analysis environment and execution is terminated. Has an analysis obstruction to do. Otherwise, it is judged that it is not an analysis environment and shows malignant behavior.
  • CPU Central Processing Unit
  • Non-Patent Document 1 describes a method for realizing symbolic execution, which is a kind of multipath execution, for JavaScript (registered trademark). According to this method, it is possible to comprehensively follow the executable route and observe the behavior in the conditional branching of the JavaScript script.
  • Non-Patent Document 2 describes a method for realizing route forced execution, which is a kind of multipath execution, for JavaScript. According to this method, it is possible to comprehensively follow all routes and observe the behavior in the conditional branching of a JavaScript script.
  • Non-Patent Document 3 describes a script executed on a script engine by manually modifying the script engine in advance and then executing the script engine on a symbolic execution platform for binaries. , A method to realize symbolic execution through a script engine is described. According to this method, if there is a script engine that can be modified manually, symbolic execution can be realized universally in any script language, and the behavior can be observed by comprehensively following the executable path.
  • Non-Patent Document 4 describes a method for analyzing a virtual machine (VM) that malware often uses to obfuscate its own programs. According to this method, information on the architecture can be obtained by analyzing the VM. Since it is the VM that controls the execution of the script in the script engine, the idea of this method can be partially diverted.
  • VM virtual machine
  • Non-Patent Document 1 and Non-Patent Document 2 have a problem that it is necessary to individually design and implement a multipath execution function for each script engine. Further, the methods described in Non-Patent Document 1 and Non-Patent Document 2 have a problem that it is necessary to know the information of the VM architecture of the script engine in advance in order to realize the multipath execution function.
  • Non-Patent Document 3 since the method described in Non-Patent Document 3 requires modification to a script engine, there is still a problem that it is necessary to know the VM architecture information of the script engine in advance. Further, the method described in Non-Patent Document 3 has a problem that it is difficult to execute fine-grained multipath for a script because detailed architecture such as a conditional branching mechanism in a script engine is not considered.
  • Analysis work is required to acquire the architecture information of this script engine.
  • an open source script engine it can be realized by analyzing the source code, but it is limited to the script language from which the source code can be obtained, and a certain amount of man-hours are required.
  • binary reverse engineering is required, and manual implementation requires a skilled reverse engineer and a large amount of man-hours, which is not realistic.
  • its reverse engineering automation has not been established.
  • Non-Patent Document 4 targets only the VM possessed by the malware and does not target the VM possessed by the script engine, there is a problem that it cannot be directly applied to the script engine. Another problem is that the method described in Non-Patent Document 4 does not refer to the acquisition of architectural information related to conditional branching, which is important for multipath execution. Further, the method described in Non-Patent Document 4 focuses only on the analysis of the VM, and does not consider the addition of functions to the VM, such as the addition of multipath execution.
  • the present invention has been made in view of the above, and is an analysis function addition device, an analysis function addition method, and an analysis function addition program capable of imparting a multipath execution function to a script engine without prior architectural information.
  • the purpose is to provide.
  • the analysis function imparting device of the present invention includes a first analysis unit that analyzes a virtual machine of a malicious script engine and an instruction set that is a system of instructions of the virtual machine. Based on the second analysis unit that analyzes the architecture and the architecture information obtained by the analysis by the first analysis unit and the second analysis unit, the granting unit that hooks the script engine to add the multi-path execution function. And, characterized by having.
  • the analysis function addition method of the present invention is an analysis function addition method executed by the analysis function addition device, and is based on the first analysis step of analyzing a virtual machine of a malignant script engine and a system of instructions of the virtual machine. Based on the second analysis step that analyzes a certain instruction set architecture and the architecture information obtained by the analysis in the first analysis step and the second analysis step, a hook that gives the script engine a multi-path execution function is provided. It is characterized by including an application step of applying.
  • the analysis function imparting program of the present invention has a first analysis step for analyzing a virtual machine of a malicious script engine, a second analysis step for analyzing an instruction set architecture which is a system of instructions of a virtual machine, and a first. Based on the architecture information obtained by the analysis in the first analysis step and the second analysis step, the computer is made to execute the grant step of hooking the script engine to grant the multi-pass execution function.
  • FIG. 1 is a diagram for explaining an example of a configuration of a script engine.
  • FIG. 2 is a diagram showing a VM pseudo code included in the script engine.
  • 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 (first test script) used for interpreter loop detection and virtual program counter detection.
  • FIG. 5 is a diagram showing an example of a test script (second test script) used for detecting a branch VM instruction.
  • FIG. 6 is a diagram showing an example of an execution trace.
  • FIG. 7 is a diagram showing an example of a VM execution trace.
  • FIG. 8 is a flowchart showing a processing procedure of the analysis function imparting process according to the embodiment.
  • FIG. 8 is a flowchart showing a processing procedure of the analysis function imparting process according to the embodiment.
  • FIG. 9 is a flowchart showing a processing procedure of the execution trace acquisition process shown in FIG.
  • FIG. 10 is a flowchart showing a processing procedure of the interpreter loop detection process shown in FIG.
  • FIG. 11 is a flowchart showing a processing procedure of the virtual program counter detection process shown in FIG.
  • FIG. 12 is a flowchart showing a processing procedure of the decoder / dispatcher detection process shown in FIG.
  • FIG. 13 is a flowchart showing a processing procedure of the conditional branch flag detection process shown in FIG.
  • FIG. 14 is a flowchart showing a processing procedure of the VM execution trace acquisition process shown in FIG.
  • FIG. 15 is a flowchart showing a processing procedure of the branch VM instruction detection process shown in FIG. FIG.
  • FIG. 16 is a flowchart showing a processing procedure of the analysis function imparting process shown in FIG.
  • FIG. 17 is a diagram showing an example of a computer in which an analysis function imparting device is realized by executing a program.
  • FIG. 18 is a diagram showing a code piece showing an example of analysis interference.
  • the analysis function imparting device analyzes the binary of the script engine using a test script, thereby performing an interpreter loop, a virtual program counter (VPC), a decoder / dispatcher, a conditional branch flag, and a VM.
  • the branch instruction (branch VM instruction) is detected in order.
  • FIG. 1 is a diagram for explaining an example of the configuration of the script engine.
  • the script engine 1 has a bytecode compiler 2 and a virtual machine (VM) 3.
  • the bytecode compiler 2 has a syntax analysis unit 4 and a bytecode generation unit 5.
  • the VM3 has a code cache unit 6, a fetch unit 7, a decoding unit 8, and an execution unit 9. These fetch unit 7, decoding unit 8, and execution unit 9 are repeatedly executed and are called an interpreter loop. Then, the script engine 1 accepts the input of the script.
  • the syntax analysis unit 4 receives the script as input, performs lexical analysis and syntax analysis, generates an Abstract Syntax Tree (AST), and outputs it to the bytecode generation unit 5.
  • the byte code generation unit 5 receives the AST as an input, converts it into a byte code, and stores it in the code cache unit 6.
  • the fetch unit 7 fetches the VM operation code from the code cache unit 6 and outputs it to the decode unit 8.
  • the VM opcode refers to the opcode portion of the VM instruction.
  • the decoding unit 8 receives the VM operation code as an input, interprets the VM operation code using the decoder dispatcher, and dispatches it to the corresponding program.
  • the execution unit 9 executes a program corresponding to the VM instruction. By repeating the interpreter loop, the VM instructions are executed one after another, and the contents described in the script are executed.
  • FIG. 2 is a diagram showing a VM pseudo code included in the script engine.
  • the pseudo code initializes the VPC (first line).
  • the while statement loop is the interpreter loop (second line).
  • the VM opcode pointed to by the VPC is acquired from the code cache (3rd line), decoded and dispatched using the Switch statement (4th, 5th, and 7th lines).
  • the program corresponding to the VM operation code of the dispatched destination is executed (lines 6 and 8).
  • the branch VM instruction is a VM instruction that generates a branch in the script
  • the conditional branch flag is an area that holds a flag as to whether or not a branch is made at the time of conditional branching.
  • the analysis function imparting device 10 acquires an execution trace consisting of a branch trace and a memory access trace for a malicious script engine binary by a hook of a branch instruction and a hook of a memory operation instruction. ..
  • the branch trace records the executed branch
  • the memory access trace records the read / write of the executed memory.
  • the analysis function adding device 10 analyzes this execution trace and detects the interpreter loop.
  • an analysis method called differential execution analysis is applied, which analyzes based on the differences between multiple execution traces acquired by changing the execution conditions.
  • the run-time conditions are changed by using different test scripts.
  • a difference execution analysis focusing on the number of branches is used.
  • the inside of the interpreted loop obtained here will be the subject of subsequent analysis.
  • the analysis function imparting device 10 analyzes the execution trace and detects the VPC.
  • the analysis function adding device applies the difference execution analysis focusing on the number of times the memory is read to detect the VPC.
  • this analysis function adding device 10 statically analyzes the binary of the script engine and detects the decoder / dispatcher.
  • the decoder dispatcher is realized by a Switch statement or a jump table or function table. Since a method of detecting such a table jump using a Switch statement, a jump table, or a function table by static analysis is generally known, the analysis function adding device 10 detects them by a predetermined method.
  • the analysis function adding device 10 analyzes the execution trace and detects the conditional branch flag.
  • the analysis function adding device 10 applies the difference execution analysis focusing on the reading of the memory as the detection of the conditional branch flag.
  • the analysis function adding device 10 acquires a VM execution trace for the script engine binary by monitoring the VPC and monitoring the VM operation code of the decoder / dispatcher.
  • the VM execution trace records the executed VM opcode and VPC.
  • the analysis function adding device 10 analyzes this VM execution trace and detects a branch VM instruction. In the detection of the branch VM instruction, the analysis function adding device 10 first executes a large number of test scripts and acquires a VM execution trace. Then, the analysis function imparting device 10 collects the VM operation code and the amount of change in the VPC before and after the execution as a set from the VM execution trace. When the VM opcode is something other than the branch VM instruction, the amount of change in the VPC is almost constant. On the other hand, when the VM operation code is a branch VM instruction, the VPC varies depending on the branch destination. The analysis function imparting device 10 evaluates the variation in the amount of change in the VPC for each VM opcode by the variance, and detects those having the variance above a certain threshold value as a branch VM instruction.
  • the analysis function adding device 10 hooks the binary of the script engine based on the VPC, the branch VM instruction, and the conditional branch flag obtained so far. By this hook, the analysis function addition device 10 monitors the destination pointed to by the VPC, and when it is a branch VM instruction, branches the execution state. Then, the analysis function imparting device 10 executes one execution state as it is, and executes the other execution state after rewriting the conditional branch flag. As a result, both execution paths of the conditional branch are executed. As described above, the analysis function adding device 10 realizes the addition of the multipath function to the crypto engine afterwards.
  • 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 includes an input unit 11, a control unit 12, a storage unit 13, and an output unit 14. Then, the analysis function imparting device 10 accepts the input of the test script and the script engine binary.
  • the input unit 11 is composed of an input device such as a keyboard and a mouse, receives input of information from the outside, and inputs the information to the control unit 12.
  • the input unit 11 receives the input of the test script and the script engine binary and outputs the input to the control unit 12.
  • the test script is a script that is input when the script engine is dynamically analyzed to acquire the execution trace and the VM execution trace. The details of the test script will be described later.
  • Script engine binaries are the executable files that make up a script engine. Script engine binaries may consist of multiple executable files.
  • the control unit 12 has an internal memory for storing a program that defines various processing procedures and required data, and executes various processing by these.
  • the control unit 12 is an electronic circuit such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit).
  • the control unit 12 includes a virtual machine analysis unit 121 (first analysis unit), an instruction set architecture analysis unit 122 (second analysis unit), and an analysis function imparting unit 123 (granting 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 the execution conditions, analyzes the plurality of execution traces by using the differential execution analysis, and acquires the VPC and the conditional branch flag.
  • the virtual machine analysis unit 121 includes an execution trace acquisition unit 1211 (first acquisition unit), an interpreter loop detection unit 1212 (first detection unit), a virtual program counter detection unit 1213 (second detection unit), and a decoder dispatcher. It has a detection unit 1214 (third detection unit) and a conditional branch flag detection unit 1215 (fourth detection unit).
  • the execution trace acquisition unit 1211 accepts the test script and the script engine binary as inputs.
  • the execution trace acquisition unit 1211 acquires an execution trace by executing a test script while monitoring the execution of the script engine binary.
  • the execution trace consists of a branch trace and a memory access trace.
  • the branch trace records the type of branch instruction at the time of execution, and the branch source address and branch destination address.
  • the memory access trace records the type of memory operation and the memory address of the operation target. It is known that branch traces and memory access traces can be obtained by instruction hooks.
  • the execution trace acquired by the execution trace acquisition unit 1211 is stored in the execution trace DB 131.
  • the interpreter loop detection unit 1212 extracts and analyzes the execution trace for the first test script stored in the execution trace DB 131, and detects the interpreter loop.
  • the interpreter loop detection unit 1212 detects the interpreter loop by discovering the branch destination by utilizing the fact that a branch with the head of the interpreter loop as the branch destination always occurs after the execution of each VM instruction.
  • the interpreter loop detection unit 1212 uses a difference execution analysis focusing on the number of branches to detect the interpreter loop.
  • the interpreter loop detection unit 1212 compares the execution traces of a plurality of test scripts having different repetitions and the number of repeated statements, and the number of branches is proportional to both the number of repetitions and the number of repeated sentences. Discover the branch destination.
  • the interpreter loop detection unit 1212 detects this branch destination as the head of the interpreter loop.
  • the virtual program counter detection unit 1213 extracts and analyzes the execution trace for the first test script stored in the execution trace DB 131, and detects the VPC.
  • the virtual program counter detection unit 1213 detects the VPC by discovering the read destination by utilizing the fact that the read to the memory holding the VPC always occurs after the execution of each VM instruction.
  • the virtual program counter detection unit 1213 uses the difference execution analysis focusing on the number of times the memory is read as the detection of the VPC.
  • the virtual program counter detection unit 1213 compares the execution traces of a plurality of test scripts acquired using the same test script as the detection of the interpreted loop, and determines both the number of times the memory is read and the number of repeated statements. Discover proportional memory.
  • the virtual program counter detection unit 1213 detects this memory as a VPC.
  • the decoder / dispatcher detection unit 1214 detects the Switch statement, function table, and jump table existing in the interpreter loop by performing a predetermined static analysis on the script engine binary.
  • the decoder dispatcher detection unit 1214 detects the instruction sequence of these processes as a decoder dispatcher.
  • the conditional branch flag detection unit 1215 extracts and analyzes the execution trace for the second test script stored in the execution trace DB 131, and discovers the conditional branch flag.
  • the conditional branch flag detection unit 1215 analyzes a plurality of execution traces by using the differential execution analysis focusing on the number of times the memory is read, and detects the conditional branch flag.
  • the conditional branch flag detection unit 1215 executes conditional branching in various patterns, compares the pattern of memory change at that time with the conditional branching pattern on the test script, and detects the memory for storing the conditional branching flag. To do.
  • the instruction set architecture analysis unit 122 analyzes the instruction set architecture, which is a system of VM instructions.
  • the instruction set architecture analysis unit 122 has a VM execution trace acquisition unit 1221 (second acquisition unit) and a branch VM instruction detection unit 1222 (fifth detection unit).
  • the VM execution trace acquisition unit 1221 accepts the test script and the script engine binary as inputs, like the execution trace acquisition unit 1211.
  • 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 the execution of the script engine binary.
  • the VM execution trace is composed of a VPC and a VM opcode for each VM instruction executed. Recording of the VPC can be realized by monitoring the memory of the VPC detected by the virtual program counter detection unit 1213. Recording of the VM operation code can be realized by monitoring the VM operation code input to the decoder detected by the decoder / dispatcher detection unit 1214.
  • the VM execution trace acquisition unit 1221 stores the acquired VM execution trace in the VM execution trace DB 133.
  • the branch VM instruction detection unit 1222 takes out the VM execution trace stored in the VM execution trace DB 133, analyzes it, and detects the branch VM instruction.
  • the branch VM instruction detection unit 1222 pays attention to the fact that the magnitude of the variation in the VPC value differs between the branch VM instruction and the other VM instructions, determines a threshold value, and branches the branch VM instruction having a larger variation in the VPC value. Detected as a VM instruction.
  • the branch VM instruction detection unit 1222 detects a branch VM instruction based on the variation in the amount of change in the virtual program counter for each VM operation code of the VM execution trace.
  • the analysis function adding unit 123 hooks the script engine to give a multipath execution function 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 analysis function addition unit 123 hooks the script engine using the obtained VPC, branch VM instruction, and conditional branch flag. This hook monitors the VPC to check the VM operation code, and if it is the VM operation code of the branch VM instruction, it is a hook that branches the execution state. Then, this hook is a hook that gives the script engine a multipath execution function by executing one execution state as it is and rewriting the conditional branch flag to execute the other execution state.
  • the storage unit 13 is realized by a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory (Flash Memory), or a storage device such as a hard disk or an optical disk, and is a processing program or process for operating the analysis function imparting device 10. 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.
  • DB execution trace database
  • the execution trace DB 131 and the VM execution trace DB 133 store the execution trace and the VM execution trace acquired by the execution trace acquisition unit 1211 and the VM execution trace acquisition unit 1221, respectively.
  • the execution trace DB 131 and the 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).
  • the execution trace acquisition unit 1211 and the VM execution trace acquisition unit 1221 are the output units 14.
  • the acquired execution trace and VM execution trace are output to the management server or the like of the execution trace DB 131 and the VM execution trace DB 133 via the communication interface, and stored in the execution trace DB 131 and the 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 to / from the external device, or may output various information to the external device.
  • test script configuration The test script will be explained.
  • a test script is a script that is input when the script engine is dynamically analyzed. This test script focuses on the number of branch instruction executions and memory read / write times, and is used to capture the difference in the behavior of the script engine that occurs when different test scripts are executed. This test script is prepared in advance for analysis and is created manually. This creation requires knowledge of the specifications of the target scripting language.
  • FIG. 4 is a diagram showing an example of a test script (first test script) used for detecting an interpreter loop and detecting a VPC.
  • the first test script uses iterative processing (second line).
  • second line In the first test script, the run-time conditions are changed and a difference is generated by increasing or decreasing the number of repetitions (2nd line) and the number of repeated sentences (3rd to 5th lines) in the test script. Let me.
  • FIG. 5 is a diagram showing an example of a test script (second test script) used for detecting a branch VM instruction.
  • the second test script uses multiple conditional branches (lines 4-8).
  • the branching condition is controlled so that the branching is performed or not performed in a pattern of a specific order (first line, fifth line).
  • 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. As described above, the execution trace is composed of a branch trace and a memory access trace. FIG. 6 is a diagram showing an example of an execution trace. Hereinafter, the configuration of the execution trace will be shown with reference to FIG.
  • the execution trace has an element called trace.
  • trace indicates whether the log line is a branch trace or a memory access trace.
  • the branch trace log line has, for example, the format described in the 1st to 10th lines of FIG. 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.
  • src indicates the branch source address
  • dst indicates the branch destination address.
  • the memory access trace log line has, for example, the format described in the 11th to 13th lines of FIG. 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 by memory. In addition, the value as a result of memory access is stored in value.
  • FIG. 7 is a diagram showing an example of a VM execution trace. As described above, the VM execution trace records the VM operation code and the VPC. FIG. 7 is a cutout of a part of the VM execution trace. Hereinafter, the configuration of the VM execution trace will be shown with reference to FIG.
  • the log line of the VM execution trace has the format shown in FIG. 7, for example, and consists of two elements, vpc and opcode.
  • vpc indicates the value of VPC.
  • opcode indicates the value of the VM opcode.
  • Interpreter loop detection is realized by analyzing the branch trace log of the acquired execution trace.
  • a branch instruction jumps to the beginning of the loop. Therefore, the interpreter loop detection unit 1212 detects the head of the interpreter loop from the branch destination addresses of the branch instructions in the branch trace.
  • the interpreter loop detection unit 1212 uses a difference execution analysis focusing on the number of branches.
  • the interpreter loop detection unit 1212 uses the execution trace corresponding to the first test script.
  • the number of branches to the beginning of the interpreter loop is proportional to the number of iterations in the test script and the number of statements in the iteration.
  • N When the number of repetitions is N and the number of repeated sentences is M, a branch to the beginning of an interpreter loop of about MN occurs. Therefore, the interpreter loop detection unit 1212 sets the branch destination of the interpreter loop as 4MN and 9MN in the execution trace for the first test script in which N and M are increased to 2N and 2M, 3N and 3M, respectively. Detect as head.
  • the detection of the virtual program counter is realized by analyzing the memory access trace log of the acquired execution trace. Since the VPC is generally stored in the memory and is read every time the VM instruction is executed, the value is read to this memory address. Therefore, the virtual program counter detection unit 1213 detects a VPC-corresponding address from the memory read target addresses in the memory access trace. The virtual program counter detection unit 1213 uses the difference execution analysis focusing on the number of times the memory is read.
  • the virtual program counter detection unit 1213 uses the execution trace corresponding to the first test script.
  • the number of times the VPC is read is proportional to the number of repetitions in the test script and the number of sentences in the repetition process.
  • N When the number of repetitions is N and the number of repeated sentences is M, reading of a VPC of about MN occurs. Therefore, the interpreter loop detection unit 1212 detects the memory with the increase of 4MN and 9MN as the VPC in the execution trace for the first test script in which N and M are increased to 2N and 2M, 3N and 3M, respectively. ..
  • the decoder dispatcher detection unit 1214 detects the decoder dispatcher by statically analyzing the binary of the script engine by a predetermined method.
  • decoder / dispatcher implementations There are generally two types of decoder / dispatcher implementations.
  • the first type of decoder / dispatcher implementation is an implementation using a Switch statement
  • the second type is an implementation using a table jump using a function table or a jump table. It is generally known that recognition of switch statements and table jumps can be realized by existing static analysis methods. Therefore, the decoder dispatcher detection unit 1214 detects as a decoder dispatcher among the Switch statements and table jumps detected by a predetermined static analysis method, those existing in the interpreter loop.
  • conditional branch flag detection unit 1215 detects the conditional branch flag by analyzing the memory access in the interpreter loop.
  • the conditional branch flag detection unit 1215 uses the execution trace obtained by using the second test script.
  • the conditional branch flag detection unit 1215 detects the conditional branch flag by narrowing down the memory access in the interpreter loop in two stages.
  • the conditional branch flag has two states, one is branching and the other is not. Further, the conditional branch flag is considered to be read a number of times proportional to the number of conditional branches.
  • conditional branch flag detection unit 1215 extracts a memory having a memory read a number of times proportional to the number of conditional branches as the first stage narrowing down. Then, the conditional branch flag detection unit 1215 extracts the memory in which the value at the time of reading each memory goes back and forth between the two values so as to correspond to the conditional branch of the test script as the second stage narrowing down.
  • conditional branch flag detection unit 1215 extracts the memory address that goes back and forth between the two values of X, Y, X, X, and Y. The conditional branch flag detection unit 1215 detects the conditional branch flag by repeating this while changing the number of branches.
  • 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 the branch VM instruction, it may be any script as long as it includes the branch control syntax. For example, prepare a test script by collecting it from the Internet or obtaining it from the official document.
  • the branch VM instruction detection unit 1222 acquires the operation code of the VM instruction and the offset of the VPC before and after the execution of the instruction as a set from the VM execution trace.
  • the branch VM instruction detection unit 1222 uses the variance s to evaluate the variation of this offset.
  • O ⁇ o 0 , o 1 , ..., o N ⁇ (see equation (1) for the average of offset o)
  • t is the threshold value, whether it is a branch instruction or not. Is determined as in Eq. (3) based on the variance s (see Eq. (2)).
  • the branch VM instruction detection unit 1222 detects the branch VM instruction.
  • a threshold value for example, a value that can divide the two groups formed by plotting the obtained value of the variance on a number line is set.
  • the analysis function addition unit 123 accepts the script engine binary and the hook points and tap points detected in the processes up to this point as inputs.
  • the analysis function adding unit 123 hooks the script engine at a hook point.
  • the analysis function adding unit 123 inserts the analysis code so that the language element corresponding to the hook is executed at the time of hooking and the memory of the tap point as its argument is output to the log.
  • the code for this analysis can be easily generated if the hook point and tap point are known. As a result, when the script is executed, its behavior is output as a log, and the analysis function is added.
  • the analysis function can be added by this hook by directly rewriting the binary for the script engine binary, or by rewriting the memory image when the binary is executed and expanded on the process memory.
  • FIG. 8 is a flowchart showing a processing procedure of the analysis function imparting process according to the embodiment.
  • the input unit 11 receives the test script and the script engine binary as inputs (step S1).
  • the execution trace acquisition unit 1211 executes an execution trace acquisition process for acquiring a branch trace and a memory access trace by executing a test script while monitoring the binary of the script engine (step S2).
  • the interpreter loop detection unit 1212 takes out the execution trace for the first test script stored in the execution trace DB 131, analyzes it, and performs the interpreter loop detection process for discovering the interpreter loop (step S3).
  • the virtual program counter detection unit 1213 takes out the execution trace for the first test script stored in the execution trace DB 131, analyzes it, and performs the virtual program counter detection process for discovering the VPC (step S4).
  • the decoder / dispatcher detection unit 1214 performs a decoder / dispatcher detection process for detecting the Switch statement, the function table, and the jump table existing in the interpreter loop by performing a predetermined static analysis on the script engine binary (step S5). ..
  • the conditional branch flag detection unit 1215 takes out and analyzes the execution trace for the second test script stored in the execution trace DB 131, and performs the conditional branch detection process for discovering the conditional branch flag (step S6).
  • the VM execution trace acquisition unit 1221 receives the test script and the script engine binary as input, and executes the test script while monitoring the execution of the script engine binary to perform the VM execution trace acquisition process for acquiring the VM execution trace. (Step S7).
  • the branch VM instruction detection unit 1222 takes out the VM execution trace stored in the VM execution trace DB 133, analyzes it, and performs the branch VM instruction detection process for detecting the branch VM instruction (step S8).
  • the analysis function addition unit 123 performs an analysis function addition process for hooking the script engine using the obtained VPC, branch VM instruction, and conditional branch flag (step S9). Then, the output unit 14 outputs the script engine binary to which the multipath execution function is added (step S10).
  • FIG. 9 is a flowchart showing a processing procedure 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 S11). Then, the execution trace acquisition unit 1211 applies a hook for acquiring the branch trace to the received script engine (step S12). Further, the execution trace acquisition unit 1211 also provides a hook for acquiring the memory access trace to the received script engine (step S13).
  • the execution trace acquisition unit 1211 inputs the test script received in that state into the script engine and executes it (step S14), and stores the execution trace acquired thereby in the execution trace DB 131 (step S15).
  • the execution trace acquisition unit 1211 determines whether or not all the input test scripts have been executed (step S16). The execution trace acquisition unit 1211 ends the process when all the input test scripts have been executed (step S16: Yes). On the other hand, when the execution trace acquisition unit 1211 has not executed all the input test scripts (step S16: No), the execution trace acquisition unit 1211 returns to the execution of the test script in step S14 and continues the process.
  • FIG. 10 is a flowchart showing a processing procedure of the interpreter loop detection process shown in FIG.
  • the interpreter loop detection unit 1212 extracts one execution trace by the first test script from the execution trace DB 131 (step S21). Then, the interpreter loop detection unit 1212 pays attention to the branch trace among the execution traces, and counts the number of branches for each branch destination (step S22). Subsequently, the interpreter loop detection unit 1212 receives the first test script used for acquiring the execution trace as an input (step S23), analyzes it, and acquires the number of repetitions and the number of repeated statements (step). S24).
  • the interpreter loop detection unit 1212 extracts one more execution trace by the first test script having a different number of repetitions and a different number of sentences from the execution trace DB 131 (step S25). Then, the interpreter loop detection unit 1212 pays attention to the branch trace and counts the number of branches for each branch destination (step S26). Further, the interpreter loop detection unit 1212 receives the first test script used for acquiring the execution trace as an input (step S27), analyzes the test script, and acquires the number of repetitions and the number of repeated statements (step). S28).
  • the interpreter loop detection unit 1212 narrows down to only the branch destinations where the number of branches changes in proportion to the number of repetitions and the increase / decrease of the repeated sentences (step S29). The interpreter loop detection unit 1212 determines whether or not the branch destination has been narrowed down to only one (step S30).
  • step S30: No If the interpreter loop detection unit 1212 has not narrowed down the branch destination to only one (step S30: No), it returns to step S25, extracts one next execution trace, and continues the process. On the other hand, when the interpreter loop detection unit 1212 narrows down the branch destination to only one (step S30: Yes), the interpreted loop detection unit 1212 stores the narrowed down branch destination as the head of the interpreter loop in the architecture information DB 132 (step S31). End the process.
  • FIG. 11 is a flowchart showing a processing procedure of the virtual program counter detection process shown in FIG. 8
  • the virtual program counter detection unit 1213 extracts one execution trace by the first test script from the execution trace DB 131 (step S41). Subsequently, the virtual program counter detection unit 1213 pays attention to the memory access trace in the execution trace, and counts the number of readings for each memory reading destination (step S42).
  • the virtual program counter detection unit 1213 receives the first test script used for acquiring the execution trace as an input (step S43), analyzes the first test script, and determines the number of repetitions and the number of repeated statements. Acquire (step S44).
  • the virtual program counter detection unit 1213 extracts one more execution trace by the first test script having a different number of repetitions and the number of repeated statements from the execution trace DB 131 (step S45). Then, the virtual program counter detection unit 1213 pays attention to the memory access trace and counts the number of readings for each memory reading destination (step S46). Further, the virtual program counter detection unit 1213 receives the first test script used for acquiring the execution trace as an input (step S47), analyzes the test script, and acquires the number of repetitions and the number of repeated statements (step S47). Step S48).
  • the virtual program counter detection unit 1213 narrows down to only the memory read destinations whose read count changes in proportion to the number of repetitions and the increase / decrease of the repeated sentences (step S49).
  • the virtual program counter detection unit 1213 determines whether or not the memory read destination has been narrowed down to only one (step S50). When the virtual program counter detection unit 1213 has not narrowed down the memory read destination to only one (step S50: No), the virtual program counter detection unit 1213 returns to step S45, extracts one next execution trace, and continues the process. On the other hand, when the virtual program counter detection unit 1213 narrows down the memory read destination to only one (step S50: Yes), the virtual program counter detection unit 1213 stores the narrowed down memory read destination as a virtual program counter in the architecture information DB 132 (step S51). ), End the process.
  • FIG. 12 is a flowchart showing a processing procedure of the decoder / dispatcher detection process shown in FIG.
  • the decoder / dispatcher detection unit 1214 receives the script engine binary as an input (step S61). Then, the decoder / dispatcher detection unit 1214 extracts the information of the interpreter loop from the architecture information DB 132 (step S62).
  • the decoder / dispatcher detection unit 1214 detects the Switch statement and the table jump in the interpreter loop by a predetermined static analysis (step S63).
  • the decoder dispatcher detection unit 1214 stores the detected Switch statement or table jump as the decoder dispatcher in the architecture information DB 132 (step S64), and ends the process.
  • FIG. 13 is a flowchart showing a processing procedure of the conditional branch flag detection process shown in FIG.
  • conditional branch flag detection unit 1215 extracts one execution trace by the second test script from the execution trace DB 131 (step S71). Then, the conditional branch flag detection unit 1215 pays attention to the memory access trace and counts the number of readings for each memory reading destination (step S72).
  • conditional branch flag detection unit 1215 receives the second test script used for acquiring the execution trace as an input (step S73), analyzes the second test script, and determines the number of conditional branches and True /. Acquire a false order pattern (step S74). Then, the conditional branch flag detection unit 1215 narrows down to only the memory read destination whose read count changes in proportion to the number of conditional branches (step S75). Further, the conditional branch flag detection unit 1215 narrows down the read memory value to only the memory read destination in which the two values are switched according to the order pattern of True / False (step S76).
  • the conditional branch flag detection unit 1215 determines whether or not the memory read destination has been narrowed down to only one (step S77). If the conditional branch flag detection unit 1215 has not narrowed down the memory read destination to only one (step S77: No), the conditional branch flag detection unit 1215 returns to step S71, extracts one next execution trace, and continues the process. On the other hand, when the conditional branch flag detection unit 1215 narrows down the memory read destination to only one (step S77: Yes), the conditional branch flag detection unit 1215 stores the narrowed down read destination as a virtual program counter in the architecture information DB 132 (step S78). End the process.
  • FIG. 14 is a flowchart showing a processing procedure of the VM execution trace acquisition process shown in FIG. 8
  • the VM execution trace acquisition unit 1221 receives the test script and the script engine binary as inputs (step S81). Then, the VM execution trace acquisition unit 1221 hooks the received script engine for recording the VPC and the VM operation code (step S82).
  • the VM execution trace acquisition unit 1221 inputs the test script received in that state into the script engine and executes 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 or not all the input test scripts have been executed (step S85). The VM execution trace acquisition unit 1221 ends the process when all the input test scripts have been executed (step S85: Yes). If the VM execution trace acquisition unit 1221 has not completed the execution of all the input test scripts (step S85: No), the VM execution trace acquisition unit 1221 returns to the execution of the test script in step S83 and continues the process.
  • FIG. 15 is a flowchart showing a processing procedure of the branch VM instruction detection process shown in FIG. 8
  • the branch VM instruction detection unit 1222 extracts one VM execution trace from the VM execution trace DB 133 (step S91). Then, the branch VM instruction detection unit 1222 totals the amount of change in the VPC before and after the execution for each VM operation code (step S92).
  • the branch VM instruction detection unit 1222 determines whether or not all the VM execution traces of the VM execution trace DB 133 have been processed (step S93). When all the VM execution traces of the VM execution trace DB 133 have not been processed (step S93: No), the branch VM instruction detection unit 1222 returns to step S91, takes out one next VM execution trace, and processes it.
  • the branch VM instruction detection unit 1222 calculates the variance of the change amount of the VPC for each VM operation code (step S94). Then, the branch VM instruction detection unit 1222 receives the threshold value as an input (step S95). The branch VM instruction detection unit 1222 narrows down to only VM operation codes whose variance is larger than the threshold value (step S96), stores them as branch VM instructions in the architecture information DB 132 (step S97), and ends the process.
  • FIG. 15 is a flowchart showing a processing procedure of the analysis function imparting process shown in FIG. 8
  • the analysis function adding unit 123 receives the script engine binary as an input (step S101). Then, the analysis function adding unit 123 extracts the VPC, the conditional branch flag, and the conditional branch VM instruction from the architecture information DB 132 (step S102). Subsequently, the analysis function adding unit 123 hooks the hook point of the script engine (step S103). The analysis function adding unit 123 generates a code and inserts it into the script engine so that the code for multipath execution is executed at the time of this hook (step S104). The analysis function adding unit 123 outputs the hooked script engine thus obtained as a script engine with a multipath execution function (step S105), and ends the process.
  • the analysis function imparting device 10 analyzes the VM of the script engine, analyzes the instruction set architecture which is the instruction system of the VM, and is based on the architecture information obtained by these analyzes. To the script engine, hook it to give the multi-pass execution function.
  • the analysis function adding device 10 executes a test script while monitoring the binary of the script engine to acquire a branch trace and a memory access trace. Then, the analysis function adding device 10 analyzes the virtual machine based on the execution trace, and acquires the architecture information of the interpreter loop, the VPC, the decoder / dispatcher, and the conditional branch flag. Further, the analysis function adding device 10 executes a test script to acquire a VM execution trace, analyzes the instruction set architecture using the VM execution trace, and acquires a branch VM instruction as architecture information. After that, the analysis function imparting device 10 imparts a multipath execution function to the script engine based on the obtained architecture information.
  • the analysis function adding device 10 detects various architectural information by analysis based on the acquisition of execution traces and VM execution traces even for a proprietary script engine for which only binaries can be obtained, and reverse engineering manually. It is possible to add a multipath execution function without requiring.
  • the analysis function adding device 10 can automatically add a multipath execution function to various script engines as long as a test script is prepared, the multipath execution function can be provided without individual design and execution. Grant can be realized.
  • the analysis function adding device 10 considers a detailed architecture such as conditional branching, it is possible to give an accurate multipath execution function to the conditional branching of the script.
  • the analysis function adding device 10 by analyzing the script engine and adding the multipath execution function afterwards, the multipath execution function is automatically applied to the script engines of various script languages. Can be granted.
  • the analysis function imparting device 10 is useful for analyzing the behavior of a malignant script described in a wide variety of script languages, and is useful for a malignant script having a route that is not executed unless specific conditions are satisfied. , Suitable for comprehensive analysis of behavior without being affected by it. Therefore, by adding the multipath execution function to various script engines by using this embodiment, it is possible to analyze the behavior of the malicious script and utilize it for measures such as detection.
  • Each component of the analysis function imparting device 10 shown in FIG. 3 is a functional concept, and does not necessarily have to be physically configured as shown in the figure. That is, the specific form of the distribution and integration of the functions of the analysis function imparting device 10 is not limited to the one shown in the figure, and all or a part thereof may be functionally or in an arbitrary unit according to various loads and usage conditions. It can be physically distributed or integrated.
  • each process performed by the analysis function imparting device 10 may be realized by a CPU and a program in which an arbitrary part is analyzed and executed by the CPU. Further, each process performed by the analysis function imparting device 10 may be realized as hardware by wired logic.
  • FIG. 17 is a diagram showing an example of a computer in which the analysis function imparting device 10 is realized by executing a program.
  • the computer 1000 has, for example, a memory 1010 and a CPU 1020.
  • the computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. Each of these parts is connected by a bus 1080.
  • Memory 1010 includes ROM 1011 and RAM 1012.
  • the ROM 1011 stores, for example, a boot program such as a BIOS (Basic Input Output System).
  • BIOS Basic Input Output System
  • the hard disk drive interface 1030 is connected to the hard disk drive 1090.
  • the disk drive interface 1040 is connected to the disk drive 1100.
  • a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100.
  • the serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120.
  • the video adapter 1060 is connected to, for example, the display 1130.
  • the hard disk drive 1090 stores, for example, OS1091, application program 1092, program module 1093, and program data 1094. That is, the program that defines each process of the analysis function imparting device 10 is implemented as a program module 1093 in which a code that can be executed by the computer 1000 is described.
  • the program module 1093 is stored in, for example, the hard disk drive 1090.
  • a program module 1093 for executing a process similar to the function configuration in the analysis function imparting device 10 is stored in the hard disk drive 1090.
  • 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, for example, a memory 1010 or a hard disk drive 1090. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the memory 1010 and the hard disk drive 1090 into the RAM 1012 as needed, and executes the program.
  • the program module 1093 and the program data 1094 are not limited to those stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1100 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). Then, the program module 1093 and the program data 1094 may be read by the CPU 1020 from another computer via the network interface 1070.
  • LAN Local Area Network
  • WAN Wide Area Network

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Virology (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

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.
　しかしながら、非特許文献１及び非特許文献２に記載の手法では、スクリプトエンジンごとに個別にマルチパス実行機能を設計し、実装する必要があるという課題があった。また、非特許文献１及び非特許文献２に記載の手法では、マルチパス実行機能を実現するために、スクリプトエンジンのＶＭのアーキテクチャの情報を事前に知る必要があるという課題があった。
　また、非特許文献３に記載の手法では、スクリプトエンジンへの改造を要するため、やはり、スクリプトエンジンのＶＭのアーキテクチャ情報を事前に知る必要があるという課題があった。また、非特許文献３に記載の手法では、スクリプトエンジン内での条件分岐の仕組みなど、詳細なアーキテクチャを考慮しないため、スクリプトに対する細粒度のマルチパス実行が難しいという課題があった。
　このスクリプトエンジンのアーキテクチャ情報の取得には、解析作業が必要となる。オープンソースのスクリプトエンジンに対しては、ソースコードの解析によって実現できるが、ソースコードが得られるスクリプト言語に限られ、一定の工数も要する。さらに、プロプライエタリのスクリプトエンジンについては、バイナリのリバースエンジニアリングの必要があり、人手での実施には熟練したリバースエンジニアと多大な工数を要するため、現実的でない。さらに、そのリバースエンジニアリングの自動化は、確立されていない。
　そして、非特許文献４に記載の手法では、マルウェアの持つＶＭのみを対象としており、スクリプトエンジンの持つＶＭは対象としていないため、スクリプトエンジンには直接的には適用できないという課題があった。また、非特許文献４に記載の手法は、マルチパス実行に重要な条件分岐に関わるアーキテクチャ情報の取得には言及していないという課題もあった。さらに、非特許文献４に記載の手法では、ＶＭの解析のみに焦点を当てており、マルチパス実行の付与など、ＶＭへの機能付与は考慮していないという課題もあった。
　本発明は、上記に鑑みてなされたものであって、スクリプトエンジンに対して、事前のアーキテクチャ情報なしにマルチパス実行機能の付与を実現できる解析機能付与装置、解析機能付与方法及び解析機能付与プログラムを提供することを目的とする。
　上述した課題を解決し、目的を達成するために、本発明の解析機能付与装置は、悪性のスクリプトエンジンの仮想機械を解析する第一の解析部と、仮想機械の命令の体系である命令セットアーキテクチャを解析する第二の解析部と、第一の解析部及び第二の解析部による解析によって得られたアーキテクチャ情報に基づいて、スクリプトエンジンに、マルチパス実行機能を付与するフックを施す付与部と、を有することを特徴とする。
　また、本発明の解析機能付与方法は、解析機能付与装置が実行する解析機能付与方法であって、悪性のスクリプトエンジンの仮想機械を解析する第一の解析工程と、仮想機械の命令の体系である命令セットアーキテクチャを解析する第二の解析工程と、第一の解析工程及び第二の解析工程における解析によって得られたアーキテクチャ情報に基づいて、スクリプトエンジンに、マルチパス実行機能を付与するフックを施す付与工程と、を含んだことを特徴とする。
　また、本発明の解析機能付与プログラムは、悪性のスクリプトエンジンの仮想機械を解析する第一の解析ステップと、仮想機械の命令の体系である命令セットアーキテクチャを解析する第二の解析ステップと、第一の解析工程及び第二の解析工程における解析によって得られたアーキテクチャ情報に基づいて、スクリプトエンジンに、マルチパス実行機能を付与するフックを施す付与ステップと、をコンピュータに実行させる。
　本発明によれば、スクリプトエンジンに対して、事前のアーキテクチャ情報なしにマルチパス実行機能の付与を実現できる。
図１は、スクリプトエンジンの構成の一例を説明するための図である。 図２は、スクリプトエンジンが有するＶＭの擬似コードを示す図である。 図３は、実施の形態に係る解析機能付与装置の構成の一例を説明する図である。 図４は、インタプリタループ検出及び仮想プログラムカウンタ検出に用いるテストスクリプト（第一のテストスクリプト）の一例を示す図である。 図５は、分岐ＶＭ命令検出に用いるテストスクリプト（第二のテストスクリプト）の一例を示す図である。 図６は、実行トレースの一例を示す図である。 図７は、ＶＭ実行トレースの一例を示す図である。 図８は、実施の形態に係る解析機能付与処理の処理手順を示すフローチャートである。 図９は、図８に示す実行トレース取得処理の処理手順を示すフローチャートである。 図１０は、図８に示すインタプリタループ検出処理の処理手順を示すフローチャートである。 図１１は、図８に示す仮想プログラムカウンタ検出処理の処理手順を示すフローチャートである。 図１２は、図８に示すデコーダ・ディスパッチャ検出処理の処理手順を示すフローチャートである。 図１３は、図８に示す条件分岐フラグ検出処理の処理手順を示すフローチャートである。 図１４は、図８に示すＶＭ実行トレース取得処理の処理手順を示すフローチャートである。 図１５は、図８に示す分岐ＶＭ命令検出処理の処理手順を示すフローチャートである。 図１６は、図８に示す解析機能付与処理の処理手順を示すフローチャートである。 図１７は、プログラムが実行されることにより、解析機能付与装置が実現されるコンピュータの一例を示す図である。 図１８は、解析妨害の一例を示すコード片を示す図である。
　以下に、本願に係る解析機能付与装置、解析機能付与方法及び解析機能付与プログラムの実施形態を図面に基づいて詳細に説明する。また、本発明は、以下に説明する実施形態により限定されるものではない。
［実施の形態］
　実施の形態に係る解析機能付与装置は、テストスクリプトを用いてスクリプトエンジンのバイナリを解析することにより、インタプリタループと、仮想プログラムカウンタ（ＶＰＣ）と、デコーダ・ディスパッチャと、条件分岐フラグと、ＶＭにおける分岐命令（分岐ＶＭ命令）とを順に検出する。
　なお、これらはいずれも、スクリプトエンジンの構成要素であり、アーキテクチャに関する情報である。図１及び図２を参照して、一般的なスクリプトエンジンの構成とそれらの働きについて説明する。
　図１は、スクリプトエンジンの構成の一例を説明するための図である。図１に示すように、スクリプトエンジン１は、バイトコードコンパイラ２と仮想機械（Virtual　Machine：ＶＭ）３を有する。また、バイトコードコンパイラ２は、構文解析部４、バイトコード生成部５を有する。また、ＶＭ３は、コードキャッシュ部６、フェッチ部７、デコード部８、実行部９を有する。これらのフェッチ部７、デコード部８、実行部９は、繰り返し実行され、インタプリタループと呼ばれる。そして、スクリプトエンジン１は、スクリプトの入力を受け付ける。
　構文解析部４は、スクリプトを入力として受け取り、字句解析及び構文解析を経て、抽象構文木（Abstract　Syntax　Tree：ＡＳＴ）を生成し、バイトコード生成部５に出力する。バイトコード生成部５は、ＡＳＴを入力として受け取り、バイトコードに変換してコードキャッシュ部６に格納する。
　フェッチ部７は、コードキャッシュ部６からＶＭオペコードをフェッチし、デコード部８に出力する。ここで、ＶＭオペコードは、ＶＭ命令のオペコード部を指す。デコード部８は、ＶＭオペコードを入力として受け取り、デコーダ・ディスパッチャを用いてＶＭオペコードを解釈し、対応したプログラムにディスパッチする。実行部９は、ＶＭ命令に対応したプログラムを実行する。インタプリタループの繰り返しにより、ＶＭ命令を次々に実行していくことで、スクリプトに記述した内容が実行される。
　図２を参照して、スクリプトエンジンの構成要素の働きについて説明する。図２は、スクリプトエンジンが有するＶＭの擬似コードを示す図である。図２に示すように、まず、擬似コードは、ＶＰＣを初期化している（１行目）。擬似コードでは、while文のループがインタプリタループである（２行目）。擬似コードでは、コードキャッシュからＶＰＣの指すＶＭオペコードが取得され（３行目）、Switch文を用いてデコード及びディスパッチされる（４、５、７行目）。そして、擬似コードでは、ディスパッチされた先の、ＶＭオペコードに対応したプログラムが実行される（６、８行目）。
　また、分岐ＶＭ命令とはスクリプト内で分岐を発生させるＶＭ命令であり、条件分岐フラグは、条件分岐時に分岐がなされるか否かのフラグを保持する領域である。
［解析機能付与装置］
　まず、本実施の形態に係る解析機能付与装置１０は、悪性のスクリプトエンジンバイナリに対して、分岐命令のフックと、メモリ操作命令のフックにより、ブランチトレースとメモリアクセストレースからなる実行トレースを取得する。ただし、ブランチトレースは、実行された分岐を記録したものであり、メモリアクセストレースは、実行されたメモリの読み書きを記録したものである。
　そして、この解析機能付与装置１０は、この実行トレースを解析し、インタプリタループを検出する。インタプリタループの検出には、実行時の条件を変えて取得した複数の実行トレースの差分を基に解析する差分実行解析と呼ばれる解析手法を適用する。この時、実行時の条件はテストスクリプトに異なるものを用いることで変更する。ここでは、分岐回数に着目した差分実行解析を用いる。ここで得られたインタプリタループの内部が、以降の解析対象となる。
　また、この解析機能付与装置１０は、実行トレースを解析し、ＶＰＣを検出する。解析機能付与装置は、ＶＰＣの検出には、メモリの読み込み回数に着目した差分実行解析を適用する。
　さらに、この解析機能付与装置１０は、スクリプトエンジンのバイナリを静的解析し、デコーダ・ディスパッチャを検出する。前提として、デコーダ・ディスパッチャは、Switch文またはジャンプテーブルや関数テーブルで実現される。こうしたSwitch文、ジャンプテーブル或いは関数テーブルを用いたテーブルジャンプは、静的解析で検出する手法が一般に知られているため、解析機能付与装置１０は、所定の方法でこれらを検出する。
　そして、この解析機能付与装置１０は、実行トレースを解析し、条件分岐フラグを検出する。解析機能付与装置１０は、条件分岐フラグの検出として、メモリの読み込みに着目した差分実行解析を適用する。
　続いて、この解析機能付与装置１０は、スクリプトエンジンバイナリに対して、ＶＰＣの監視と、デコーダ・ディスパッチャのＶＭオペコードの監視により、ＶＭ実行トレースを取得する。ただし、ＶＭ実行トレースは、実行されたＶＭオペコードと、ＶＰＣを記録したものである。
　この解析機能付与装置１０は、このＶＭ実行トレースを解析し、分岐ＶＭ命令を検出する。解析機能付与装置１０は、分岐ＶＭ命令の検出において、まず、多数のテストスクリプトを実行して、ＶＭ実行トレースを取得する。そして、解析機能付与装置１０は、ＶＭ実行トレースから、ＶＭオペコードと、その実行の前後でのＶＰＣの変化量を組にして収集する。ＶＭオペコードが分岐ＶＭ命令以外のものの場合、ＶＰＣの変化量は、ほぼ一定である。一方、ＶＭオペコードが分岐ＶＭ命令のものの場合、ＶＰＣは分岐先によってばらつきが生じる。解析機能付与装置１０は、ＶＭオペコードごとＶＰＣの変化量のばらつきを分散で評価し、分散が一定の閾値以上のものを、分岐ＶＭ命令として検出する。
　そして、解析機能付与装置１０は、ここまでで得られたＶＰＣ、分岐ＶＭ命令、及び、条件分岐フラグに基づいて、スクリプトエンジンのバイナリに対して、フックを施す。このフックによって、解析機能付与装置１０は、ＶＰＣが指す先を監視し、それが分岐ＶＭ命令であるとき、実行状態を分岐させる。そして、解析機能付与装置１０は、一方の実行状態をそのまま実行し、もう一方の実行状態は条件分岐フラグを書き換えた上で実行する。これによって、条件分岐の両方の実行経路が実行されるようになる。以上のようにして、解析機能付与装置１０は、クリプトエンジンへの後付けでのマルチパス機能の付与を実現する。
［解析機能付与装置の構成］
　続いて、図３を参照して、実施の形態に係る解析機能付与装置１０の構成について具体的に説明する。図３は、実施の形態に係る解析機能付与装置の構成の一例を説明する図である。
　図１に示すように、解析機能付与装置１０は、入力部１１、制御部１２、記憶部１３、出力部１４を有する。そして、解析機能付与装置１０は、テストスクリプト及びスクリプトエンジンバイナリの入力を受け付ける。
　入力部１１は、キーボードやマウス等の入力デバイスで構成され、外部からの情報の入力を受け付け、制御部１２に入力する。入力部１１は、テストスクリプト及びスクリプトエンジンバイナリの入力を受け付け、制御部１２に出力する。テストスクリプトは、スクリプトエンジンを動的解析して実行トレース及びＶＭ実行トレースを取得する際に、入力されるスクリプトである。なお、テストスクリプトの詳細は後述する。スクリプトエンジンバイナリは、スクリプトエンジンを構成する実行可能ファイルである。スクリプトエンジンバイナリは、複数の実行可能ファイルによって構成される場合がある。
　制御部１２は、各種の処理手順などを規定したプログラム及び所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する。例えば、制御部１２は、ＣＰＵ（Central　Processing　Unit）やＭＰＵ（Micro　Processing　Unit）などの電子回路である。制御部１２は、仮想機械解析部１２１（第一の解析部）、命令セットアーキテクチャ解析部１２２（第二の解析部）及び解析機能付与部１２３（付与部）を有する。
　仮想機械解析部１２１は、スクリプトエンジンのＶＭを解析する。仮想機械解析部１２１は、実行時の条件を変えて複数の実行トレースを取得し、差分実行解析を用いて複数の実行トレースを解析し、ＶＰＣ及び条件分岐フラグを取得する。仮想機械解析部１２１は、実行トレース取得部１２１１（第一の取得部）、インタプリタループ検出部１２１２（第一の検出部）、仮想プログラムカウンタ検出部１２１３（第二の検出部）、デコーダ・ディスパッチャ検出部１２１４（第三の検出部）及び条件分岐フラグ検出部１２１５（第四の検出部）を有する。
　実行トレース取得部１２１１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け付ける。実行トレース取得部１２１１は、スクリプトエンジンバイナリの実行を監視しながら、テストスクリプトを実行することで、実行トレースを取得する。
　実行トレースは、ブランチトレースとメモリアクセストレースとによって構成される。ブランチトレースは、実行の際の分岐命令の種類と、分岐元アドレスと分岐先アドレスを記録する。メモリアクセストレースは、メモリ操作の種類と、操作対象のメモリアドレスを記録する。ブランチトレース及びメモリアクセストレースは、命令フックによって取得可能であることが知られている。実行トレース取得部１２１１が取得した実行トレースは、実行トレースＤＢ１３１に格納される。
　インタプリタループ検出部１２１２は、実行トレースＤＢ１３１に格納された第一のテストスクリプトに対する実行トレースを取り出して解析し、インタプリタループを検出する。インタプリタループ検出部１２１２は、各ＶＭ命令の実行後には、必ずインタプリタループの先頭を分岐先とする分岐が発生することを利用し、この分岐先を発見することで、インタプリタループを検出する。
　このため、インタプリタループ検出部１２１２は、インタプリタループの検出には、分岐の回数に着目した差分実行解析を用いる。インタプリタループ検出部１２１２は、繰り返し回数及び繰り返される文の数が異なる繰り返しを持った複数のテストスクリプトの実行トレースを比較し、分岐回数が繰り返し回数及び繰り返される文の数の両方に比例している分岐先を発見する。インタプリタループ検出部１２１２は、この分岐先をインタプリタループの先頭として検出する。
　仮想プログラムカウンタ検出部１２１３は、実行トレースＤＢ１３１に格納された第一のテストスクリプトに対する実行トレースを取り出して解析し、ＶＰＣを検出する。仮想プログラムカウンタ検出部１２１３は、各ＶＭ命令の実行後には、必ずＶＰＣを保持するメモリへの読み込みが発生することを利用し、この読み込み先を発見することで、ＶＰＣを検出する。
　このため、仮想プログラムカウンタ検出部１２１３は、ＶＰＣの検出として、メモリの読み込み回数に着目した差分実行解析を用いる。仮想プログラムカウンタ検出部１２１３は、インタプリタループの検出と同じテストスクリプトを用いて取得された複数のテストスクリプトの実行トレースを比較し、メモリ読み込み回数が繰り返される回数及び繰り返される文の数との両方に比例しているメモリを発見する。仮想プログラムカウンタ検出部１２１３は、このメモリをＶＰＣとして検出する。
　デコーダ・ディスパッチャ検出部１２１４は、スクリプトエンジンバイナリに対して、所定の静的解析により、インタプリタループ内に存在するSwitch文や関数テーブル、ジャンプテーブルを検出する。デコーダ・ディスパッチャ検出部１２１４は、これらの処理の命令列をデコーダ・ディスパッチャとして検出する。
　条件分岐フラグ検出部１２１５は、実行トレースＤＢ１３１に格納された第二のテストスクリプトに対する実行トレースを取り出して解析し、条件分岐フラグを発見する。条件分岐フラグ検出部１２１５は、メモリの読み込み回数に着目した差分実行解析を用いて、複数の実行トレースを解析し、条件分岐フラグを検出する。条件分岐フラグ検出部１２１５は、様々なパターンで条件分岐を実行し、その際のメモリの変化のパターンをテストスクリプト上の条件分岐のパターンと照らし合わせることで、条件分岐フラグを格納するメモリを検出する。
　命令セットアーキテクチャ解析部１２２は、ＶＭの命令の体系である命令セットアーキテクチャを解析する。命令セットアーキテクチャ解析部１２２は、ＶＭ実行トレース取得部１２２１（第二の取得部）及び分岐ＶＭ命令検出部１２２２（第五の検出部）を有する。
　ＶＭ実行トレース取得部１２２１は、実行トレース取得部１２１１と同じく、テストスクリプト及びスクリプトエンジンバイナリを入力として受け付ける。ＶＭ実行トレース取得部１２２１は、スクリプトエンジンバイナリの実行を監視しながら、テストスクリプトを実行することで、ＶＭ上で実行された実行トレースであるＶＭ実行トレースを取得する。
　ＶＭ実行トレースは、実行されたＶＭ命令ごとのＶＰＣとＶＭオペコードで構成される。ＶＰＣの記録は、仮想プログラムカウンタ検出部１２１３で検出されたＶＰＣのメモリを監視することで実現できる。ＶＭオペコードの記録は、デコーダ・ディスパッチャ検出部１２１４で検出されたデコーダに入力されるＶＭオペコードを監視することで実現できる。ＶＭ実行トレース取得部１２２１は、取得したＶＭ実行トレースは、ＶＭ実行トレースＤＢ１３３に格納される。
　分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースＤＢ１３３に格納されたＶＭ実行トレースを取り出して解析し、分岐ＶＭ命令を検出する。分岐ＶＭ命令検出部１２２２は、分岐ＶＭ命令とそれ以外のＶＭ命令とではＶＰＣの値のばらつきの大きさが異なることに着目し、閾値を決めて、よりＶＰＣの値のばらつきの大きいものを分岐ＶＭ命令として検出する。分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースのＶＭオペコードごとの仮想プログラムカウンタの変化量のばらつきによって、分岐ＶＭ命令を検出する。
　解析機能付与部１２３は、仮想機械解析部１２１及び命令セットアーキテクチャ解析部１２２による解析によって得られたアーキテクチャ情報に基づいて、スクリプトエンジンに、マルチパス実行機能を付与するフックを施す。解析機能付与部１２３は、得られたＶＰＣ、分岐ＶＭ命令及び条件分岐フラグを用いてスクリプトエンジンにフックを施す。このフックは、ＶＰＣを監視してＶＭオペコードを確認し、分岐ＶＭ命令のＶＭオペコードであれば、実行状態を分岐させるフックである。そして、このフックは、一方の実行状態はそのまま実行し、もう一方の実行状態は条件分岐フラグを書き換えて実行することで、スクリプトエンジンにマルチパス実行機能を付与するフックである。
　記憶部１３は、ＲＡＭ（Random　Access　Memory）、フラッシュメモリ（Flash　Memory）等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現され、解析機能付与装置１０を動作させる処理プログラムや、処理プログラムの実行中に使用されるデータなどが記憶される。記憶部１３は、実行トレースデータベース（ＤＢ）１３１、ＶＭ実行トレースＤＢ１３３及びアーキテクチャ情報ＤＢ１３２を有する。
　実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３は、それぞれ実行トレース取得部１２１１及びＶＭ実行トレース取得部１２２１によって取得された実行トレース及びＶＭ実行トレースを格納する。実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３は、解析機能付与装置１０によって管理される。もちろん、実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３は、他の装置（サーバ等）によって管理されていてもよく、この場合には、実行トレース取得部１２１１及びＶＭ実行トレース取得部１２２１は、出力部１４の通信インタフェースを介して、取得した実行トレース及びＶＭ実行トレースを、実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３の管理サーバ等に出力して、実行トレースＤＢ１３１及びＶＭ実行トレースＤＢ１３３に記憶させる。
　出力部１４は、例えば、液晶ディスプレイやプリンタ等であって、解析機能付与装置１０に関する情報を含む各種情報を出力する。また、出力部１４は、外部装置との間で、各種データの入出力を司るインタフェースであってもよく、外部装置に各種情報を出力してもよい。
［テストスクリプトの構成］
　テストスクリプトについて説明する。テストスクリプトは、スクリプトエンジンを動的解析する際に入力されるスクリプトである。このテストスクリプトは、分岐命令の実行やメモリ読み書きの回数に着目し、異なる回数のテストスクリプトを実行したときに生じるスクリプトエンジンの挙動の差分を捉えるために用いられる。このテストスクリプトは、解析の事前に準備するものであり、手動で作成するものである。この作成には、対象のスクリプト言語の仕様に関する知識が必要となる。
　図４は、インタプリタループの検出及びＶＰＣの検出に用いるテストスクリプト（第一のテストスクリプト）の一例を示す図である。第一のテストスクリプトでは、繰り返し処理を用いる（２行目）。第一のテストスクリプトでは、テストスクリプト内の繰り返し回数（２行目）や繰り返される文の数（３行目から５行目）を増減させることで、実行時の条件を変更し、差分を発生させる。
　図５は、分岐ＶＭ命令検出に用いるテストスクリプト（第二のテストスクリプト）の一例を示す図である。第二のテストスクリプトでは、複数回の条件分岐を用いる（４行目から８行目）。第二のテストスクリプトにおいて、この複数回の条件分岐では、特定の順序のパターンで分岐がなされたり、なされなかったりするように、分岐条件を制御する（１行目、５行目）。第二のテストスクリプトでは、条件分岐の回数や、分岐の成否の順序パターンを変更し、差分を発生させる。
［実行トレースの構成］
　次に、実行トレースについて説明する。図６は、実行トレースの一例を示す図である。実行トレースは、前述の通り、ブランチトレースとメモリアクセストレースによって構成されている。図６は、実行トレースの一例を示す図である。以降、図６を用いて実行トレースの構成を示す。
　実行トレースは、traceという要素を有する。traceには、そのログ行がブランチトレースか、メモリアクセストレースかが示される。
　ブランチトレースのログ行は、例えば、図６の１行目から１０行目に記載の書式になっており、type、src、dstの三つの要素からなる。typeは、実行された分岐命令がcall命令によるものか、jmp命令によるものか、ret命令によるものかを示す。また、srcは、分岐元のアドレスを示し、dstは、分岐先のアドレスを示す。
　メモリアクセストレースのログ行は、たとえば、図６の１１行目から１３行目に記載の書式になっており、type、target、valueの三つの要素からなる。typeは、メモリアクセスが読み込みか書き込みかを示す。targetは、メモリアクセスの対象となるメモリアドレスを示す。また、valueには、メモリアクセスの結果の値が格納される。
［ＶＭ実行トレースの構成］
　次に、ＶＭ実行トレースについて説明する。図７は、ＶＭ実行トレースの一例を示す図である。ＶＭ実行トレースは、前述の通り、ＶＭオペコードとＶＰＣとを記録したものである。図７は、ＶＭ実行トレースの一部を切り出したものである。以降、図７を用いてＶＭ実行トレースの構成を示す。
　ＶＭ実行トレースのログ行は、たとえば、図７に記載の書式になっており、vpc及びopcodeの二つの要素からなる。vpcは、ＶＰＣの値を示す。また、opcodeは、ＶＭオペコードの値を示す。
［インタプリタループ検出部の処理］
　次に、インタプリタループ検出部１２１２の処理について説明する。インタプリタループの検出は、取得した実行トレースのブランチトレースのログを解析することで実現される。インタプリタループでは一般に、ＶＭ命令の実行後に分岐命令でループの先頭に飛ぶ。このため、インタプリタループ検出部１２１２は、ブランチトレース中の分岐命令の分岐先アドレスの中から、インタプリタループの先頭に該当するものを検出する。インタプリタループ検出部１２１２は、分岐回数に着目した差分実行解析を用いる。
　インタプリタループ検出部１２１２は、第一のテストスクリプトに対応した実行トレースを用いる。インタプリタループの先頭への分岐の回数は、テストスクリプト内の繰り返し回数及び、繰り返し処理の中の文の数に比例する。繰り返しの回数をＮ、繰り返される文の数をＭとしたとき、概ねＭＮ程度のインタプリタループの先頭への分岐が発生する。このため、インタプリタループ検出部１２１２は、Ｎ及びＭをそれぞれ２Ｎと２Ｍ、３Ｎと３Ｍと増やした第一のテストスクリプトに対する実行トレースにおいて、４ＭＮ、９ＭＮという増え方をした分岐先を、インタプリタループの先頭として検出する。
［仮想プログラムカウンタ検出部の処理］
　次に、仮想プログラムカウンタ検出部１２１３の処理について説明する。仮想プログラムカウンタの検出は、取得した実行トレースのメモリアクセストレースのログを解析することで実現される。ＶＰＣは一般にメモリ上に格納されており、ＶＭ命令が実行されるたびに読み込まれるため、このメモリアドレスへの値の読み込みが発生する。このため、仮想プログラムカウンタ検出部１２１３は、メモリアクセストレース中のメモリ読み込みの対象アドレスの中から、ＶＰＣに該当するものを検出する。仮想プログラムカウンタ検出部１２１３は、メモリの読み込み回数に着目した差分実行解析を用いる。
　仮想プログラムカウンタ検出部１２１３は、第一のテストスクリプトに対応した実行トレースを用いる。ＶＰＣの読み込みの回数は、テストスクリプト内の繰り返し回数及び、繰り返し処理の中の文の数に比例する。繰り返しの回数をＮ、繰り返される文の数をＭとしたとき、概ねＭＮ程度のＶＰＣの読み込みが発生する。このため、インタプリタループ検出部１２１２は、Ｎ及びＭをそれぞれ２Ｎと２Ｍ、３Ｎと３Ｍと増やした第一のテストスクリプトに対する実行トレースにおいて、４ＭＮ、９ＭＮという増え方をしたメモリを、ＶＰＣとして検出する。
［デコーダ・ディスパッチャ検出部の処理］
　次に、デコーダ・ディスパッチャ検出部１２１４の処理について説明する。デコーダ・ディスパッチャ検出部１２１４は、スクリプトエンジンのバイナリを所定の手法で静的解析することで、デコーダ・ディスパッチャを検出する。
　デコーダ・ディスパッチャの実装には一般に、二つの種類が存在する。デコーダ・ディスパッチャの実装の一つ目の種類は、Switch文を用いた実装であり、二つ目の種類は、関数テーブルやジャンプテーブルを用いたテーブルジャンプによる実装である。Switch文及びテーブルジャンプの認識は、既存の静的解析の手法で実現できることが一般に知られている。このため、デコーダ・ディスパッチャ検出部１２１４は、所定の静的解析の手法で検出されたSwitch文及びテーブルジャンプのうち、インタプリタループ内に存在するものを、デコーダ・ディスパッチャとして検出する。
［条件分岐フラグ検出部の処理］
　次に、条件分岐フラグ検出部１２１５の処理について説明する。条件分岐フラグ検出部１２１５は、インタプリタループ内でのメモリアクセスを解析することで、条件分岐フラグを検出する。
　条件分岐フラグ検出部１２１５は、第二のテストスクリプトを用いて得られた実行トレースを用いる。条件分岐フラグ検出部１２１５は、インタプリタループ内でのメモリアクセスから、二段階の絞り込みをすることで、条件分岐フラグを検出する。条件分岐フラグには、分岐がなされるか、なされないかの二つの状態がある。また、条件分岐フラグは、条件分岐の回数に比例した回数、読み込まれると考えられる。
　このことから、条件分岐フラグ検出部１２１５は、一段階目の絞り込みとして、条件分岐の回数に比例した回数のメモリ読み込みがあるメモリを抽出する。そして、条件分岐フラグ検出部１２１５は、二段階目の絞り込みとして、各メモリ読み込み時の値が、テストスクリプトの条件分岐と対応付くように二つの値を行き来しているメモリを抽出する。
　例えば、条件分岐フラグが、分岐がなされる場合をＸ、なされない場合をＹで保持している場合、図５の第二のテストスクリプトでは、条件分岐の順序のパターンはなされる、なされない、なされる、なされる、なされないとなる。このため、条件分岐フラグ検出部１２１５は、Ｘ、Ｙ、Ｘ、Ｘ、Ｙと二つの値を行き来しているメモリアドレスを抽出する。条件分岐フラグ検出部１２１５は、これを分岐の回数を変更しながら繰り返すことにより、条件分岐フラグを検出する。
［分岐ＶＭ命令検出部の処理］
　次に、分岐ＶＭ命令検出部１２２２の処理について説明する。分岐ＶＭ命令検出部１２２２は、取得したＶＭ実行トレースのログを解析することで分岐ＶＭ命令を検出する。ここでのテストスクリプトは、分岐ＶＭ命令が含まれていればよいため、分岐の制御構文を含むスクリプトでありさえすればどのようなものでもよい。例えば、インターネット上から収集したり、公式ドキュメントから取得したりしてテストスクリプトを準備する。
　まず、分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースから、ＶＭ命令のオペコードと、命令の実行前後でのＶＰＣのオフセットとを、組として取得する。このオフセットｏは、命令の実行前のＶＰＣの値をｐｐｒｅｖ、実行後の値をｐｎｅｘｔとして、ｏ＝ｐｎｅｘｔ－ｐｐｒｅｖで算出される。
　ここで、あるＶＭ命令が分岐命令のとき、このオフセットは、分岐先に依存して変化する。一方、分岐命令以外のときは、オフセットは、ＶＭ命令のサイズに依存して変化する。このため、ＶＭ命令のオペコードとオフセットとの組を収集し、オペコードごとにオフセットの値を見たとき、分岐命令であれば分岐先によって様々な値にばらつき、分岐命令以外であればＶＭ命令のサイズという特定の値に集中する。
　したがって、分岐ＶＭ命令検出部１２２２は、このオフセットのばらつきを評価するため、分散ｓを用いる。あるオペコードに対するオフセットの集合ＯをＯ＝｛ｏ０，ｏ１，・・・，ｏＮ｝（オフセットｏの平均は（１）式を参照）とし、ｔを閾値としたとき、分岐命令か否かは、分散ｓ（（２）式を参照）を基に、（３）式のように判定される。これによって、分岐ＶＭ命令検出部１２２２は、分岐ＶＭ命令を検出する。
Figure JPOXMLDOC01-appb-M000001
Figure JPOXMLDOC01-appb-M000002
Figure JPOXMLDOC01-appb-M000003
　なお、分岐以外のＶＭ命令では、ばらつきがほとんど見られず、分岐ＶＭ命令とそれ以外のＶＭ命令との境界は明確であることが多い。このため、閾値として、例えば、得られた分散の値を数直線上にプロットして、できた二つの群を分割可能な値が、設定される。
［解析機能付与部の処理］
　次に、解析機能付与部１２３の処理を説明する。解析機能付与部１２３は、スクリプトエンジンバイナリと、ここまでの処理で検出されたフックポイント及びタップポイントを入力として受け付ける。解析機能付与部１２３は、スクリプトエンジンに対して、フックポイントでのフックを施す。
　ここで、解析機能付与部１２３は、フック時に、フックに対応した言語要素が実行され、その引数としてのタップポイントのメモリがログ出力されるように、解析用のコードを挿入する。この解析用のコードは、フックポイントとタップポイントとが判明していれば、容易に生成できる。これによって、スクリプトが実行された際に、その挙動がログ出力されるようになり、解析機能の付与が実現される。
　このフックによる解析機能の付与は、スクリプトエンジンバイナリに対するバイナリを直接書き換えて実現してもよく、バイナリが実行されてプロセスメモリ上に展開された際にメモリイメージを書き換えて実現してもよい。
［解析機能付与装置の処理手順］
　次に、解析機能付与装置１０による解析機能付与処理の処理手順について説明する。図８は、実施の形態に係る解析機能付与処理の処理手順を示すフローチャートである。
　まず、入力部１１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け取る（ステップＳ１）。
　そして、実行トレース取得部１２１１は、スクリプトエンジンのバイナリを監視しながらテストスクリプトを実行してブランチトレースとメモリアクセストレースを取得する実行トレース取得処理を行う（ステップＳ２）。そして、インタプリタループ検出部１２１２は、実行トレースＤＢ１３１に格納された第一のテストスクリプトに対する実行トレースを取り出して解析し、インタプリタループを発見するインタプリタループ検出処理を行う（ステップＳ３）。
　仮想プログラムカウンタ検出部１２１３は、実行トレースＤＢ１３１に格納された第一のテストスクリプトに対する実行トレースを取り出して解析し、ＶＰＣを発見する仮想プログラムカウンタ検出処理を行う（ステップＳ４）。デコーダ・ディスパッチャ検出部１２１４は、スクリプトエンジンバイナリに対して、所定の静的解析により、インタプリタループ内に存在するSwitch文や関数テーブル、ジャンプテーブルを検出するデコーダ・ディスパッチャ検出処理を行う（ステップＳ５）。条件分岐フラグ検出部１２１５は、実行トレースＤＢ１３１に格納された第二のテストスクリプトに対する実行トレースを取り出して解析し、条件分岐フラグを発見する条件分岐検出処理を行う（ステップＳ６）。
　ＶＭ実行トレース取得部１２２１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け付け、スクリプトエンジンバイナリの実行を監視しながら、テストスクリプトを実行することで、ＶＭ実行トレースを取得するＶＭ実行トレース取得処理を行う（ステップＳ７）。分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースＤＢ１３３に格納されたＶＭ実行トレースを取り出して解析し、分岐ＶＭ命令を検出する分岐ＶＭ命令検出処理を行う（ステップＳ８）。
　解析機能付与部１２３は、得られたＶＰＣ、分岐ＶＭ命令及び条件分岐フラグを用いてスクリプトエンジンにフックを施す解析機能付与処理を行う（ステップＳ９）。そして、出力部１４は、マルチパス実行機能が付与されたスクリプトエンジンバイナリを出力する（ステップＳ１０）。
［実行トレース取得処理の処理手順］
　次に、図９に示す実行トレース取得処理の流れについて説明する。図９は、図８に示す実行トレース取得処理の処理手順を示すフローチャートである。
　まず、実行トレース取得部１２１１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け取る（ステップＳ１１）。そして、実行トレース取得部１２１１は、受け取ったスクリプトエンジンに対して、ブランチトレースを取得するためのフックを施す（ステップＳ１２）。また、実行トレース取得部１２１１は、受け取ったスクリプトエンジンに対して、メモリアクセストレースを取得するためのフックも施す（ステップＳ１３）。
　そして、実行トレース取得部１２１１は、その状態で受け取ったテストスクリプトをスクリプトエンジンに入力して実行させ（ステップＳ１４）、それによって取得される実行トレースを実行トレースＤＢ１３１に格納する（ステップＳ１５）。
　実行トレース取得部１２１１は、入力されたテストスクリプトを全て実行し終えているか否かを判定する（ステップＳ１６）。実行トレース取得部１２１１は、入力されたテストスクリプトを全て実行し終えている場合（ステップＳ１６：Ｙｅｓ）、処理を終了する。これに対し、実行トレース取得部１２１１は、入力されたテストスクリプトを全て実行していない場合（ステップＳ１６：Ｎｏ）、ステップＳ１４のテストスクリプトの実行に戻って処理を続ける。
［インタプリタループ検出処理の処理手順］
　次に、図８に示すインタプリタループ検出処理の流れについて説明する。図１０は、図８に示すインタプリタループ検出処理の処理手順を示すフローチャートである。
　まず、インタプリタループ検出部１２１２は、実行トレースＤＢ１３１から第一のテストスクリプトによる実行トレースを一つ取り出す（ステップＳ２１）。そして、インタプリタループ検出部１２１２は、実行トレースのうちのブランチトレースに着目し、分岐先ごとに分岐回数を数え上げる（ステップＳ２２）。続いて、インタプリタループ検出部１２１２は、実行トレースの取得に用いた第一のテストスクリプトを入力として受け取り（ステップＳ２３）、それを解析して繰り返しの回数と繰り返される文の数を取得する（ステップＳ２４）。
　インタプリタループ検出部１２１２は、実行トレースＤＢ１３１から、繰り返し回数や繰り返される文の数の異なる第一のテストスクリプトによる実行トレースを、さらに一つ取り出す（ステップＳ２５）。そして、インタプリタループ検出部１２１２は、ブランチトレースに着目し、分岐先ごとに分岐回数を数え上げる（ステップＳ２６）。また、インタプリタループ検出部１２１２は、実行トレースの取得に用いた第一のテストスクリプトを入力として受け取り（ステップＳ２７）、テストスクリプトを解析して繰り返しの回数と繰り返される文の数を取得する（ステップＳ２８）。
　そして、インタプリタループ検出部１２１２は、繰り返し回数や繰り返される文の増減に比例して分岐回数が変化する分岐先のみに絞り込む（ステップＳ２９）。インタプリタループ検出部１２１２は、分岐先を一つのみに絞り込めたか否かを判定する（ステップＳ３０）。
　インタプリタループ検出部１２１２は、分岐先を一つのみに絞り込めていない場合（ステップＳ３０：Ｎｏ）、ステップＳ２５に戻り、次の実行トレースを一つ取り出して処理を継続する。一方、インタプリタループ検出部１２１２は、分岐先を一つのみに絞り込めた場合（ステップＳ３０：Ｙｅｓ）、絞り込まれた分岐先をインタプリタループの先頭としてアーキテクチャ情報ＤＢ１３２に格納して（ステップＳ３１）、処理を終了する。
［仮想プログラムカウンタ検出処理の処理手順］
　次に、図８に示す仮想プログラムカウンタ検出処理の流れについて説明する。図１１は、図８に示す仮想プログラムカウンタ検出処理の処理手順を示すフローチャートである。
　まず、仮想プログラムカウンタ検出部１２１３は、実行トレースＤＢ１３１から第一のテストスクリプトによる実行トレースを一つ取り出す（ステップＳ４１）。続いて、仮想プログラムカウンタ検出部１２１３は、実行トレースのうちのメモリアクセストレースに着目し、メモリ読み込み先ごとに読み込み回数を数え上げる（ステップＳ４２）。
　仮想プログラムカウンタ検出部１２１３は、実行トレースの取得に用いた第一のテストスクリプトを入力として受け取り（ステップＳ４３）、その第一のテストスクリプトを解析して繰り返しの回数と繰り返される文の数とを取得する（ステップＳ４４）。
　続いて、仮想プログラムカウンタ検出部１２１３は、実行トレースＤＢ１３１から、繰り返し回数や繰り返される文の数の異なる第一のテストスクリプトによる実行トレースを、さらに一つ取り出す（ステップＳ４５）。そして、仮想プログラムカウンタ検出部１２１３は、メモリアクセストレースに着目し、メモリ読み込み先ごとに読み込み回数を数え上げる（ステップＳ４６）。また、仮想プログラムカウンタ検出部１２１３は、実行トレースの取得に用いた第一のテストスクリプトを入力として受け取り（ステップＳ４７）、テストスクリプトを解析して繰り返しの回数と繰り返される文の数を取得する（ステップＳ４８）。
　ここで、仮想プログラムカウンタ検出部１２１３は、繰り返し回数や繰り返される文の増減に比例して読み込み回数が変化するメモリ読み込み先のみに絞り込む（ステップＳ４９）。
　そして、仮想プログラムカウンタ検出部１２１３は、メモリ読み込み先を一つのみに絞り込めたか否かを判定する（ステップＳ５０）。仮想プログラムカウンタ検出部１２１３は、メモリ読み込み先を一つのみに絞り込めていない場合（ステップＳ５０：Ｎｏ）、ステップＳ４５に戻り、次の実行トレースを一つ取り出して処理を継続する。一方、仮想プログラムカウンタ検出部１２１３は、メモリ読み込み先を一つのみに絞り込めた場合（ステップＳ５０：Ｙｅｓ）、絞り込まれたメモリ読み込み先を仮想プログラムカウンタとしてアーキテクチャ情報ＤＢ１３２に格納して（ステップＳ５１）、処理を終了する。
［デコーダ・ディスパッチャ検出処理の処理手順］
　次に、図８に示すデコーダ・ディスパッチャ検出処理の流れについて説明する。図１２は、図８に示すデコーダ・ディスパッチャ検出処理の処理手順を示すフローチャートである。
　まず、デコーダ・ディスパッチャ検出部１２１４は、スクリプトエンジンバイナリを入力として受け取る（ステップＳ６１）。そして、デコーダ・ディスパッチャ検出部１２１４はアーキテクチャ情報ＤＢ１３２から、インタプリタループの情報を取り出す（ステップＳ６２）。
　続いて、デコーダ・ディスパッチャ検出部１２１４は、インタプリタループ内のSwitch文及びテーブルジャンプを、所定の静的解析で検出する（ステップＳ６３）。デコーダ・ディスパッチャ検出部１２１４は、検出されたSwitch文またはテーブルジャンプをデコーダ・ディスパッチャとして、アーキテクチャ情報ＤＢ１３２に格納し（ステップＳ６４）、処理を終了する。
［条件分岐フラグ検出処理の処理手順］
　次に、図８に示す条件分岐フラグ検出処理の流れについて説明する。図１３は、図８に示す条件分岐フラグ検出処理の処理手順を示すフローチャートである。
　まず、条件分岐フラグ検出部１２１５は、実行トレースＤＢ１３１から第二のテストスクリプトによる実行トレースを一つ取り出す（ステップＳ７１）。そして、条件分岐フラグ検出部１２１５は、メモリアクセストレースに着目し、メモリ読み込み先ごとに読み込み回数を数え上げる（ステップＳ７２）。
　また、条件分岐フラグ検出部１２１５は、実行トレースの取得に用いた第二のテストスクリプトを、入力として受け取り（ステップＳ７３）、この第二のテストスクリプトを解析して、条件分岐の回数とTrue／Falseの順序パターンを取得する（ステップＳ７４）。そして、条件分岐フラグ検出部１２１５は、条件分岐の回数に比例して読み込み回数が変化するメモリ読み込み先のみに絞り込む（ステップＳ７５）。さらに、条件分岐フラグ検出部１２１５は、読み込んだメモリの値がTrue／Falseの順序パターンに合わせて二つの値を行き来しているメモリ読み込み先のみに絞り込む（ステップＳ７６）。
　条件分岐フラグ検出部１２１５は、メモリ読み込み先を一つのみに絞り込めたか否かを判定する（ステップＳ７７）。条件分岐フラグ検出部１２１５は、メモリ読み込み先を一つのみに絞り込めていない場合（ステップＳ７７：Ｎｏ）、ステップＳ７１に戻り、次の実行トレースを一つ取り出して処理を継続する。一方、条件分岐フラグ検出部１２１５は、メモリ読み込み先を一つのみに絞り込めた場合（ステップＳ７７：Ｙｅｓ）、絞り込まれた読み込み先を仮想プログラムカウンタとしてアーキテクチャ情報ＤＢ１３２に格納し（ステップＳ７８）、処理を終了する。
［ＶＭ実行トレース取得処理の処理手順］
　次に、図８に示すＶＭ実行トレース取得処理の流れについて説明する。図１４は、図８に示すＶＭ実行トレース取得処理の処理手順を示すフローチャートである。
　まず、ＶＭ実行トレース取得部１２２１は、テストスクリプト及びスクリプトエンジンバイナリを入力として受け取る（ステップＳ８１）。そして、ＶＭ実行トレース取得部１２２１は、受け取ったスクリプトエンジンに対して、ＶＰＣ及びＶＭオペコードを記録するためのフックを施す（ステップＳ８２）。
　ＶＭ実行トレース取得部１２２１は、その状態で受け取ったテストスクリプトをスクリプトエンジンに入力して実行させ（ステップＳ８３）、それによって取得されるＶＭ実行トレースをＶＭ実行トレースＤＢ１３３に格納する（ステップＳ８４）。
　ＶＭ実行トレース取得部１２２１は、入力されたテストスクリプトを全て実行したか否かを判定する（ステップＳ８５）。ＶＭ実行トレース取得部１２２１は、入力されたテストスクリプトを全て実行し終えている場合（ステップＳ８５：Ｙｅｓ）、処理を終了する。ＶＭ実行トレース取得部１２２１は、入力されたテストスクリプトを全て実行し終えていない場合（ステップＳ８５：Ｎｏ）、ステップＳ８３のテストスクリプトの実行に戻って処理を続ける。
［分岐ＶＭ命令検出処理の処理手順］
　次に、図８に示す分岐ＶＭ命令検出処理の流れについて説明する。図１５は、図８に示す分岐ＶＭ命令検出処理の処理手順を示すフローチャートである。
　まず、分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースＤＢ１３３から、ＶＭ実行トレースを一つ取り出す（ステップＳ９１）。そして、分岐ＶＭ命令検出部１２２２は、ＶＭオペコードごとに、実行の前後でのＶＰＣの変化量を集計する（ステップＳ９２）。
　分岐ＶＭ命令検出部１２２２は、ＶＭ実行トレースＤＢ１３３の全てのＶＭ実行トレースを処理し終えたか否かを判定する（ステップＳ９３）。ＶＭ実行トレースＤＢ１３３の全てのＶＭ実行トレースを処理し終えていない場合（ステップＳ９３：Ｎｏ）、分岐ＶＭ命令検出部１２２２は、ステップＳ９１に戻り、次のＶＭ実行トレースを一つ取り出して処理する。
　ＶＭ実行トレースＤＢ１３３の全てのＶＭ実行トレースを処理し終えている場合（ステップＳ９３：Ｙｅｓ）、分岐ＶＭ命令検出部１２２２は、ＶＭオペコードごとにＶＰＣの変化量の分散を算出する（ステップＳ９４）。そして、分岐ＶＭ命令検出部１２２２は、閾値を入力として受け取る（ステップＳ９５）。分岐ＶＭ命令検出部１２２２は、分散が閾値よりも大きいＶＭオペコードのみに絞り込み（ステップＳ９６）、それらを分岐ＶＭ命令としてアーキテクチャ情報ＤＢ１３２に格納して（ステップＳ９７）、処理を終了する。
［解析機能付与処理の処理手順］
　次に、図８に示す解析機能付与処理の流れについて説明する。図１５は、図８に示す解析機能付与処理の処理手順を示すフローチャートである。
　まず、解析機能付与部１２３は、スクリプトエンジンバイナリを入力として受け取る（ステップＳ１０１）。そして、解析機能付与部１２３はアーキテクチャ情報ＤＢ１３２からＶＰＣ、条件分岐フラグ、条件分岐ＶＭ命令を取り出す（ステップＳ１０２）。続いて、解析機能付与部１２３は、スクリプトエンジンのフックポイントにフックを施す（ステップＳ１０３）。解析機能付与部１２３は、このフック時に、マルチパス実行用コードが実行されるよう、コードを生成してスクリプトエンジンに挿入する（ステップＳ１０４）。解析機能付与部１２３は、こうして得られたフックの施されたスクリプトエンジンを、マルチパス実行機能付きのスクリプトエンジンとして出力し（ステップＳ１０５）、処理を終了する。
［実施の形態の効果］
　このように、本実施の形態に係る解析機能付与装置１０は、スクリプトエンジンのＶＭを解析し、ＶＭの命令の体系である命令セットアーキテクチャを解析し、これらの解析によって得られたアーキテクチャ情報に基づいてスクリプトエンジンに、マルチパス実行機能を付与するフックを施す。
　具体的には、解析機能付与装置１０は、スクリプトエンジンのバイナリを監視しながらテストスクリプトを実行してブランチトレースとメモリアクセストレースを取得する。そして、解析機能付与装置１０は、その実行トレースに基づいて仮想機械を解析し、インタプリタループ、ＶＰＣ、デコーダ・ディスパッチャ、条件分岐フラグのアーキテクチャ情報を取得する。さらに、解析機能付与装置１０は、テストスクリプトを実行してＶＭ実行トレースを取得し、そのＶＭ実行トレースを用いて命令セットアーキテクチャを解析して分岐ＶＭ命令をアーキテクチャ情報として取得する。その後、解析機能付与装置１０は、得られたアーキテクチャ情報を基にスクリプトエンジンにマルチパス実行機能を付与する。
　これによって、解析機能付与装置１０は、バイナリのみしか手に入らないプロプライエタリなスクリプトエンジンに対しても、実行トレース及びＶＭ実行トレースの取得に基づく解析により各種アーキテクチャ情報を検出し、人手でのリバースエンジニアリングを要することなく、マルチパス実行機能の付与を実現できる。
　また、解析機能付与装置１０は、多様なスクリプトエンジンに対して、テストスクリプトさえ用意すれば自動でマルチパス実行機能を付与できるため、個別の設計や実行をようすることなく、マルチパス実行機能の付与を実現できる。
　さらに、解析機能付与装置１０は、条件分岐などの詳細なアーキテクチャを考慮しているため、スクリプトの条件分岐に対して正確なマルチパス実行機能の付与を実現できる。
　このように、解析機能付与装置１０によれば、スクリプトエンジンを解析し、マルチパス実行機能を後付けで付与することにより、多種多様なスクリプト言語のスクリプトエンジンに対して、マルチパス実行機能の自動的な付与を実現できる。
　上述したように、解析機能付与装置１０は、多種多様なスクリプト言語で記述される悪性スクリプトの挙動の解析に有用であり、特定の条件を満たさなければ実行されない経路を持った悪性スクリプトに対して、その影響を受けずに、挙動を網羅的に解析することに適している。したがって、本実施の形態を用いて、様々なスクリプトエンジンにマルチパス実行機能を付与することによって、悪性スクリプトの挙動を解析して検知などの対策に生かすことが可能である。
［実施形態のシステム構成について］
　図３に示す解析機能付与装置１０の各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、解析機能付与装置１０の機能の分散及び統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散または統合して構成することができる。
　また、解析機能付与装置１０においておこなわれる各処理は、全部または任意の一部が、ＣＰＵ及びＣＰＵにより解析実行されるプログラムにて実現されてもよい。また、解析機能付与装置１０においておこなわれる各処理は、ワイヤードロジックによるハードウェアとして実現されてもよい。
　また、実施の形態において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的に行うこともできる。もしくは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述及び図示の処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて適宜変更することができる。
［プログラム］
　図１７は、プログラムが実行されることにより、解析機能付与装置１０が実現されるコンピュータの一例を示す図である。コンピュータ１０００は、例えば、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０、ネットワークインタフェース１０７０を有する。これらの各部は、バス１０８０によって接続される。
　メモリ１０１０は、ＲＯＭ１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic　Input　Output　System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブ１１００に挿入される。シリアルポートインタフェース１０５０は、例えばマウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えばディスプレイ１１３０に接続される。
　ハードディスクドライブ１０９０は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、解析機能付与装置１０の各処理を規定するプログラムは、コンピュータ１０００により実行可能なコードが記述されたプログラムモジュール１０９３として実装される。プログラムモジュール１０９３は、例えばハードディスクドライブ１０９０に記憶される。例えば、解析機能付与装置１０における機能構成と同様の処理を実行するためのプログラムモジュール１０９３が、ハードディスクドライブ１０９０に記憶される。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid　State　Drive）により代替されてもよい。
　また、上述した実施の形態の処理で用いられる設定データは、プログラムデータ１０９４として、例えばメモリ１０１０やハードディスクドライブ１０９０に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出して実行する。
　なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０に記憶される場合に限らず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ１１００等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、プログラムモジュール１０９３及びプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local　Area　Network）、ＷＡＮ（Wide　Area　Network）等）を介して接続された他のコンピュータに記憶されてもよい。そして、プログラムモジュール１０９３及びプログラムデータ１０９４は、他のコンピュータから、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
　以上、本発明者によってなされた発明を適用した実施の形態について説明したが、本実施の形態による本発明の開示の一部をなす記述及び図面により本発明は限定されることはない。すなわち、本実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例及び運用技術等はすべて本発明の範疇に含まれる。
　１　スクリプトエンジン
　２　バイトコードコンパイラ
　３　仮想機械（ＶＭ）
　４　構文解析部
　５　バイトコード生成部
　６　コードキャッシュ部
　７　フェッチ部
　８　デコード部
　９　実行部
　１０　解析機能付与装置
　１１　入力部
　１２　制御部
　１３　記憶部
　１４　出力部
　１２１　仮想機械解析部
　１２２　命令セットアーキテクチャ解析部
　１２３　解析機能付与部
　１３１　実行トレースデータベース（ＤＢ）
　１３２　アーキテクチャ情報ＤＢ
　１３３　ＶＭ実行トレースＤＢ
　１２１１　実行トレース取得部
　１２１２　インタプリタループ検出部
　１２１３　仮想プログラムカウンタ検出部
　１２１４　デコーダ・ディスパッチャ検出部
　１２１５　条件分岐フラグ検出部
　１２２１　ＶＭ実行トレース取得部
　１２２２　分岐ＶＭ命令検出部

Claims (8)

  1. 　悪性のスクリプトエンジンの仮想機械を解析する第一の解析部と、
    　前記仮想機械の命令の体系である命令セットアーキテクチャを解析する第二の解析部と、
    　前記第一の解析部及び前記第二の解析部による解析によって得られたアーキテクチャ情報に基づいて、スクリプトエンジンに、マルチパス実行機能を付与するフックを施す付与部と、
    　を有することを特徴とする解析機能付与装置。
  2. 　前記アーキテクチャ情報は、前記仮想機械の命令が実行されるたびにメモリから読み込まれる対象アドレスである仮想プログラムカウンタ、実行状態の条件分岐時に分岐がなされるか否かのフラグを保持する領域である条件分岐フラグ、及び、実行状態の分岐を発生させる仮想機械命令である分岐仮想機械命令であることを特徴とする請求項１に記載の解析機能付与装置。
  3. 　前記第一の解析部及び前記第二の解析部は、テスト用のスクリプトを用いた解析を実施することを特徴とする請求項１または２に記載の解析機能付与装置。
  4. 　前記第一の解析部は、
    　実行時の条件を変えて複数の実行トレースを取得する第一の取得部を有し、
    　差分実行解析を用いて前記複数の実行トレースを解析し、前記仮想プログラムカウンタ及び前記条件分岐フラグを取得することを特徴とする請求項２に記載の解析機能付与装置。
  5. 　前記第一の解析部は、
    　前記複数の実行トレースを解析し、インタプリタループを検出する第一の検出部と、
    　メモリの読み込み回数に着目した差分実行解析を用いて前記複数の実行トレースを解析し、前記仮想プログラムカウンタを検出する第二の検出部と、
    　スクリプトエンジンのバイナリを静的解析し、デコーダ・ディスパッチャを検出する第三の検出部と、
    　メモリの読み込み回数に着目した差分実行解析を用いて前記複数の実行トレースを解析し、前記条件分岐フラグを検出する第四の検出部と、
    　を有することを特徴とする請求項４に記載の解析機能付与装置。
  6. 　前記第二の解析部は、
    　前記仮想機械において実行された実行トレースである仮想機械実行トレースを取得する第二の取得部と、
    　前記仮想機械実行トレースの仮想機械オペコードごとの仮想プログラムカウンタの変化量のばらつきによって、前記分岐仮想機械命令を検出する第五の検出部と、
    　を有することを特徴とする請求項２に記載の解析機能付与装置。
  7. 　解析機能付与装置が実行する解析機能付与方法であって、
    　悪性のスクリプトエンジンの仮想機械を解析する第一の解析工程と、
    　前記仮想機械の命令の体系である命令セットアーキテクチャを解析する第二の解析工程と、
    　前記第一の解析工程及び前記第二の解析工程における解析によって得られたアーキテクチャ情報に基づいて、スクリプトエンジンに、マルチパス実行機能を付与するフックを施す付与工程と、
    　を含んだことを特徴とする解析機能付与方法。
  8. 　悪性のスクリプトエンジンの仮想機械を解析する第一の解析ステップと、
    　前記仮想機械の命令の体系である命令セットアーキテクチャを解析する第二の解析ステップと、
    　前記第一の解析ステップ及び前記第二の解析ステップにおける解析によって得られたアーキテクチャ情報に基づいて、スクリプトエンジンに、マルチパス実行機能を付与するフックを施す付与ステップと、
    　をコンピュータに実行させるための解析機能付与プログラム。
PCT/JP2019/040336 2019-10-11 2019-10-11 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム WO2021070393A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2019/040336 WO2021070393A1 (ja) 2019-10-11 2019-10-11 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
US17/764,988 US20230028595A1 (en) 2019-10-11 2019-10-11 Analysis function imparting device, analysis function imparting method, and analysis function imparting program
JP2021551100A JP7287480B2 (ja) 2019-10-11 2019-10-11 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/040336 WO2021070393A1 (ja) 2019-10-11 2019-10-11 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム

Publications (1)

Publication Number Publication Date
WO2021070393A1 true WO2021070393A1 (ja) 2021-04-15

Family

ID=75438071

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/040336 WO2021070393A1 (ja) 2019-10-11 2019-10-11 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム

Country Status (3)

Country Link
US (1) US20230028595A1 (ja)
JP (1) JP7287480B2 (ja)
WO (1) WO2021070393A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023067663A1 (ja) * 2021-10-18 2023-04-27 日本電信電話株式会社 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067667A1 (ja) * 2021-10-18 2023-04-27 日本電信電話株式会社 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067665A1 (ja) * 2021-10-18 2023-04-27 日本電信電話株式会社 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067668A1 (ja) * 2021-10-18 2023-04-27 日本電信電話株式会社 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11989292B2 (en) * 2018-10-11 2024-05-21 Nippon Telegraph And Telephone Corporation Analysis function imparting device, analysis function imparting method, and recording medium
JP2023000907A (ja) * 2021-06-18 2023-01-04 株式会社日立製作所 ソースコード修正支援装置及びソースコード修正支援方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10033747B1 (en) * 2015-09-29 2018-07-24 Fireeye, Inc. System and method for detecting interpreter-based exploit attacks

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013008326A1 (ja) * 2011-07-13 2013-01-17 富士通株式会社 ソフトウェア検証方法、およびソフトウェア検証システム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10033747B1 (en) * 2015-09-29 2018-07-24 Fireeye, Inc. System and method for detecting interpreter-based exploit attacks

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
KINDER, JOHANNES: "Towards Static Analysis of Virtualization-Obfuscated Binaries", 2012 19TH WORKING CONFERENCE ON REVERSE ENGINEERING, IEEE, XP032283250, ISSN: 1095-1350, ISBN: 978-0-7695-4891-3, Retrieved from the Internet <URL:https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6385102> DOI: 10.1109/WCRE.2012.16 *
USUI, TOSHINORI ET AL.: "Automatic Enhancement of Script Engines by Appending Behavior Analysis Capabilities", PROCEEDINGS OF COMPUTER SECURITY SYMPOSIUM 2018, vol. 2018, no. 2, 15 October 2018 (2018-10-15), pages 1016 - 1023, XP058485564 *
USUI, TOSHINORI ET AL.: "Automatically Appending Multi-Path Execution Functionality to Vanilla Script Engines", PROCEEDINGS OF COMPUTER SECURITY SYMPOSIUM 2019, vol. 2019, 14 October 2019 (2019-10-14), pages 961 - 968 *
WATANABE, KENJI ET AL.: "Static and Dynamic Analysis of Java Virtual Machine", IPSJ SIG TECHNICAL REPORT, vol. 97, no. 76, 21 August 1997 (1997-08-21), pages 73 - 78, ISSN: 0919-6072 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023067663A1 (ja) * 2021-10-18 2023-04-27 日本電信電話株式会社 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067667A1 (ja) * 2021-10-18 2023-04-27 日本電信電話株式会社 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067665A1 (ja) * 2021-10-18 2023-04-27 日本電信電話株式会社 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067668A1 (ja) * 2021-10-18 2023-04-27 日本電信電話株式会社 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム

Also Published As

Publication number Publication date
US20230028595A1 (en) 2023-01-26
JP7287480B2 (ja) 2023-06-06
JPWO2021070393A1 (ja) 2021-04-15

Similar Documents

Publication Publication Date Title
WO2021070393A1 (ja) 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
JP7115552B2 (ja) 解析機能付与装置、解析機能付与方法及び解析機能付与プログラム
JP7201078B2 (ja) データ引数を動的に識別し、ソースコードを計装するためのシステムと方法
US9720798B2 (en) Simulating black box test results using information from white box testing
WO2022180702A1 (ja) 解析機能付与装置、解析機能付与プログラム及び解析機能付与方法
US9507933B2 (en) Program execution apparatus and program analysis apparatus
CN109101815B (zh) 一种恶意软件检测方法及相关设备
Cachera et al. Certified memory usage analysis
Kim et al. Survey of dynamic taint analysis
WO2017068889A1 (ja) 解析装置、解析方法、および解析プログラム
Ferrara et al. : Backward Context-Sensitive Flow Reconstruction of Taint Analysis Results
WO2023067665A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067668A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
US11057416B2 (en) Analyze code that uses web framework using local parameter model
JP6984760B2 (ja) 変換装置及び変換プログラム
KR20190051301A (ko) 퍼징 수행 시스템, 퍼징용 실행 흐름 정보 추출 장치 및 방법
CN114077737A (zh) 基于污点分析的Android组件间通信数据流检测方法
Bhardwaj et al. Fuzz testing in stack-based buffer overflow
WO2023067667A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
WO2023067663A1 (ja) 解析機能付与方法、解析機能付与装置及び解析機能付与プログラム
JP7452691B2 (ja) 解析機能付与装置、解析機能付与方法および解析機能付与プログラム
KR102572607B1 (ko) 비실행데이터 내의 셸코드 식별장치 및 방법
WO2024079794A1 (ja) 解析機能付与装置、解析機能付与方法および解析機能付与プログラム
JP6599053B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
Youssef et al. Tracing Software Exploitation

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

Country of ref document: EP

Kind code of ref document: A1

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 2021551100

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19948586

Country of ref document: EP

Kind code of ref document: A1