Vulnerability detection device, vulnerability detection method, and vulnerability detection program

Abstract

This vulnerability discovery device (10) includes: a virtual machine analyzing unit (121) that analyzes the VM of a script engine; a command set architecture analyzing unit (122) that analyzes a command set architecture that is a system of VM commands, collects the VM commands, and determines the command content of the collected VM commands; and a vulnerability discovery unit (123) that uses a mutated code to perform fuzzing on the VM on the basis of architecture information acquired by the virtual machine analyzing unit (121) and the command set architecture analyzing unit (122).

Description

Technical Field

[0001] The present invention relates to a vulnerability discovery device, a vulnerability discovery method, and a vulnerability discovery program.

Background Art

[0002] As a technology for discovering defects latent in software, there is what is called dynamic testing. Dynamic testing is software testing. In software testing, testing is performed by actually giving input values to a target program and executing it to observe its behavior.

[0003] One type of dynamic testing is fuzzing. Fuzzing is a technology for discovering vulnerabilities latent in software. Fuzzing is a technology for discovering vulnerabilities by repeatedly generating or mutating input values and giving them to a target program to execute, observing the execution state of the program, and searching for inputs that can cause problems leading to vulnerabilities such as crashes. <所

[0004] At this time, what to use as input values and how to generate or mutate the input values are important factors related to the vulnerability discovery efficiency. For example, if there is a path that is not executed unless it is within a specific range of input values and there is a vulnerability there, it will take a great deal of time to discover that vulnerability if the input values for traversing that path are not efficiently discovered.

[0005] In current fuzzing, it is common to give an initial input value called a seed and mutate it. Therefore, what to use as the seed and how to mutate it are important.

[0006] In recent years, one of the software for which vulnerability discovery has become important is a script engine (also called an interpreter). Since such a script engine may execute untrusted scripts from the outside, it is important to discover vulnerabilities in advance ahead of attackers.

[0007] There are two main methods for fuzzing execution environments using virtual machines (VMs), such as script engines. The first method uses a script as a seed for fuzzing, and searches for vulnerabilities by inputting it into the script engine while mutating it. The second method uses bytecode generated from the script as a seed and similarly inputs it into the script engine.

[0008] Non-Patent Document 1 describes a first method for fuzzing the PHP script engine, defining a unique intermediate representation. First, the technology described in Non-Patent Document 1 converts the PHP script into this intermediate representation, modifies it, and then converts it back to the PHP script to use as input.

[0009] Furthermore, the technology described in Non-Patent Document 2 obtains type information by statically analyzing JavaScript code in order to fuzz the JavaScript (registered trademark) engine, and performs mutations using an abstract syntax tree, enabling mutations that maintain type and structure.

[0010] On the other hand, as a second method, Non-Patent Document 3 proposes a technique for fuzzing Android's ART VM by mutating the DEX bytecode.

[0011] In the technology described in Non-Patent Document 4, in order to efficiently fuzz the Java VM (JVM), the type of mutation to be performed when mutating Java bytecode is selected using Markov chain Monte Carlo, with the uniqueness of runtime code coverage as an indicator.

[0012] The technology described in Non-Patent Document 5 employs a modified mutation and selection method with the aim of preserving legitimate bytecode that the JVM can execute during mutation, in order to discover defects hidden deeper within the JVM through fuzzing. [Prior art documents] [Non-patent literature]

[0013] [Non-Patent Document 1] V. S Rao, T. Gupta, S. Vasan, and D. L.R, “PHPIL: Fuzzing the PHP Interpreter with Custom Bytecode”, In Proceedings of the 11th International Conference on Computing, Communication and Networking Technologies, pp. 1-5, 2020. [Non-Patent Document 2] S. Park, W. Xu, I. Yun, D. Jang, and T. Kim, “Fuzzing JavaScript Engines with Aspect-preserving Mutation”, In Proceedings of the 2020 IEEE Symposium on Security and Privacy, pp. 1629-1642, 2020. [Non-Patent Document 3] S. Kyle, H. Leather, B. Franke, D. Butcher, and S. Monteith, “Application of Domain-aware Binary Fuzzing to Aid Android Virtual Machine Testing”, In Proceedings of the 11th ACM SIGPLAN / SIGOPS International Conference on Virtual Execution Environments, pp. 121-132, 2015. [Non-Patent Document 4] Y. Chen, T. Su, C. Sun, Z. Su, and J. Zhao, “Coverage-Directed Differential Testing of JVM Implementations”, In Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation, pp. 85-99, 2016. [Non-Patent Document 5] Y. Chen, T. Su, and Z. Su, “Deep Differential Testing of JVM Implementations”, In Proceedings of the 2019 IEEE / ACM 41st International Conference on Software Engineering, pp. 1257-1268, 2019. [Overview of the project] [Problems that the invention aims to solve]

[0014] However, the methods described in Non-Patent Documents 1 and 2 perform fuzzing only based on script variations, which limits the comprehensiveness of the tests when viewed from the perspective of bytecode sequences.

[0015] Furthermore, the methods described in Non-Patent Documents 3, 4, and 5 have the drawback that they cannot be applied to VMs whose internal specifications are unknown, because they use VM information to mutate the bytecode.

[0016] To mutate bytecode, it is necessary to know in advance where the bytecode generated by the scripting engine is stored in the VM, and information about the instruction set architecture of the bytecode that the VM can interpret. This information is necessary because the current bytecode needs to be retrieved from the scripting engine's VM, mutated within the correct scope as bytecode instructions, and then re-embedded in the VM.

[0017] However, in many cases, the internal specifications of the VM are not publicly available, and it is not easy to know the internal specifications of the VM. Therefore, generally, it is necessary to reverse-engineer the VM to clarify the internal specifications and obtain information independently.

[0018] Performing analysis, design, and implementation manually and individually for the script engine is not practical from the perspective of such effort.

[0019] The present invention has been made in view of the above, and an object thereof is to provide a vulnerability discovery device, a vulnerability discovery method, and a vulnerability discovery program that can realize fuzzing with bytecode as an input value without requiring manual individual analysis, design, and implementation even for a script engine with unknown internal specifications of the VM.

Means for Solving the Problems

[0020] In order to solve the above-described problems and achieve the object, the vulnerability discovery device of the present invention includes a first analysis unit that analyzes a virtual machine of a script engine, and analyzes an instruction set architecture that is a system of instructions of the virtual machine to collect virtual machine instructions, and a second analysis unit that determines the instruction content of the collected virtual machine instructions, and an execution unit that fuzzes the virtual machine using the mutated code based on the architecture information obtained by the first analysis unit and the second analysis unit.

Effects of the Invention

[0021] According to the present invention, even for a script engine with unknown internal specifications of the VM, fuzzing with bytecode as an input value can be realized without requiring manual individual analysis, design, and implementation.

Brief Description of the Drawings

[0022] [Figure 1] FIG. 1 is a diagram for explaining an example of the configuration of a script engine. [Figure 2] FIG. 2 is a diagram showing the pseudo code of the VM possessed by the script engine. [Figure 3] FIG. 3 is a diagram explaining an example of the configuration of vulnerability discovery according to the embodiment. [Figure 4] FIG. 4 is a diagram showing an example of a test script used for detecting a virtual program counter (VPC). [Figure 5] FIG. 5 is a diagram showing an example of a test script used for detecting a branch VM instruction. [Figure 6] FIG. 6 is a diagram showing an example of an execution trace. [Figure 7] FIG. 7 is a diagram showing an example of a VM execution trace. [Figure 8] FIG. 8 is a diagram explaining the processing of the VM instruction boundary detection unit. [Figure 9] FIG. 9 is a diagram explaining the processing of the virtual program counter detection unit. [Figure 10] FIG. 10 is a diagram explaining the processing of the dispatcher detection unit. [Figure 11] FIG. 11 is a diagram explaining the processing of the code cache detection unit. [Figure 12] FIG. 12 is a diagram explaining the processing of the VM instruction determination unit. [Figure 13] FIG. 13 is a diagram explaining the processing of the mutation part. [Figure 14] FIG. 14 is a flowchart showing the processing procedure of the analysis processing according to the embodiment. [Figure 15] FIG. 15 is a flowchart showing the processing procedure of the execution trace acquisition processing shown in FIG. 14. [Figure 16] FIG. 16 is a flowchart showing the processing procedure of the VM instruction boundary detection processing shown in FIG. 14. [Figure 17] FIG. 17 is a flowchart showing the processing procedure of the virtual program counter detection processing shown in FIG. 14. [Figure 18] FIG. 18 is a flowchart showing the processing procedure of the dispatcher detection processing shown in FIG. 14. [Figure 19] Figure 19 is a diagram illustrating the process of detecting the conditional branch flag shown in Figure 14. [Figure 20] Figure 20 is a flowchart showing the processing steps of the code cache detection process shown in Figure 14. [Figure 21] Figure 21 is a flowchart showing the processing steps for the VM execution trace acquisition process shown in Figure 14. [Figure 22] Figure 22 is a flowchart showing the processing procedure for the VM instruction collection process shown in Figure 14. [Figure 23] Figure 23 is a flowchart showing the processing procedure for the VM instruction determination process shown in Figure 14. [Figure 24] Figure 24 is a flowchart showing the processing procedure for the branch VM instruction determination process shown in Figure 23. [Figure 25] Figure 25 is a flowchart showing the processing procedure for the conditional branch VM instruction determination process shown in Figure 23. [Figure 26] Figure 26 is a flowchart showing the processing procedure for the VM instruction call determination process shown in Figure 23. [Figure 27] Figure 27 is a flowchart showing the processing procedure for the return VM instruction determination process shown in Figure 23. [Figure 28] Figure 28 is a flowchart showing the processing procedure for the bytecode extraction process shown in Figure 14. [Figure 29] Figure 29 is a flowchart showing the processing procedure for the mutation treatment shown in Figure 14. [Figure 30] Figure 30 is a flowchart showing the processing steps of the execution process shown in Figure 14. [Figure 31] Figure 31 shows an example of a computer in which vulnerability discovery is achieved through the execution of a program. [Modes for carrying out the invention]

[0023] Embodiments of the vulnerability detection device, vulnerability detection method, and vulnerability detection program according to the present invention will be described in detail below with reference to the drawings. Furthermore, the present invention is not limited to the embodiments described below.

[0024] [Embodiment] The vulnerability detection device according to this embodiment is a vulnerability detection device that can perform fuzzing using bytecode as input, even for script engines whose internal specifications of the VM are unknown, without requiring manual individual analysis, design, and implementation.

[0025] The vulnerability detection device according to the embodiment executes a test script while monitoring the script engine binary, and obtains branch traces and memory access traces as execution traces. Based on the execution traces, the vulnerability detection device analyzes the VM and obtains architectural information such as VM instruction boundaries, virtual program counters (VPCs), dispatchers, conditional branch flags, and the code cache where the executed VM instructions are stored.

[0026] The vulnerability detection device runs test scripts while monitoring the VPC and dispatcher to obtain VM execution traces. By analyzing the VM execution traces, the vulnerability detection device collects VM instructions, determines the content of the VM instructions, and obtains information about the instruction set architecture.

[0027] The vulnerability detection device then fuzzes the VM using mutated code based on the acquired architecture information. The vulnerability detection device repeatedly extracts, mutates, and embeds bytecode based on the acquired architecture information and then executes it to achieve fuzzing. The vulnerability detection device extracts bytecode from the code cache by running a seed script while monitoring the code cache, mutates the extracted bytecode, and then embeds it back into the code cache to perform fuzzing.

[0028] Referring to Figures 1 and 2, we will explain the general structure and operation of a script engine. Figure 1 is a diagram illustrating an example of a script engine structure. As shown in Figure 1, script engine 1 has a bytecode compiler 2 and a VM 3. The bytecode compiler 2 also has a syntax analysis unit 4 and a bytecode generation unit 5. The VM 3 has a code cache unit 6, a fetch unit 7, a decode unit 8, and an execution unit 9. These fetch unit 7, decode unit 8, and execution unit 9 are executed repeatedly and are called an interpreter loop. Then, script engine 1 accepts script input.

[0029] The parsing unit 4 receives the script as input, performs lexical and syntactic analysis, generates an Abstract Syntax Tree (AST), and outputs it to the bytecode generation unit 5. The bytecode generation unit 5 receives the AST as input, converts it to bytecode, and stores it in the code cache unit 6.

[0030] The fetch unit 7 fetches VM opcodes from the code cache unit 6 and outputs them to the decode unit 8. Here, the VM opcode refers to the opcode portion of the VM instruction. The decode unit 8 receives the VM opcode as input, interprets it using a decoder / dispatcher, and dispatches it to the corresponding program. The execution unit 9 executes the program corresponding to the VM instruction. The contents written in the script are executed by repeatedly executing VM instructions one after another through the interpreter loop.

[0031] Refer to Figure 2 to explain the function of the components of the script engine. Figure 2 shows the pseudocode for a VM that the script engine has. As shown in Figure 2, first the pseudocode initializes the VPC (line 1). In the pseudocode, the while statement loop is the interpreter loop (line 2). In the pseudocode, the VM opcode pointed to by the VPC is obtained from the code cache (line 3), and it is decoded and dispatched using a switch statement (lines 4, 5, and 7). Then, in the pseudocode, the program corresponding to the dispatched VM opcode is executed (lines 6 and 8).

[0032] Furthermore, a branch VM instruction is a VM instruction that causes a branch within a script, and the conditional branch flag is an area that holds a flag indicating whether or not a branch occurs when a conditional branch is triggered.

[0033] [Configuration of vulnerability detection device] Next, with reference to Figure 3, the configuration of the vulnerability detection device 10 according to the embodiment will be described in detail. Figure 3 is a diagram illustrating an example of the configuration of the vulnerability detection device according to the embodiment.

[0034] As shown in Figure 3, the vulnerability detection device 10 has an input unit 11, a control unit 12, a storage unit 13, and an output unit 14. The vulnerability detection device 10 accepts a test script, a script engine binary, and a seed script as input.

[0035] The input unit 11 consists of input devices such as a keyboard and mouse, and receives information from external sources and inputs it to the control unit 12. The input unit 11 also has a communication interface for sending and receiving various information with other devices connected via wired connections or networks, and receives information transmitted from other devices. The input unit 11 receives test scripts, script engine binaries, and seed scripts and outputs them to the control unit 12.

[0036] The test script is the script that is input when dynamically analyzing the script engine to obtain execution traces and VM execution traces. Details of the test script will be described later. The script engine binary is the executable file that makes up the script engine. The script engine binary may consist of multiple executable files. The seed script is a script that contains the bytecode that serves as the initial input value.

[0037] The control unit 12 has an internal memory for storing programs that define various processing procedures and necessary data, and executes various processes using these. For example, 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 has a virtual machine analysis unit 121 (first analysis unit), an instruction set architecture analysis unit 122 (second analysis unit), and a vulnerability detection unit 123.

[0038] The virtual machine analysis unit 121 analyzes the VM of the script engine. The virtual machine analysis unit 121 acquires multiple execution traces by changing the execution conditions, analyzes the multiple execution traces using differential execution analysis, and obtains the VPC and conditional branch flags. The virtual machine analysis unit 121 also analyzes the script engine binary to obtain the VM instruction boundaries and dispatcher. The virtual machine analysis unit 121 detects the code cache from the VM execution trace. The code cache stores the VM instructions that are executed.

[0039] The virtual machine analysis unit 121 includes an execution trace acquisition unit 1211 (first acquisition unit), a VM instruction boundary detection unit 1212 (first detection unit), a virtual program counter detection unit 1213 (second detection unit), a dispatcher detection unit 1214 (third detection unit), a conditional branch flag detection unit 1215 (fourth detection unit), and a code cache detection unit 1216 (fifth detection unit).

[0040] The execution trace acquisition unit 1211 accepts the test script and the script engine binary as input. The execution trace acquisition unit 1211 acquires the execution trace by executing the test script while monitoring the execution of the script engine binary.

[0041] The execution trace consists of a branch trace and a memory access trace. The branch trace records the type of branch instruction during execution, as well as the source and destination addresses of the branch. The memory access trace records the type of memory operation and the memory address of the operation. It is known that both branch traces and memory access traces can be obtained by instruction hooks. The execution trace obtained by the execution trace acquisition unit 1211 is stored in the execution trace DB 131.

[0042] The VM instruction boundary detection unit 1212 clusters the execution trace to detect the boundary of each VM instruction. The VM instruction boundary detection unit 1212 clusters the execution trace and detects clusters with execution counts equal to or greater than a threshold as VM instructions. Clustering detects consecutive code regions that are executed multiple times. This can be done, for example, by grouping instructions that are close in code distance from each other, by searching for common subsequences of executed code blocks, or by other methods. The vulnerability detection device 10 detects the start and end points of consecutive instruction sequences that constitute the detected VM instruction as boundaries. The VM instruction boundaries detected here are used in VPC detection and dispatcher detection.

[0043] The virtual program counter detection unit 1213 retrieves and analyzes the execution trace for the first test script stored in the execution trace DB 131 to detect the VPC. The virtual program counter detection unit 1213 analyzes multiple execution traces using differential execution analysis focusing on the number of memory reads and the boundaries of each VM instruction detected by the VM instruction boundary detection unit 1212 to detect the VPC. The virtual program counter detection unit 1213 detects the VPC by discovering the destination of this read, utilizing the fact that a read to the memory holding the VPC always occurs after the execution of each VM instruction.

[0044] Therefore, the virtual program counter detection unit 1213 uses differential execution analysis focusing on the number of memory reads to detect VPCs. The virtual program counter detection unit 1213 compares the execution traces of multiple test scripts obtained using test scripts and finds memory where the number of memory reads changes in proportion to the increase or decrease of both the number of repetitions and the number of repeated statements. Then, the virtual program counter detection unit 1213 refers to the boundaries of each VM instruction detected by the VM instruction boundary detection unit 1212 and narrows down the memory where the value of the read memory always points to the starting point of the VM instruction. The virtual program counter detection unit 1213 detects this memory as a VPC.

[0045] The dispatcher detection unit 1214 extracts each VM instruction portion from the script engine binary based on the VM instruction boundary detection unit 1212, and detects the portion with high similarity between each VM instruction as a dispatcher. As a prerequisite, dispatchers are implemented by referencing a pointer cache and jumping to the pointer of the next VM instruction handler. Dispatchers are distributed after each VM instruction handler, and generally, their code is highly identical. By searching for highly identical code located after these VM instruction handlers, the vulnerability detection device detects dispatchers in a predetermined manner. For detecting portions with high similarity, for example, a sequence alignment algorithm may be used, or other methods may be employed.

[0046] The conditional branch flag detection unit 1215 retrieves and analyzes the execution trace for the second test script stored in the execution trace DB 131 to discover the conditional branch flag. The conditional branch flag detection unit 1215 analyzes multiple execution traces using differential execution analysis that focuses on the number of memory reads to detect the conditional branch flag. The conditional branch flag detection unit 1215 executes conditional branching in various patterns and compares the patterns of memory changes in those cases with the conditional branching patterns in the test script to detect the memory where the conditional branch flag is stored.

[0047] The code cache detection unit 1216 detects the code cache, which is a cache where executed VM instructions are stored, from the VM execution trace based on the execution trace, VPC, and VM execution trace.

[0048] The code cache detection unit 1216 detects the memory area pointed to by the VPC as a code cache from the VM execution trace. The code cache detection unit 1216 detects the code location that called the memory allocation function that allocated this code cache from the execution trace. The code cache detection unit 1216 detects all memory areas allocated at this code location as a code cache from the VM execution trace.

[0049] The code cache detection unit 1216 detects the code location that is writing to the code cache from the execution trace. The code cache detection unit 1216 detects the write by this code location in the VM execution trace as an update to the code cache.

[0050] The instruction set architecture analysis unit 122 analyzes the instruction set architecture, which is the instruction system of the VM. The instruction set architecture analysis unit 122 collects VM instructions. It determines the instruction content of the collected VM instructions.

[0051] The instruction set architecture analysis unit 122 includes a VM execution trace acquisition unit 1221 (second acquisition unit), a VM instruction collection unit 1222 (first collection unit), and a VM instruction determination unit 1223 (first determination unit).

[0052] The VM execution trace acquisition unit 1221, like the execution trace acquisition unit 1211, accepts test scripts and script engine binaries as input. The VM execution trace acquisition unit 1221 acquires VM execution traces by monitoring the VPC and the pointers to VM instruction handlers dispatched by the dispatcher. The VM execution trace acquisition unit 1221 acquires VM execution traces, which are execution traces executed on the VM, by executing test scripts while monitoring the execution of the script engine binary. In detecting branch VM instructions, the VM execution trace acquisition unit 1221 acquires VM execution traces by executing numerous test scripts. The VM execution trace acquisition unit 1221 associates pointers to VM instructions with VM instructions and virtually assigns VM opcodes as identifiers to each.

[0053] A VM execution trace is an execution trace performed in a VM, where a VM opcode is virtually assigned as an identifier, and it records the pointer to the executed VM handler and the VPC. Specifically, a VM execution trace consists of the VPC and VM opcode for each executed VM instruction. Recording the VPC can be achieved by monitoring the memory of the VPC detected by the virtual program counter detection unit 1213. A VM opcode is a virtually assigned identifier that associates a pointer to a VM instruction with the VM instruction itself. The VM execution trace acquired by the VM execution trace acquisition unit 1221 is stored in the VM execution trace DB 133.

[0054] The VM instruction collection unit 1222 accepts the VPC and dispatcher as input, executes a script while monitoring the VPC and dispatcher, and obtains a VM execution trace. The VM instruction collection unit 1222 collects VM instructions from the VM execution trace.

[0055] The VM instruction determination unit 1223 determines the instruction content of the VM instruction collected by the VM instruction collection unit 1222. First, the VM instruction determination unit 1223 determines a branch VM instruction based on the variation in the amount of change in VPC for each VM opcode in the VM execution trace.

[0056] The VM instruction determination unit 1223 retrieves and analyzes the VM execution trace stored in the VM execution trace DB 133 to determine a branch VM instruction. For each VM opcode assigned as an identifier, the VM instruction determination unit 1223 collects the amount of change in the VPC before and after its execution. If the VM opcode is not a branch VM instruction, the amount of change in the VPC is almost constant. On the other hand, if the VM opcode is a branch VM instruction, the VPC will vary depending on the branch destination.

[0057] Therefore, the VM instruction determination unit 1223 determines a branch VM instruction based on the variation in the amount of change of the virtual program counter for each VM opcode in the VM execution trace. The VM instruction determination unit 1223 focuses on the fact that the magnitude of variation in the VPC value differs between branch VM instructions and other VM instructions, sets a threshold, and determines that those with a larger variation in the VPC value are branch VM instructions. Specifically, the VM instruction determination unit 1223 evaluates the variation in the amount of change of the VPC for each VM opcode using variance, and determines that those with a variance above a certain threshold are branch VM instructions.

[0058] Furthermore, the VM instruction determination unit 1223 determines which branch VM instructions are conditional branch VM instructions in order to construct a precise control flow graph. When a conditional branch occurs, access to the conditional branch flag always occurs in order to determine the branch destination. Therefore, a conditional branch VM instruction can be determined by verifying whether the conditional branch flag is accessed when each branch VM instruction is executed. In other words, if the conditional branch flag is accessed when a branch VM instruction is executed, it can be determined that it is a conditional branch VM instruction, and if it is not accessed, it can be determined that it is not a conditional branch VM instruction. Accordingly, the VM instruction determination unit 1223 determines that branch VM instructions that involve access to the conditional branch flag are conditional branch VM instructions based on the VM execution trace and memory access trace.

[0059] Furthermore, the VM instruction determination unit 1223 also determines call and return VM instructions. In a branch using a call VM instruction, the address immediately following the caller in the bytecode is saved, and after the execution of the called subroutine, the return VM instruction returns to that saved address. Therefore, the VM instruction determination unit 1223 designates a branch VM instruction as instruction 1, and subsequent branch VM instructions as instruction 2, and determines that instruction 2 returns to the address immediately following instruction 1 in the bytecode, and that the pair of instruction 1 and instruction 2 is a call and return VM instruction.

[0060] Next, the VM instruction determination unit 1223 determines that branch VM instructions that access a conditional branch flag are conditional branch VM instructions. In this case, the VM instruction determination unit 1223 retrieves a list of opcodes for branch VM instructions from the architecture information DB 132, retrieves one VM execution trace from the VM execution trace DB 133, and retrieves the corresponding execution trace from the execution trace DB 131.

[0061] The VM instruction determination unit 1223 extracts one location from the VM execution trace where a branch VM instruction is being executed, and then extracts a memory access trace from the execution trace that corresponds to the execution of the extracted branch VM instruction.

[0062] The VM instruction determination unit 1223 determines, based on the memory access trace, whether the retrieved branch VM instruction accesses a conditional branch flag. The VM instruction determination unit 1223 determines that the retrieved branch VM instruction is a conditional branch VM instruction if it accesses a conditional branch flag.

[0063] The VM instruction determination unit 1223 then scans the VM execution trace for any branch VM instruction, and if there is a branch instruction that branches immediately after this branch VM instruction, it determines that this branch VM instruction is a call VM instruction.

[0064] In this case, the VM instruction determination unit 1223 retrieves a list of opcodes for branch VM instructions from the architecture information DB 132 and retrieves one VM execution trace from the VM execution trace DB 133. The VM instruction determination unit 1223 then retrieves one location from the VM execution trace where a branch VM instruction is being executed.

[0065] The VM instruction determination unit 1223 scans the VM execution trace for branch VM instructions that appear after the extracted branch VM instruction. Based on the scan results, the VM instruction determination unit 1223 determines whether or not there was a branch VM instruction that branches immediately after the extracted branch VM instruction. If there was a branch VM instruction that branches immediately after the extracted branch VM instruction, the VM instruction determination unit 1223 determines that the extracted branch VM instruction is a call VM instruction.

[0066] Furthermore, the VM instruction determination unit 1223 extracts the calling VM instruction from the VM execution trace, and if there is a branching VM instruction that branches immediately after the extracted calling VM instruction, it determines that the branching VM instruction that branches immediately after the extracted calling VM instruction is a return VM instruction.

[0067] In this case, the VM instruction determination unit 1223 retrieves a list of opcodes for branch VM instructions from the architecture information DB 132 and retrieves one VM execution trace from the VM execution trace DB 133. The VM instruction determination unit 1223 then retrieves one location from the VM execution trace where a calling VM instruction is being executed.

[0068] The VM instruction determination unit 1223 scans the VM execution trace for branch VM instructions that appear after the extracted call VM instruction and determines whether or not there was a branch VM instruction that branches immediately after the extracted call VM instruction.

[0069] The VM instruction determination unit 1223 determines that if there is a branch VM instruction that branches immediately after the retrieved call VM instruction, this branch VM instruction that branches immediately after the retrieved call VM instruction is a return VM instruction.

[0070] The vulnerability detection unit 123 fuzzes the VM using mutated code based on the architecture information obtained by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122. The vulnerability detection unit 123 executes a seed script while monitoring the code cache to extract bytecode from the code cache. Then, the vulnerability detection unit 123 modifies the extracted bytecode, embeds it back into the code cache, and executes it. The vulnerability detection unit 123 includes a mutation unit 1231 and a fuzzing execution unit 1232.

[0071] The mutation unit 1231 modifies the bytecode extracted by the fuzzing execution unit 1232 in a predetermined way, such as adding, deleting, or modifying VM instructions, and outputs the updated bytecode dictionary to the fuzzing execution unit 2132.

[0072] The fuzzing execution unit 1232 accepts the seed script, VPC, and code cache as input. The fuzzing execution unit 1232 then executes the seed script while monitoring the code cache and extracts bytecode from the code cache. The fuzzing execution unit 2132 re-embeds the mutated code at the location pointed to by the VPC in the code cache and resumes execution. The fuzzing execution unit 1232 outputs the input values ​​(bytecode) where problems such as crashes occurred during execution.

[0073] The memory unit 13 is implemented using semiconductor memory elements such as RAM (Random Access Memory) and flash memory, or storage devices such as hard disks and optical discs, and stores processing programs that operate the vulnerability detection device 10, as well as data used during the execution of the processing programs. The memory unit 13 includes an execution trace database (DB) 131, a VM execution trace DB 133, and an architecture information DB 132 that stores architecture information acquired by the virtual machine analysis unit 121 and the instruction set architecture analysis unit 122.

[0074] The execution trace DB 131 and VM execution trace DB 133 store the execution traces and VM execution traces acquired by the execution trace acquisition unit 1211 and VM execution trace acquisition unit 1221, respectively. The execution trace DB 131 and VM execution trace DB 133 are managed by the vulnerability detection device 10. Of course, the execution trace DB 131 and VM execution trace DB 133 may also be managed by other devices (such as servers). In this case, the execution trace acquisition unit 1211 and VM execution trace acquisition unit 1221 output the acquired execution traces and VM execution traces to the management server of the execution trace DB 131 and VM execution trace DB 133 via the communication interface of the output unit 14, and store them in the execution trace DB 131 and VM execution trace DB 133.

[0075] The output unit 14 may be, for example, a liquid crystal display or a printer, and outputs various information including information related to the vulnerability detection device 10. Alternatively, the output unit 14 may be an interface that handles the input and output of various data to and from an external device, and may output various information to the external device.

[0076] [Test script structure] This section explains test scripts. Test scripts are input scripts used when dynamically analyzing a scripting engine. These test scripts focus on the execution of branch instructions and the number of memory read / write operations, and are used to capture the differences in the scripting engine's behavior when the test script is executed a different number of times. These test scripts are prepared in advance of the analysis and are created manually. Creating them requires knowledge of the specifications of the target scripting language.

[0077] Figure 4 shows an example of a test script (the first test script) used for VPC detection. The first test script uses loop processing (line 2). In the first test script, the execution conditions are changed and differences are generated by increasing or decreasing the number of repetitions (line 2) and the number of statements repeated (lines 3 to 5) within the test script.

[0078] Figure 5 shows an example of a test script (second test script) used for branch VM instruction detection. The second test script uses multiple conditional branches (lines 4 to 8). In the second test script, the branching conditions are controlled so that branching occurs or does not occur in a specific order pattern (lines 1 and 5). The second test script generates differences by changing the number of conditional branches and the order pattern of success or failure of the branches.

[0079] [Configuring execution traces] Next, we will explain the execution trace. Figure 6 shows an example of an execution trace. As mentioned above, the execution trace consists of a branch trace and a memory access trace. Figure 6 is an excerpt of a portion of the execution trace. Hereafter, Figure 6 will be used to illustrate the structure of the execution trace.

[0080] Execution traces have an element called `trace`. The `trace` element indicates whether the log line is a branch trace or a memory access trace.

[0081] The log lines of a branch trace follow the format shown in lines 1 through 10 of Figure 6, for example, and consist of three elements: type, src, and dst. `type` indicates whether the executed branch instruction was a call, jmp, or ret instruction. `src` indicates the address of the branch source, and `dst` indicates the address of the branch destination.

[0082] The log lines of a memory access trace follow the format shown in lines 11 through 13 of Figure 6, for example, and consist of three elements: type, target, and value. `type` indicates whether the memory access is a read or a write. `target` indicates the memory address being accessed. `value` stores the result of the memory access.

[0083] [Configuring VM execution traces] Next, we will explain VM execution tracing. Figure 7 shows an example of VM execution tracing. As mentioned above, VM execution tracing records the VM opcode and VPC. Figure 7 is an excerpt of a portion of the VM execution tracing. Hereafter, Figure 7 will be used to show the structure of VM execution tracing.

[0084] A VM execution trace log line follows the format shown in Figure 7, for example, and consists of two elements: vpc and vmop (vm opcode). vpc indicates the value of the VPC. vmop indicates the value of the VM opcode virtually allocated to each pointer that points to the beginning of the VM instruction handler being executed, retrieved from the pointer cache.

[0085] [VM instruction boundary detection unit processing] Next, the processing of the VM instruction boundary detection unit 1212 will be explained. Figure 8 is a diagram illustrating the processing of the VM instruction boundary detection unit 1212.

[0086] The VM instruction boundary detection unit 1212 detects the boundaries of each VM instruction. At this time, the VM instruction boundary detection unit 1212 detects VM instructions and their boundaries for threaded code type VMs, which are difficult to grasp because they do not have an interpreter loop. Specifically, the VM instruction boundary detection unit 1212 retrieves the execution trace from the execution trace DB 131. Then, as shown in Figure 8, the VM instruction boundary detection unit 1212 clusters the execution trace in a predetermined way and detects clusters with execution counts above a threshold as VM instructions (for example, VM instruction handlers 1 to 3). The VM instruction boundary detection unit 1212 detects the start and end points of a continuous sequence of instructions that constitute a VM instruction as boundaries.

[0087] [Processing of the virtual program counter detection unit] Next, the processing of the virtual program counter detection unit 1213 will be described. The virtual program counter detection unit 1213 detects the VPC and pointer cache. The detection of virtual program counters is achieved by analyzing the memory access trace logs of the acquired execution trace. The virtual program counter detection unit 1213 uses differential execution analysis that focuses on the number of memory reads. Figure 9 is a diagram illustrating the processing of the virtual program counter detection unit 1213.

[0088] The virtual program counter detection unit 1213 retrieves one execution trace from the execution trace DB 131 for the first test script. The number of VPC reads is proportional to the number of repetitions in the test script and the number of statements in the repetitive processing. When the number of repetitions is N and the number of statements repeated is M, approximately MN VPC reads occur. Therefore, the virtual program counter detection unit 1213 extracts memory increases of 4MN and 9MN in the execution traces for the first test script where N and M are increased to 2N and 2M, and 3N and 3M, respectively. Specifically, as shown in Figure 9, the virtual program counter detection unit 1213 extracts memory areas that are monotonically increasing with a Read / Write for each VM instruction execution (Figure 9(1)).

[0089] The virtual program counter detection unit 1213 then detects a VPC (Virtual Program Counter) if the value of the read memory always points to the starting point of a VM instruction. Specifically, the virtual program counter detection unit 1213 compares the destination of the VPC with the address of the VM instruction handler and narrows down the memory region to a matching one (Figure 9(2)).

[0090] [Processing by the dispatcher detection unit] Next, the processing of the dispatcher detection unit 1214 will be described. The dispatcher detection unit 1214 detects the dispatcher by analyzing the script engine binary using a predetermined method. Figure 10 is a diagram illustrating the processing of the dispatcher detection unit 1214.

[0091] The dispatcher detection unit 1214 detects dispatchers. Based on the VM instruction boundaries detected by the VM instruction boundary detection unit 1212, the dispatcher detection unit 1214 extracts each VM instruction portion from the script engine binary. Then, assuming that the dispatcher code is highly similar (Figure 10 (1)), the dispatcher detection unit 1214 calculates the code similarity between each VM instruction and detects the portion with high similarity across all VM instructions as the dispatcher. The dispatcher detection unit 1214 can detect code that is commonly executed in the latter half of a VM instruction as the dispatcher (Figure 10 (1)).

[0092] [Code Cache Detection Unit] Next, the processing of the code cache detection unit 1216 will be explained. Figure 11 is a diagram illustrating the processing of the code cache detection unit 1216.

[0093] The code cache detection unit 1216 detects the memory area pointed to by the VPC as a code cache from the VM execution trace (Figure 11 (1)).

[0094] The code cache detection unit 1216 detects the code location that called the memory allocation function that allocated this code cache from the execution trace (Figure 11 (2)). The code cache detection unit 1216 detects all memory areas allocated at this code location as the code cache from the VM execution trace (Figure 11 (3)).

[0095] The code cache detection unit 1216 detects the code location that is writing to the code cache from the execution trace (Figure 11 (4)). The code cache detection unit 1216 detects the write by this code location as a code cache update in the VM execution trace (Figure 11 (5)).

[0096] [VM command judgment unit] Next, we will explain the processing of the VM instruction determination unit 1223. First, the VM instruction determination unit 1223 determines a branch VM instruction by analyzing the acquired VM execution trace log. The test script here only needs to contain a branch VM instruction, so any script that includes branch control syntax is acceptable. For example, a test script can be prepared by collecting it from the internet or obtaining it from official documentation.

[0097] First, the VM instruction determination unit 1223 associates a pointer to a VM instruction with the VM instruction for each VM execution trace in the VM execution trace DB 133, and virtually assigns a VM opcode as an identifier to each. Figure 12 is a diagram illustrating the processing of the VM instruction determination unit 1223.

[0098] Here, when a VM instruction is a branch instruction, the progress of the VPC varies depending on the branch destination. On the other hand, when it is not a branch instruction, the progress of the VPC varies depending on the size of the VM instruction. Therefore, when we collect pairs of VM instruction opcodes and pointers to VM instructions and examine the progress of the VPC for each opcode, if it is a branch instruction, we will see variations in the progress of the VPC depending on the branch destination.

[0099] Therefore, the VM instruction determination unit 1223 uses variance to evaluate the variability of pointers to this VM instruction. The VM instruction determination unit 1223 calculates the variance of the VPC change for each VM opcode and narrows down the selection to only VM opcodes where the calculated variance is greater than a threshold. In this way, the VM instruction determination unit 1223 associates pointers with VM instructions and determines that VM instructions with variability in the progress of the VPC (VM instruction handler 3 in the example in Figure 12) are branch VM instructions (Figure 12 (1)).

[0100] The set of VPC progressions O for a given opcode is O={o0,o1,···,o N(See equation (1) for the average of VPCo) and with t as the threshold, whether or not it is a branch instruction is determined based on the variance s (See equation (2)) as shown in equation (3). Based on this, the VM instruction determination unit 1223 determines that it is a branch VM instruction.

[0101]

number

[0102]

number

[0103]

number

[0104] Furthermore, for VM instructions other than branch instructions, there is almost no variation, and the boundary between branch VM instructions and other VM instructions is often clear. For this reason, a threshold value is set, for example, by plotting the obtained variance values ​​on a number line and setting a value that can divide the resulting two groups. The VM instruction determination unit 1223 determines conditional branch VM instructions, call VM instructions, and return VM instructions based on branch VM instructions.

[0105] [Processing of the mutant area] Next, the processing of the mutation portion 1231 will be explained. Figure 13 is a diagram illustrating the processing of the mutation portion 1231.

[0106] The mutation unit 1231 refers to the list of VM instructions (Figure 13(1)). This list of VM instructions is collected by the VM instruction collection unit 1222. Then, when a bytecode is taken from the bytecode dictionary (Figure 13(2)), the mutation unit 1231 modifies the taken bytecode in a predetermined way, such as by adding, deleting, or modifying VM instructions (Figure 13(3)).

[0107] [Procedure for handling vulnerability detection devices] Next, the processing procedure for the analysis by the vulnerability detection device 10 will be described. Figure 14 is a flowchart showing the processing procedure for the analysis according to the embodiment.

[0108] First, the input unit 11 receives the test script and the script engine binary as input (step S1).

[0109] Then, the execution trace acquisition unit 1211 performs execution trace acquisition processing to acquire branch traces and memory access traces by executing a test script while monitoring the script engine binary (step S2).

[0110] The VM instruction boundary detection unit 1212 detects VM instructions and performs VM instruction boundary detection processing to detect the boundaries of VM instructions (step S3). The virtual program counter detection unit 1213 retrieves and analyzes the execution trace for the first test script stored in the execution trace DB 131 and performs virtual program counter detection processing to discover the VPC (step S4).

[0111] The dispatcher detection unit 1214 extracts each VM instruction portion from the script engine binary and performs a dispatcher detection process to detect the portion with a high degree of similarity between each VM instruction as a dispatcher (step S5).

[0112] The conditional branch flag detection unit 1215 retrieves and analyzes the execution trace for the second test script stored in the execution trace DB 131 and performs a conditional branch detection process to find the conditional branch flag (step S6).

[0113] The code cache detection unit 1216 performs a code cache detection process (step S7) in which it detects the area of ​​the code that calls the memory allocation function as the code cache based on the execution trace and VPC, and detects the area that is writing to the area of ​​the code as an update to the code cache.

[0114] The VM execution trace acquisition unit 1221 accepts a test script and a script engine binary as input, and performs a VM execution trace acquisition process to acquire a VM execution trace by executing the test script while monitoring the execution of the script engine binary (step S8).

[0115] The VM instruction collection unit 1222 performs a VM instruction collection process to obtain VM instructions from the VM execution trace (step S9). The VM instruction determination unit 1223 performs a VM instruction determination process to determine the instruction content of the collected VM instructions (step S10).

[0116] When the input unit 11 receives the seed script input (step S11), the fuzzing execution unit 1232 performs a bytecode extraction process that executes the seed script while monitoring the code cache and extracts bytecode from the code cache (step S12).

[0117] The mutation unit 1231 performs mutation processing to mutate the bytecode extracted by the fuzzing execution unit 1232 in a predetermined way, such as adding, deleting, or modifying VM instructions (step S13). The fuzzing execution unit 1232 then re-embeds the mutated code at the location pointed to by the VPC in the code cache and performs execution processing (step S14).

[0118] The vulnerability detection unit 123 determines whether or not a problem such as a crash occurred during the execution process (step S15). If a problem such as a crash occurred (step S15: Yes), it outputs the input value in which the problem occurred (step S16). If no problem such as a crash occurred (step S15: No), it returns to the mutation process in step S13 and continues fuzzing the VM.

[0119] [Processing steps for obtaining execution traces] Next, we will explain the execution trace acquisition process flow shown in Figure 14. Figure 15 is a flowchart showing the processing steps of the execution trace acquisition process shown in Figure 14.

[0120] First, the execution trace acquisition unit 1211 receives the test script and the script engine binary as input (step S21). Then, the execution trace acquisition unit 1211 hooks the received script engine to acquire branch traces (step S22). In addition, the execution trace acquisition unit 1211 also hooks the received script engine to acquire memory access traces (step S23).

[0121] Then, the execution trace acquisition unit 1211 inputs the received test script into the script engine and executes it (step S24), and stores the execution trace obtained therefrom in the execution trace DB 131 (step S25).

[0122] The execution trace acquisition unit 1211 determines whether or not all of the input test scripts have been executed (step S26). If the execution trace acquisition unit 1211 has finished executing all of the input test scripts (step S26: Yes), it terminates the process. On the other hand, if the execution trace acquisition unit 1211 has not executed all of the input test scripts (step S26: No), it returns to the execution of the test scripts in step S24 and continues the process.

[0123] [Processing procedure for VM instruction boundary detection] Next, we will explain the VM instruction boundary detection process flow shown in Figure 14. Figure 16 is a flowchart showing the processing steps of the VM instruction boundary detection process shown in Figure 14.

[0124] First, the VM instruction boundary detection unit 1212 retrieves the execution trace from the execution trace DB 131 (step S31). The VM instruction boundary detection unit 1212 clusters the execution trace using a predetermined method (step S32). Any clustering method may be used.

[0125] The VM instruction boundary detection unit 1212 detects clusters whose execution count exceeds a threshold as VM instructions (step S33). The VM instruction boundary detection unit 1212 then uses the start and end points of a sequence of instructions constituting a VM instruction as boundaries (step S34). The VM instruction boundary detection unit 1212 outputs the VM instruction boundary as a return value (step S35) and terminates the VM instruction boundary detection process.

[0126] [Processing procedure for detecting virtual program counters] Next, we will explain the flow of the virtual program counter detection process shown in Figure 14. Figure 17 is a flowchart showing the processing steps of the virtual program counter detection process shown in Figure 14.

[0127] First, the virtual program counter detection unit 1213 retrieves one execution trace from the execution trace DB 131 using the first test script (step S41). Next, the virtual program counter detection unit 1213 focuses on the memory access trace among the execution traces and counts the number of reads for each memory read destination (step S42).

[0128] The virtual program counter detection unit 1213 receives the first test script used to obtain the execution trace as input (step S43), and analyzes the first test script to obtain the number of repetitions and the number of statements repeated (step S44).

[0129] Next, the virtual program counter detection unit 1213 retrieves another execution trace from the execution trace DB 131, using a first test script with different repetition counts and the number of statements repeated (step S45). Then, the virtual program counter detection unit 1213 focuses on the memory access trace and counts the number of reads for each memory read destination (step S46). The virtual program counter detection unit 1213 also receives the first test script used to obtain the execution trace as input (step S47), analyzes the test script, and obtains the number of repetitions and the number of statements repeated (step S48).

[0130] Here, the virtual program counter detection unit 1213 narrows down the memory read destinations to only those whose read count changes in proportion to the number of repetitions or the increase or decrease in the number of repeated statements (step S49). Furthermore, the virtual program counter detection unit 1213 narrows down the memory read destinations narrowed down in step S49 to those in which the value of the read memory always points to the starting point of the VM instruction (step S50).

[0131] The virtual program counter detection unit 1213 then determines whether it has been able to narrow down the memory read destination to just one (step S51). If the virtual program counter detection unit 1213 has not been able to narrow down the memory read destination to just one (step S51: No), it returns to step S45, extracts the next execution trace, and continues processing. On the other hand, if the virtual program counter detection unit 1213 has been able to narrow down the memory read destination to just one (step S51: Yes), it stores the narrowed-down memory read destination as a virtual program counter in the architecture information DB 132 (step S52), and terminates processing.

[0132] [Processing steps for dispatcher detection] Next, we will explain the flow of the dispatcher detection process shown in Figure 14. Figure 18 is a flowchart showing the processing steps of the dispatcher detection process shown in Figure 14.

[0133] First, the dispatcher detection unit 1214 receives the script engine binary as input (step S61). The dispatcher detection unit 1214 receives the VM instruction boundary from the VM instruction boundary detection unit 1212 (step S62).

[0134] The dispatcher detection unit 1214 extracts each VM instruction portion from the script engine binary based on the VM instruction boundaries received from the VM instruction boundary detection unit 1212 (step S63). The dispatcher detection unit 1214 calculates the code similarity between each VM instruction using a predetermined method (step S64). Any method capable of calculating code similarity can be used.

[0135] The dispatcher detection unit 1214 extracts portions with high similarity among all VM instructions based on the similarity calculated in step S64 (step S65). Then, the dispatcher detection unit 1214 determines whether it is the end portion of a VM instruction (step S66).

[0136] If it is not the end of a VM instruction (step S66: No), the dispatcher detection unit 1214 returns to step S65 and continues processing. If it is the end of a VM instruction (step S66: Yes), the dispatcher detection unit 1214 outputs the extracted portion as a dispatcher (step S67) and terminates processing.

[0137] [Processing procedure for detecting conditional branching flags] Next, we will explain the flow of the conditional branch flag detection process shown in Figure 14. Figure 19 is a flowchart showing the processing steps of the conditional branch flag detection process shown in Figure 14.

[0138] First, the conditional branch flag detection unit 1215 retrieves one execution trace from the execution trace DB 131 using the second test script (step S71). Then, the conditional branch flag detection unit 1215 focuses on the memory access trace and counts the number of reads for each memory read destination (step S72).

[0139] Furthermore, the conditional branch flag detection unit 1215 receives the second test script used to obtain the execution trace as input (step S73), analyzes this second test script to obtain the number of conditional branches and the True / False sequence pattern (step S74). Then, the conditional branch flag detection unit 1215 narrows down the memory read destinations to only those where the number of reads changes in proportion to the number of conditional branches (step S75). In addition, the conditional branch flag detection unit 1215 narrows down the memory read destinations to only those where the value of the read memory alternates between two values ​​according to the True / False sequence pattern (step S76).

[0140] The conditional branch flag detection unit 1215 determines whether or not it has been able to narrow down the memory read destination to just one (step S77). If the conditional branch flag detection unit 1215 has not been able to narrow down the memory read destination to just one (step S77: No), it returns to step S71, extracts the next execution trace, and continues processing. On the other hand, if the conditional branch flag detection unit 1215 has been able to narrow down the memory read destination to just one (step S77: Yes), it stores the narrowed read destination as a virtual program counter in the architecture information DB 132 (step S78) and terminates processing.

[0141] [Processing steps for code cache detection] Next, we will explain the flow of the code cache detection process shown in Figure 14. Figure 20 is a flowchart showing the processing steps of the code cache detection process shown in Figure 14.

[0142] When the code cache detection unit 1216 receives the execution trace, VPC, and VM execution trace as input (step S81), it obtains the memory area pointed to by the VPC from the VM execution trace (step S82). The VM execution trace is obtained by the VM execution trace acquisition unit 1221.

[0143] The code cache detection unit 1216 obtains the code location of the caller of the memory allocation function that allocated the memory area obtained in step S82 from the execution trace (step S83). The code cache detection unit 1216 detects all the areas allocated at the code location obtained in step S83 as the code cache from the VM execution trace (step S84).

[0144] The code cache detection unit 1216 obtains the code locations that are writing to the code cache from the execution trace (step S85). The code cache detection unit 1216 detects all areas written at the code locations obtained in step S85 from the VM execution trace as code cache updates (step S86). The code cache detection unit 1216 returns the detected code cache and its update locations (step S87) and terminates the code cache detection process.

[0145] [Processing steps for obtaining VM execution traces] Next, we will explain the flow of the VM execution trace acquisition process shown in Figure 14. Figure 21 is a flowchart showing the processing steps of the VM execution trace acquisition process shown in Figure 14.

[0146] First, the VM execution trace acquisition unit 1221 receives the test script and script engine binary as input (step S91). Then, the VM execution trace acquisition unit 1221 applies a hook to the received script engine to record the VPC and VM opcode (step S92).

[0147] The VM execution trace acquisition unit 1221 inputs the received test script into the script engine and executes it (step S93), and stores the resulting VM execution trace in the VM execution trace DB 133 (step S94).

[0148] The VM execution trace acquisition unit 1221 determines whether or not all of the input test scripts have been executed (step S95). If the VM execution trace acquisition unit 1221 has finished executing all of the input test scripts (step S95: Yes), it terminates the process. If the VM execution trace acquisition unit 1221 has not finished executing all of the input test scripts (step S95: No), it returns to the execution of the test scripts in step S93 and continues the process.

[0149] [VM instruction collection process procedure] Next, we will explain the VM instruction collection process flow shown in Figure 14. Figure 22 is a flowchart showing the processing steps of the VM instruction collection process shown in Figure 14.

[0150] The VM instruction collection unit 1222 accepts the VPC and dispatcher as input (step S101) and acquires various scripts from the internet (step S102). The VM instruction collection unit 1222 executes the scripts while monitoring the VPC and dispatcher and acquires VM execution traces (step S103).

[0151] The VM instruction collection unit 1222 retrieves VM instructions from the VM execution trace (step S104) and adds them to the VM instruction list (step S105). If the VM instruction collection unit 1222 finds a VM instruction that is not in the list (step S106: No), it returns to step S102. If the VM instruction collection unit 1222 no longer finds any VM instructions that are not in the list (step S106: Yes), it returns the VM instruction list (step S107) and terminates the VM instruction collection process.

[0152] [Processing procedure for VM instruction determination] Next, we will explain the VM instruction determination process flow shown in Figure 14. Figure 23 is a flowchart showing the processing steps of the VM instruction determination process shown in Figure 14.

[0153] The VM instruction determination unit 1223 performs a branch VM instruction determination process to determine which VM instructions among those collected by the VM instruction collection unit 1222 are branch VM instructions (step S111). The VM instruction determination unit 1223 determines that branch VM instructions that access a conditional branch flag are conditional branch VM instructions (step S112).

[0154] The VM instruction determination unit 1223 scans the VM execution trace for any branch VM instruction and, if there is a branch instruction that branches immediately after any branch VM instruction, it performs a call VM instruction determination process to determine that the branch VM instruction is a call VM instruction (step S113).

[0155] The VM instruction determination unit 1223 extracts the called VM instruction from the VM execution trace and performs a return VM instruction determination process to determine whether the extracted VM instruction is a return VM instruction (step S114).

[0156] The VM instruction determination unit 1223 determines other VM instructions in a predetermined way from the difference in VM execution traces obtained using multiple test scripts in which the VM instruction is called (step S115).

[0157] Next, the VM instruction determination unit 1223 adds the determined VM instruction to the VM instruction list (step S116). The VM instruction determination unit 1223 returns the list of VM instructions (step S117) and terminates the VM instruction determination process.

[0158] [Processing procedure for determining branch VM instructions] Figure 24 is a flowchart showing the processing procedure for the branch VM instruction determination process shown in Figure 23.

[0159] The VM instruction determination unit 1223 retrieves one VM execution trace from the VM execution trace DB 133 (step S121). The VM instruction determination unit 1223 associates a pointer to a VM instruction with the VM instruction and assigns a VM opcode as an identifier to each (step S122). Then, the VM instruction determination unit 1223 aggregates the amount of change in the VPC before and after execution for each VM opcode (step S123).

[0160] The VM instruction determination unit 1223 determines whether it has finished processing all VM execution traces in the VM execution trace DB 133 (step S124). If it has not finished processing all VM execution traces in the VM execution trace DB 133 (step S124: No), the VM instruction determination unit 1223 returns to step S121 and takes out the next VM execution trace to process.

[0161] If all VM execution traces in the VM execution trace DB133 have been processed (step S124: Yes), the VM instruction determination unit 1223 calculates the variance of the VPC change for each VM opcode (step S125). Then, the VM instruction determination unit 1223 receives a threshold as input (step S126). The VM instruction determination unit 1223 narrows down to only VM opcodes whose variance is greater than the threshold (step S127), stores them as branch VM instructions in the architecture information DB132 (step S128), and terminates processing.

[0162] [Processing procedure for conditional branch VM instruction judgment] Figure 25 is a flowchart showing the processing procedure for the conditional branch VM instruction determination process shown in Figure 23.

[0163] The VM instruction determination unit 1223 retrieves a list of opcodes for branch VM instructions from the architecture information DB 132 (step S131). The VM instruction determination unit 1223 retrieves one VM execution trace from the VM execution trace DB 133 (step S132). The VM instruction determination unit 1223 retrieves the corresponding execution trace from the execution trace DB 131 (step S133).

[0164] The VM instruction determination unit 1223 extracts one location from the VM execution trace where a branch VM instruction is being executed (step S134). The VM instruction determination unit 1223 extracts a memory access trace from the execution trace that corresponds to the execution of the extracted branch VM instruction (step S135).

[0165] The VM instruction determination unit 1223 determines, based on the memory access trace, whether the branch VM instruction extracted in step S134 accesses a conditional branch flag (step S136).

[0166] If the conditional branch flag is being accessed (step S136: Yes), the VM instruction determination unit 1223 determines that the branch VM instruction retrieved in step S134 is a conditional branch VM instruction (step S137). The VM instruction determination unit 1223 stores the opcode of this conditional branch VM instruction in the architecture information DB 132 (step S138).

[0167] If the conditional branch flag has not been accessed (step S136: No), or after step S138, the VM instruction determination unit 1223 determines whether or not all locations executing branch VM instructions have been processed (step S139).

[0168] If not all locations executing branch VM instructions have been processed (step S139: No), the VM instruction determination unit 1223 retrieves the next location executing a branch VM instruction (step S140), returns to step S135, and processes the retrieved branch VM instruction.

[0169] If all points where branch VM instructions are being executed have been processed (step S139: Yes), the VM instruction determination unit 1223 determines whether or not all VM execution traces have been processed (step S141).

[0170] If not all VM execution traces have been processed (step S141: No), the VM instruction determination unit 1223 retrieves the next VM execution trace (step S142), returns to step S133, and processes the retrieved VM execution trace. If all VM execution traces have been processed (step S141: Yes), the VM instruction determination unit 1223 terminates the conditional branch VM instruction determination process.

[0171] [Processing procedure for determining the calling VM instruction] Figure 26 is a flowchart showing the processing procedure for the VM instruction call determination process shown in Figure 23.

[0172] The VM instruction determination unit 1223 retrieves a list of opcodes for branch VM instructions from the architecture information DB 132 (step S151). The VM instruction determination unit 1223 retrieves one VM execution trace from the VM execution trace DB 133 (step S152). The VM instruction determination unit 1223 retrieves one location from the VM execution trace where a branch VM instruction is being executed (step S153).

[0173] The VM instruction determination unit 1223 scans the VM execution trace for branch VM instructions that appear after the branch VM instruction extracted in step S153 (step S154). Based on the scan results in step S154, the VM instruction determination unit 1223 determines whether or not there was a branch VM instruction that branches immediately after the branch VM instruction extracted in step S153 (step S155).

[0174] If there is a branch VM instruction that branches immediately after the branch VM instruction extracted in step S153 (step S155: Yes), the VM instruction determination unit 1223 determines that the branch VM instruction extracted in step S153 is a call VM instruction (step S156). The VM instruction determination unit 1223 stores the opcode of the call VM instruction in the architecture information DB 132 (step S157).

[0175] The VM instruction determination unit 1223 determines whether there is no branch VM instruction that branches immediately after the branch VM instruction extracted in step S153 (step S155: No), or whether all locations executing branch VM instructions have been processed after the completion of processing in step S157 (step S158).

[0176] If not all locations executing branch VM instructions have been processed (step S158: No), the VM instruction determination unit 1223 retrieves the next location executing a branch VM instruction (step S159), returns to step S154, and processes the retrieved branch VM instruction.

[0177] If all points where branch VM instructions are being executed have been processed (step S158: Yes), the VM instruction determination unit 1223 determines whether or not all VM execution traces have been processed (step S160).

[0178] If not all VM execution traces have been processed (step S160: No), the VM instruction determination unit 1223 retrieves the next VM execution trace (step S161), returns to step S153, and processes the retrieved VM execution trace. If all VM execution traces have been processed (step S160: Yes), the VM instruction determination unit 1223 terminates the VM instruction call determination process.

[0179] [Processing procedure for determining the return VM instruction] Figure 27 is a flowchart showing the processing procedure for the return VM instruction determination process shown in Figure 23.

[0180] The VM instruction determination unit 1223 retrieves a list of opcodes for branch VM instructions from the architecture information DB 132 (step S171). The VM instruction determination unit 1223 retrieves one VM execution trace from the VM execution trace DB 133 (step S172). The VM instruction determination unit 1223 retrieves one location from the VM execution trace where a calling VM instruction is being executed (step S173).

[0181] The VM instruction determination unit 1223 scans the VM execution trace for branch VM instructions that appear after the called VM instruction extracted in step S173 (step S174).

[0182] The VM instruction determination unit 1223 determines whether or not there was a branch VM instruction that branches immediately after the called VM instruction extracted in step S173 (step S175).

[0183] If there is a branch VM instruction that branches immediately after the calling VM instruction extracted in step S173 (step S175: Yes), the VM instruction determination unit 1223 determines that the branch VM instruction that branches immediately after the calling VM instruction extracted in step S173 is a return VM instruction (step S176). The VM instruction determination unit 1223 stores the opcode of the return VM instruction in the architecture information DB 132 (step S177).

[0184] The VM instruction determination unit 1223 determines whether there is no branch VM instruction that branches immediately after the called VM instruction extracted in step S173 (step S175: No), or whether all locations executing branch VM instructions have been processed after the completion of processing in step S177 (step S178).

[0185] If not all locations executing branch VM instructions have been processed (step S178: No), the VM instruction determination unit 1223 retrieves the next location executing a branch VM instruction (step S179), returns to step S174, and processes the retrieved branch VM instruction.

[0186] If all points where branch VM instructions are being executed have been processed (step S178: Yes), the VM instruction determination unit 1223 determines whether or not all VM execution traces have been processed (step S180).

[0187] If not all VM execution traces have been processed (step S180: No), the VM instruction determination unit 1223 retrieves the next VM execution trace (step S181), returns to step S173, and processes the retrieved VM execution trace. If all VM execution traces have been processed (step S180: Yes), the VM instruction determination unit 1223 terminates the return VM instruction determination process.

[0188] [Processing steps for bytecode extraction] Next, we will explain the flow of the bytecode extraction process shown in Figure 14. Figure 28 is a flowchart showing the processing steps of the bytecode extraction process shown in Figure 14.

[0189] The vulnerability detection unit 123 accepts a seed script as input (step S191). The vulnerability detection unit 123 accepts a code cache as input (step S192).

[0190] The fuzzing execution unit 1232 executes a seed script while monitoring the code cache (step S193). The vulnerability discovery unit 123 extracts bytecode from the code cache (step S194) and stores the bytecode in a dictionary (step S195).

[0191] [Processing procedure for mutations] Next, we will explain the mutation processing flow shown in Figure 14. Figure 29 is a flowchart showing the mutation processing procedure shown in Figure 14.

[0192] The mutation unit 1231 accepts a dictionary of bytecodes obtained in the bytecode extraction process as input (step S201). The mutation unit 1231 also accepts a list of VM instructions as input (step S202).

[0193] The mutation unit 1231 takes one bytecode from the bytecode dictionary (step S203), and mutates the taken bytecode in a predetermined way, such as adding, deleting, or modifying VM instructions (step S204). Then, the mutation unit 1231 adds the mutated bytecode to the bytecode dictionary (step S205).

[0194] If the mutation unit 1231 has not mutated all of the bytecode to be mutated (step S206: No), it returns to step S203. If the mutation unit 1231 has mutated all of the bytecode to be mutated (step S206: Yes), it returns the updated bytecode dictionary (step S207).

[0195] [Execution Procedure] Next, we will explain the execution process flow shown in Figure 14. Figure 30 is a flowchart showing the processing steps of the execution process shown in Figure 14.

[0196] The fuzzing execution unit 1232 accepts the seed script as input (step S211). The fuzzing execution unit 1232 accepts the VPC and code cache as input (step S212).

[0197] The fuzzing execution unit 1232 executes the seed script while monitoring the VPC and code cache (step S213). The fuzzing execution unit 1232 stops execution at the moment the bytecode is executed (step S214). Then, the fuzzing execution unit 1232 retrieves the bytecode from the bytecode dictionary (step S215).

[0198] The fuzzing execution unit 1232 places the extracted bytecode at the location pointed to by the VPC in the code cache (step S216). Then, the fuzzing execution unit 1232 resumes execution (step S217).

[0199] [Effects of the embodiment] As described above, the vulnerability detection device 10 according to this embodiment analyzes the VM of the script engine, collects VM instructions, determines the content of the collected VM instructions, and obtains information on the instruction set architecture, which is the instruction system of the VM. Based on the acquired architecture information, the vulnerability detection device 10 fuzzes the VM using mutated code. For this reason, the vulnerability detection device 10 can perform fuzzing using bytecode as input even for script engines whose internal specifications of the VM are unknown.

[0200] Specifically, the vulnerability detection device 10 executes a test script while monitoring the script engine binary, and obtains branch traces and memory access traces as execution traces. Based on these execution traces, the vulnerability detection device 10 analyzes the VM and obtains architectural information such as VM instruction boundaries, VPC, dispatcher, conditional branch flags, and code cache. Furthermore, the vulnerability detection device 10 executes a test script while monitoring the VPC and dispatcher, and obtains VM execution traces. By analyzing the VM execution traces, the vulnerability detection device 10 collects VM instructions, determines the content of the VM instructions, and obtains information on the instruction set architecture.

[0201] In this way, the vulnerability detection device 10 can obtain architectural information, including information indicating where the bytecode generated by the script engine is stored in the VM, and information on the instruction set architecture of the bytecode that the VM can interpret, even for script engines whose internal specifications of the VM are unknown.

[0202] The vulnerability detection device 10 then detects the code cache based on the execution trace, VPC, and VM execution trace. The vulnerability detection device 10 monitors the code cache, executes a seed script to extract bytecode from the code cache, modifies the extracted bytecode, and then re-embeds it in the code cache for execution. Therefore, based on the acquired architecture information, the vulnerability detection device 10 can retrieve the current bytecode from the VM of the script engine, modify it within the correct range as a bytecode instruction, and re-embed it in the VM.

[0203] Thus, the vulnerability detection device 10 can detect various architectural information even for script engines whose internal specifications are unknown to the VM, by analyzing the acquisition of execution traces and VM execution traces. Therefore, it can perform fuzzing with bytecode as input without requiring manual reverse engineering.

[0204] Furthermore, the vulnerability detection device 10 can automatically perform fuzzing with bytecode as input for various script engines, provided that a test script is provided. Therefore, bytecode-based fuzzing can be achieved without the need for individual design or execution.

[0205] This enables the vulnerability detection device 10 to perform fuzzing using bytecode as input, even for a wide variety of script engine implementations, and to discover potential vulnerabilities.

[0206] Thus, according to the vulnerability detection device 10 of this embodiment, by analyzing a script engine whose internal specifications are unknown and obtaining information on the bytecode storage location and instruction set architecture, fuzzing with bytecode as input can be performed on script engines of a wide variety of scripting languages.

[0207] Furthermore, the vulnerability detection device 10 is useful for discovering vulnerabilities in a wide variety of scripting engines, and is suitable for discovering vulnerabilities latent in behaviors that are difficult to extract when using scripts as input, by fuzzing with bytecode as input.

[0208] Therefore, by using the vulnerability detection device 10 to perform fuzzing on various script engines with bytecode as input, it is possible to discover potential vulnerabilities and use the findings to implement countermeasures such as fixing them.

[0209] [Regarding the system configuration of the embodiment] Each component of the vulnerability detection device 10 shown in Figure 3 is a functional concept and does not necessarily have to be physically configured as shown. In other words, the specific forms of distribution and integration of the functions of the vulnerability detection device 10 are not limited to those shown, and all or part of it can be configured by functionally or physically distributing or integrating it in any unit according to various loads and usage conditions.

[0210] Furthermore, each process performed in the vulnerability detection device 10 may be implemented entirely or partially by a CPU and a program executed by the CPU for analysis. Alternatively, each process performed in the vulnerability detection device 10 may be implemented as hardware using wired logic.

[0211] Furthermore, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually. Alternatively, all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters described above and illustrated may be changed as appropriate unless otherwise specified.

[0212] [program] Figure 31 shows an example of a computer in which a vulnerability detection device 10 is realized when a program is executed. The computer 1000 has, for example, 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. These components are connected by a bus 1080.

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

[0214] The hard disk drive 1090 stores, for example, the OS 1091, application program 1092, program module 1093, and program data 1094. That is, the program that defines each process of the vulnerability detection device 10 is implemented as a program module 1093 in which code executable by the computer 1000 is written. The program module 1093 is stored, for example, in the hard disk drive 1090. For example, a program module 1093 for performing the same processes as the functional configuration of the vulnerability detection device 10 is stored in the hard disk drive 1090. Note that the hard disk drive 1090 may be replaced by an SSD (Solid State Drive).

[0215] Furthermore, the configuration data used in the processing of the above-described embodiment is stored as program data 1094 in, for example, memory 1010 or hard disk drive 1090. The CPU 1020 then reads the program module 1093 and program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as needed and executes them.

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

[0217] Although embodiments applying the invention made by the present inventors have been described above, the present invention is not limited by the descriptions and drawings that constitute part of the disclosure of the present invention in these embodiments. That is, all other embodiments, examples, and operational techniques made by those skilled in the art based on these embodiments are included in the scope of the present invention. [Explanation of symbols]

[0218] 10 Vulnerability detection device 11 Input section 12 Control Unit 13 Storage section 14 Output section 121 Virtual Machine Analysis Department 122 Instruction Set Architecture Analysis Unit 123 Vulnerability Discovery Department 131 Execution Trace Database (DB) 132 Architecture Information Database 133 VM execution trace DB 1211 Execution Trace Acquisition Unit 1212 VM Instruction Boundary Detection Unit 1213 Virtual Program Counter Detection Unit 1214 Dispatcher detection unit 1215 Conditional branching flag detection unit 1216 Code Cache Detection Unit 1221 VM Execution Trace Acquisition Unit 1222 VM Instruction Collection Unit 1223 VM instruction judgment unit 1231 Mutation site 1232 Fuzzing Execution Department

Claims

1. The first analysis unit analyzes the virtual machine of the script engine, A second analysis unit analyzes the instruction set architecture, which is the instruction system of the virtual machine, collects virtual machine instructions, and determines the instruction content of the collected virtual machine instructions. An execution unit that fuzzes a virtual machine using mutated code based on the architecture information obtained by the first and second analysis units, It has, The first analysis unit is, A first acquisition unit that acquires multiple execution traces by changing the execution conditions, A first detection unit clusters the execution traces to detect the boundaries of each virtual machine instruction, A second detection unit analyzes the multiple execution traces using differential execution analysis focusing on the number of memory reads and the boundaries of each virtual machine instruction detected by the first detection unit, and detects a virtual program counter, which is a variable that points to the next virtual machine instruction to be executed. A third detection unit analyzes the binary of the script engine and detects a dispatcher based on the boundaries of each virtual machine instruction detected by the first detection unit, A fourth detection unit analyzes the multiple execution traces using differential execution analysis that focuses on the number of memory reads, and detects a conditional branch flag, which is an area that holds a flag indicating whether or not a branch occurs at a conditional branch in the execution state. It has, The second analysis unit described above is: A second acquisition unit acquires a virtual machine execution trace, which is an execution trace performed in the virtual machine. A first collection unit that executes a test script while monitoring the virtual program counter and the dispatcher, obtains the virtual machine execution trace, and collects virtual machine instructions from the virtual machine execution trace, A first determination unit that determines the instruction content of the virtual machine instruction collected by the first collection unit, It has, The first analysis unit is, A fifth detection unit detects a code cache, which is a cache where the virtual machine instructions to be executed are stored, from the virtual machine execution trace, based on the execution trace, the virtual program counter, and the virtual machine execution trace. It has, The vulnerability detection device is characterized in that the execution unit monitors the code cache, executes a seed script to extract bytecode from the code cache, modifies the extracted bytecode, and then embeds it back into the code cache and executes it.

2. The first determination unit is, The branch virtual machine instruction is determined by the variation in the amount of change in the virtual program counter for each virtual machine opcode in the virtual machine execution trace. Among the aforementioned branch virtual machine instructions, the branch virtual machine instruction that accesses the conditional branch flag is determined to be a conditional branch virtual machine instruction. From the aforementioned virtual machine execution trace, scan for any branch virtual machine instruction, and if there is a branch instruction that branches immediately after the arbitrary branch virtual machine instruction, determine that the arbitrary branch virtual machine instruction is a call virtual machine instruction. The calling virtual machine instruction is extracted from the virtual machine execution trace, and if there is a branching virtual machine instruction that branches immediately after the extracted calling virtual machine instruction, the branching virtual machine instruction that branches immediately after the extracted calling virtual machine instruction is determined to be a return virtual machine instruction. The vulnerability detection device according to feature 1.

3. A vulnerability detection method performed by a vulnerability detection device, The first analysis step involves analyzing the virtual machine of the script engine, A second analysis step involves analyzing the instruction set architecture, which is the instruction system of the virtual machine, collecting virtual machine instructions, and determining the instruction content of the collected virtual machine instructions. Based on the architecture information obtained in the first and second analysis steps, an execution step is performed to fuzz a virtual machine using the modified code, Includes, The first analysis step is, The first acquisition step involves obtaining multiple execution traces by changing the execution conditions, A first detection step involves clustering the execution traces to detect the boundaries of each virtual machine instruction, A second detection step involves analyzing the multiple execution traces using differential execution analysis focusing on the number of memory reads and the boundaries of each virtual machine instruction detected in the first detection step, and detecting a virtual program counter, which is a variable that points to the next virtual machine instruction to be executed. A third detection step involves analyzing the binary of the script engine and detecting the dispatcher based on the boundaries of each virtual machine instruction detected in the first detection step, A fourth detection step involves analyzing the multiple execution traces using differential execution analysis that focuses on the number of memory reads, and detecting a conditional branch flag, which is an area that holds a flag indicating whether or not a branch occurs at a conditional branch in the execution state. Includes, The second analysis step described above is: A second acquisition step involves acquiring a virtual machine execution trace, which is an execution trace performed in the virtual machine. A first collection step involves executing a test script while monitoring the virtual program counter and the dispatcher to obtain the virtual machine execution trace, and collecting virtual machine instructions from the virtual machine execution trace. A first determination step for determining the instruction content of the virtual machine instruction collected in the first collection step, Includes, The first analysis step is, A fifth detection step, based on the execution trace, the virtual program counter, and the virtual machine execution trace, detects a code cache, which is a cache where the virtual machine instructions to be executed are stored, from the virtual machine execution trace. Includes, The execution step is a vulnerability detection method characterized by executing a seed script while monitoring the code cache to extract bytecode from the code cache, adding mutations to the extracted bytecode, and then embedding it back into the code cache and executing it again.

4. The first analysis step involves analyzing the virtual machine of the script engine, A second analysis step involves analyzing the instruction set architecture, which is the instruction system of the virtual machine, collecting virtual machine instructions, and determining the instruction content of the collected virtual machine instructions. An execution step in which a virtual machine is fuzzed using mutated code based on the architecture information obtained in the first and second analysis steps, Have the computer run it, The first analysis step described above is: The first acquisition step involves obtaining multiple execution traces by changing the execution conditions, A first detection step involves clustering the execution traces to detect the boundaries of each virtual machine instruction, A second detection step involves analyzing the multiple execution traces using differential execution analysis focusing on the number of memory reads and the boundaries of each virtual machine instruction detected in the first detection step, and detecting a virtual program counter, which is a variable that points to the next virtual machine instruction to be executed. A third detection step involves analyzing the script engine binary and detecting a dispatcher based on the boundaries of each virtual machine instruction detected in the first detection step, A fourth detection step involves analyzing the multiple execution traces using differential execution analysis that focuses on the number of memory reads, and detecting a conditional branch flag, which is an area that holds a flag indicating whether or not a branch occurs at a conditional branch in the execution state. Includes, The second analysis step described above is: A second acquisition step involves acquiring a virtual machine execution trace, which is an execution trace performed in the virtual machine; A first collection step involves executing a test script while monitoring the virtual program counter and the dispatcher to obtain the virtual machine execution trace, and collecting virtual machine instructions from the virtual machine execution trace. A first determination step for determining the instruction content of the virtual machine instruction collected in the first collection step, Includes, The first analysis step described above is: A fifth detection step, based on the execution trace, the virtual program counter, and the virtual machine execution trace, detects a code cache, which is a cache where the virtual machine instructions to be executed are stored, from the virtual machine execution trace. Includes, The execution step involves a vulnerability detection program that runs a seed script while monitoring the code cache to extract bytecode from the code cache, modifies the extracted bytecode, and then embeds it back into the code cache for execution.

Images