JP5273057B2 - Module update detection program, module update detection method, and module update detection apparatus - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To identify an updated module from compiled binary data. <P>SOLUTION: A module update detection device extracts operation information to be executed by binary data obtained by compiling a source file whose module has been updated from the binary data. The module update detection device extracts a machine language instruction from the operation information, and extracts an updated operation code from the extracted machine language instruction. On the other hand, the module update detection device extracts the operation information to be executed by the binary data obtained by compiling the source file whose module has not been updated yet from the binary data. The module update detection device extracts the machine language instruction from the operation information, and extracts the operation code which has not been updated yet from the extracted machine language instruction. Afterwards, the module update detection device detects whether or not the module has been updated by comparing the updated operation code with the operation code which has not been updated yet. <P>COPYRIGHT: (C)2011,JPO&amp;INPIT

Description

  The present invention relates to a module update detection program, a module update detection method, and a module update detection apparatus.

  2. Description of the Related Art Conventionally, as a method for detecting that a program module has been changed due to a change in system specifications or the like, a method for comparing and detecting a module before update and a module after update has been used. Specifically, a method for comparing module source files and a method for comparing binary data after module compilation are used.

  For example, in the case of the method of comparing the source files of modules, as shown in (1) of FIG. 13, the user can visually check the method and the like in the source file. Such updated locations can also be detected visually. However, in the case of a large-scale source file, the burden on the user is large, and oversight or the like also occurs, so that it is difficult to detect accurately. For this reason, recently, a method of comparing source files with a file comparison tool such as Windiff is used.

  In the case of a method of comparing class files that are binary data after compilation, it is difficult for the user to visually confirm the class file as shown in (2) of FIG. However, the class file has different compilation results if the original source file is different. From this, it is possible to detect whether or not the source file itself has been updated by comparing the class file obtained by the compilation before the module change with the class file obtained by the compilation after the change. In addition, FIG. 13 is a figure explaining a prior art.

JP 9-251400 A

  However, the conventional technique has a problem that an updated module cannot be specified unless the source files of the modules before and after the update are compared. For example, when the source file before and after the update is compared by the file comparison tool, the updated module can be specified, but the comparison of the module source file is essential.

  Further, when comparing the binary data after compilation, it can be specified only that the source file has been updated or not updated, and it cannot be specified which module has been updated. That is, even if any conventional technique is used, an updated module cannot be specified without a module source file.

  The disclosed technology has been made in view of the above, and provides a module update detection program, a module update detection method, and a module update detection device capable of specifying an updated module from compiled binary data The purpose is to do.

  In one aspect, a module update detection program, a module update detection method, and a module update detection apparatus disclosed in the present application, in one aspect, are operations performed by binary data from binary data obtained by compiling a source file with an updated module. Causes a computer to execute an operation extraction procedure for extracting information. Further, the computer executes an instruction extraction procedure for extracting a machine language instruction from the operation information extracted by the operation extraction procedure, and a code extraction procedure for extracting an operation code from the machine language instruction extracted by the instruction extraction procedure. Whether the module is updated by comparing the opcode extracted by the code extraction procedure with the opcode extracted from binary data obtained by compiling the source file before the module is updated. The computer executes an update detection procedure for detecting the above.

  According to one aspect of the module update detection program, the module update detection method, and the module update detection apparatus disclosed in the present application, there is an effect that it is possible to specify an updated module from the compiled binary data.

FIG. 1 is a block diagram illustrating the configuration of the module update detection apparatus according to the first embodiment. FIG. 2 is a block diagram illustrating the configuration of the module update detection apparatus according to the second embodiment. FIG. 3 is a diagram illustrating an example of information stored in the detection target class file DB. FIG. 4 is a diagram illustrating a condition example of method extraction stored in the extraction condition DB. FIG. 5 is a diagram illustrating an example of attribute extraction conditions stored in the extraction condition DB. FIG. 6 is a diagram showing an example of bytecode extraction conditions stored in the extraction condition DB. FIG. 7 is a diagram illustrating an example of an operation code extraction condition stored in the extraction condition DB. FIG. 8 is a diagram illustrating an example of information stored in the pre-update opcode information DB. FIG. 9 is a diagram illustrating an example of extracting a method from a class file. FIG. 10 is a diagram illustrating an example of extracting an operation code from a method. FIG. 11 is a flowchart illustrating the flow of processing in the module update detection apparatus according to the second embodiment. FIG. 12 is a diagram illustrating an example of a computer system that executes a module update detection program. FIG. 13 is a diagram for explaining the prior art.

  Hereinafter, embodiments of a module update detection program, a module update detection method, and a module update detection apparatus disclosed in the present application will be described in detail with reference to the drawings. Note that the present invention is not limited to the embodiments.

  FIG. 1 is a block diagram illustrating the configuration of the module update detection apparatus according to the first embodiment. The module update detection apparatus 1 shown in FIG. 1 may be built in a test machine that tests a program such as a developed source code or the like, or may be built in a compiler that compiles the source code. The module update detection apparatus 1 according to the first embodiment is connected to a compiler and receives an example of binary data 2 after compilation from the compiler.

  The module update detection apparatus 1 according to the first embodiment includes an operation extraction unit 1a, an instruction extraction unit 1b, a code extraction unit 1c, and an update detection unit 1d. The operation extraction unit 1a extracts operation information executed by the binary data 2 from the binary data 2 obtained by compiling the source file with the updated module.

  The instruction extraction unit 1b extracts a machine language instruction from the operation information extracted by the operation extraction unit 1a. The code extraction unit 1c extracts an operation code from the machine language instruction extracted by the instruction extraction unit 1b. The update detection unit 1d compares the operation code extracted by the code extraction unit 1c with the operation code extracted from the binary data obtained by compiling the source file before the module is updated, and the module is updated. It is detected whether or not. Then, the module update detection device 1 transmits the comparison result as an update detection result 3 to an external device or displays it on a display or the like.

  That is, the module update detection apparatus 1 according to the first embodiment detects whether the module in the source code has been updated from the binary data that is the actual asset after compilation by comparing the operation code changed by the module change. be able to. As a result, the module update detection apparatus 1 according to the first embodiment can specify an updated module from the compiled binary data.

  By the way, the module update detection apparatus may have various control units other than the control unit described in the first embodiment. Therefore, in the second embodiment, a module update detection apparatus having various control units in addition to the control unit described in the first embodiment will be described.

[Configuration of module update detection device]
First, the configuration of the module update detection apparatus according to the second embodiment will be described with reference to FIG. FIG. 2 is a block diagram illustrating the configuration of the module update detection apparatus according to the second embodiment. As illustrated in FIG. 2, the module update detection apparatus 10 includes a communication control I / F (InterFace) unit 11, an input unit 12, a display unit 13, a storage unit 15, and a control unit 20.

  The communication control I / F unit 11 is an interface having at least one communication port, and controls information exchanged with other devices. For example, the communication control I / F unit 11 is connected to a compiler, receives a class file obtained by compiling a Java (registered trademark) source file, and detects a class file DB (DataBase) to be detected in the storage unit 15 described later. 16 and the pre-update opcode information DB 18. The communication control I / F unit 11 is connected to a management computer used by the program developer, receives a module update detection processing start instruction, and transmits a module update detection result and the like.

  The input unit 12 is, for example, a keyboard, a mouse, a microphone, and the like. The input unit 12 receives an input of a module update detection process start instruction and an end instruction from the user, and inputs the input to the control unit 20 and the like described later. The input unit 12 can read information from and write information to a storage medium such as a CD (Compact Disc), a DVD (Digital Versatile Disc), or a magnetic disk. For example, the input unit 12 can read the class file from the storage medium and store it in the storage unit 15.

  Note that the display unit 13 described later also realizes a pointing device function in cooperation with the mouse. The display unit 13 is, for example, a monitor, a display, a touch panel, a speaker, or the like, and displays and outputs a module update detection result or the like performed by the control unit 20 described later.

  The storage unit 15 stores data and programs necessary for various processes performed by the control unit 20, and includes a detection target class file DB 16, an extraction condition DB 17, and a pre-update opcode information DB 18. The detection target class file DB 16, the extraction condition DB 17, and the pre-update opcode information DB 18 are, for example, a semiconductor memory element such as a RAM (Random Access Memory), or a storage device such as a hard disk or an optical disk.

  The detection target class file DB 16 stores a class file for performing module update detection processing. For example, as shown in FIG. 3, the detection target class file DB 16 is binary data compiled by a compiler, and stores a class file dumped in hexadecimal notation. The detection target class file DB 16 may store the class file received via the communication control I / F unit 11, read out from the storage medium received by the input unit 12, and store the class file. Any method may be used. FIG. 3 is a diagram illustrating an example of information stored in the detection target class file DB.

  The extraction condition DB 17 stores extraction conditions used when each function unit of the control unit 20 extracts an operation code from a class file stored in the detection target class file DB 16. For example, the extraction condition DB 17 stores the conditions shown in FIGS. FIG. 4 is a diagram illustrating an example of method extraction conditions stored in the extraction condition DB, and FIG. 5 is a diagram illustrating an example of attribute extraction conditions stored in the extraction condition DB. FIG. 6 is a diagram showing an example of bytecode extraction conditions stored in the extraction condition DB, and FIG. 7 is a diagram showing an example of opcode extraction conditions stored in the extraction condition DB.

  For example, as illustrated in FIG. 4, the extraction condition DB 17 stores a method extraction condition used by the method extraction unit 21 when extracting a “method” from a “class file”. Specifically, the extraction condition DB 17 stores “element” stored in the class file in association with “size” of the element. For example, the extraction condition DB 17 includes “magic number, 4 bytes”, “minor version, 2 bytes”, “major version, 2 bytes”, “number of constant pools, 2 bytes”, “constant pool, “Variable length” is stored. The extraction condition DB 17 stores “access flag, 2 bytes”, “own class, 2 bytes”, “parent class, 2 bytes”, “number of interfaces, 2 bytes”, “interface, 2 bytes × number of interfaces”. To do. The extraction condition DB 17 includes “number of fields, 2 bytes”, “field, variable length”, “number of methods, 2 bytes”, “method, variable length”, “number of attributes, 2 bytes”, “attribute, variable length”. Is memorized.

  The method extraction condition stored here is information indicating what information is written at which position in the class file. As an example, the “magic number” is written in the position from the beginning of the class file to the 4th byte, and in the next 2 bytes of the magic number, in other words, in the 5th and 6th bytes of the class file. "Minor version" is written. Then, the method extraction unit 21 extracts each piece of information according to the method extraction condition from the top of the class file in this way, and extracts “number of methods” information and “method” information from the class file.

  The magic number is information for identifying the class file format, and has a value of, for example, 0xCAFEBABE. The minor version indicates the minor version of the class file, and the major version indicates the major version of the class file. The number of constant pools indicates the number of elements in the following constant pool, and the constant pool is a structure table that can be accessed by an index and expresses various constants referenced from within the class file. . The access flag is a flag that represents the access permission or attribute of the class or interface.

  The own class is information indicating an index of constant pool information indicating its own class information, and the parent class is information indicating an index of constant pool information indicating its own parent class information. The number of interfaces indicates the number of implemented interfaces, and the interface indicates an array of constant pool information indexes representing installed interface information. The field number indicates the number of class fields, and the field indicates an array of information representing the class fields. The method number indicates the number of methods, and the method indicates an array of information representing the method. The number of attributes indicates the number of attributes, and the attribute indicates an array of information representing the attributes.

  Further, as illustrated in FIG. 5, the extraction condition DB 17 stores attribute extraction conditions used by the attribute extraction unit 22 when extracting “attribute” information from “method” information. Specifically, the extraction condition DB 17 stores an “element” included in the method information in association with the “size” of the element. For example, the extraction condition DB 17 sets “element, size” as “access flag, 2 bytes”, “method name, 2 bytes”, “descriptor, 2 bytes”, “number of attributes, 2 bytes”, “attribute, variable length”. And remember.

  The attribute extraction condition stored here is information indicating in which position of the “method” information extracted from the class file the “attribute” information is written. As an example, an “access flag” is written at the position from the beginning of the method information extracted by the method extraction unit 21 to the second byte. In addition, the “method name” is written in the next two bytes of the access flag, in other words, the third and fourth bytes of the method information. Then, the attribute extraction unit 22 extracts each piece of information from the top of the method information according to the attribute extraction condition, and extracts “attribute” information from the “method” information.

  The access flag indicates a mask flag indicating access permission or attribute of the method, and the method name indicates an index of constant pool information indicating the method name. The descriptor indicates an index of constant pool information representing the method descriptor. The attribute number indicates the number of attributes, and the attribute indicates an array of information indicating the attribute of the method.

  Further, as illustrated in FIG. 6, the extraction condition DB 17 stores byte code extraction conditions used by the byte code extraction unit 23 when extracting “byte code” information from “attribute” information. Specifically, the extraction condition DB 17 stores the “element” stored in the attribute information in association with the “size” of the element. For example, the extraction condition DB 17 stores “attribute name, 2 bytes”, “attribute length, 4 bytes”, “maximum stack, 2 bytes”, “maximum number of local variables, 2 bytes” as “element, size”. . The extraction condition DB 17 includes “code length, 4 bytes”, “code, code length”, “number of exception tables, 2 bytes”, “exception table, 8 × number of exception tables”, “number of attributes, “2 bytes” and “attribute, variable length” are stored.

  The byte code extraction condition stored here is information indicating in which position of the “attribute” information extracted from the class file the “byte code” information is written. As an example, “attribute name” is written at the position from the beginning of the attribute information extracted by the attribute extraction unit 22 to the second byte. In addition, the “attribute length” is written in the next 4 bytes of the attribute name, in other words, in the position of the third to sixth bytes of the attribute information. Then, the byte code extraction unit 23 extracts each piece of information according to the byte code extraction condition from the top of the attribute information as described above, and extracts “byte code” information from the “attribute” information.

  The attribute name indicates an index of constant pool information indicating the character string “Code”, and the attribute length indicates the length of the attribute (attribute). The maximum stack indicates the maximum depth of the operand stack, and the maximum number of local variables indicates the number of local variables. The length of the code indicates the length of the byte code, and the code indicates the byte code that is a machine language instruction. The number of exception tables indicates the number of exception tables, and the exception table indicates an array of exception information handled by this method. The attribute number indicates the number of attributes, and the attribute indicates an array of information indicating the attribute of CodeAttribute.

  Further, as shown in FIG. 7, the extraction condition DB 17 stores an operation code extraction condition used by the operation code extraction unit 24 when extracting “operation code” information from “byte code” information. Specifically, the extraction condition DB 17 stores “opcode, operand1, operand2,...” As information included in the bytecode information. The operation code extraction condition stored here is information indicating in which position of the “byte code” information extracted from the class file the “opcode” information is written. Using this information, the operation code extraction unit 24 extracts “operation code” information from the “byte code” information. There are 204 types of opcodes, and the size and meaning of each operand are different, but the size and meaning are determined for each opcode. For this reason, the operation code extraction unit 24 can extract only the operation code by referring to the byte code in order from the top by using the operation code extraction condition in which the size of the operation code and its operands are all known.

  Returning to FIG. 2, the pre-update opcode information DB 18 stores the opcode extracted from the pre-update state of the class file to be detected. The opcodes and operands stored in the pre-update opcode information DB 18 are acquired and stored by executing each control unit of the control unit 20 described later.

  Further, the pre-update opcode information DB 18 stores, for example, an “identifier” that identifies a class file and an “opcode” extracted for each method in the class file in association with each other. By doing so, the pre-update opcode information DB 18 can store the opcodes extracted from each of the plurality of class files so that they can be uniquely identified.

  As an example, the pre-update opcode information DB 18 includes “0, 2A, −”, “1, B1, −”, “3, −, 00” as “Index, opcode, operand”, as shown in FIG. “4, −2E” or the like is stored. Further, the pre-update opcode information DB 18 stores valid line position information indicating lines that are actually executed in the source file, as shown in FIG. This Index indicates an item number that distinguishes the extracted opcode and operand. The operation code is obtained by replacing instructions of a processor such as a CPU (Central Processing Unit) with a bit string, and indicates an instruction number to be processed by the processor. An operand is a target on which an operation is performed, and indicates a memory address where data used as information is stored, a place where a calculation result is stored, and the like. FIG. 8 is a diagram illustrating an example of information stored in the pre-update opcode information DB.

  Further, the pre-update opcode information DB 18 may store the extracted method and opcode in association with each version of the class file. For example, the pre-update opcode information DB 18 stores a “class identifier” that identifies a class file, a “version” that indicates the update history of the class file, a “method identifier” that identifies a method, and an extracted “opcode” in association with each other. . By doing so, the module update detection apparatus 10 can compare the opcode extracted from the current class file with the opcode extracted from any version of the class file specified by the user. As a result, a developer or the like can recognize how much the current class file has been updated from an arbitrary version of the class file. Further, the module update detection apparatus 10 can also compare the operation codes extracted from each of two arbitrary version class files specified by the user.

  The control unit 20 is, for example, an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an electronic circuit such as a CPU or MPU (Micro Processing Unit). The control unit 20 includes a control program such as an OS (Operating System), a program that defines various processing procedures, and an internal memory for storing necessary data. Furthermore, the control unit 20 includes a method extraction unit 21, an attribute extraction unit 22, a byte code extraction unit 23, an operation code extraction unit 24, and an update detection unit 25, and executes various processes.

  The method extraction unit 21 extracts method information from a class file obtained by compiling a Java source file with an updated module. For example, when the module update detection processing start instruction is received by the input unit 12 or the like, the method extraction unit 21 reads a class file stored in the detection target class file DB 16. Then, the method extraction unit 21 extracts a method from the read class file in accordance with the method extraction condition stored in the extraction condition DB 17 and outputs the extracted method to the attribute extraction unit 22. Alternatively, the method extraction unit 21 writes the extracted method in a memory or the like.

  As an example, the method extraction unit 21 extracts “CA FE BA BE” as a magic number from the class file in hexadecimal notation shown in FIG. 3 according to the method extraction condition. Subsequently, the method extraction unit 21 extracts “00 00” as the minor version and the subsequent “00 31” as the major version. Subsequently, the method extraction unit 21 extracts “00 37” as the number of constant pools, and extracts a constant pool having “0x0037” = “54” elements. That is, the method extraction unit 21 extracts the element 1 as “07 00 02”. Thus, the method extraction unit 21 extracts the constant pools in order from the number of constant pools “00 37” in the class file.

  After extracting the number of constant pools, the method extraction unit 21 “access flag”, “own class”, “parent class”, “number of interfaces”, “interface”, “number of fields”, “fields” according to the method extraction condition. Are extracted in order from the class file. Thereafter, the method extraction unit 21 extracts “number of methods” from the class file, and extracts “methods” corresponding to the number of extracted methods from the class file.

  For example, the method extraction unit 21 extracts “61 2F 6C 61 6E 67 2F 4F 62 6A 65 63 74 01 00 05 05 63 6F 75 6E 74 01 00 01” from the class file as shown in FIG. . Similarly, the method extraction unit 21 extracts “49 01 00 06 3C 69 6E 69 74 3E 01 00 15 28 4C 6A 61 76 61 2F 6C 61 6E 67” as the method B. Similarly, the method extraction unit 21 extracts “2F 53 74 72 69 6E 67 3B 29 56 01 00 04 43 6F 64 65 07 00 0B 01 00 0F 6A” as the method C. Then, the method extraction unit 21 outputs the extracted methods A, B, and C to the attribute extraction unit 22. FIG. 8 is a diagram illustrating an example of extracting a method from a class file.

  The attribute extraction unit 22 extracts method information attributes from the method information extracted by the method extraction unit 21. For example, the attribute extraction unit 22 extracts attribute information from each of the method A, method B, and method C extracted by the method extraction unit 21 in accordance with the attribute extraction condition stored in the extraction condition DB 17, and extracts the extracted attribute information as a byte. The data is output to the code extraction unit 23.

  As an example, the attribute extraction unit 22 extracts “49 01” of the method B “49 01 00 06 3C 69 6E 69 74 3E 01 00 15 28 4C 6A 61 76 61 2F 6C 61 6E 67” as an access flag. Subsequently, the attribute extraction unit 22 extracts the next 2 bytes “00 06” of the access flag as a method name, and extracts the next 2 bytes “3C 69” of the method name as a descriptor. Further, the attribute extraction unit 22 extracts the next 2 bytes “6E 69” of the descriptor as the number of attributes, and then extracts “74 3E 01 00 15 28 4C 6A 61 76 61 2F 6C 61 6E 67” as the attribute information. To do.

  The byte code extraction unit 23 extracts a byte code that is a machine language instruction from the attribute information extracted by the attribute extraction unit 22. For example, the byte code extraction unit 23 extracts byte code information from each attribute information extracted from each method by the attribute extraction unit 22 in accordance with the byte code extraction conditions stored in the extraction condition DB 17, and extracts the extracted byte code information. The result is output to the operation code extraction unit 24.

  As an example, the bytecode extraction unit 23 extracts “74 3E” of the attribute information “74 3E 01 00 15 28 4C 6A 61 76 61 2F 6C 61 6E 67” of the method B as an attribute name. Subsequently, the bytecode extraction unit 23 extracts the next 4 bytes “01 00 15 28” of the attribute name as the attribute length. Subsequently, the byte code extraction unit 23 extracts the next 2 bytes “4C 6A” of the attribute length as the maximum stack. In this way, the byte code extraction unit 23 extracts each piece of attribute information from the top of the attribute information in accordance with the byte code extraction condition in order from the top of the attribute information, and extracts the byte code information.

  The operation code extraction unit 24 extracts an operation code from the byte code information extracted by the byte code extraction unit 23. For example, the operation code extraction unit 24 extracts the operation code information from the byte code information extracted from the attribute information by the byte code extraction unit 23 according to the operation code extraction condition stored in the extraction condition DB 17, and updates the extracted operation code information. Output to the detector 25.

  As an example, in the byte code information of each method information extracted by the byte code extraction unit 23, “opcode, operand 1, operand 2” is basically repeatedly described. By using this, the operation code extraction unit 24, as shown in FIG. 10, "0, 2A,-", "1, B4,-", "3,-, 00" as "Index, operation code, operand". , “4, −2E”, etc. Further, the pre-update opcode information DB 18 stores valid line position information indicating lines that are actually executed in the source file, as shown in FIG. The Index, the opcode, and the operand are the same information as in FIG. 8, and detailed description thereof is omitted here. FIG. 10 is a diagram illustrating an example of extracting an operation code from a method.

  The update detection unit 25 compares the operation code extracted by the bytecode extraction unit 23 with the operation code extracted from the class file before the Java module is updated, and detects whether or not the module has been updated. For example, the update detection unit 25 compares the operation code information extracted from the byte code information by the operation code extraction unit 24 with the operation code extracted from the class file before the Java module is updated. If there is a difference as a result of the comparison, the update detection unit 25 detects that there is an update, and outputs a method having the updated operation code to the display unit 13 or the management computer.

  For example, the update detection unit 25 acquires the operation code of the version of the class file designated by the user from the pre-update operation code information DB 18. Then, the update detection unit 25 compares the operation code extracted by the bytecode extraction unit 23, the operand, the operation code in the valid row position information, and the operation code acquired from the pre-update operation code information DB 18 using a comparison tool or the like. . If a difference is found as a result of the comparison, the update detection unit 25 detects that the source file has been updated, and detects a method having an operation code having a difference as an updated method.

  As an example, when the update detection unit 25 compares the operation code information before update in FIG. 8 with FIG. 10 as the operation code information after update, the value of “Index = 1” is “B1” before update. Since it is “B4” after the update, an update is detected.

[Process flow]
Next, the flow of processing in the module update detection apparatus according to the second embodiment will be described with reference to FIG. FIG. 11 is a flowchart illustrating the flow of processing in the module update detection apparatus according to the second embodiment.

  As illustrated in FIG. 11, the method extraction unit 21 of the module update detection apparatus 10 receives a module update detection process start instruction via the input unit 12 or the like (step S <b> 101). Subsequently, the method extraction unit 21 reads one class file stored in the detection target class file DB 16 (step S102).

  Subsequently, the method extraction unit 21 extracts a method from the read class file in accordance with the method extraction condition stored in the extraction condition DB 17 (step S103). Then, the attribute extraction unit 22 reads one method information extracted by the method extraction unit 21, and extracts the attribute of the method information from the read method information according to the attribute extraction condition stored in the extraction condition DB 17 (step S104). .

  Subsequently, the byte code extraction unit 23 extracts a byte code from the attribute extracted by the attribute extraction unit 22 in accordance with the byte code extraction condition stored in the extraction condition DB 17 (step S105). Subsequently, the operation code extraction unit 24 extracts operation code information from the byte code information extracted by the byte code extraction unit 23 in accordance with the operation code extraction condition stored in the extraction condition DB 17 (step S106).

  Thereafter, the update detection unit 25 compares the operation code extracted by the bytecode extraction unit 23 with the operation code extracted from the class file before the Java module is updated (step S107). As a result of the comparison, if there is a difference (Yes at Step S108), the update detection unit 25 detects that the target method has been updated (Step S109). On the other hand, if there is no difference as a result of the comparison (No at Step S109), the update detection unit 25 detects that the target method has not been updated (Step S110).

  And the update detection part 25 performs the process of step S112, when the process from step S104 to step S110 is performed about all the methods of a class file (step S111 affirmation). Thereafter, when the process from step S102 to step S111 is executed for the class file subject to update detection (Yes at step S112), the update detection unit 25 ends the process.

  On the other hand, when there is a method that does not execute the processes from step S104 to step S110 (No at step S111), the module update detection apparatus 10 executes the processes after step S104. If there is a class file that has not been subjected to the processing from step S102 to step S111 (No at step S112), the module update detection apparatus 10 executes the processing after step S102.

[Effects of Example 2]
Thus, the module update detection apparatus 10 according to the second embodiment extracts only the operation code that is changed when the method is changed as a comparison target. As a result, the module update detection apparatus 10 according to the second embodiment identifies the updated method by comparing the class files before and after the update obtained by compiling without comparing the source files of the modules before and after the update. Is possible. Further, the module update detection apparatus 10 excludes operands that are affected by others, such as when other methods are changed, from being compared, so that unnecessary comparison processing can be omitted, and efficient comparison processing can be performed. The update detection can be executed at high speed.

  In addition, since the update can be detected from the compiled class file without using the source file itself, the update of the module (method) can be confirmed even in a situation where there is no source file. In addition, since it is not necessary to hold a source file having a larger capacity than the class file, the memory can be used effectively.

  Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the embodiments described above. Therefore, different embodiments will be described below.

(Comparison method)
For example, the module update detection apparatus 10 according to the second embodiment has described the example in which the operation code extracted from the class file before update and the operation code extracted from the class file after update are compared using a comparison tool or the like. However, the present invention is not limited to this. As an example, the module update detection apparatus 10 compares the hash value of the opcode extracted from the class file before the update with the hash value of the opcode extracted from the class file after the update to determine whether or not the update has been performed. It can also be detected. A general hash function can be used as a method for calculating the hash value of each operation code.

  As an example, the module update detection device 10 generates a hash value by generating one data combining all the operation codes extracted from the updated class file and calculating the generated data using a hash function. To do. Similarly, the module update detection apparatus 10 generates one data combining all the operation codes extracted from the class file before the update, and calculates a hash value by calculating the generated data using a hash function. . The module update detection apparatus 10 detects that there is no update when both hash values match, and detects that there is an update when both hash values do not match. By doing so, even when comparing a large number of operation codes obtained from a complicated and huge number of source files, it is possible to compare efficiently.

(Target program)
For example, in the second embodiment, a Java source file has been described as an example of an update detection target. However, the present invention is not limited to this. For example, when it is possible to determine what information is written at which position in the compiled binary data, the update is detected in the source file of any language by the same method as in the first and second embodiments. be able to.

  In the first and second embodiments, the example has been described in which it is detected whether or not there is an update using only the operation code as a comparison target. However, the present invention is not limited to this. For example, by storing the offset before update, it is detected whether the operand itself has been changed or whether the operand has been changed due to the influence of others. As a result, it is possible to detect whether or not the method has been updated even with a comparison method using operands.

(System configuration etc.)
In addition, among the processes described in the present embodiment, all or a part of the processes described as being automatically performed can be manually performed. Alternatively, for example, all or part of the processing described as being performed manually such as reception of a processing start instruction can be automatically performed by a known method. In addition, the processing procedures, control procedures, and specific names shown in the above-mentioned documents and drawings, for example, information including various data and parameters shown in FIGS. 3 to 8 etc. are optional unless otherwise specified. Can be changed.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device, for example, integrating the method extraction unit 21 and the attribute extraction unit 22 is not limited to that shown in the figure. In addition, all or a part of each device can be configured to be functionally or physically distributed / integrated in arbitrary units according to various loads or usage conditions. Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.

(program)
By the way, the various processes described in the above embodiments can be realized by executing a program prepared in advance on a computer system such as a personal computer or a workstation. Therefore, in the following, an example of a computer system that executes a program having the same function as in the above embodiment will be described.

  FIG. 12 is a diagram illustrating an example of a computer system that executes a module update detection program. As illustrated in FIG. 12, the computer system 100 includes a RAM 101, an HDD 102, a ROM (Read Only Memory) 103, and a CPU 104. Here, the ROM 103 stores in advance a program that exhibits the same function as in the above embodiment. That is, as shown in FIG. 12, the ROM 103 stores a method extraction program 103a, an attribute extraction program 103b, and a byte code extraction program 103c in advance. The ROM 103 stores an operation code extraction program 103d and an update detection program 103e in advance.

  Then, the CPU 104 reads out and executes these programs 103a to 103e, thereby forming each process as shown in FIG. That is, each of the programs 103a to 103e is a method extraction process 104a, an attribute extraction process 104b, a byte code extraction process 104c, an operation code extraction process 104d, and an update detection process 104e. The method extraction process 104a corresponds to the method extraction unit 21 shown in FIG. 2, similarly, the attribute extraction process 104b corresponds to the attribute extraction unit 22, and the byte code extraction process 104c corresponds to the byte code extraction unit 23. Corresponding to The operation code extraction process 104d corresponds to the operation code extraction unit 24 illustrated in FIG. 2, and the update detection process 104e corresponds to the update detection unit 25.

  Further, the HDD 102 is provided with a detection target class file table 102a, an extraction condition table 102b, and a pre-update opcode information table 102c. The detection target class file table 102a corresponds to the detection target class file DB 16 shown in FIG. 2, the extraction condition table 102b corresponds to the extraction condition DB 17, and the pre-update operation code information table 102c corresponds to the pre-update operation code information DB 18. To do.

  By the way, the above-described programs 103 a to 103 e are not necessarily stored in the ROM 103. For example, the programs 103a to 103e are stored in a “portable physical medium” such as a flexible disk (FD), a CD-ROM, a DVD disk, a magneto-optical disk, or an IC card inserted into the computer system 100. May be. Further, it may be stored in a “fixed physical medium” such as a hard disk drive (HDD) provided inside or outside the computer system 100. Further, it may be stored in “another computer system” connected to the computer system 100 via a public line, the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or the like. Then, the computer system 100 may read the program from these and execute it.

  That is, the program referred to in the other embodiments is recorded in a computer-readable manner on a recording medium such as the above-mentioned “portable physical medium”, “fixed physical medium”, “communication medium”, and the like. . Then, the computer system 100 realizes the same function as the above-described embodiment by reading and executing the program from such a recording medium. The program referred to in the other embodiments is not limited to being executed by the computer system 100. For example, the present invention can be similarly applied to a case where another computer system or server executes a program or a case where these programs cooperate to execute a program.

DESCRIPTION OF SYMBOLS 1 Module update detection apparatus 1a Operation extraction part 1b Instruction extraction part 1c Code extraction part 1d Update detection part 2 Compiled binary data 3 Update detection result 10 Module update detection apparatus 11 Communication control I / F part 12 Input part 13 Display part 15 Storage unit 16 Detection target class file DB
17 Extraction condition DB
18 Pre-update opcode information DB
DESCRIPTION OF SYMBOLS 20 Control part 21 Method extraction part 22 Attribute extraction part 23 Byte code extraction part 24 Opcode extraction part 25 Update detection part

Claims (6)

An operation extraction procedure for extracting operation information executed by the binary data from the binary data obtained by compiling the updated source file of the module;
An instruction extraction procedure for extracting a machine language instruction from the operation information extracted by the operation extraction procedure;
A code extraction procedure for extracting an operation code from the machine language instruction extracted by the instruction extraction procedure;
Whether the module is updated by comparing the opcode extracted by the code extraction procedure with the opcode extracted from binary data obtained by compiling the source file before the module is updated. A module update detection program which causes a computer to execute an update detection procedure to be detected.   Whether the module is updated by comparing the hash value of the operation code extracted by the code extraction procedure with the hash value of the operation code extracted from the binary data before being updated, in the update detection procedure The module update detection program according to claim 1, wherein the module update detection program is detected. An operation extraction step of extracting operation information executed by the binary data from the binary data obtained by compiling the source file with the updated module;
An instruction extraction step of extracting a machine language instruction from the operation information extracted by the operation extraction step;
A code extraction step of extracting an operation code from the machine language instruction extracted by the instruction extraction step;
It is determined whether or not the module is updated by comparing the opcode extracted in the code extraction step with the opcode extracted from binary data obtained by compiling the source file before the module is updated. A module update detection method comprising: an update detection step for detecting.   Whether the module is updated by comparing the hash value of the operation code extracted by the code extraction step with the hash value of the operation code extracted from the binary data before being updated, in the update detection step The module update detection method according to claim 3, wherein the module update is detected. A code storage unit for storing an operation code extracted from binary data obtained by compiling a source file before the module is updated;
An operation extraction unit that extracts operation information executed by the binary data from binary data obtained by compiling the updated source file of the module;
An instruction extraction unit for extracting a machine language instruction from the operation information extracted by the operation extraction unit;
A code extraction unit that extracts an operation code from the machine language instruction extracted by the instruction extraction unit;
An update detection unit that detects whether the module has been updated by comparing the operation code extracted by the code extraction unit with an operation code stored in the code storage unit. Detection device.   The update detection unit detects whether the module has been updated by comparing the hash value of the operation code extracted by the code extraction unit and the hash value of the operation code stored in the code storage unit. The module update detection apparatus according to claim 5.

Images