Analysis apparatus, analysis method, and analysis program

Abstract

To obtain information on the internal structure of a symbol table, regarding a script engine for a script language of unknown specifications.SOLUTION: An analysis apparatus 10 includes a symbol table detection unit 1222 and a symbol table analysis unit 1223. The symbol table detection unit 1222 detects, in a memory region used by a program for executing a script, from a first address, a plurality of structures including addresses on a reference path to a second address including a value designated in the script, as a symbol table. The symbol table analysis unit 1223 analyzes an execution trace obtained by causing the program to execute the script, to obtain structure information of the symbol table detected by the symbol table detection unit 1222.SELECTED DRAWING: Figure 4

Description

[Technical field]

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

[0002] [Script Analysis] Script analysis techniques are used for a variety of purposes, including compiler optimization for just-in-time (JIT) compilation, software testing and debugging, fuzzing, and malware analysis.

[0003] [Importance of obtaining variable information] Obtaining variable information is one of the important elements in analyzing a script. What variables a script holds when it is executed is important information for understanding the function of the script.

[0004] The variable information here includes information such as how many variables exist in what scope, what values ​​each variable holds, which code part reads and writes which variable, etc. To obtain such variable information, it is necessary to analyze the script.

[0005] To achieve this analysis, there are analysis support functions such as debuggers and bytecode disassemblers that can be used in some cases. However, if such functions are not available, it is necessary to analyze the script independently to obtain variable information, which is not easy.

[0006] [Analysis method] There are two techniques for analyzing programs that contain scripts: static analysis and dynamic analysis. Dynamic analysis is a technique that analyzes the behavior of the program by actually executing it and observing its behavior. Static analysis is a technique that analyzes the function of the program by interpreting its meaning without executing it. These analysis techniques are used to obtain branch information.

[0007] [Necessity to deal with obfuscation] One technique for hindering analysis is obfuscation. Obfuscation involves applying conversions that make a program difficult to interpret, primarily to hinder static analysis. In the case of script obfuscation, for example, part of the script is encoded or encrypted, and then dynamically decoded or decrypted at run time before execution. In such cases, the type of script that will be executed is not clear until execution time. This makes static analysis of the script difficult.

[0008] Malicious scripts and protected scripts are generally obfuscated, making static analysis difficult. Software protection is an important technique for protecting the intellectual property rights of creators. Reverse engineering is a technique for clarifying the technology used to implement software. This is a technique for analyzing a program to understand its structure and specifications. Software protection is a technique for protecting software from program analysis for such reverse engineering.

[0009] [Script execution method] Scripts are executed by a script engine (also called an interpreter). Scripts are generally converted into bytecode at runtime, and the bytecode is interpreted and executed by a Virtual Machine (VM). This means that the script is parsed before execution, and the bytecode is parsed at runtime.

[0010] As mentioned above, if the script is obfuscated, static analysis before execution becomes difficult. Therefore, it is necessary to dynamically analyze the bytecode and obtain variable information from the information obtained at execution time.

[0011] [About the symbol table] In script engines, values ​​used in scripts are generally managed by a data structure called a symbol table. A symbol table is a table that stores information such as values ​​related to variables, constants, and functions, and is created during the semantic analysis phase of the script. A script engine's symbol table generally consists of multiple structures and arrays and the references between them, and at the end of the references are value objects that hold the actual values.

[0012] Therefore, to accurately determine the internal structure of a symbol table, the following three pieces of information about the symbol table are required: the first is the reference to the symbol table in the script engine, the second is the structure of the structures and arrays that make up the symbol table, and the third is the structure of the part of the symbol table that holds the value objects. [Prior art documents] [Non-patent literature]

[0013] [Non-Patent Document 1] Asia Slowinska, Traian Stancescu, and Herbert Bos, “Howard: a Dynamic Excavator for Reverse Engineering Data Structures”, In Proceedings of the 18 the Network and Distributed Systems Security Symposium, 2011. Summary of the Invention [Problem to be solved by the invention]

[0014] However, the conventional techniques have a problem in that it is not possible to obtain information about the internal structure of a symbol table for a script engine of a script language whose specifications are unknown.

[0015] For example, the technique described in Non-Patent Document 1 does not target the symbol table held by the script engine, and does not realize the symbol table structure specific to scripts or the analysis of the aforementioned symbol table VM commands, so there is a problem that it cannot be directly applied.

[0016] It is also possible to analyze the script engine to detect the symbol table, and to analyze its structure and the VM instructions that access the symbol table.

[0017] Such a technique makes it possible to recover part of the symbol table and obtain variable information.

[0018] On the other hand, such techniques do not provide a detailed analysis of the structures and arrays that make up the symbol table or the references between them, and may not be able to accurately reference or search the symbol table.

[0019] The present invention has been made in consideration of the above, and aims to provide an analysis device, an analysis method, and an analysis program that can analyze in detail the internal structure of a VM's symbol table, even for script engines of a wide variety of script languages ​​whose specifications are unknown. [Means for solving the problem]

[0020] In order to solve the above-mentioned problems and achieve the object, the analysis device of the present invention is characterized in having a symbol table detection unit that detects, as a symbol table, a plurality of structures in a memory area used by a program to execute a script, including addresses on a reference path from a first address to a second address including a value specified in the script, and a symbol table analysis unit that analyzes an execution trace obtained by having the program execute the script and obtains structural information of the symbol table detected by the symbol table detection unit. Effect of the Invention

[0021] According to the present invention, it is possible to obtain information about the internal structure of a symbol table for a script engine of a script language whose specifications are unknown. [Brief description of the drawings]

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

[0023] Hereinafter, an embodiment of an analysis device, an analysis method, and an analysis program according to the present application will be described in detail with reference to the drawings. The present invention is not limited to the embodiment described below. The analysis device also functions as an extraction device.

[0024] [Embodiment] An analysis device according to an embodiment first analyzes the VM of a script engine. The analysis device executes a test script while monitoring the binary of the script engine, and acquires a branch trace and a memory access trace as an execution trace. The analysis device analyzes a virtual machine (VM) based on the execution trace, and acquires, as architecture information, a virtual program counter (VPC) and a bytecode cache in which VM instructions to be executed are stored. Then, based on the analysis result of the VM of the script engine, the analysis device detects a symbol table that holds information about variables. Furthermore, the analysis device analyzes the symbol table.

[0025] The analysis device may output the results of the analysis of the symbol table. The analysis device may also use the results of the analysis of the symbol table for providing dynamic bytecode instrumentation.

[0026] The analysis device provides the script engine with dynamic bytecode instrumentation functionality based on the analysis results of the VM and the analysis results of the symbol table. Based on the acquired architecture information, the analysis device executes a porting script to port the bytecode and symbol table to the bytecode and symbol table generated by the script engine in its memory space based on the porting destination script, thereby providing the script engine with dynamic bytecode instrumentation. The porting destination script is the subject of analysis by the script engine with dynamic bytecode instrumentation functionality. In the following description, the process of porting the bytecode or symbol table may be referred to as injection.

[0027] The configuration of a typical script engine and its function will be described with reference to Figs. 1 and 2. Fig. 1 is a diagram for explaining an example of the configuration of a script engine. As shown in Fig. 1, the script engine 1 has a bytecode compiler 2 and a VM 3. The bytecode compiler 2 also has a syntax analysis unit 4 and a bytecode generation unit 5. The VM 3 also has a code cache unit 6, a fetch unit 7, a decode unit 8, and an execution unit 9. The fetch unit 7, the decode unit 8, and the execution unit 9 are executed repeatedly and are called an interpreter loop. The script engine 1 then accepts the input of a script.

[0028] The syntax analysis unit 4 receives a script as input, and generates an Abstract Syntax Tree (AST) through lexical analysis and syntax analysis, and outputs it to the bytecode generation unit 5. The bytecode generation unit 5 receives the AST as input, converts it into bytecode, and stores it in the code cache unit 6.

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

[0030] The function of the components of the script engine will be described with reference to FIG. 2. FIG. 2 is a diagram showing pseudocode of the VM of the script engine. As shown in FIG. 2, the pseudocode first initializes the VPC (line 1). In the pseudocode, a while loop is an interpreter loop (lines 2 to 7). In the pseudocode, the fetch unit 7 acquires the VM opcode of the VM instruction at the position pointed to by the VPC in the bytecode cache that holds the bytecode (line 3). The decoder uses a Switch statement to interpret the VM instruction (line 4), and the dispatcher calls the instruction handler based on the VM opcode (lines 5 and after). In the pseudocode, the instruction handler performs an operation corresponding to the instruction. Input and output are performed using a virtual stack and virtual registers (line 6), and constants and variables are referenced via a symbol table (line 7).

[0031] [An example of instrumentation using bytecode porting] The analysis device according to the embodiment analyzes a script engine whose internal specifications are unknown, acquires information for dynamic bytecode instrumentation, and provides the script engine with a dynamic bytecode instrumentation function.

[0032] The analysis device provides the script engine with a dynamic bytecode instrumentation function, for example, an instrumentation function based on bytecode porting.

[0033] Fig. 3 is a diagram explaining an example of instrumentation by bytecode porting. In this instrumentation, the script engine executes the ported script, and if there is a process that meets the hook condition, it saves and saves the process that meets the hook condition (Fig. 3 (1)).

[0034] In this instrumentation, the processing part corresponding to the hook condition is overwritten with a branch instruction to the stub, and the stub is executed (Fig. 3 (2) and (3)). The stub includes a process to obtain a specific variable from the symbol table using a symbol table VM instruction, a process to call the ported bytecode with a branch VM instruction after passing the obtained variable, and a process to branch back to the original location after the ported bytecode is executed.

[0035] Next, the stub calls the ported bytecode, executes it (Figure 3 (4)), and branches back to the original location after the ported bytecode is executed. Then, after branching back to the original location by executing the stub, the saved processing is restored and processing is resumed (Figure 3 (5)).

[0036] Before the process of providing the analysis function, the analysis device executes the test script while monitoring the binary of the script engine, and obtains architecture information including the VPC, the bytecode cache, and the symbol table.

[0037] In this way, the analysis device can detect various architectural information through analysis based on the execution trace and VM execution trace, even for script engines whose VM internal specifications are unknown, and can thus provide dynamic bytecode instrumentation functionality to the script engine without the need for manual reverse engineering or the use of support functions such as a debugger.

[0038] Furthermore, the analysis device can accurately refer to and search for symbol tables by analyzing the structure of the symbol tables and the references between the symbol tables in detail. This allows the analysis device to inject the symbol tables based on the analysis results. As a result, the analysis device can accurately and efficiently provide dynamic bytecode instrumentation functions.

[0039] [Analysis equipment configuration] Next, the configuration of the analysis device 10 according to the embodiment will be specifically described with reference to Fig. 4. Fig. 4 is a diagram illustrating an example of the configuration of the analysis device 10 according to the embodiment.

[0040] As shown in Fig. 4, the analysis device 10 includes an input unit 11, a control unit 12, a storage unit 13, and an output unit 14. The analysis device 10 receives input of a test script and a script engine binary. Note that, although the present embodiment describes a script engine as an example of a target, the present invention is not limited to this as long as it is an execution environment using a virtual machine. Therefore, the script engine binary may be referred to as a virtual machine binary.

[0041] The input unit 11 is composed of input devices such as a keyboard and a mouse, and receives input of information from the outside and inputs it to the control unit 12. The input unit 11 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. The input unit 11 receives input of test scripts, script engine binaries, porting scripts, porting destination scripts, and hook settings, and outputs them to the control unit 12.

[0042] The test script is a script that is input when dynamically analyzing a 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.

[0043] [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.

[0044] 5 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.

[0045] FIG. 6 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. 6, 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.

[0046] FIG. 7 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. 7, 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.

[0047] Fig. 8 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. 8.

[0048] [Porting script] Fig. 9 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. 10 is a diagram showing the bytecode and the symbol table generated by executing the porting script shown in Fig. 9.

[0049] As shown in Fig. 9, the porting script includes a function to be ported 202 and a call section 204 of the function to be ported. The function to be ported 202 includes the process content to be ported 203. When the porting script is executed, bytecode 205 (see Fig. 10) corresponding to the processing portion of the process content to be ported 203 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.

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

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

[0052] The storage unit 13 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 device 10, data used during execution of the processing program, etc. The storage unit 13 has an execution trace database (DB) 131, and an architecture information DB 132 that stores architecture information acquired by the virtual machine analysis unit 121 and the symbol table analysis unit 122 (described later).

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

[0054] Configure Execution Tracing Next, the execution trace will be explained. Fig. 12 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. 12 shows an excerpt of a part of an execution trace. The structure of an execution trace will be explained below with reference to Fig. 12.

[0055] 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.

[0056] A branch trace log line has the format shown in lines 1 to 10 of Figure 12, 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.

[0057] A log line of a memory access trace has the format shown, for example, in lines 11 to 13 of Figure 12, 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 is used during memory access. Additionally, value stores the value resulting from the memory access.

[0058] Returning to Fig. 4, the control unit 12 will be described. The control unit 12 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 12 is an electronic circuit such as a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). The control unit 12 has a virtual machine analysis unit 121, a symbol table analysis unit 122, an extraction unit 123, and an injection unit 124.

[0059] The virtual machine analysis unit 121 analyzes the VM of the script engine. The virtual machine analysis unit 121 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 121 detects a bytecode cache from the execution traces. The bytecode cache stores the VM instructions to be executed.

[0060] The virtual machine analysis unit 121 includes an execution trace acquisition unit 1211 , a virtual program counter detection unit 1212 , and a bytecode cache detection unit 1213 .

[0061] The execution trace acquisition unit 1211 receives the first to third test scripts and the script engine binary as input. The execution trace acquisition unit 1211 acquires an execution trace by executing the first to third test scripts while monitoring the execution of the script engine binary.

[0062] 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 1211 is stored in the execution trace DB 131.

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

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

[0065] For this reason, the virtual program counter detection unit 1212 uses differential execution analysis focusing on the number of memory reads to detect VPCs. The virtual program counter detection unit 1212 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. The virtual program counter detection unit 1212 then refers to the boundaries of each VM instruction and narrows down the memory values ​​read to those whose values ​​always point to the start points of the VM instructions. The virtual program counter detection unit 1212 detects these memories as VPCs.

[0066] (Configuring VM Execution Tracing) Here, the VM execution trace will be explained. Fig. 13 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. 13 shows a part of the VM execution trace. The configuration of the VM execution trace will be described below with reference to Fig. 13.

[0067] A log line of a VM execution trace is, for example, in the format shown in FIG. 13 and consists of two elements, vpc and vmop (vm opcode). vpc indicates the value of the 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.

[0068] The bytecode cache detection unit 1213 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.

[0069] The bytecode cache detection unit 1213 detects the memory area pointed to by the VPC as a bytecode cache from the VM execution trace. The bytecode cache detection unit 1213 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 1213 detects all memory areas allocated at this code location from the VM execution trace as code caches.

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

[0071] The symbol table analysis unit 122 detects and analyzes a symbol table and includes an interpretation execution function detection unit 1221, a symbol table detection unit 1222, a symbol table analysis unit 1223, and a value object analysis unit 1224.

[0072] Here, the structure of the symbol table will be explained with reference to Fig. 14. Fig. 14 is a diagram for explaining the structure of the symbol table. As shown in Fig. 14, 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.

[0073] 14, the symbol table has a structure 251, a structure 252, an array 253, and a structure 254. Furthermore, structure 251 includes a pointer to structure 252. Furthermore, structure 252 includes a pointer to array 253. Furthermore, array 253 includes a pointer to structure 254.

[0074] The end of the symbol table, structure 254, contains a value object. A value object is data related to a value 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 the variable name, variable type, and value, respectively.

[0075] 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 251 is a management structure.

[0076] 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 Figure 15. Figure 15 is a diagram for explaining the interpretation execution function.

[0077] The function "interp" in Figure 15 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 the 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.

[0078] 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.

[0079] The symbol table analyzer 122 obtains the execution trace, the VPC, and the bytecode cache from the virtual machine analyzer 121 .

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

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

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

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

[0084] Fig. 16 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, in addition to general taint propagation in accordance with data movement, symbol table detection unit 1222 also propagates a taint when a pointer is referenced. As shown in Fig. 16, first, symbol table detection unit 1222 assigns taint tag 273 to an address of memory area 271. Then, when data to which taint tag 273 has been assigned is referenced as a pointer during execution of a test script, symbol table detection unit 1222 propagates taint tag 273 to an address that holds a value referenced by the pointer.

[0085] 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.

[0086] Here, the symbol table detection unit 1222 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 1222 stores the identified target of memory access as a value in the symbol table.

[0087] The symbol table detection unit 1222 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.

[0088] 14, symbol table detection unit 1222 identifies a memory access to value "1234" of structure 254. In this case, "1234" is a characteristic value. Here, each pointer from structure 251, which is a management structure, to value "1234" of structure 254 is assigned the same taint tag as value "1234."

[0089] As a result, symbol table detection unit 1222 can detect a symbol table including a pointer to structure 252, a pointer to array 253, a pointer to structure 254, and the value of structure 254, "1234".

[0090] 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 253 that structure 252 has is a member variable of structure 252, and the offset of the member variable from the start address of structure 252 is also unknown. Therefore, symbol table analyzer 1223 analyzes the structures of the structures and arrays included in the symbol table. Symbol table analyzer 1223 performs reference analysis and structure analysis.

[0091] (Reference analysis) Reference analysis will be described with reference to Fig. 17. Fig. 17 is a diagram for explaining reference analysis. Symbol table analysis unit 1223 performs reference analysis by utilizing the fact that the effective address of a structure is specified by offset reference from a starting address (base register) and that the effective address of an array is specified by index reference from a starting address (base register).

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

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

[0094] If a memory access with a taint tag uses a base register and an index register, the symbol table analyzer 1223 determines that the access destination of the memory access is an element of an array. The symbol table analyzer 1223 then obtains the head and subscript of the array from the base register and index register.

[0095] 17, before the reference analysis is performed, it is unknown whether data structure 283 is a structure or an array. The memory access to which taint tag 287 of data structure 283 is assigned uses a base register and an index register. Thus, symbol table analyzer 1223 regards the access destination of memory access to which taint tag 287 of data structure 283 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."

[0096] (Structural analysis) Structural analysis will be described with reference to Figures 18 and 19. Figures 18 and 19 are diagrams for explaining structural analysis. Symbol table analyzer 1223 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 254 in Figure 14 (where structure 251 is a management structure), array 253 holds a reference to structure 254, which is a value object, so it is determined that the detected symbol table holds value objects in an array.

[0097] On the other hand, if a structure holds a reference to a structure that is a value object, the symbol table analyzer 1223 determines that the detected symbol table holds the value object in a linked list. In this case, the symbol table analyzer 1223 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.

[0098] 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.

[0099] For example, in the symbol table ending at structure 254 in Figure 14 (where structure 251 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.

[0100] 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.

[0101] When the symbol table analyzer 1223 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 (estimates) whether the data structure is a linked list or not, by taking the difference. This enables the symbol table analyzer 1223 to detect the structures of the value objects and the linked list.

[0102] If the symbol table analysis unit 1223 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.

[0103] 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 1223 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 1223 estimates that the subsequent references, which are the differences, are linked lists.

[0104] 18 includes data structures other than the linked list from structure 291, which is a management structure, to the structure immediately preceding structure 2921, and linked list 292. Linked list 292 includes structure 2921 and structure 2922. Structure 2922 is a value object.

[0105] 19 includes data structures other than the linked list from structure 296, which is a management structure, to the structure immediately preceding structure 2971, and linked list 297. Linked list 297 includes structure 2971, structure 2972, structure 2973, structure 2974, structure 2975, and structure 2976. Structures 2974, structure 2975, and structure 2976 are value objects.

[0106] Here, structures such as value objects (structure 2974, etc.) shown in Figs. 18 and 19 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. 18 and 19, 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).

[0107] The value object analysis unit 1224 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 analysis unit 1224 detects the portion excluding the portion where a difference occurs depending on the value of the test script. The value object analysis unit 1224 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 analysis unit 1224 detects the value portion "1234" and the variable name portion "i" from the structure 2974.

[0108] Similarly, when "j=5.678" and "k="9012"" are stored as test scripts, the value object analysis unit 1224 detects the portion excluding the portion where the difference occurs depending on the value of the test script. The value object analysis unit 1224 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 1224 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 1224 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.

[0109] In this way, the value object analysis unit 1224 can appropriately extract the tag part of a tagged union by detecting the part where a difference occurs depending on 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 depending on 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 depending on 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.

[0110] The extraction unit 123 receives a porting script as an input. The extraction unit 123 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 121 and information about the symbol table acquired by analysis by the symbol table analysis unit 122. The extraction unit 123 includes a bytecode extraction unit 1231 and a symbol table extraction unit 1232.

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

[0112] The symbol table extraction unit 1232 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.

[0113] The injection unit 124 injects a porting bytecode and a porting script into the bytecode and the symbol table generated in the memory space of the script engine by the execution of the porting destination script, respectively.

[0114] The configuration of the injection unit 124 will be described with reference to Fig. 22. Fig. 22 is a diagram showing an example of the configuration of the injection unit. As shown in Fig. 22, the injection unit 124 has an execution operation unit 1241, a bytecode injection unit 1242, and a symbol table injection unit 1243.

[0115] The execution control unit 1241 controls the execution of the porting destination script by the script engine. The execution control unit 1241 includes an execution unit 12411, an execution suspension unit 12412, a memory enumeration unit 12413, and an execution resumption unit 12414.

[0116] The execution unit 12411 causes the script engine to start executing the porting destination script. The execution pause unit 12412 causes the script engine to pause the execution of the porting destination script. The memory enumeration unit 12413 extracts and enumerates the memory areas of the bytecode and symbol table from the process of the script engine that is executing the porting destination script. The execution resumption unit 12414 causes the script engine to start executing the porting destination script.

[0117] The bytecode injection unit 1242 injects (writes) the porting bytecode into the memory area of ​​the enumerated bytecode. The symbol table injection unit 1243 injects (writes) the porting bytecode into the memory area of ​​the enumerated symbol table.

[0118] The output unit 14 is, for example, a liquid crystal display or a printer, and outputs various information including information related to the analysis device 10. The output unit 14 may also be an interface that controls input and output of various data between an external device and the output unit 14, and may output various information to the external device.

[0119] [Virtual program counter detection processing] Next, the processing of the virtual program counter detection unit 1212 will be described. The virtual program counter detection unit 1212 detects VPC and pointer cache. The detection of the virtual program counter is realized by analyzing the log of the memory access trace of the acquired execution trace. The virtual program counter detection unit 1212 uses differential execution analysis focusing on the number of times memory is read. FIG. 20 is a diagram for explaining the processing of the virtual program counter detection unit 1212.

[0120] The virtual program counter detection unit 1212 extracts one execution trace by the first test script from the execution trace DB 131. The number of times a VPC is read is proportional to the number of repetitions in the test script and the number of statements in the repetitive process. When the number of repetitions is N and the number of repeated statements is M, approximately MN VPCs are read. Therefore, the virtual program counter detection unit 1212 extracts memory that has increased by 4MN and 9MN in the execution trace for the first test script in which N and M have been increased to 2N and 2M, respectively, and 3N and 3M. Specifically, as shown in FIG. 20, the virtual program counter detection unit 1212 extracts a memory area that has a monotonically increasing Read / Write for each VM instruction execution ((1) in FIG. 20).

[0121] Then, the virtual program counter detection unit 1212 detects, as a VPC, a memory value that always points to the start point of a VM instruction. Specifically, the virtual program counter detection unit 1212 compares the VPC's pointing destination with the address of the VM instruction handler, and narrows down the memory area to the matching memory area ((2) in FIG. 20).

[0122] [Bytecode cache detection part] Next, a description will be given of the processing of the bytecode cache detection unit 1213. FIG.

[0123] The bytecode cache detection unit 1213 detects a memory area pointed to by a VPC as a bytecode cache from a VM execution trace ((1) in FIG. 21).

[0124] The bytecode cache detection unit 1213 detects the code location of the caller of the memory allocation function that allocated this bytecode cache from the execution trace ((2) in FIG. 21). The bytecode cache detection unit 1213 detects all memory areas allocated at this code location from the VM execution trace as bytecode caches ((3) in FIG. 21).

[0125] The bytecode cache detection unit 1213 detects a code location that writes to the bytecode cache from the execution trace ((4) in FIG. 21). The bytecode cache detection unit 1213 detects writing by this code location from the VM execution trace as an update of the bytecode cache ((5) in FIG. 21).

[0126] [Analysis equipment processing procedure] The processing procedure of the analysis device 10 will be described with reference to Fig. 23. Fig. 23 is a flowchart showing the processing procedure of the analysis process according to the embodiment.

[0127] First, the input unit 11 accepts input of a test script and a script engine binary (step S11).

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

[0129] Next, the execution trace acquisition unit 1211 executes an execution trace acquisition process (step S12). The virtual program counter detection unit 1212 executes a virtual program counter detection process (step S13). The bytecode cache detection unit 1213 executes a bytecode cache detection process (step S14).

[0130] Next, the interpretation execution function detection unit 1221 executes an interpretation execution function detection process (step S15). The symbol table detection unit 1222 executes a symbol table detection process (step S16). The symbol table analysis unit 1223 executes a symbol table analysis process (step S17).

[0131] Here, if the extraction process is not executed (step S18, No), the output unit 14 outputs the bytecode, the symbol table, and the analysis result of the symbol table (step S19). On the other hand, if the extraction process is executed (step S18, Yes), the analysis device 10 proceeds to step S20. For example, whether or not the extraction process is executed is designated in advance by the user. Furthermore, when proceeding to step S20, the analysis device 10 functions as an extraction device.

[0132] The process from step S20 onwards will be described. The value object analysis unit 1224 executes a value object table analysis process (step S20). The bytecode extraction unit 1231 executes a bytecode extraction process (step S21). The symbol table extraction unit 1232 executes a symbol table extraction process (step S22).

[0133] If the injection process is not executed (step S23, No), the output unit 14 outputs the bytecode, the symbol table, and the structural information of the symbol table (step S24). On the other hand, if the injection process is executed (step S23, Yes), the analysis device 10 proceeds to step S25.

[0134] The process after step S25 will be described. The injection unit 124 executes the injection process (step S25). The output unit 14 outputs the result of the injection process (step S26).

[0135] The details of the processing procedure of the execution trace acquisition processing (step S12 in FIG. 23) will be described with reference to FIG 24. FIG 24 is a flowchart showing the processing procedure of the execution trace acquisition processing.

[0136] 24, first, the execution trace acquisition unit 1211 receives a test script and a script engine binary as input (step S1201). Next, the execution trace acquisition unit 1211 hooks the virtual machine to acquire a branch trace (step S1202). In addition, the execution trace acquisition unit 1211 hooks the virtual machine to acquire a memory access trace (step S1203).

[0137] Here, the execution trace acquiring unit 1211 inputs the test script into the virtual machine and executes it (step S1204), and then the execution trace acquiring unit 1211 stores the acquired execution trace in the execution trace DB 131 (step S1205).

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

[0139] The virtual program counter detection process (step S13 in FIG. 23) will be described in detail with reference to FIG 25. FIG 25 is a flowchart showing the procedure of the virtual program counter detection process.

[0140] As shown in FIG. 25, first, the virtual program counter detection unit 1212 extracts one execution trace by the first test script from the execution trace DB (step S1301).

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

[0142] Next, the virtual program counter detection unit 1212 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 (step S1305). The virtual program counter detection unit 1212 focuses on the memory access trace and counts up the number of reads for each memory read destination (step S1306). The virtual program counter detection unit 1212 receives as input the first test script used to obtain the execution trace (step S1307).

[0143] Then, the virtual program counter detection unit 1212 analyzes the test script to obtain the number of repetitions and the number of repeated statements (step S1308).The virtual program counter detection unit 1212 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 S1309).The virtual program counter detection unit 1212 narrows down the memory read destinations to those whose read values ​​always point to the start point of the VM instruction (step S1310).

[0144] If the virtual program counter detection unit 1212 narrows down the memory read destinations to only one (step S1311, Yes), it stores the narrowed down read destination as a virtual program counter in the architecture information DB 132 (step S1312). On the other hand, if the virtual program counter detection unit 1212 cannot narrow down the memory read destinations to only one (step S1311, No), it returns to step S1305 and repeats the process.

[0145] The bytecode cache detection process (step S14 in FIG. 23) will be described in detail with reference to FIG. 26. FIG. 26 is a flowchart showing the procedure of the bytecode cache detection process.

[0146] As shown in FIG. 26, first, the bytecode cache detection unit 1213 receives an execution trace and a VM execution trace as input (step S1401).

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

[0148] Next, the bytecode cache detection unit 1213 detects all areas secured at the code location as bytecode cache (step S1404). The bytecode cache detection unit 1213 acquires the code location that writes to the bytecode cache from the execution trace (step S1405). The bytecode cache detection unit 1213 detects all areas written at the code location as updates to the bytecode cache (step S1406).

[0149] The bytecode cache detection unit 1213 returns the bytecode cache and its updated portion (step S1407).

[0150] The interpretation execution function detection process (step S15 in FIG. 23) will be described in detail with reference to FIG 27. FIG 27 is a flowchart showing the procedure of the interpretation execution function detection process.

[0151] 27, first, the interpretation execution function detection unit 1221 receives an execution trace as an input (step S1501). The interpretation execution function detection unit 1221 receives a VPC and a bytecode cache as an input (step S1502).

[0152] Next, the interpretive execution function detection unit 1221 detects each function from the call and return branches in the branch trace (step S1503). Here, the interpretive execution function detection unit 1221 extracts one function (step S1504). The interpretive execution function detection unit 1221 scans the memory access trace within the function (step S1505).

[0153] If memory access to the VPC and the bytecode cache is detected (Yes at step S1506), the interpretive execution function detection unit 1221 outputs the function as an interpretive execution function (step S1507).

[0154] If no memory access to the VPC or bytecode cache is found (step S1506, No), the interpreted execution function detection unit 1221 extracts the next function (step S1508) and returns to step S1505.

[0155] In this way, the interpretive execution function detection unit 1221 detects interpretive execution functions in which memory access is seen to either or both of the virtual program counter, which is a variable that points to the instructions of the script engine that executes the script, and the bytecode cache, which is the memory area pointed to by the virtual program counter, in the execution trace.

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

[0157] 28, first, the symbol table detection unit 1222 receives an execution trace as an input (step S1601). The symbol table detection unit 1222 receives an interpretation execution function as an input (step S1602).

[0158] Next, symbol table detection unit 1222 executes the interpretation execution function while monitoring it (step S1603). Symbol table detection unit 1222 acquires arguments of the interpretation execution function (step S1604). If the arguments are pointers, symbol table detection unit 1222 assigns each of the arguments a unique taint tag (step S1605). Symbol table detection unit 1222 executes while propagating the taint tag according to the pointer reference (step S1606).

[0159] Here, the symbol table detection unit 1222 extracts one characteristic value in the test script (step S1607).The symbol table detection unit 1222 searches the memory access trace for the characteristic value (step S1608).

[0160] When a memory access with a characteristic value is detected (step S1609, Yes), the symbol table detection unit 1222 detects the target of the memory access as a value in the symbol table (step S1611).

[0161] If no memory access of a characteristic value is found (step S1609, No), the symbol table detection unit 1222 extracts the next characteristic value (step S1610).

[0162] If all characteristic values ​​have not been processed (step S1612, No), the symbol table detection unit 1222 extracts the next characteristic value (step S1610).

[0163] When all characteristic values ​​have been processed (Yes at step S1612), the symbol table detection unit 1222 checks the taint tags assigned to the values ​​in the symbol table (step S1613).

[0164] The symbol table detection unit 1222 determines that the taint tag is related to a symbol table (step S1614). The symbol table detection unit 1222 determines that the memory area to which the taint tag is assigned is a symbol table (step S1615). A taint map related to the taint tag is output (step S1616).

[0165] In this way, the symbol table detection unit 1222 detects, as a symbol table, multiple structures that contain addresses on a reference path from a first address to a second address that contains a value specified in the script in a memory area used by the script engine (an example of a program) to execute a script.

[0166] For example, the symbol table detection unit 1222 detects, as a symbol table, multiple structures including addresses on a reference path from a first address (the start address of the management structure) indicated by a pointer of an argument of the interpretation execution function to a second address (the address of the characteristic value).

[0167] Furthermore, symbol table detection unit 1222 assigns taint tags to addresses on a reference path from the first address to the second address, and detects, as a symbol table, a plurality of structures including addresses to which taint tags have been assigned.

[0168] The symbol table analysis process (step S17 in FIG. 23) will be described in detail with reference to FIG 29. FIG 29 is a flowchart showing the processing procedure of the symbol table detection process.

[0169] 29, first, the symbol table analyzer 1223 receives an execution trace as an input (step S1701). The symbol table analyzer 1223 receives a taint map of the symbol table as an input (step S1702).

[0170] Next, the symbol table analyzer 1223 extracts one value with a taint tag from the taint map (step S1703).The symbol table analyzer 1223 searches the memory access trace with the extracted value (step S1704).

[0171] If no memory access using the value is found (step S1705, No), symbol table analyzer 1223 extracts the next value (step S1706) and returns to step S1704.

[0172] If a memory access using a value is found (step S1705, Yes), the symbol table analysis unit 1223 executes a reference analysis process (step S1707) and a structure analysis process (step S1708) and outputs information on the reference and structure of the symbol table (step S1709).

[0173] In this way, the symbol table analysis unit 1223 analyzes the execution trace obtained by having a script engine (an example of a program) execute a test script (an example of a first script), and obtains structural information of the symbol table generated by the script engine.

[0174] This enables the symbol table analysis unit 1223 to analyze the script engine, detect the symbol table, and perform detailed analysis of its structure and the references between symbol tables, thereby making it possible to obtain information about the internal structure of the symbol table even for script engines of a wide variety of scripting languages ​​whose specifications are unknown.

[0175] For example, the structural information is the top address of each element (structure or array) of the symbol table shown in Fig. 14, the address and value of a pointer included in each element of the symbol table, etc. Therefore, the analysis device 10 can identify the structure of each element and the reference relationship between elements based on the structural information.

[0176] The reference analysis process (step S1707 in FIG. 29) will be described in detail with reference to Fig. 30. Fig. 30 is a flowchart showing the processing procedure of the reference analysis process.

[0177] As shown in FIG. 30, first, symbol table analyzer 1223 receives as input a specific memory access seen in a memory access trace (step S1741).

[0178] The symbol table analyzer 1223 determines whether the memory access uses a base register (step S1742) and whether the memory access uses an index register (step S1743).

[0179] If the memory access does not use the base register (step S1742, No), the symbol table analyzer 1223 determines that the memory access destination is neither an array nor a structure (step S1755). If the memory access uses the base register but not the index register (step S1742: Yes and step S1743: No), the symbol table analyzer 1223 determines that the memory access destination is a member variable of a structure (step S1744). If the memory access uses both the base register and the index register (step S1742 and step S1743: Yes), the symbol table analyzer 1223 determines that the memory access destination is an element of an array (step S1749).

[0180] Following step S1744, symbol table analyzer 1223 executes the following process. Symbol table analyzer 1223 acquires the base register and effective address at the time of the memory access (step S1745). Symbol table analyzer 1223 detects the value of the base register as the start address of the structure at the memory access destination (step S1746).

[0181] The symbol table analyzer 1223 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 S1747). The symbol table analyzer 1223 outputs the start address and offset of the structure (step S1748).

[0182] Following step S1749, symbol table analyzer 1223 executes the following process. Symbol table analyzer 1223 acquires the base register and index register at the time of the memory access (step S1750). Symbol table analyzer 1223 detects the value of the base register as the starting address of the array at the memory access destination (step S1751).

[0183] The symbol table analyzer 1223 detects the value of the index register as a subscript of the array of the memory access destination (step S1752).The symbol table analyzer 1223 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 S1753).The symbol table analyzer 1223 outputs the top address, subscript, and offset of the array (step S1754).

[0184] In this way, when the memory access to an address on the reference path from the first address to the second address shown in the execution trace uses both the base register and the index register, the symbol table analyzer 1223 determines that the target of the memory access is an element of an array, and obtains the first address of the array and the subscript of the element from the base register and the index register. Also, when the memory access to an address on the reference path from the first address to the second address shown in the execution trace uses the base register but does not use the index register, the symbol table analyzer 1223 determines that the target of the memory access is a member variable of a structure, and calculates the offset of the member variable from the first address of the structure based on the effective address and the base register. This allows the symbol table analyzer 1223 to perform analysis regardless of whether the element of the symbol table is a structure or an array.

[0185] The structure analysis process (step S1708 in FIG. 29) will be described in detail with reference to FIG 31. FIG 31 is a flowchart showing the procedure of the structure analysis process.

[0186] As shown in FIG. 31, first, symbol table analyzer 1223 receives as input a specific memory access seen in a memory access trace (step S1771).

[0187] If the value objects of the symbol table are managed by an array (Yes at step S1772), the symbol table analysis unit 1223 outputs the structure of the array obtained by the reference analysis (step S1773).

[0188] If the value objects of the symbol table are not managed in an array (step S1772, No), the symbol table analyzer 1223 accepts multiple test scripts as input (step S1774). The symbol table analyzer 1223 performs processing up to the reference analysis processing for each test script (step S1775). The symbol table analyzer 1223 extracts references from the management structure to value objects from the references of each test script (step S1776).

[0189] Here, symbol table analysis unit 1223 obtains the difference in the references (step S1777). If no difference in the length of the references is found in accordance with the number of values ​​in the test script (step S1778, No), symbol table analysis unit 1223 ends the process.

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

[0191] The symbol table analyzer 1223 detects, from the reference, a member variable having a reference that connects elements of the linked list (step S1780). The symbol table analyzer 1223 detects, from the reference, a value object portion that an element of the linked list has (step S1781). The symbol table analyzer 1223 outputs the structure of the linked list (step S1782).

[0192] Symbol table detection unit 1222 can detect, as a symbol table, a plurality of structures including addresses on a reference path for each of a plurality of test scripts. Symbol table analysis unit 1223 detects a structure of a part (unlinked list) common to a plurality of symbol tables and a structure of a part (linked list) not common to a plurality of symbol tables based on the length of each reference path of a plurality of symbol tables detected by symbol table detection unit 1222. In this way, symbol table analysis unit 1223 can analyze the structure of a symbol table with higher accuracy by using a plurality of test scripts.

[0193] The value object analysis process (step S20 in FIG. 23) will be described in detail with reference to FIG 32. FIG 32 is a flowchart showing the procedure of the value object analysis process.

[0194] 32, first, the value object analysis unit 1224 receives a plurality of test scripts as input (step S2021). The value object analysis unit 1224 receives a plurality of structures as input (step S2022).

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

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

[0197] The value object analysis unit 1224 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 S2027).The value object analysis unit 1224 detects the type held by the structure from the type of the tag value for the test script value (step S2028).

[0198] The bytecode extraction process (step S21 in FIG. 23) will be described in detail with reference to FIG 33. FIG 33 is a flowchart showing the procedure of the bytecode extraction process.

[0199] 33, first, the bytecode extraction unit 1231 accepts a VPC as an input (step S2101). The bytecode extraction unit 1231 accepts a bytecode cache as an input (step S2102). The bytecode extraction unit 1231 accepts a script to be extracted (e.g., a porting destination script) as an input (step S2103). The bytecode extraction unit 1231 accepts a script engine binary as an input (step S2104).

[0200] The bytecode extraction unit 1231 executes the script to be extracted (step S2105). The bytecode extraction unit 1231 stops the execution at the interpretation execution function (step S2106). The bytecode extraction unit 1231 extracts the bytecode from the bytecode cache (step S2107). The bytecode extraction unit 1231 resumes the execution, and stops the execution again at the time of the execution of the first VM instruction (step S2108).

[0201] The bytecode extraction unit 1231 extracts the value of the VPC (step S2109), and outputs the extracted bytecode and the value of the VPC (step S2110).

[0202] The symbol table extraction process (step S22 in FIG. 23) will be described in detail with reference to Fig. 34. Fig. 34 is a flowchart showing the processing procedure of the symbol table extraction process.

[0203] 34, first, symbol table extraction unit 1232 accepts symbol table reference and structure information as input (step S2201). Symbol table extraction unit 1232 accepts a script to be extracted as input (step S2202). Symbol table extraction unit 1232 accepts a script engine binary as input (step S2203).

[0204] The symbol table extraction unit 1232 executes the script to be extracted (step S2204). The execution is stopped by the interpretation execution function (step S2205). The symbol table extraction unit 1232 acquires a pointer to the management structure from the argument of the interpretation execution function (step S2206). The symbol table extraction unit 1232 extracts the symbol table by tracing the management structure from the symbol table reference and structure information (step S2207). The symbol table extraction unit 1232 outputs the extracted symbol table (step S2208).

[0205] In this way, symbol table extraction unit 1232 extracts a symbol table from the memory area used by the script engine to execute the porting script (an example of a second script) based on the structural information. By using the structural information, which is detailed information on the structure of the symbol table and the references between the symbol tables, symbol table extraction unit 1232 can detect the symbol table more accurately. As a result, more accurate porting (injection) of the bytecode and the symbol table becomes possible.

[0206] Symbol table extraction unit 1232 extracts, as a symbol table, a number of structures including the addresses obtained by repeatedly calculating the addresses of the pointers included in the structures and the addresses of the beginnings of the structures pointed to by the pointers, based on the structure information, starting from a specific structure. Repeated address calculation corresponds to the process of tracing the reference from the management structure, as shown in step S2207.

[0207] The symbol table extraction unit 1232 can extract a symbol table based on the interpretation execution function. That is, the symbol table extraction unit 1232 extracts, as a symbol table, a plurality of structures including addresses obtained by repeatedly calculating the address of a pointer included in a structure and the address of the beginning of a structure pointed to by a pointer based on structural information, starting from a management execution entity pointed to by a pointer of an argument of an interpretation execution function in which memory access to either or both of a virtual program counter, which is a variable pointing to an instruction of a program executing a porting script, and a bytecode cache, which is a memory area pointed to by the virtual program counter, is observed in an execution trace, as a symbol table.

[0208] By determining the starting point in this manner, the symbol table extraction unit 1232 can accurately detect the symbol table.

[0209] The injection process (step S25 in FIG. 23) will be described in detail with reference to FIG 35. FIG 35 is a flowchart showing the procedure of the injection process.

[0210] 35, first, the injection unit 124 receives a test script and a script engine binary at the input unit 11 (step S2501). The injection unit 124 inputs a target script to a target script engine at the execution unit 2411 and executes it (step S2502).

[0211] The target script engine is the script engine that corresponds to the script engine binary. The target script is, for example, the script to be ported to.

[0212] The injection unit 124 pauses the target script engine at the beginning of the interpretation execution function in the execution pause unit 2412 (step S2503). The injection unit 124 receives the bytecode and VPC value extracted by the extraction unit 123 as input (step S2504). The injection unit 124 receives the symbol table extracted by the extraction unit 123 as input (step S2505).

[0213] The injection unit 124 executes a bytecode injection process (step S2506) and a symbol table injection process (step S2507). The injection unit 124 resumes the execution of the target script engine in the execution resumption unit 2414 (step S2508).

[0214] The bytecode injection process (step S2506 in FIG. 35) will be described in detail with reference to FIG. 36. FIG. 36 is a flowchart showing the procedure of the bytecode injection process.

[0215] 36, first, the bytecode injection unit 1242 accepts a process of a running target script engine as an input (step S2541). The bytecode injection unit 1242 accepts a VPC as an input (step S2542). The bytecode injection unit 1242 accepts a bytecode cache as an input (step S2543). The bytecode injection unit 1242 accepts an extracted bytecode as an input (step S2544).

[0216] The bytecode injection unit 1242 writes the extracted bytecode to the bytecode cache of the process of the target script engine (step S2545). The bytecode injection unit 1242 sets the memory address where the extracted bytecode is written to the VPC (step S2546).

[0217] The symbol table injection process (step S2507 in FIG. 35) will be described in detail with reference to FIG. 37. FIG. 37 is a flowchart showing the processing procedure of the symbol table injection process.

[0218] 37, first, the symbol table injection unit 1243 accepts a process of a running target script engine as an input (step S2571). The symbol table injection unit 1243 accepts structural information of a symbol table as an input (step S2572). The symbol table injection unit 1243 accepts an extracted symbol table as an input (step S2573).

[0219] The symbol table injection unit 1243 obtains the start address of the management structure from the argument of the interpretation execution function (step S2574). The symbol table injection unit 1243 extracts a symbol table of one scope from the extracted symbol table (step S2575). The symbol table injection unit 1243 refers to the start address of the management structure based on the structural information of the symbol table, and traces to the symbol table of the corresponding scope (step S2576).

[0220] The symbol table injection unit 1243 writes the symbol table of the extracted symbol table of the scope to the traced destination (step S2577). When the symbol table injection unit 1243 has injected all the scopes of the extracted symbol table (step S2578, Yes), the process ends.

[0221] If all the scopes of the extracted symbol table have not been injected (step S2578, No), symbol table injection unit 1243 extracts the symbol table of the next scope from the extracted symbol table (step S2579), and returns to step S2576.

[0222] In this way, symbol table injection unit 1243 injects the symbol table extracted by symbol table extraction unit 1232 into the position specified based on the structural information in the memory area used by the program to execute the porting destination script (third script example). Symbol table injection unit 1243 can accurately inject the symbol table by using the structural information.

[0223] [System configuration of the embodiment] Each component of analysis device 10 shown in Fig. 4 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 the functions of analysis device 10 is not limited to that shown in the figure, and all or part of it can be functionally or physically distributed or integrated in any unit depending on various loads, usage conditions, etc.

[0224] Furthermore, all or any part of each process performed in analysis device 10 may be realized by a CPU and a program analyzed and executed by the CPU. Furthermore, each process performed in analysis device 10 may be realized as hardware using wired logic.

[0225] Furthermore, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually. Alternatively, all or part of the processes described as being performed manually can be performed automatically by a known method. In addition, the process procedures, control procedures, specific names, and information including various data and parameters described above and shown in the drawings can be changed as appropriate unless otherwise specified.

[0226] [program] 38 is a diagram showing an example of a computer in which analysis device 10 is realized by executing a program. Computer 1000 has, for example, memory 1010 and CPU 1020. Computer 1000 also has hard disk drive interface 1030, disk drive interface 1040, serial port interface 1050, video adapter 1060, and network interface 1070. Each of these components is connected by bus 1080.

[0227] The memory 1010 includes a ROM 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 1100. A removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to a mouse 1110 and a keyboard 1120, for example. The video adapter 1060 is connected to a display 1130, for example.

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

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

[0230] 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 1100 or the like. Alternatively, the program module 1093 and the program data 1094 may be stored in another computer connected via a network (such as a local area network (LAN) or wide area network (WAN)). The program module 1093 and the program data 1094 may then be read by the CPU 1020 from the other computer via the network interface 1070.

[0231] Although the embodiments of the present invention have been described above, the present invention is not limited by the descriptions and drawings that form part of the disclosure of the present invention according to the present embodiments. In other words, other embodiments, examples, and operation techniques made by those skilled in the art based on the present embodiments are all included in the scope of the present invention. [Explanation of symbols]

[0232] 10 Analysis device 11 Input section 12 Control section 13 Storage section 14 Output section 121 Virtual Machine Analysis Department 122 Symbol Table Analysis Unit 123 Extraction part 124 Injection part 131 Execution Trace DB 132 Architecture Information DB 1211 Execution trace acquisition unit 1212 Virtual Program Counter Detector 1213 Bytecode Cache Detector 1221 Interpretation Execution Function Detection Unit 1222 Symbol Table Detector 1223 Symbol Table Analysis Unit 1224 Value Object Parser 1231 Bytecode Extraction Unit 1232 Symbol Table Extraction Unit 1241 Execution Operation Unit 1242 Bytecode Injector 1243 Symbol Table Injection Section 12411 Executive Department 12412 Execution pause section 12413 Memory Enumeration Unit 12414 Execution restart section

Claims

1. a symbol table detection unit that detects, as a symbol table, a plurality of structures including addresses on a reference path from a first address to a second address including a value specified in the script in a memory area used by a program to execute the script; a symbol table analysis unit that analyzes an execution trace obtained by executing the script in a program and acquires structural information of the symbol table detected by the symbol table detection unit; An analysis device comprising:

2. an interpretive execution function detection unit that detects an interpretive execution function that has a memory access to either or both of a virtual program counter, which is a variable indicating an instruction of a program that executes the script, and a bytecode cache, which is a memory area indicated by the virtual program counter, in the execution trace; The symbol table detection unit detects, as a symbol table, a plurality of structures including addresses on a reference path from the first address indicated by a pointer of an argument of the interpretation execution function to the second address.

2. The analysis device according to claim 1 .

3. The symbol table detection unit assigns a taint tag to the first address, propagates the taint tag from the first address to the second address in accordance with a pointer reference in the execution of the script, and detects, as the symbol table, a plurality of structures including an address to which the taint tag is assigned.

2. The analysis device according to claim 1 .

4. When a memory access to an address on a reference path from the first address to the second address, which is indicated in the execution trace, uses both a base register and an index register, the symbol table analysis unit determines that a target of the memory access is an element of an array, and obtains a top address of the array and a subscript of the element from the base register and the index register.

2. The analysis device according to claim 1 .

5. When a memory access to an address on a reference path from the first address to the second address, which is indicated in the execution trace, uses a base register and does not use an index register, the symbol table analysis unit determines that a target of the memory access is a member variable of a structure, and calculates an offset of the member variable from a start address of the structure based on the effective address and the base register.

2. The analysis device according to claim 1 .

6. the symbol table detection unit detects, for each of the plurality of scripts, a plurality of structures including an address on the reference path as the symbol table; The symbol table analysis unit detects a structure of a portion common to the plurality of symbol tables and a structure of a portion not common to the plurality of symbol tables based on the length of the reference path of each of the plurality of symbol tables detected by the symbol table detection unit.

2. The analysis device according to claim 1 .

7. An analysis method performed by an analysis device, comprising: a symbol table detection step of detecting, as a symbol table, a plurality of structures including addresses on a reference path from a first address to a second address including a value specified in the script in a memory area used by a program to execute the script; a symbol table analysis step of analyzing an execution trace obtained by executing the script in a program and acquiring structural information of the symbol table detected by the symbol table detection step; An analysis method comprising:

8. a symbol table detection step of detecting, as a symbol table, a plurality of structures including addresses on a reference path from a first address to a second address including a value specified in the script in a memory area used by a program to execute the script; a symbol table analysis step of analyzing an execution trace obtained by executing the script in a program and acquiring structural information of the symbol table detected by the symbol table detection step; An analysis program characterized by causing a computer to execute the above.

Images