Estimation of features corresponding to extracted commands used to divide code of software

Abstract

A feature estimating device includes a parser identifying means for identifying a parser, the parser being contained in software, for parsing user input and executing a relevant command, a dividing means for extracting commands form a character string in the parser and clustering control flows connecting with the extracted commands as starting points to divide a code of the software for each feature, and a feature estimating means for estimating, based on a characteristic part of each divided code, a feature for each divided code.

Claims

1. A feature estimating device comprising: at least one processor; and at least one memory storing instructions executable by the processor to identify a parser, the parser being contained in software, for parsing user input and executing a relevant command; extract upper commands to be directly executed by the parser, from a character string in the parser; cluster control flows connecting with the extracted upper commands as starting points to divide code of the software for each of a plurality of features of the software; estimate each of the plurality of features based on a characteristic part of the divided code for the feature, and based on information about an application programming interface (API) to be called when the divided code for the feature is executed; and perform code inspection on the code of the software for each of the plurality of features that has been estimated, wherein the upper commands include a first command as a first starting point of the starting points, the plurality of features include a first feature corresponding to the first command, and the divided code for the first feature contains the code of the software, including all subcommands, through which the control flows are traceable downstream from the first command as the first starting point.

2. The feature estimating device according to claim 1, wherein the characteristic part of the divided code for each of the plurality of features contains at least one of a name of a corresponding command, a name of a function corresponding to the corresponding command, a user-defined function called inside the function, a library function, a system call, and an instruction contained in the divided code.

3. The feature estimating device according to claim 1, wherein each of the plurality of features is estimated based on information about an application programming interface (API) to be called when the divided code for the feature is executed.

4. The feature estimating device according to claim 1, wherein each of the plurality of features is estimated based further on information about a state of file access when the divided code for the feature is executed.

5. A feature estimating method comprising: identifying, by a processor, a parser, the parser being contained in software, for parsing user input and executing a relevant command; extracting, by the processor, upper commands to be directly executed by the parser, from a character string in the parser; clustering, by the processor, control flows connecting with the extracted upper commands as starting points to divide code of the software for each of a plurality of features of the software; estimating each of the plurality of features, by the processor, based on a characteristic part of the divided code for the feature, and based on information about an application programming interface (API) to be called when the divided code for the feature is executed; and performing, by the processor, code inspection on the code of the software for each of the plurality of features that has been estimated, wherein the upper commands include a first command as a first starting point of the starting points, the plurality of features include a first feature corresponding to the first command, and the divided code for the first feature contains the code of the software, including all subcommands, through which the control flows are traceable downstream from the first command as the first starting point.

6. A non-transitory computer-readable medium storing a program executable by a computer to perform: identifying a parser, the parser being contained in software, for parsing user input and executing a relevant command; extracting upper commands to be directly executed by the parser, from a character string in the parser; clustering control flows connecting with the extracted upper commands as starting points to divide code of the software for each of a plurality of features of the software; estimating each of the plurality of features based on a characteristic part of the divided code for the feature, and based on information about an application programming interface (API) to be called when the divided code for the feature is executed; and performing code inspection on the code of the software for each of the plurality of features that has been estimated, wherein the upper commands include a first command as a first starting point of the starting points, the plurality of features include a first feature corresponding to the first command, and the divided code for the first feature contains the code of the software, including all subcommands, through which the control flows are traceable downstream from the first command as the first starting point.

Description

BRIEF DESCRIPTION OF DRAWINGS

(1) FIG. 1 is a block diagram showing a configuration of a feature estimating device according to a first example embodiment;

(2) FIG. 2 is a block diagram showing a configuration of a feature estimating device according to a second example embodiment;

(3) FIG. 3 is a flowchart for explaining a procedure of processing of estimating a feature for each divided code in the feature estimating device according to the second example embodiment;

(4) FIG. 4 is a diagram for explaining processing of extracting commands from a character string in a parser in step S102 of FIG. 3;

(5) FIG. 5 is a diagram for explaining processing of dividing a code of software for each feature by clustering control flows connecting with the extracted commands as starting points in step S103 of FIG. 3; and

(6) FIG. 6 is a diagram for explaining processing in steps S104 and S105 of FIG. 3.

DESCRIPTION OF EMBODIMENTS

(7) Hereinafter, example embodiments of the present invention will be described with reference to the drawings. The following description and the drawings are appropriately omitted or simplified to clarify the explanation. In the drawings, the same elements are denoted by the same reference signs, and duplicated descriptions are omitted as necessary.

First Example Embodiment

(8) A first example embodiment will be described below.

(9) FIG. 1 is a block diagram showing a configuration of a feature estimating device 10 according to a first example embodiment. As shown in FIG. 1, the feature estimating device 10 includes a parser identifying means 11, a dividing means 12, and a feature estimating means 13.

(10) The parser identifying means 11 identifies a parser contained in software. Here, a parser is for parsing user input and executing a relevant command. The dividing means 12 extracts commands from a character string in the parser and clusters control flows connecting with the extracted commands as starting points to divide a code of the software for each feature. The feature estimating means 13 estimates a feature for each divided code based on a characteristic part of each divided code.

(11) It is possible to estimate features contained in software from a code to be able to accurately easily inspect the code of the software for each feature.

Second Example Embodiment

(12) A second example embodiment will be described below.

(13) First, a configuration example of a feature estimating device according to the second example embodiment is described. FIG. 2 is a block diagram showing a configuration of a feature estimating device 110 according to the second example embodiment. As shown in FIG. 2, the feature estimating device 110 includes a parser identifying means 111, a dividing means 112, a feature estimating means 113, and a feature labeling means 114.

(14) The parser identifying means 111 identifies a parser contained in software and for parsing user input and executing a relevant command. Note that, a method for identifying a parser in a code of software may be a known method of, for example, searching for a characteristic function used in the parser. The dividing means 112 extracts commands from a character string in the parser and clusters control flows connecting with the extracted commands as starting points to divide a code of the software for each feature. The feature estimating means 113 estimates, based on a characteristic part of each divided code, a feature for each divided code. The feature labeling means 114 labels each divided code with the feature estimated by the feature estimating means 113.

(15) In the above description, the control flows are clustered using the extracted commands as the starting points, but control flows to be validated by settings may be clustered using setting items of the software as starting points instead of the commands. In this case, the parser is for parsing setting information and controlling validity/invalidity of the control flows depending on the settings.

(16) Next, a procedure of processing of estimating a feature for each divided code in the feature estimating device 110 is described. Note that, FIG. 2 is appropriately referred to in the following description.

(17) FIG. 3 is a flowchart for explaining a procedure of processing of estimating a feature for each divided code in the feature estimating device 110. As shown in FIG. 3, first, the parser identifying means 111 identifies a parser contained in software (step S101). Then, the dividing means 112 extracts commands from a character string in the parser (step S102). Then, the dividing means 112 clusters control flows connecting with the extracted commands as starting points to divide a code of the software for each feature (step S103). Then, the feature estimating means 113 estimates, based on a characteristic part of each divided code, a feature for each divided code (step S104). Then, the feature labeling means 114 labels each divided code with the feature estimated by the feature estimating means 113 (step S105).

(18) FIG. 4 is a diagram for explaining the processing of extracting commands from a character string in a parser in step S102 of FIG. 3. As shown in FIG. 4, if a subject to be inspected is a source code, the code about a parser contains a conditional statement (for example, an if statement or a switch-case statement) for executing an upper command (an upper command k; k=1 to n) input by a user. If a subject to be inspected is a binary, a character string of an upper command is in a reference destination of an instruction for comparing character strings or the like. That is, the code about the parser contains all the character strings of the upper command to be directly executed by the parser. Thus, when character strings of a command are extracted from the code about the parser, the character strings of an upper command 1, an upper command 2, . . . , and an upper command n are cmd1, cmd2, . . . , and cmdn, respectively.

(19) FIG. 5 is a diagram for explaining the processing of dividing a code of software for each feature by clustering control flows connecting with the extracted commands as starting points in step S103 of FIG. 3. FIG. 5 shows an example of a control flow graph of software to be analyzed. Here, the control flow graph is a graph representing all possible paths that are passed through when the software is executed.

(20) In the example shown in FIG. 5, a control flow Cfk (k=1 to n) from the parser extends to an upper command Ck (k=1 to n). A control flow Cfk1a (k=1 to n) from the upper command Ck extends to a first layer subcommand SCfk1a (k=1 to n), and a control flow Cfk1b (k=1 to n) from the upper command Ck extends to a first layer subcommand SCfk1b (k=1 to n). In addition, a control flow Cfk2a from the first layer subcommand SCfk1 a extends to a second layer subcommand SCfk2a (k=1 to n), and a control flow Cfk2b from the first layer subcommand SCfk1b extends to a second layer subcommand SCfk2b (k=1 to n).

(21) That is, control flows from the parser extend to upper commands (parent commands). Then, control flows extend from each upper command to first layer subcommands (child commands), and further extend from the first layer subcommands to second layer subcommands (grandchild commands). Except for a special case, it is assumed that, in general software, control flows extending from a parser connect with downstream subcommands through upper commands as described above.

(22) Control flows that can be traced from an upper command are clustered as a cluster of the upper command. In the example shown in FIG. 5, the control flow Cfk1a, the control flow Cfk1b, the control flow Cfk2a, and the control flow Cfk2b are clustered as the feature k (k=1 to n).

(23) A divided code of a feature corresponding to a first command, which is one of the upper commands, contains the codes of all the subcommands through which the control flows that can be traced downstream from the first command as a starting point. The code of the first command and the codes of the subcommands through which the control flows clustered as a cluster of the first command pass are assumed to be a divided code of one feature contained in the software.

(24) That is, in the example shown in FIG. 5, the divided code of the feature k corresponding to the upper command Ck contains the codes of the first layer subcommand SCfk1a, the first layer subcommand SCfk1b, the second layer subcommand SCfk2a, and the second layer subcommand SCfk2b. The code of the upper command Ck, and the codes of the subcommands through which the control flows clustered as a cluster of the upper command Ck pass are assumed to be a divided code of one feature contained in the software.

(25) In this manner, by clustering control flows connecting with upper commands as starting points, it is possible to identify the range of each feature contained in software (in the example shown in FIG. 5, the feature k; k=1 to n). Note that, for convenience of explanation, the number of first layer subcommands to which the control flows from an upper command is two, and the number of second layer subcommands to which the control flows from the first layer subcommands is two in the example shown in FIG. 5, but those numbers are not limited to two. In addition, for convenience of explanation, the number of subclaim layers is two in the example shown in FIG. 5, but the number of subclaim layers is not limited to two.

(26) FIG. 6 is a diagram for explaining the processing in steps S104 and S105 of FIG. 3. As shown in FIG. 6, a divided code for each feature contains a name of a command, a name of a function corresponding to the command, a user-defined function called inside the function, a library function, and a characteristic part such as an API. However, if a subject to be inspected is a stripped binary, a name of a function cannot be used. A feature contained in the software can be estimated based on at least one of a name of a command, a name of a function corresponding to the command, a user-defined function called inside the function, a library function, an API, a system call, and an instruction that are contained in the divided code of the feature. Then, the estimated feature is labeled. In the example shown in FIG. 6, the feature of the feature k (k=1 to n) is labeled as a label_k (k=1 to n).

(27) In the estimation of a feature of the software in step S104 of FIG. 3, information about an API to be called when the divided code is executed may be taken into consideration. In addition, in the estimation of a feature of the software in step S104 of FIG. 3, information about a state of file access when the divided code is executed may be taken into consideration. With the consideration, it is possible to further improve the accuracy of estimation of a feature.

(28) From the above, since the feature estimating device 110 divides a code on the basis of upper commands whose control flows directly connecting with a parser, dividing accuracy of features is high. Here, high dividing accuracy means that all codes related to a feature are contained and that no code unrelated to the features is contained. With the feature estimating device 110, dividing accuracy of functions is high, and it is possible to estimate features contained in software from a code to be able to accurately easily inspect the code of the software for each feature.

(29) In the above example embodiments, the present invention is described as a hardware configuration, but the present invention is not limited thereto. The present invention can be achieved by a central processing unit (CPU) executing a program.

(30) The program for performing the processing of estimating a feature for each divided code can be stored by various types of non-transitory computer-readable media and provided to a computer. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as flexible disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (such as magneto-optical disks), Compact Disc Read Only Memory (CD-ROM), CD-R, CD-R/W, and semiconductor memories (such as mask ROM, Programmable ROM (PROM), Erasable PROM (EPROM), flash ROM, and Random Access Memory (RAM)). The program may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (such as electric wires, and optical fibers) or a wireless communication line.

(31) The present invention has been described above with reference to the example embodiments but is not limited by the above. Various modifications that can be understood by those skilled in the art can be made to the configurations and the details of the present invention without departing from the scope of the invention. The software to be analyzed in the above example embodiments may be executable codes or source codes. In addition, the software to be analyzed may be a single code or codes containing a library loaded from the outside.

REFERENCE SIGNS LIST

(32) 10, 110 Feature estimating device 11, 111 Parser identifying means 12, 112 Dividing means 13, 113 Feature estimating means 114 Feature labeling means