Verification device, verification method, and verification program

Abstract

To properly realize a byte code injection attack by malware.SOLUTION: A byte code injection processing unit 130 of a verification device 100 writes malicious byte code to a memory address where target byte code has been located. A symbol table search unit 141 repeatedly performs pointer detection through memory searches and calculation of a start address of a structure based on the structure information of a symbol table, thereby calculating a start address of a management structure that manages the execution state of a script and function information. A symbol table injection unit 142 writes a malicious symbol table to an address identified from the start address of the management structure calculated by the symbol table search unit 141. An execution processing unit 120, with respect to malicious byte code and a malicious symbol table written into a memory space of a process of a temporarily stopped script engine, restarts the process of the script engine so as to execute the malicious byte code while referring to the malicious symbol table.SELECTED DRAWING: Figure 2

Description

[Technical field]

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

[0002] [Verification of attack resistance] Activities to strengthen security include actively launching simulated attacks to verify attack resistance and to devise countermeasures. For example, penetration testing involves launching cyber attacks using a wide variety of attack methods that attackers actually use to attempt intrusions into systems, primarily evaluating the presence or absence of vulnerabilities, which can be used to strengthen security.

[0003] Furthermore, some organizations have a department called the Red Team that specializes in attacks. The Red Team launches simulated attacks against systems using methods used in real attacks, attempting attacks at a wide range of stages, not just intrusion. This allows not only the presence or absence of vulnerabilities to be verified, but also a comprehensive evaluation of the organization's practical ability to deal with attacks. Red Team activities, in particular, use advanced attack methods to verify and ensure security that can deal with such attacks.

[0004] [Verification of resistance to malware attacks] Red team activities also verify resistance to malware attacks, for example by verifying whether security mechanisms such as antivirus software, malware analysis sandboxes, and Endpoint Detection and Response (EDR) deployed on a system can detect the malware when it invades the system.

[0005] [Code injection attack] Once malware invades a target computer, it attempts to conceal its activities to avoid detection by security mechanisms. One of these techniques is a code injection attack. A code injection attack is an attack in which malicious code is injected into a benign process and executed. A typical example is an attack in which malicious code is written into the memory space of a benign process and then a new thread is started to execute the code. This causes the process of a legitimate program that originally exists on the target computer to exhibit malicious behavior, making detection difficult.

[0006] [Bytecode injection attack overview] One type of code injection attack is the bytecode injection attack. Most existing code injection attacks inject native code, which is a sequence of instructions that can be directly executed by a processor. In contrast, a bytecode injection attack targets a script engine (also called an interpreter) and injects bytecode that is interpreted and executed by the script engine process that is executing a benign script.

[0007] [Script execution method] Scripts are executed by a script engine (also called an interpreter). Generally, scripts are converted into bytecode when executed, and the bytecode is interpreted and executed by a virtual machine (VM). Therefore, to inject bytecode into a script engine process and execute it, it is necessary to inject bytecode that can be interpreted by the script engine's VM into the appropriate part of the VM.

[0008] [About the symbol table] In script engines, constants and variables used by bytecode are generally managed by a symbol table. A symbol table is a table that stores information such as the name, value, and type of variables, constants, subroutines, etc., and is created in the semantic analysis phase. A script engine's symbol table generally holds information such as name, type (variable, constant, subroutine, etc.), scope, attributes (depending on the type, for example, whether it is a constant or variable, and what type), and value. Then, bytecode is executed while accessing and referencing such a symbol table. Therefore, the behavior of a script engine process is determined depending on both the bytecode and the symbol table.

[0009] [Bytecode injection attack details] To carry out a bytecode injection attack, it is necessary to execute a malicious script in a script engine in advance and extract the corresponding malicious bytecode. Next, create malware that embeds the malicious bytecode and infiltrate the malware into the target environment. Then, input a benign script that exists in the target environment into the script engine and execute it, and inject the malicious bytecode into an appropriate position in the memory of that process, thereby carrying out the attack. This attack realizes malicious behavior even while a benign script is being executed, making detection difficult.

[0010] As mentioned above, the values ​​that bytecodes refer to during execution are managed in a symbol table, so when injecting, it is necessary to inject not only the bytecode but also the corresponding symbol table. In order to inject the bytecode and symbol table appropriately, it is necessary to understand their internal structures.

[0011] [Detectability of bytecode injection attacks] Unlike native code, bytecode does not usually require execution privileges in memory areas. In addition, this attack does not require characteristic behaviors seen in typical existing attacks, such as starting a thread. Therefore, it is difficult to detect using existing techniques that detect attacks based on such characteristics. Furthermore, since the specifications of the VM instructions that make up the bytecode are unique to each script engine, there is no unified analysis method, and even if it is detected, analysis is not easy.

[0012] [Verification of resistance to bytecode injection attacks] As such, bytecode injection attacks are more difficult to detect than many other existing code injection attacks, and can cause significant damage if they are actually used in an attack. For this reason, it is advisable to verify resistance to attacks in advance through red team exercises and consider countermeasures. [Prior art documents] [Non-patent literature]

[0013] [Non-Patent Document 1] Taemin Park, Julian Lettner, Yeoul Na, Stijn Volckaert, and MichaelFranz: Bytecode Corruption Attacks Are Real ― And How To Defend Against Them, InProceedings of the 15th Conference on Detection of Intrusions and Malware andVulnerability Assessment, 2018 Summary of the Invention [Problem to be solved by the invention]

[0014] However, the above-mentioned conventional techniques cannot adequately realize bytecode injection attacks by malware. For example, it is difficult to directly apply conventional techniques to attacks on script engines whose internal structures are unknown, or to code injection attacks used by malware. [Means for solving the problem]

[0015] In order to solve the above-mentioned problems and achieve the object, the verification device of the present invention is characterized by having a bytecode injection processing unit that writes malicious bytecode at a memory address where a target bytecode is searched for, a symbol table search unit that repeatedly detects a pointer by memory search and calculates the starting address of a structure based on structural information of the symbol table, and calculates the starting address of a management structure that manages process information, a symbol table injection unit that writes the malicious symbol table at an address searched from the starting address of the management structure calculated by the symbol table search unit, and an execution processing unit that causes a script engine to execute a script in which the malicious bytecode and malicious symbol table are written. Effect of the Invention

[0016] According to the present invention, it is possible to appropriately realize a bytecode injection attack by malware. [Brief description of the drawings]

[0017] [Figure 1] FIG. 1 is a diagram illustrating an overview of a bytecode injection attack. [Diagram 2] FIG. 2 is a block diagram illustrating an example of the configuration of the verification device according to the first embodiment. [Diagram 3] FIG. 3 is a diagram showing a specific example of the symbol table search process. [Figure 4] FIG. 4 is a flowchart illustrating an example of an overall process of the verification device according to the first embodiment. [Diagram 5] FIG. 5 is a flowchart illustrating an example of the memory enumeration process. [Figure 6] FIG. 6 is a flowchart illustrating an example of the memory enumeration process. [Figure 7] FIG. 7 is a flowchart illustrating an example of a bytecode search process. [Figure 8] FIG. 8 is a flowchart illustrating an example of a bytecode injection process. [Figure 9] FIG. 9 is a flowchart showing an example of the symbol table search process. [Figure 10] FIG. 10 is a flowchart showing an example of the process flow of the symbol table injection process. [Figure 11] FIG. 11 is a block diagram illustrating an example of the configuration of a verification device according to the second embodiment. [Figure 12] FIG. 12 is a block diagram illustrating an example of the configuration of the analysis unit. [Figure 13] FIG. 13 is a diagram showing an example of a first test script used for detecting a virtual program counter (VPC). [Figure 14] FIG. 14 is a diagram illustrating an example of the second test script. [Figure 15] FIG. 15 is a diagram illustrating an example of the third test script. [Figure 16] FIG. 16 is a diagram illustrating an example of the fourth test script. [Figure 17] FIG. 17 is a diagram showing an example of a porting script. [Figure 18] FIG. 18 is a diagram showing the bytecode and symbol table generated by executing the porting script shown in FIG. [Figure 19] FIG. 19 is a diagram illustrating an example of a bytecode. [Figure 20] FIG. 20 is a diagram illustrating an example of an execution trace. [Figure 21] FIG. 21 is a diagram illustrating an example of a VM execution trace. [Figure 22] FIG. 22 is a diagram for explaining the structure of the symbol table. [Figure 23] FIG. 23 is a diagram for explaining the interpretation execution function. [Figure 24] FIG. 24 is a diagram for explaining the taint analysis. [Diagram 25] FIG. 25 is a diagram for explaining the reference analysis. [Figure 26] FIG. 26 is a diagram for explaining the structural analysis. [Figure 27] FIG. 27 is a diagram for explaining the structural analysis. [Figure 28] FIG. 28 is a flowchart illustrating a processing procedure of the analysis process of the analysis unit according to the second embodiment. [Figure 29] FIG. 29 is a flowchart illustrating the procedure of the execution trace acquisition process. [Diagram 30] FIG. 30 is a flowchart showing the procedure of the virtual program counter detection process. [Diagram 31] FIG. 31 is a flowchart illustrating a procedure for the bytecode cache detection process. [Diagram 32] FIG. 32 is a flowchart showing the procedure of the interpretation execution function detection process. [Diagram 33] FIG. 33 is a flowchart showing the processing procedure of the symbol table detection process. [Diagram 34] FIG. 34 is a flowchart showing the processing procedure of the symbol table analysis process. [Diagram 35] FIG. 35 is a flowchart showing the processing procedure of the reference analysis process. [Diagram 36] FIG. 36 is a flowchart showing the procedure of the structure analysis process. [Figure 37] FIG. 37 is a flowchart showing the procedure of the value object analysis process. [Figure 38] FIG. 38 is a flowchart showing the procedure of the bytecode extraction process. [Figure 39] FIG. 39 is a flowchart showing the processing procedure of the symbol table extraction process. [Diagram 40] FIG. 40 is a diagram illustrating an example of a computer that executes an analysis program. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] Hereinafter, embodiments of a verification device, a verification method, and a verification program according to the present application will be described in detail with reference to the drawings. Note that the verification device, the verification method, and the verification program according to the present application are not limited to the embodiments.

[0019] 1. Embodiment 1 (1-1. Overview of Verification Device 100) First, an overview of the verification device 100 according to the first embodiment will be described. The verification device 100 is an information processing device such as malware that executes malicious bytecode in a target environment. The verification device 100 injects malicious bytecode and a malicious symbol table into a target script input to a script engine in the target environment, thereby causing a PC in the target environment to perform unintended behavior.

[0020] The behavior that is to be performed on PCs in the target environment refers to behavior that is detrimental to the owner of the PC in the target environment, such as automatically sending information externally, automatically encrypting files, or automatically downloading malware.

[0021] Here, an overview of a bytecode injection attack by the verification device 100 will be described with reference to Fig. 1. Fig. 1 is a diagram showing an overview of a bytecode injection attack according to an embodiment. In the example shown in Fig. 1, the verification device 100 has a function equivalent to an injector (malware).

[0022] As described above, a bytecode injection attack requires a malicious bytecode and a corresponding malicious symbol table. Therefore, first, in an analysis device in an attacker's environment, a malicious script is executed by a script engine to extract the malicious bytecode and the malicious symbol table. In addition, a target bytecode and a target symbol table into which the malicious bytecode and the malicious symbol table are injected are required, so they are extracted by executing the target script in the same way.

[0023] After the malicious bytecode, the malicious symbol table, the target bytecode, and the target symbol table are extracted, the information is embedded in an injector in an attacker's environment. Then, the injector invades the target environment and causes a script engine to execute the target script. Next, the injector identifies the location of the target bytecode and the location of the target symbol table by memory search. Then, the injector injects the malicious bytecode into the target bytecode and the malicious symbol table into the target symbol table by memory writing, and causes a script engine in the target environment to execute the malicious bytecode.

[0024] The verification device 100 first enumerates the stack memory and the heap memory on the script engine process. Next, the verification device 100 writes the malicious bytecode into the memory address where the target bytecode was searched, and sets the memory address where the malicious bytecode was written in the VPC. Then, the verification device 100 repeatedly performs detection of a pointer by memory search and calculation of the head address of the structure based on the structural information of the symbol table, and calculates the head address of a management structure that manages the execution state of the script and information of functions. Next, the verification device 100 writes the malicious symbol table into the address searched from the head address of the calculated management structure. After that, the verification device 100 resumes the script engine process for the malicious bytecode and the malicious symbol table written in the memory space of the paused script engine process, thereby executing the malicious bytecode while referring to the malicious symbol table.

[0025] As a result, the verification device 100 can appropriately write malicious bytecode and malicious symbol table to the target bytecode and target symbol table related to the target script being executed by the script engine of the target environment, thereby realizing a bytecode injection attack by malware and verifying the attack resistance of the target environment.

[0026] (1-2. Configuration of Verification Device 100) Next, the configuration of the verification device 100 will be described with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the configuration of the verification device according to the embodiment. The verification device 100 has an input unit 110, an execution processing unit 120, a bytecode injection processing unit 130, and a symbol table injection processing unit 140.

[0027] The input unit 110 is composed of input devices such as a keyboard and a mouse, and receives input of information from the outside and inputs it to each component. The input unit 110 also has a communication interface for transmitting and receiving various information to and from other devices connected via a wired connection or a network, and receives input of information transmitted from other devices. For example, the input unit 110 receives data required for processing performed by the verification device 100, such as architecture information input from the outside, target virtual machine binary, target script, target bytecode, malicious bytecode, target symbol table, and malicious symbol table. The architecture information includes, for example, VPC (Virtual Program Counter), bytecode cache, and structural information of the symbol table.

[0028] The execution processing unit 120 has an execution unit 121, an execution suspension unit 122, a memory enumeration unit 123, and an execution resumption unit 124. The bytecode injection processing unit 130 has a bytecode search unit 131 and a bytecode injection unit. The symbol table injection processing unit 140 has a symbol table search unit 141 and a symbol table injection unit 142.

[0029] Here, we will explain the overall process flow of the verification device 100. In the following, we will first explain the overall process flow of the verification device 100, and then explain each process individually along the process flow.

[0030] The verification device 100 first accepts a target script and a target script engine, and then inputs the target script to the target script engine to execute it. The verification device 100 then waits for the interpretation execution function to be executed, stops the target script engine, and enumerates the stack memory and the heap memory on the script engine process. The verification device 100 then writes a malicious bytecode to the target bytecode searched from the enumerated memory, and writes a malicious symbol table to an address searched from the structural information of the symbol table, and resumes the target script engine.

[0031] The memory enumeration unit 123 enumerates stack memories and heap memories on the script engine process. For example, the memory enumeration unit 123 receives the process of the target script engine that is currently running as an input, and enumerates all heap memories and all stack memories from information of a structure that manages information on the process.

[0032] The bytecode search unit 131 outputs the memory address of the target bytecode searched for in the memory in the bytecode cache. For example, the bytecode search unit 131 searches the enumerated stack memories and heap memories with the target bytecode, finds a bytecode that matches the target bytecode, and outputs the memory address.

[0033] The bytecode injection unit 132 writes malicious bytecode to the memory address output by the above-mentioned bytecode search unit 131. For example, the bytecode injection unit 132 writes the malicious bytecode extracted by the analysis unit 210 described later or the like to the memory address where the target bytecode is found, and sets the memory address where the malicious bytecode is written in the VPC. Here, since the VPC holds the address of the next instruction to be executed in the bytecode, by changing the value of the VPC to the start address of the written malicious bytecode, it is possible to start execution from the start of the malicious bytecode when execution is resumed.

[0034] Based on the structural information of the symbol table, the symbol table search unit 141 repeatedly detects a pointer by memory search and calculates the start address of the structure, and calculates the start address of a management structure that manages the execution state of a script and information on functions. The symbol table search unit 141 also calculates the start address of the management structure starting from a structure that includes a value object selected from the symbol table and searched for in memory. Note that the structure related to the processing of the symbol table search unit 141 described above includes an array.

[0035] Here, a specific example of the symbol table search process will be described with reference to Fig. 3. Fig. 3 is a diagram showing a specific example of the symbol table search process according to the embodiment. First, the structure of the symbol table will be described. As shown in Fig. 3, the symbol table includes a plurality of structures or arrays as elements. Furthermore, in the symbol table, references between elements are defined by pointers. Note that structures and arrays can be said to be variables of a type including a plurality of values.

[0036] 3, the symbol table has structure A, structure B, array C, and structure D. Furthermore, structure A includes a pointer to structure B. Furthermore, structure B includes a pointer to array C. Furthermore, array C includes a pointer to structure D.

[0037] Structure D, which is the end of the symbol table, has a value object. A value object is data related to values ​​used in a script. For example, a value object includes a variable name, a variable type, and a value. "var_name", "int", and "1234" correspond to a variable name, a variable type, and a value, respectively. There are structures that hold information about the execution state of a script, and structures that hold information about functions that are being executed. Such structures are called management structures (hereinafter, when simply written as a structure, it refers to a management structure that manages the execution state of a script and information about functions). In the example of Figure 3, structure A is a management structure.

[0038] Next, the symbol table search process will be described. The symbol table search unit 141 performs a memory search using the value "1234" in the target script, and finds "Structure D", which is the searched value object. Next, the symbol table search unit 141 searches the memory for "Structure D" to find a pointer to "Structure D" in "Array C" (Step α). Next, the symbol table search unit 141 calculates the start address of "Array C" from the structure information (Step β). Here, the structure information has, for example, an offset from the start address of "Array C" for an element in "Array C" that has a pointer to "Structure D", and the start address of "Array C" can be calculated by subtracting this offset from the element that has a pointer to the found "Structure D".

[0039] Then, symbol table search unit 141 performs similar processing (steps α and β) to find a pointer to "array C" in "structure B" and calculate the start address of "structure B." Furthermore, symbol table search unit 141 performs similar processing (steps α and β) to find a pointer to "structure B" in "structure A" and calculate the start address of "structure A."

[0040] Here, since it is known in advance from the structure information that "structure A" is the original management structure, symbol table search unit 141 outputs the top address of "structure A", which is the original management structure.

[0041] This allows the verification device 100 to properly follow the pointers of each structure from "Structure A" to "Structure D" in the original management structure and write the malicious symbol table. Furthermore, the verification device 100 can realize a bytecode injection attack that is difficult to detect in the target environment by calculating the top address of structure A with the minimum behavior of reading / writing and searching memory through the above-mentioned process.

[0042] The symbol table injection unit 142 writes the malicious symbol table to an address searched from the start address of the management structure calculated by the symbol table search unit 141. For example, the symbol table injection unit 142 traces the symbol table corresponding to the range to which the malicious symbol table is to be written from the start address of the management structure calculated by the symbol table search unit 141, and writes the malicious symbol table to the destination.

[0043] The execution resumption unit 124 resumes the script engine process for the malicious bytecode and the malicious symbol table written in the memory space of the paused script engine process, thereby executing the malicious bytecode while referring to the malicious symbol table. For example, the execution resumption unit 124 resumes the execution of the paused target script engine process, thereby executing the malicious bytecode written in the memory space of the paused target script engine process while referring to the malicious symbol table also written in the memory space.

[0044] (1-3. Example of Processing by Verification Device 100) Next, the process flow of the verification device 100 will be described. First, the overall process flow of the verification device 100 will be described with reference to Fig. 4. Fig. 4 is a flowchart showing an example of the overall process of the verification device according to the first embodiment. Note that the processes from the memory enumeration process (S14) to the symbol table injection process (S18) shown in the flowchart of Fig. 4 will be described in detail with reference to the flowcharts shown in Figs. 5 to 10 described later.

[0045] First, the verification device 100 accepts a test script and a virtual machine binary (S11). Then, the execution unit 121 inputs the target script to the target script engine and executes it (S12). Next, the execution pause unit 122 waits for the execution of the interpretation execution function and pauses the target script engine (S13). After that, the memory enumeration unit 123 performs a memory enumeration process (S14).

[0046] Then, the bytecode search unit 131 performs a bytecode search process (S15). Next, the bytecode injection unit 132 performs a bytecode injection process (S16). After that, the symbol table search unit 141 performs a symbol table search process (S17).

[0047] Then, symbol table injection unit 142 performs the symbol table injection process (S18), after which execution resumption unit 124 resumes the execution of the target script engine (S19) and ends the process.

[0048] [Memory enumeration process] Next, the memory enumeration process (S14 in FIG. 4) will be described with reference to FIG. 5 and FIG. 6. FIG. 5 and FIG. 6 are flowcharts showing an example of the memory enumeration process according to the first embodiment. First, the memory enumeration unit 123 receives a process of a target script engine that is currently running as an input (S1401). Then, the memory enumeration unit 123 acquires a structure that manages information about the process (S1402). Next, the memory enumeration unit 123 refers to the structure that manages information about the process and acquires a structure that manages information about the heap (S1403). After that, the memory enumeration unit 123 selects the first heap (S1404).

[0049] Then, the memory enumeration unit 123 acquires the range of the heap from the structure that manages the information of the heap (S1405). Next, the memory enumeration unit 123 reads the memory of the range of the heap (S1406). Thereafter, if the processing of all the heaps is completed (S1407; Yes), the memory enumeration unit 123 refers to the structure that manages the information of the process and enumerates the threads in the process (S1409). On the other hand, if the processing of all the heaps is not completed (S1407; No), the memory enumeration unit 123 selects the next heap (S1408), returns to S1405, and continues the processing.

[0050] After the process of S1409, the memory enumeration unit 123 selects the first thread (S1410). Then, the memory enumeration unit 123 acquires the stack range from the structure that manages thread information (S1411). Next, the memory enumeration unit 123 reads the memory in the stack range (S1412). Thereafter, if the processing of all threads is completed (S1413; Yes), the memory enumeration unit 123 outputs the memories of all stacks and all heaps (S1414) and ends the processing. On the other hand, if the processing of all threads is not completed (S1413; No), the memory enumeration unit 123 selects the next thread (S1415), returns to S1411, and continues the processing.

[0051] [Bytecode search process] Next, the bytecode search process (S15 in FIG. 4) will be described with reference to FIG. 7. FIG. 7 is a flowchart showing an example of the bytecode search process according to the embodiment. First, the bytecode search unit 131 receives a bytecode cache (S151). Then, the bytecode search unit 131 receives a target bytecode (S152). Next, the bytecode search unit 131 receives stack and heap memories (S153). Next, the bytecode search unit 131 selects one of the memories in the bytecode cache (S154).

[0052] After that, the bytecode search unit 131 searches the memory for the target bytecode (S155). If the target bytecode is found (S156; Yes), the bytecode search unit 131 outputs the memory address of the found target bytecode (S157) and ends the process. On the other hand, if the target bytecode is not found (S156; No), the bytecode search unit 131 selects the next memory (S158) and returns to S155 to continue the process.

[0053] [Bytecode injection processing] Next, the bytecode search process (S16 in FIG. 4) will be described with reference to FIG. 8. FIG. 8 is a flowchart showing an example of the bytecode injection process according to the embodiment. First, the bytecode injection unit 132 receives a VPC (S161). Then, the bytecode injection unit 132 receives a process of a target script engine that is running (S162). Next, the bytecode injection unit 132 receives a memory address where the target bytecode was found (S163). Next, the bytecode injection unit 132 receives a malicious bytecode (S164).

[0054] After that, the bytecode injection unit 132 writes the malicious bytecode to the memory address where the target bytecode of the process of the target script engine was found (S165).Then, the bytecode injection unit 132 sets the memory address where the malicious bytecode was written to the VPC (S166), and ends the process.

[0055] [Symbol table search process] Next, the flow of the symbol table search process (S17 in FIG. 4) will be described with reference to FIG. 9. FIG. 9 is a flowchart showing an example of the symbol table search process according to the embodiment. First, the symbol table search unit 141 receives structural information of a symbol table (S1701). Next, the symbol table search unit 141 receives a target symbol table (S1702). Next, the symbol table search unit 141 receives stack and heap memories (S1703).

[0056] After that, the symbol table search unit 141 selects one value object in the symbol table (S1704). Then, the symbol table search unit 141 searches the memory for the selected value object (S1705). If the selected value object is detected (S1706; Yes), the symbol table search unit 141 searches the memory for the start address of the structure and detects the pointer (S1707). On the other hand, if the selected value object is not detected (S1706; No), the symbol table search unit 141 selects the next value object (S1708), returns to S1705, and continues the process.

[0057] After the process of S1707, the symbol table search unit 141 calculates the start address of the structure (S1709). If the parent management structure has been reached (S1710; Yes), the symbol table search unit 141 calculates the start address of the management structure (S1711) and ends the process. On the other hand, if the parent management structure has not been reached (S1710; No), the process returns to S1707 and continues.

[0058] [Symbol table injection processing] Next, the symbol table injection process (S18 in FIG. 4) will be described with reference to FIG. 10. FIG. 10 is a flowchart showing an example of the processing flow of the symbol table injection process according to the embodiment. First, the symbol table injection unit 142 receives the top address of the management structure (S181). Next, the symbol table injection unit 142 receives structural information of the symbol table (S182). Next, the symbol table injection unit 142 receives a malignant symbol table (S183). Then, the symbol table injection unit 142 selects a symbol table of one scope from the malignant symbol table (S184).

[0059] After that, the symbol table injection unit 142 searches for a symbol table of the corresponding scope from the first address of the management structure (S185). Next, the symbol table injection unit 142 writes the symbol table selected from the malignant symbol table to the searched destination (S186). If writing has been completed for all scopes of the malignant symbol table (S187; Yes), the symbol table injection unit 142 ends the process. On the other hand, if writing has not been completed for all scopes of the malignant symbol table (S187; No), the symbol table injection unit 142 selects a symbol table of the next scope (S188), returns to S185, and continues the process.

[0060] (1-4. Effects of the First Embodiment) As described above, the verification device 100 according to this embodiment includes the bytecode injection processing unit 130, the symbol table search unit 141, the symbol table injection unit 142, and the execution processing unit 120. The bytecode injection processing unit 130 writes malicious bytecode into a memory address where the target bytecode has been searched.

[0061] The symbol table search unit 141 repeatedly detects a pointer by memory search and calculates the start address of the structure based on the structural information of the symbol table, and calculates the start address of a management structure that manages the execution state of a script and information on functions. The symbol table injection unit 142 writes the malicious symbol table to an address searched from the start address of the management structure calculated by the symbol table search unit 141. The execution processing unit 120 resumes the script engine process for the malicious bytecode and the malicious symbol table written in the memory space of the paused script engine process, thereby executing the malicious bytecode while referring to the malicious symbol table.

[0062] As a result, the verification device 100 can write malicious bytecode and a malicious symbol table in appropriate locations of a target script executed by a target script engine and execute the script, thereby appropriately implementing a bytecode injection attack by malware. Therefore, the verification device 100 can be used for active cyber defense such as red team activities.

[0063] The verification device 100 also has a memory enumeration unit 123. The memory enumeration unit 123 enumerates stack memories and heap memories on the process of the script engine. The bytecode injection processing unit 130 of the verification device 100 writes malicious bytecode into memory addresses where the target bytecode was found on the stack and heap memories, and sets the memory address where the malicious bytecode was written in the VPC.

[0064] This allows the verification device 100 to search for the target bytecode from the stack memory and heap memory on the script engine process, write the malicious bytecode in the appropriate location, and set the memory address where the malicious bytecode is written to the VPC.By changing the value of VPC to the starting address of the written malicious bytecode, it is possible to start execution from the beginning of the malicious bytecode when execution is resumed.

[0065] Furthermore, the symbol table search unit 141 of the verification device 100 calculates the start address of the management structure starting from the structure containing the value object selected from the symbol table and searched for in the memory. This allows the verification device 100 to search for the value object described in the symbol table in the memory, and to calculate the start address of the management structure by repeatedly detecting the pointer and calculating the start address of the structure, tracing back from the searched structure.

[0066] 2. Embodiment 2 (2-1. Overview of the Second Embodiment) First, the configuration of a verification device 200 according to the second embodiment will be described with reference to Fig. 11. Fig. 12 is a diagram showing an example of the configuration of the verification device according to the second embodiment. The verification device 200 has an analysis unit 210 in which an input unit 110 receives a test script and a binary to be analyzed, and extracts a bytecode, a symbol table, and structural information of the symbol table from the received information.

[0067] The verification device 200 receives a malicious script and a target script as a test script using the function of the analysis unit 210, extracts malicious bytecode and malicious symbol table, target bytecode and target symbol table, and transmits them to the bytecode search unit 131 and the symbol table search unit 141 described above, and each process described in the first embodiment is performed. The analysis unit 210 also extracts structural information of the symbol table. Here, for example, the structural information is an offset from the top address of each element (structure or array) of the symbol table shown in FIG. 3 to each member variable, a reference relationship of pointers included in each element of the symbol table, etc. Therefore, the symbol table search unit 141 etc. can identify the structure of each element and the reference relationship between elements based on the structural information.

[0068] Therefore, in the following, the verification device 200 according to the second embodiment will be described, particularly the processing performed by the analysis unit 210. Note that a description of the same configuration and processing as the verification device 100 according to the first embodiment will be omitted. In addition, in the following, a case where the analysis unit 210 exists inside the verification device 200 will be described, but this is not limiting. For example, a series of processing may be performed by an external device having the function of the analysis unit 210, and the extracted information may be transmitted to the verification device 200.

[0069] (2-2. Configuration of analysis unit 210) First, the configuration of the analysis unit 210 according to the second embodiment will be specifically described with reference to Fig. 12. Fig. 12 is a diagram illustrating an example of the configuration of the analysis unit 210 according to the second embodiment. As shown in Fig. 12, the analysis unit 210 has a control unit 211, a storage unit 212, and an output unit 213.

[0070] The analysis unit 210 receives the test script and the virtual machine binary received by the input unit 110. As the test script, a malicious script that extracts a malicious bytecode and a malicious symbol table, and a target script that extracts a target bytecode and a target symbol table are received.

[0071] Here, the test script is a script that is input when dynamically analyzing the script engine to obtain an execution trace. The test script includes a first test script for VM analysis, a second test script for symbol table detection, and a third test script for symbol table detection. The script engine binary is an executable file that constitutes the script engine. The script engine binary may be composed of multiple executable files.

[0072] [Test script configuration] Let us explain about test scripts. A test script is a script that is input when dynamically analyzing a script engine. This test script focuses on the number of branch instruction executions and memory reads and writes, and is used to capture the difference in the behavior of the script engine that occurs when the test script is executed a different number of times. This test script is prepared before the analysis and is created manually. Creating it requires knowledge of the specifications of the target script language.

[0073] 13 is a diagram showing an example of a first test script used for detecting VPCs. The first test script uses a repetitive process (line 2). The first test script changes the execution conditions and generates differences by increasing or decreasing the number of repetitions (line 2) and the number of repeated statements (lines 3 to 5) in the test script. The first test script is subject to processes from the execution trace acquisition process to the bytecode cache detection process, which will be described later.

[0074] FIG. 14 is a diagram showing an example of a second test script. In the second test script, a characteristic value variable is used to enable matching of values ​​to detect a symbol table. For example, in the example of FIG. 14, the characteristic value is "1234". By including the characteristic value in the second test script, it becomes possible to detect the storage location of this characteristic value from the memory access trace by matching the characteristic value at the time of symbol table detection. The second test script is subject to the execution trace acquisition process and the symbol table detection process, which will be described later. The second test script is used to detect a symbol table having a value object.

[0075] FIG. 15 is a diagram showing an example of a third test script. In the third test script, multiple variables of characteristic values ​​are used. For example, in the example of FIG. 15, the characteristic values ​​are "1234", "5.678", and "9012". The third test script is used in conjunction with the second test script to take differences and detect a symbol table that holds value objects in a linked list.

[0076] Fig. 16 is a diagram showing an example of a fourth test script. Variable g is a global variable. Variable l is a local variable. In a script engine, multiple symbol tables may be held for each value scope, such as a global scope and a local scope. Such a symbol table is detected by a test script using values ​​of multiple scopes, as shown in Fig. 16.

[0077] [Porting script] Fig. 17 is a diagram showing an example of a porting script. By executing the porting script, bytecode and a symbol table to be ported during dynamic bytecode instrumentation are extracted. Fig. 18 is a diagram showing the bytecode and the symbol table generated by executing the porting script shown in Fig. 17.

[0078] As shown in Fig. 17, the porting script includes a function 302 to be ported and a call section 304 of the function to be ported. The function 302 to be ported includes the process content 303 to be ported. When the porting script is executed, bytecode 305 (see Fig. 18) corresponding to the processing portion of the process content 303 to be ported is extracted and ported to the bytecode generated by the script engine in its own memory space based on the porting destination script. By describing various processes for analyzing the behavior of the script in this section, the porting destination script can be analyzed.

[0079] Then, the caller 304 of the function to be ported calls the function to be ported 302, generating bytecode and symbol table 310 (see FIG. 18), which makes it possible to extract the function. The symbol table 310 is ported to a symbol table generated by the script engine in its own memory space based on the porting destination script.

[0080] 19 is a diagram showing an example of a bytecode. Bytecode 305 is an example, and a bytecode exists for each routine. As shown in bytecode 305, for example, the bytecode has a data structure including an opcode 3051 and an operand 3052. The opcode 3051 is a value that specifies the type of operation, and is actually specified by a corresponding hexadecimal value. The operand 3052 is a value that is the target of the operation, and is generally specified by an ordinal number in a symbol table.

[0081] The storage unit 212 is realized by a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk, and stores a processing program that operates the analysis unit 210, data used during execution of the processing program, etc. The storage unit 212 has an execution trace database (DB) 2121, and an architecture information DB 2122 that stores architecture information acquired by a virtual machine analysis unit 2111 and a symbol table analysis unit 2112 (described later).

[0082] The execution trace DB 2121 stores the execution trace acquired by the execution trace acquisition unit 21111. The execution trace DB 2121 is managed by the analysis unit 210. Of course, the execution trace DB 2121 may be managed by another device (such as a server). In this case, the execution trace acquisition unit 21111 (described later) outputs the acquired execution trace to a management server of the execution trace DB 2121 or the like via the communication interface of the output unit 213, and stores the execution trace in the execution trace DB 2121.

[0083] Configure Execution Tracing Next, the execution trace will be explained. Fig. 20 is a diagram showing an example of an execution trace. As described above, an execution trace is composed of a branch trace and a memory access trace. Fig. 20 shows an excerpt of a part of an execution trace. The structure of an execution trace will be explained below with reference to Fig. 20.

[0084] An execution trace has an element called "trace." In "trace," it is indicated whether the log line is a branch trace or a memory access trace.

[0085] A log line of a branch trace has the format shown in lines 1 to 10 of Fig. 20, for example, and consists of three elements: type, src, and dst. type indicates whether the executed branch instruction was a call instruction, a jmp instruction, or a ret instruction. src indicates the address of the branch source, and dst indicates the address of the branch destination.

[0086] A log line of a memory access trace has the format shown, for example, in lines 11 to 13 of Figure 20, and consists of six elements: type, target, base, index, size, and value. Type indicates whether the memory access is a read or write. Target indicates the memory address that is the target of the memory access. Base indicates the value of the base register. Index indicates the value of the index register. Size indicates the size of the memory access. Base and index only exist if the base register or index register was used during memory access. Additionally, value stores the value resulting from the memory access.

[0087] Returning to Fig. 12, the control unit 211 will be described. The control unit 211 has an internal memory for storing programs that define various processing procedures and required data, and executes various processes using these. For example, the control unit 211 is an electronic circuit such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). The control unit 211 has a virtual machine analysis unit 2111, a symbol table analysis unit 2112, and an extraction unit 2113.

[0088] The virtual machine analysis unit 2111 analyzes the VM of the script engine. The virtual machine analysis unit 2111 obtains a plurality of execution traces by changing the conditions at the time of execution, analyzes the plurality of execution traces using differential execution analysis, and obtains the VPC. The virtual machine analysis unit 2111 detects a bytecode cache from the execution traces. The bytecode cache stores the VM instructions to be executed.

[0089] The virtual machine analysis unit 2111 includes an execution trace acquisition unit 21111 , a virtual program counter detection unit 21112 , and a bytecode cache detection unit 21113 .

[0090] The execution trace acquisition unit 21111 receives the first to third test scripts and the script engine binary as input. The execution trace acquisition unit 21111 executes the first to third test scripts while monitoring the execution of the script engine binary, thereby acquiring an execution trace.

[0091] The execution trace is composed of a branch trace and a memory access trace. The branch trace records the type of branch instruction at the time of execution, the branch source address, and the branch destination address. The memory access trace can record all or part of the type of memory operation at the time of execution (read / write), the memory address and value of the operation target, the base register, the index register, and the size of the memory access. It is known that the branch trace and memory access trace can be acquired by hooking the branch instruction and the memory operation instruction, inserting a code for log output, and executing it. The execution trace acquired by the execution trace acquisition unit 21111 is stored in the execution trace DB 2121.

[0092] Furthermore, when acquiring the execution trace, the execution trace acquisition unit 21111 acquires an API (Application Programming Interface) trace and stores it in the execution trace DB 2121. The API trace is a record of the system API called during execution and its arguments.

[0093] The virtual program counter detection unit 21112 extracts and analyzes the execution trace for the first test script stored in the execution trace DB 2121 to detect the VPC. The virtual program counter detection unit 21112 analyzes a plurality of execution traces using differential execution analysis focusing on the number of memory reads to detect the VPC. The virtual program counter detection unit 21112 utilizes the fact that a read into the memory that holds the VPC always occurs after the execution of each VM instruction, and detects the VPC by discovering the read destination.

[0094] For this reason, the virtual program counter detection unit 21112 uses differential execution analysis focusing on the number of memory reads to detect VPCs. The virtual program counter detection unit 21112 compares execution traces of multiple test scripts acquired using the first test script, and finds memories whose memory read counts change in proportion to both the increase and decrease of the number of repetitions and the number of repeated statements. Then, the virtual program counter detection unit 21112 refers to the boundaries of each VM instruction and narrows down the memory values ​​read to those that always point to the start point of the VM instruction. The virtual program counter detection unit 21112 detects this memory as a VPC.

[0095] (Configuring VM Execution Tracing) Here, the VM execution trace will be explained. Fig. 21 is a diagram showing an example of a VM execution trace. As described above, the VM execution trace is a record of the VM opcode and the VPC. Fig. 21 shows a part of the VM execution trace. The configuration of the VM execution trace will be shown below with reference to Fig. 21.

[0096] A log line of a VM execution trace has a format shown in FIG. 21, for example, and consists of two elements, vpc and vmop (vm opcode). vpc indicates the value of VPC. Also, vmop indicates the value of the VM opcode virtually assigned to each pointer that points to the beginning of the VM instruction handler to be executed, obtained from the pointer cache.

[0097] The bytecode cache detection unit 21113 detects a bytecode cache, which is a cache in which virtual machine instructions to be executed are stored, from the VM execution trace based on the execution trace, the VPC and the VM execution trace.

[0098] The bytecode cache detection unit 21113 detects the memory area pointed to by the VPC as a bytecode cache from the VM execution trace. The bytecode cache detection unit 21113 detects the code location of the caller of the memory allocation function that allocated this bytecode cache from the execution trace. The bytecode cache detection unit 21113 detects all memory areas allocated at this code location from the VM execution trace as code caches.

[0099] The bytecode cache detection unit 21113 detects a code location that writes to the bytecode cache from the execution trace. The bytecode cache detection unit 21113 detects writing by this code location from the VM execution trace as an update of the bytecode cache.

[0100] The symbol table analysis unit 2112 detects and analyzes a symbol table. The symbol table analysis unit 2112 includes an interpretation execution function detection unit 21121, a symbol table detection unit 21122, a symbol table analysis unit 21123, and a value object analysis unit 21124.

[0101] Here, the structure of the symbol table will be explained with reference to Fig. 22. Fig. 22 is a diagram for explaining the structure of the symbol table. As shown in Fig. 22, the symbol table includes multiple data structures (structures or arrays). Also, in the symbol table, references between data structures are defined by pointers. Note that structures and arrays can be said to be variables of a type that includes multiple values.

[0102] 22, the symbol table has structure 351, structure 352, array 353, and structure 354. Furthermore, structure 351 includes a pointer to structure 352. Furthermore, structure 352 includes a pointer to array 353. Furthermore, array 353 includes a pointer to structure 354.

[0103] The end of the symbol table, structure 354, contains a value object. A value object is data about a value used in a script. For example, a value object contains a variable name, a variable type, and a value. "var_name", "int", and "1234" correspond to the variable name, variable type, and value, respectively.

[0104] There are structures that hold information about the execution state of a script, and structures that hold information about a function that is being executed. Such structures are called management structures. Structure 351 is a management structure.

[0105] A function that interprets and executes a script is called an interpretation execution function, and the interpretation execution function has a pointer to a management structure as an argument. The interpretation execution function will be explained with reference to Fig. 23. Fig. 23 is a diagram for explaining the interpretation execution function.

[0106] The function "interp" in Figure 23 is an interpretation execution function. Additionally, "script_ctx_info" and "func_info" are arguments to the function "interp." "script_ctx_info" is a pointer to a structure that holds information about the execution state of a script. Additionally, "func_info" is a pointer to a structure that holds information about the function being executed. In other words, both "script_ctx_info" and "func_info" are pointers to management structures.

[0107] Note that the management structure and the symbol table do not have to correspond one-to-one. The management structure can have multiple different symbol tables for each scope within the script of the values ​​held by the symbol table.

[0108] The symbol table analyzer 2112 obtains the execution trace, the VPC, and the bytecode cache from the virtual machine analyzer 2111 .

[0109] The interpretive execution function detection unit 21121 detects an interpretive execution function from an execution trace. First, the interpretive execution function detection unit 21121 receives input of an execution trace, a VPC, and a bytecode cache.

[0110] The interpretive execution function detection unit 21121 detects functions from call and return branches in a branch trace included in the execution trace. Then, the interpretive execution function detection unit 21121 detects, among the detected functions, a function that performs memory access to a VPC or a bytecode cache as an interpretive execution function.

[0111] The symbol table detection unit 21122 detects a symbol table from the execution trace. First, the symbol table detection unit 21122 receives an input of the execution trace and an interpretation execution function. The symbol table detection unit 21122 executes the interpretation execution function while monitoring it, and obtains arguments of the interpretation execution function.

[0112] The symbol table detection unit 21122 assigns a unique taint tag to the acquired arguments that are pointers. Furthermore, the symbol table detection unit 21122 executes the interpretation execution function while propagating the taint tag. This method of propagating taint tags is called taint analysis.

[0113] Fig. 24 is a diagram for explaining taint analysis in which a taint is propagated when a pointer is referenced. In the taint analysis in this embodiment, the symbol table detection unit 21122 propagates a taint when a pointer is referenced, in addition to general taint propagation in accordance with data movement. As shown in Fig. 24, first, the symbol table detection unit 21122 assigns a taint tag 373 to an address of a memory area 371. Then, when data to which the taint tag 373 is assigned is referenced as a pointer during execution of a test script, the symbol table detection unit 21122 propagates the taint tag 373 to an address that holds a value referenced by the pointer.

[0114] Propagating a taint tag may involve, for example, adding information to a taint map, which is a data structure that holds a correspondence between memory addresses and taint tags assigned to each address.

[0115] Here, the symbol table detection unit 21122 searches the memory access trace for a characteristic value included in the test script and identifies a matching memory access (matching of characteristic values). The symbol table detection unit 21122 stores the identified target of memory access as a value in the symbol table.

[0116] The symbol table detection unit 21122 detects a memory area to which a taint tag that is the same as a value in the symbol table is assigned as a symbol table, and outputs a taint map.

[0117] 22, the symbol table detection unit 21122 identifies a memory access to the value "1234" of the structure 354. In this case, "1234" is a characteristic value. Here, the same taint tag as the value "1234" is assigned to each pointer from the management structure 351 to the value "1234" of the structure 354.

[0118] As a result, the symbol table detection unit 21122 can detect a symbol table including a pointer to structure 352, a pointer to array 353, a pointer to structure 354, and the value of structure 354, "1234".

[0119] On the other hand, at this point, the structure of the structure or array including the value and the pointer is unknown. For example, it is not known at this point that the pointer to array 353 held by structure 352 is a member variable of structure 352, and the offset of the member variable from the start address of structure 352 is also unknown. Therefore, symbol table analyzer 21123 analyzes the structures of the structures and arrays included in the symbol table. Symbol table analyzer 21123 performs reference analysis and structural analysis.

[0120] (Reference analysis) Reference analysis will be described with reference to Fig. 25. Fig. 25 is a diagram for explaining reference analysis. The symbol table analyzer 21123 performs reference analysis by utilizing the fact that the effective address of a structure is specified by offset reference from the start address (base register) and that the effective address of an array is specified by index reference from the start address (base register).

[0121] If a memory access with a taint tag uses a base register and does not use an index register, the symbol table analyzer 21123 determines that the access destination of the memory access is a member variable of a structure.Then, the symbol table analyzer 21123 calculates an offset from the difference between the effective address and the base register.The symbol table analyzer 21123 also obtains the start address of the structure from the base register.

[0122] 25, before the reference analysis is performed, it is unknown whether data structure 382 is a structure or an array. The memory access to which taint tag 386 of data structure 382 is assigned uses a base register and does not use an index register. As a result, symbol table analyzer 21123 regards the access destination of the memory access to which taint tag 386 of data structure 382 is assigned as a member variable of the structure. Here, symbol table analyzer 21123 sets the value of the base register as the start address of data structure 382, ​​which is a structure. Then, symbol table analyzer 21123 calculates an offset from the start address of data structure 382 from the difference between the effective address of the member variable and the base register.

[0123] If a tainted tagged memory access uses a base register and an index register, the symbol table analyzer 21123 determines that the memory access destination is an element of an array. The symbol table analyzer 21123 then obtains the head and subscript of the array from the base register and index register.

[0124] 25, before the reference analysis is performed, it is unknown whether data structure 383 is a structure or an array. The memory access to which taint tag 387 of data structure 383 is assigned uses a base register and an index register. Thus, symbol table analyzer 21123 regards the access destination of memory access to which taint tag 387 of data structure 383 is assigned as an element of an array, and obtains the head and subscript of the array from the base register and index register. Note that "C[i]" means "element with subscript i of array C."

[0125] (Structural analysis) Structural analysis will be described with reference to Fig. 26 and Fig. 27. Fig. 26 and Fig. 27 are diagrams for explaining structural analysis. The symbol table analyzer 21123 analyzes whether the detected symbol table holds value objects in an array or in a linked list, and if it holds them in a linked list, analyzes the structure. For example, in the symbol table ending in structure 354 in Fig. 22 (wherein structure 351 is a management structure), array 253 holds a reference to structure 354, which is a value object, so it is determined that the detected symbol table holds value objects in an array.

[0126] On the other hand, if a structure holds a reference to a structure that is a value object, the symbol table analyzer 21123 determines that the detected symbol table holds the value object in a linked list. In this case, the symbol table analyzer 21123 regards the symbol table as a data structure that combines a linked list and a data structure other than a linked list. For example, the linked list includes a reference to a value object and a reference to the next element.

[0127] When the symbol table holds value objects in an array, the length of the reference from the management structure to each value object is constant regardless of the number of value objects.

[0128] For example, in the symbol table ending at structure 354 in Figure 22 (where structure 351 is a management structure), it takes three references to reach the value object, so the reference length is 3. Since value objects are managed as an array, the reference length is constant regardless of the number of value objects. Note that a management structure cannot become a value object, so the minimum reference length is 1.

[0129] On the other hand, when the symbol table holds value objects in a linked list, the length of the reference from the management structure to each value object may vary depending on the number of value objects.

[0130] When the symbol table analyzer 21123 determines that the symbol table holds value objects in a linked list, it compares the references from the management structures of the symbol tables for multiple test scripts with different numbers of variables to the value objects, and determines the difference between the references and identifies (estimates) linked lists and data structures other than linked lists. This enables the symbol table analyzer 21123 to detect the structures of value objects and linked lists.

[0131] If the symbol table analysis unit 21123 determines that the symbol table holds value objects in a linked list, it can detect the structure of the value objects and the linked list by comparing references to value objects from the symbol table management structure for multiple test scripts with different numbers of variables and taking the differences.

[0132] For example, if the obtained reference lengths are 3, 5, and 4, at least three references are required from the management structure to the value object, and two references are not enough to reach the value object. From this, symbol table analyzer 21123 estimates that the three data structures including the common part, the management structure (corresponding to two references), are data structures other than a linked list. Then, symbol table analyzer 21123 estimates that the subsequent references, which are the differences, are linked lists.

[0133] 26 includes data structures other than the linked list from structure 391, which is a management structure, to the structure immediately preceding structure 3921, and linked list 392. Linked list 392 includes structure 3921 and structure 3922. Structure 3922 is a value object.

[0134] 27 includes data structures other than the linked list from structure 396, which is a management structure, to the structure immediately preceding structure 3971, and linked list 397. Linked list 397 includes structure 3971, structure 3972, structure 3973, structure 3974, structure 3975, and structure 3976. Structures 3974, structure 3975, and structure 3976 are value objects.

[0135] Here, structures such as value objects (structure 3974, etc.) shown in Figs. 26 and 27 may be called tagged unions. For example, when a test script such as "i=1234" is held, the tagged union has a part that holds a value such as "1234" and another part that holds a tag such as "0x1". However, it is not easy to distinguish between the tag part of the tagged union and the part of the union that holds the value of the test script. Note that in Figs. 26 and 27, the value part is expressed in decimal such as "1234" to facilitate understanding, but the value exists in memory as a binary number (or hexadecimal number).

[0136] The value object parser 21124 determines that the portion hit by matching "1234" corresponding to the test script is the portion of the tagged union where a difference occurs depending on the value of the test script (the portion that holds the value of the test script). In this way, the value object parser 21124 detects the portion excluding the portion where a difference occurs depending on the value of the test script. The value object parser 21124 also considers variable name portions such as "i", "j", and "k" as portions where a difference occurs depending on the value of the test script. For example, the value object parser 21124 detects the value portion "1234" and the variable name portion "i" from the structure 3974.

[0137] Similarly, when "j=5.678" and "k="9012"" are stored as test scripts, the value object analysis unit 21124 detects the portion excluding the portion where the difference occurs depending on the value of the test script. The value object analysis unit 21124 compares the portions of the structures storing the respective test scripts excluding the portion where the difference occurs depending on the value of the test script, and detects the member variables where the difference occurs depending on the type of the test script as the portion where the tag is stored (the portion where the difference occurs depending on the type). For example, for "j=5.678" of the test script, the value object analysis unit 21124 detects the portion "5.678" that stores the value and the portion "0x2" that stores the other tag. The type of "j=5.678" is, for example, a floating point. For example, for "k="9012"" of the test script, the value object analysis unit 21124 detects the portion ""9012"" that stores the value and the portion "0x3" that stores the other tag. Note that the type of "k="9012"" is, for example, a string.

[0138] As a result, the value object analysis unit 21124 can appropriately extract the tag part of a tagged union by detecting the part where a difference occurs due to the type of the test script from the part of the tagged union that is detected by comparing the test script values ​​and excluding the part where a difference occurs due to the test script value. Note that in the above-mentioned process, a search for the test script value is performed to detect the part where a difference occurs due to the test script value, but this is not limited to this, and for example, the detection process can be performed by using the number of occurrences of the value instead of searching for the value.

[0139] The extraction unit 2113 receives a porting script as an input. The extraction unit 2113 executes the porting script to extract porting bytecode and porting symbol table based on information about the architecture acquired by analysis by the virtual machine analysis unit 2111 and information about the symbol table acquired by analysis by the symbol table analysis unit 2112. The extraction unit 2113 includes a bytecode extraction unit 21131 and a symbol table extraction unit 21132.

[0140] The bytecode extraction unit 21131 executes the porting script while monitoring writing and execution of the bytecode cache detected by the bytecode cache detection unit 21113, and extracts the data written in the bytecode cache as the porting bytecode.

[0141] The symbol table extraction unit 21132 executes the porting script, obtains a pointer to the management structure from the argument of the interpretation execution function, and further extracts the porting symbol table by tracing back from the management structure using the symbol table reference and structure information.

[0142] The output unit 213 outputs the bytecode and symbol table extracted by the extraction unit 2113, structural information of the symbol table, and architecture information including VPC, bytecode cache, structural information of the symbol table, etc. to the execution processing unit 120, the bytecode injection processing unit 130, or the symbol table injection processing unit 140.

[0143] Through the above-mentioned series of processes, the analysis unit 210 extracts a malicious bytecode and a malicious symbol table by receiving an input of a malicious script, and extracts a target bytecode and a target symbol table by receiving an input of a target script. The analysis unit 210 then outputs each of the extracted information to the bytecode injection processing unit 130 or the symbol table injection processing unit 140, thereby executing the process described in the first embodiment and realizing a bytecode injection attack.

[0144] (2-3. An example of processing by the analysis unit 210) Next, a process flow of the analysis unit 210 will be described. First, an overall process flow of the analysis unit 210 will be described with reference to Fig. 28. Fig. 28 is a flowchart showing an example of an overall process of the analysis unit according to the second embodiment.

[0145] First, the analysis unit 210 receives an input of a test script and a script engine binary (step S21).

[0146] A script engine binary is an executable file that makes up a script engine. A script engine binary may consist of multiple executable files.

[0147] Next, the execution trace acquisition unit 21111 executes an execution trace acquisition process (step S22). The virtual program counter detection unit 21112 executes a virtual program counter detection process (step S23). The bytecode cache detection unit 21113 executes a bytecode cache detection process (step S24).

[0148] Next, the interpretation execution function detection unit 21121 executes an interpretation execution function detection process (step S25). The symbol table detection unit 21122 executes a symbol table detection process (step S26). The symbol table analysis unit 21123 executes a symbol table analysis process (step S27).

[0149] Next, the value object analysis unit 21124 executes a value object analysis process (step S28). The bytecode extraction unit 21131 executes a bytecode extraction process (step S29). The symbol table extraction unit 21132 executes a symbol table extraction process (step S30). Then, the output unit 213 outputs the bytecode, the symbol table, and structural information of the symbol table (step S31).

[0150] Next, the details of the processing procedure of the execution trace acquisition process (S22 in FIG. 28) will be described with reference to Fig. 29. Fig. 29 is a flowchart showing the processing procedure of the execution trace acquisition process.

[0151] 29, first, the execution trace acquisition unit 21111 receives a test script and a script engine binary as input (step S221). Next, the execution trace acquisition unit 21111 hooks the virtual machine to acquire a branch trace (step S222). In addition, the execution trace acquisition unit 21111 hooks the virtual machine to acquire a memory access trace (step S223).

[0152] Here, the execution trace acquisition unit 21111 inputs the test script into the virtual machine and executes it (step S224).Then, the execution trace acquisition unit 21111 stores the acquired execution trace in the execution trace DB 2121 (step S225).

[0153] If the execution trace acquisition unit 21111 has not executed all the input test scripts (step S226, No), the process returns to step S224 and repeats the process. On the other hand, if the execution trace acquisition unit 21111 has executed all the input test scripts (step S226, Yes), the process ends.

[0154] The virtual program counter detection process (step S23 in FIG. 28) will be described in detail with reference to FIG 30. FIG 30 is a flowchart showing the procedure of the virtual program counter detection process.

[0155] As shown in FIG. 30, first, the virtual program counter detection unit 21112 extracts one execution trace by the first test script from the execution trace DB 2121 (step S2301).

[0156] Next, the virtual program counter detection unit 21112 focuses on the memory access trace and counts the number of reads for each memory read destination (step S2302). The virtual program counter detection unit 21112 receives as input the first test script used to acquire the execution trace (step S2303). The virtual program counter detection unit 21112 analyzes the test script to acquire the number of repetitions and the number of repeated statements (step S2304).

[0157] Next, the virtual program counter detection unit 21112 extracts another execution trace by the first test script having a different number of repetitions or number of repeated statements from the execution trace DB 2121 (step S2305). The virtual program counter detection unit 21112 focuses on the memory access trace and counts up the number of reads for each memory read destination (step S2306). The virtual program counter detection unit 21112 receives as input the first test script used to obtain the execution trace (step S2307).

[0158] Then, the virtual program counter detection unit 21112 analyzes the test script to obtain the number of repetitions and the number of repeated statements (step S2308).The virtual program counter detection unit 21112 narrows down the memory read destinations to only those whose read counts change in proportion to the increase or decrease in the number of repetitions or the number of repeated statements (step S2309).The virtual program counter detection unit 21112 narrows down the memory read destinations to those whose read values ​​always point to the start point of the VM instruction (step S2310).

[0159] If the virtual program counter detection unit 21112 narrows down the memory read destinations to only one (step S2311, Yes), it stores the narrowed down read destination as a virtual program counter in the architecture information DB 2122 (step S2312). On the other hand, if the virtual program counter detection unit 21112 cannot narrow down the memory read destinations to only one (step S2311, No), it returns to step S2305 and repeats the process.

[0160] The bytecode cache detection process (step S24 in FIG. 28) will be described in detail with reference to FIG 31. FIG 31 is a flowchart showing the procedure of the bytecode cache detection process.

[0161] As shown in FIG. 31, first, the bytecode cache detection unit 21113 receives an execution trace and a VM execution trace as input (step S241).

[0162] Next, the bytecode cache detection unit 21113 acquires the memory area pointed to by the VPC from the VM execution trace (step S242). The bytecode cache detection unit 21113 acquires the code location of the caller of the memory allocation function that has allocated the memory area from the execution trace (step S243).

[0163] Next, the bytecode cache detection unit 21113 detects all areas secured at the code location as bytecode cache (step S244). The bytecode cache detection unit 21113 acquires the code location that writes to the bytecode cache from the execution trace (step S245). The bytecode cache detection unit 1213 detects all areas written at the code location as updates to the bytecode cache (step S246).

[0164] The bytecode cache detection unit 21113 returns the bytecode cache and its updated portion (step S247).

[0165] The interpretation execution function detection process (step S25 in FIG. 28) will be described in detail with reference to FIG 32. FIG 32 is a flowchart showing the procedure of the interpretation execution function detection process.

[0166] 32, first, the interpretation execution function detection unit 21121 receives an execution trace as an input (step S251). The interpretation execution function detection unit 21121 receives a VPC and a bytecode cache as an input (step S252).

[0167] Next, the interpretive execution function detection unit 21121 detects each function from the call and return branches in the branch trace (step S253). Here, the interpretive execution function detection unit 21121 extracts one function (step S254). The interpretive execution function detection unit 21121 scans the memory access trace within the function (step S255).

[0168] If a memory access to a VPC or a bytecode cache is detected (Yes at step S256), the interpretive execution function detection unit 21121 outputs the function as an interpretive execution function (step S257).

[0169] If no memory access to the VPC or bytecode cache is found (step S256, No), the interpretive execution function detection unit 21121 extracts the next function (step S258) and returns to step S255.

[0170] The symbol detection process (step S26 in FIG. 28) will be described in detail with reference to Fig. 33. Fig. 33 is a flowchart showing the processing procedure of the symbol table detection process.

[0171] 33, first, the symbol table detection unit 21122 receives an execution trace as an input (step S2601). The symbol table detection unit 21122 receives an interpretation execution function as an input (step S2602).

[0172] Next, the symbol table detection unit 21122 executes the interpretation execution function while monitoring it (step S2603). The symbol table detection unit 21122 acquires arguments of the interpretation execution function (step S2604). If the arguments are pointers, the symbol table detection unit 21122 assigns each of the arguments a unique taint tag (step S2605). The symbol table detection unit 21122 executes while propagating the taint tag according to the pointer reference (step S2606).

[0173] Here, the symbol table detection unit 21122 extracts one characteristic value in the test script (step S2607).The symbol table detection unit 21122 searches the memory access trace for the characteristic value (step S2608).

[0174] When a memory access of a characteristic value is detected (step S2609, Yes), the symbol table detection unit 21122 detects the target of the memory access as a value in the symbol table (step S2611).

[0175] If no memory access of a characteristic value is found (step S2609, No), the symbol table detection unit 21122 extracts the next characteristic value (step S2610).

[0176] If all characteristic values ​​have not been processed (step S2612, No), the symbol table detection unit 21122 extracts the next characteristic value (step S2610).

[0177] When all characteristic values ​​have been processed (Yes at step S2612), the symbol table detection unit 21122 checks the taint tags assigned to the values ​​in the symbol table (step S2613).

[0178] The symbol table detection unit 21122 determines that the taint tag is related to a symbol table (step S2614). The symbol table detection unit 21122 determines that the memory area to which the taint tag is assigned is a symbol table (step S2615). The symbol table detection unit 21122 outputs a taint map related to the taint tag (step S2616).

[0179] The symbol table analysis process (step S27 in FIG. 28) will be described in detail with reference to FIG 34. FIG 34 is a flowchart showing the processing procedure of the symbol table detection process.

[0180] 34, first, the symbol table analyzer 21123 receives an execution trace as an input (step S2701). The symbol table analyzer 21123 receives a taint map of the symbol table as an input (step S2702).

[0181] Next, the symbol table analyzer 21123 extracts one value with a taint tag from the taint map (step S2703).The symbol table analyzer 21123 searches the memory access trace with the extracted value (step S2704).

[0182] If no memory access using the value is found (step S2705, No), the symbol table analyzer 21123 extracts the next value (step S2706) and returns to step S2704.

[0183] If a memory access using a value is found (step S2705, Yes), the symbol table analysis unit 21123 executes a reference analysis process (step S2707) and a structure analysis process (step S2708), and outputs information on the reference and structure of the symbol table (step S2709).

[0184] The reference analysis process (step S2707 in FIG. 34) will be described in detail with reference to FIG 35. FIG 35 is a flowchart showing the processing procedure of the reference analysis process.

[0185] As shown in FIG. 35, first, the symbol table analyzer 21123 receives as an input a specific memory access seen in a memory access trace (step S2741).

[0186] The symbol table analyzer 21123 determines whether the memory access uses a base register (step S2742) and whether the memory access uses an index register (step S2743).

[0187] If the memory access does not use the base register (step S2742, No), the symbol table analyzer 21123 determines that the memory access destination is neither an array nor a structure (step S2755). If the memory access uses the base register but does not use the index register (step S2742: Yes and step S2743: No), the symbol table analyzer 21123 determines that the memory access destination is a member variable of a structure (step S2744). If the memory access uses both the base register and the index register (step S2742 and step S2743: Yes), the symbol table analyzer 21123 determines that the memory access destination is an element of an array (step S2749).

[0188] Following step S2744, the symbol table analyzer 21123 executes the following process. The symbol table analyzer 21123 acquires the base register and effective address at the time of the memory access (step S2745). The symbol table analyzer 21123 detects the value of the base register as the start address of the structure at the memory access destination (step S2746).

[0189] The symbol table analyzer 21123 calculates the offset of the member variable of the structure of the memory access destination from the difference between the effective address and the base register (step S2747). The symbol table analyzer 21123 outputs the top address and offset of the structure (step S2748).

[0190] Following step S2749, the symbol table analyzer 21123 executes the following process. The symbol table analyzer 21123 acquires the base register and index register at the time of the memory access (step S2750). The symbol table analyzer 21123 detects the value of the base register as the starting address of the array at the memory access destination (step S2751).

[0191] The symbol table analyzer 21123 detects the value of the index register as the subscript of the array of the memory access destination (step S2752).The symbol table analyzer 21123 calculates the offset of the element of the array of the memory access destination from the difference between the effective address and the base register (step S2753).The symbol table analyzer 21123 outputs the top address, subscript, and offset of the array (step S2754).

[0192] The structure analysis process (step S2708 in FIG. 34) will be described in detail with reference to FIG. 36. FIG. 36 is a flowchart showing the procedure of the structure analysis process.

[0193] As shown in FIG. 36, first, the symbol table analyzer 21123 receives as an input a specific memory access seen in a memory access trace (step S2771).

[0194] If the value objects of the symbol table are managed by an array (Yes at step S2772), the symbol table analysis unit 21123 outputs the structure of the array obtained by the reference analysis (step S2773).

[0195] If the value objects of the symbol table are not managed in an array (step S2772, No), the symbol table analyzer 21123 accepts multiple test scripts as input (step S2774). The symbol table analyzer 21123 performs processing up to reference analysis processing for each test script (step S2775). The symbol table analyzer 21123 extracts references from the management structure to value objects from the references of each test script (step S2776).

[0196] Here, the symbol table analyzer 21123 obtains the difference in the references (step S2777). If the symbol table analyzer 21123 finds no difference in the length of the references according to the number of values ​​in the test script (step S2778, No), the process ends.

[0197] If a difference in the length of the reference is found according to the number of values ​​in the test script (Yes at step S2778), the symbol table analyzer 21123 determines that the part where the difference is found is a linked list (step S2779).

[0198] The symbol table analyzer 21123 detects, from the reference, a member variable having a reference that connects elements of the linked list (step S2780). The symbol table analyzer 21123 detects, from the reference, a value object portion that an element of the linked list has (step S2781). The symbol table analyzer 21123 outputs the structure of the linked list (step S2782).

[0199] The value object analysis process (step S28 in FIG. 28) will be described in detail with reference to FIG 37. FIG 37 is a flowchart showing the procedure of the value object analysis process.

[0200] 37, first, the value object analysis unit 21124 receives a plurality of test scripts as input (step S281). The value object analysis unit 21124 receives a plurality of structures as input (step S282).

[0201] The value object analysis unit 21124 detects member variables that hold values ​​of the test script from the structure by matching (step S283). The value object analysis unit 21124 extracts a portion of the structure that does not depend on the value of the test script (step S284).

[0202] The value object analysis unit 21124 finds differences between structures while associating them with test scripts (step S285). The value object analysis unit 21124 detects member variables for which differences are found depending on the type of the test script as parts that hold tags (step S286).

[0203] The value object analysis unit 21124 detects the correspondence between the tag value and the type by examining the dependency between the test script type and the tag value from the difference (step S287).The value object analysis unit 21124 detects the type held by the structure from the type of the tag value for the test script value (step S288).

[0204] The bytecode extraction process (step S29 in FIG. 28) will be described in detail with reference to FIG. 38. FIG. 38 is a flowchart showing the procedure of the bytecode extraction process.

[0205] 38, first, the bytecode extraction unit 21131 accepts a VPC as an input (step S2901). The bytecode extraction unit 21131 accepts a bytecode cache as an input (step S2902). The bytecode extraction unit 21131 accepts a script to be extracted as an input (step S2903). The bytecode extraction unit 21131 accepts a script engine binary as an input (step S2904).

[0206] The bytecode extraction unit 21131 executes the script to be extracted (step S2905). The bytecode extraction unit 21131 stops the execution at the interpretation execution function (step S2906). The bytecode extraction unit 21131 extracts the bytecode from the bytecode cache (step S2907). The bytecode extraction unit 21131 resumes the execution, and stops the execution again at the time of the execution of the first VM instruction (step S2908).

[0207] The bytecode extraction unit 21131 extracts the value of the VPC (step S2909). The bytecode extraction unit 21131 outputs the extracted bytecode and the value of the VPC (step S2910).

[0208] The symbol table extraction process (step S30 in FIG. 28) will be described in detail with reference to Fig. 39. Fig. 39 is a flowchart showing the processing procedure of the symbol table extraction process.

[0209] 39, first, the symbol table extraction unit 21132 receives symbol table reference and structure information as input (step S301). The symbol table extraction unit 21132 receives a script to be extracted as input (step S302). The symbol table extraction unit 21132 receives a script engine binary as input (step S303).

[0210] The symbol table extraction unit 21132 executes the script to be extracted (step S304). The symbol table extraction unit 21132 stops execution at the interpretation execution function (step S305). The symbol table extraction unit 21132 acquires a pointer to the management structure from the argument of the interpretation execution function (step S306). The symbol table extraction unit 21132 extracts the symbol table by tracing from the management structure based on the symbol table reference and structure information (step S307). The symbol table extraction unit 21132 outputs the extracted symbol table (step S308).

[0211] (2-4. Effects of the Second Embodiment) As described above, the verification device 200 of embodiment 2 further includes a symbol table analysis unit 21123 that analyzes the execution trace obtained by having the program execute a first script and acquires structural information of the symbol table included in the execution trace, and a symbol table extraction unit 21132 that extracts a symbol table based on the information acquired by the symbol table analysis unit 21123 from the data in the memory area obtained by having the program execute a second script. The symbol table search unit 141 calculates the top address of the management structure based on the structural information of the symbol table acquired by the symbol table analysis unit 21123, and the symbol table injection unit 142 writes the malignant symbol table extracted by the symbol table extraction unit 21132 to the address.

[0212] As a result, the verification device 200 can detect the symbol table when a malicious script and a target script are input, and use information obtained by detailed analysis of the structure and relationships to perform a bytecode injection attack on the target environment, thereby enabling malware to perform bytecode injection attacks on script engines of a wide variety of scripting languages ​​whose internal structures are unknown.

[0213] [3. System configuration, etc.] Of the processes described in the above embodiment 1 or embodiment 2, some of the processes described as being performed automatically can be performed manually. Alternatively, all or some of the processes described as being performed manually can be performed automatically by a known method. In addition, the information including the processing procedures, specific names, various data and parameters shown in the above documents and drawings can be changed arbitrarily unless otherwise specified. For example, the various information shown in each drawing is not limited to the illustrated information.

[0214] In addition, each component of each device shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure, and all or a part of it can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions. Furthermore, each processing function performed by each device can be realized in whole or in any part by a CPU and a program analyzed and executed by the CPU, or can be realized as hardware using wired logic.

[0215] 12 may be held in a storage server or the like, rather than being held by the analysis unit 210. In this case, the analysis unit 210 acquires various pieces of information by accessing the storage server.

[0216] [4. Hardware Configuration] Fig. 40 is a diagram showing an example of a hardware configuration. The above-described verification device 100 according to the first embodiment or the verification device 200 according to the second embodiment is realized by a computer 1000 having a configuration as shown in Fig. 40, for example.

[0217] 40 is a diagram showing an example of a computer that executes a verification program. The computer 1000 has, for example, a memory 1010 and a CPU 1020. The computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0218] The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012. The ROM 1011 stores a boot program such as a BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to a hard disk drive 1090. The disk drive interface 1040 is connected to a disk drive 1041. A removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1041. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

[0219] The hard disk drive 1090 stores, for example, an OS (Operating System) 1091, an application program 1092, a program module 1093, and program data 1094. That is, a program that defines each process of the verification device 100 or the verification device 200 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, the program module 1093 for executing the same process as the functional configuration of the verification device 100 or the verification device 200 is stored in the hard disk drive 1090. The hard disk drive 1090 may be replaced by an SSD (Solid State Drive).

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

[0221] Note that the program module 1093 and the program data 1094 are not limited to being stored in the hard disk drive 1090, but may be stored in, for example, a removable storage medium and read by the CPU 1020 via the disk drive 1041 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (LAN, WAN, etc.). Then, the program module 1093 and the program data 1094 may be read by the CPU 1020 from the other computer via the network interface 1070. [Explanation of symbols]

[0222] 100, 200 Verification device 110 Input section 120 Execution Processing Unit 121 Executive Department 122 Execution pause section 123 Memory Enumeration Unit 124 Execution resume section 130 Bytecode injection processing unit 131 Bytecode Search Unit 132 Bytecode Injector 140 Symbol table injection processing unit 141 Symbol Table Search Unit 142 Symbol Table Injection Section 210 Analysis Department 211 Control Unit 2111 Virtual Machine Analysis Department 21111 Execution trace acquisition unit 21112 Virtual Program Counter Detector 21113 Bytecode cache detector 2112 Symbol table analysis unit 21121 Interpretation execution function detection unit 21122 Symbol table detector 21123 Symbol table analysis unit 21124 Value Object Parser 2113 Extraction part 21131 Bytecode Extraction Unit 21132 Symbol table extraction unit 212 Storage section 2121 Execution Trace DB 2122 Architecture Information DB 213 Output section

Claims

1. a bytecode injection processor that writes a malicious bytecode into a memory address where a target bytecode is found; a symbol table search unit that repeatedly performs memory search to detect pointers and calculate the start addresses of structures based on structural information of the symbol table, and calculates the start addresses of management structures that manage the execution states of scripts and information about functions; a symbol table injection unit that writes a malicious symbol table into an address searched from the start address of the management structure calculated by the symbol table search unit; an execution processing unit that executes the malicious bytecode and the malicious symbol table written in a memory space of the suspended script engine process by restarting the script engine process, while referring to the malicious symbol table; A verification device comprising:

2. A memory enumeration unit that enumerates a stack memory and a heap memory on the process of the script engine, The bytecode injection processing unit writes a malicious bytecode to a memory address where a target bytecode was searched in the stack memory and the heap memory, and sets the memory address where the malicious bytecode was written in a virtual program counter.

2. The verification device according to claim 1.

3. The symbol table search unit calculates a start address of the management structure from a structure including the value object selected from the symbol table and searched for in the memory as a starting point.

2. The verification device according to claim 1.

4. a symbol table analysis unit that analyzes an execution trace obtained by executing a first script in a program and acquires structural information of the symbol table included in the execution trace; a symbol table extraction unit that extracts the malicious symbol table from data in a memory area obtained by executing a second script in the program based on information acquired by the symbol table analysis unit; and the symbol table search unit calculates a start address of the management structure based on the structural information of the symbol table acquired by the symbol table analysis unit; The symbol table injection unit writes the malicious symbol table extracted by the symbol table extraction unit to the address.

2. The verification device according to claim 1.

5. A verification method performed by a verification device, comprising: a bytecode injection process for writing a malicious bytecode to a memory address where a target bytecode is retrieved; a symbol table search step for repeatedly detecting a pointer by memory search and calculating the start address of a structure based on structural information of the symbol table, and calculating the start address of a management structure for managing the execution state of a script and information on functions; a symbol table injection step of writing a malicious symbol table to an address searched from the start address of the management structure calculated by the symbol table search step; an execution process step of executing the malicious bytecode and the malicious symbol table written in the memory space of the suspended script engine process by restarting the script engine process, while referring to the malicious symbol table; A verification method comprising:

6. a bytecode injection procedure for writing a malicious bytecode to a memory address where a target bytecode is retrieved; a symbol table search procedure for repeatedly detecting a pointer by memory search and calculating the start address of a structure based on structural information of the symbol table, and calculating the start address of a management structure for managing the execution state of a script and information on functions; a symbol table injection step of writing a malicious symbol table to an address searched from the start address of the management structure calculated by the symbol table search step; an execution process step of executing the malicious bytecode and the malicious symbol table written in the memory space of the suspended script engine process by restarting the script engine process, while referring to the malicious symbol table; A verification program for running the above on a computer.

Images