JP2013065168A - Application analyzer and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an application analyzer capable of reducing erroneous detection of a malicious application, and to provide a program.SOLUTION: An application analyzer comprises: a disassembly section 10 for disassembling an executable code of an application to be analyzed to obtain a source code corresponding to the executable code; an API extraction section 11 for extracting a first API that obtains information held in a terminal and a second API that transmits the information to an external device, from the source code; an analysis section 12 for analyzing the source code to identify a method that calls the extracted API, and for determining whether or not the identified method is invoked in response to an event not due to an operation performed by a user in a state where the application is activated; an application determination section 13 for determining whether or not the application to be analyzed is malicious on the basis of the analysis result by the analysis section 12.

Description

  The present invention relates to an application analysis apparatus that analyzes application functions. The present invention also relates to a program for causing a computer to function as the application analysis apparatus.

  Portable information terminals called smartphones that use an open platform using a general-purpose OS (operating system) have become widespread. In addition, as a general-purpose OS installed in smartphones, Android (registered trademark) OS that has abundant API (Application Program Interface) that is a set of instructions and functions for using information and functions managed by the terminal Has attracted attention. As an example, this specification describes a smartphone equipped with an Android (registered trademark) OS.

  A smartphone is a platform that allows anyone to freely develop and publish applications and allow users to freely install published applications. By introducing a published application to a smartphone, various functions of the smartphone can be expanded flexibly and easily.

  However, among applications, there is a malicious application that collects information in a terminal and transmits it to the outside so that the user does not notice it. In particular, an application that impersonates a legitimate application and performs such illegal behavior is called a Trojan horse, and it is difficult for the user to notice the threat.

  Smartphones have APIs that control phones and cameras, and applications can make calls, send SMS messages, and take photos using the APIs. If these actions are secretly performed by a malicious application, self-accounting and privacy leakage will occur.

  Smartphones are more closely connected to users than PCs (personal computers), and they collect personal information such as phone numbers, e-mail addresses, address books, e-mail transmission / reception histories, and Internet browsing histories. . In addition, because of the high functionality of the terminal and the mode of use that is always carried, it is possible to easily acquire information such as location information that was not collected by conventional PCs, and face the threat of misuse of information.

  In addition, the smartphone has a function of automatically starting the application in response to a change in the state of the terminal, in addition to a function that allows the user to explicitly operate to start the application. For example, the application can be automatically started by a change in the state of the terminal such as an incoming call, a terminal restarted, or WiFi turned on. Therefore, once a user mistakenly installs a malicious application on a terminal, information leakage may occur without the user's knowledge. Therefore, there is a need to protect users from threats where information is misused in environments where applications are readily available.

  As a technique for protecting users from threats caused by malicious applications, a mechanism for verifying application safety in advance and detecting malicious applications is effective. Dynamic analysis and static analysis methods have been proposed as methods for detecting applications that leak information.

  The dynamic analysis is a method for determining malignancy / benignity of an application by actually operating the application and analyzing a log in which the behavior of the application is recorded (see, for example, Non-Patent Document 1). As a typical analysis method, there is a method using information of an strace log. This method is a method for analyzing malignant behavior from information recorded in a log when an application uses a system function. However, with this method, when information to be transmitted to the outside is encrypted, malignant behavior cannot be detected. In addition, the application has a timer function, and it may be configured that malignant behavior occurs 10 hours after the application starts, so it is necessary to monitor for a long time. There is a problem that it is difficult to detect.

  On the other hand, the static analysis is a method of disassembling the execution code of the application to acquire the source code of the application and analyzing the malignant behavior from the source code. Non-Patent Document 2 describes a method of inspecting a smartphone application using static analysis and determining whether the analysis target application is an information leakage application. Specifically, this method analyzes whether an API for acquiring personal information is connected to an API for transmitting information to the outside. Also, whether the user's consent (consent) operation regarding the use of information is performed between the timing at which the API for acquiring personal information is executed and the timing at which the API for sending information to the outside is executed. I am considering.

Keisuke Takemori, Takamasa Sugawara, Ayumu Kubota, Tomoaki Takano, "Information leak detection on Android mobile phones", IEICE, SCIS2011 Symposium, January 2011 EGELE M., KRUEGEL C., KIRDA E., AND VIGNA G., PiOS: Detecting Privacy Leaks in iOS Applications., In Proceedings of the Network and Distributed System Security Symposium (2011)

  In the method described in Non-Patent Document 2, the user's consent operation is performed between the timing at which the API for acquiring personal information is executed and the timing at which the API for transmitting information to the outside is executed. It is a feature of benign applications. However, in this method, timings other than those described above (for example, timing immediately after activation of the application) are not considered as timing for the user to perform an operation for consent. For this reason, when a benign application configured to acquire personal information and send information to the outside is analyzed after an explicit consent operation by the user, an API for acquiring personal information is executed. If it is found that the user's consent operation is not performed between the timing at which the API for transmitting information to the outside and the timing at which the API for transmitting information is executed, there is a possibility that it is erroneously detected as a malicious application.

  The present invention has been made in view of the above-described problems, and detects erroneous detection of a malignant application that may occur in a conventional method of determining benign / malignant application in consideration of an operation performed by a user on a terminal. An object of the present invention is to provide an application analysis apparatus and a program that can be reduced.

  The present invention has been made to solve the above-described problem, and disassembles an execution code of an application to be analyzed, obtains a source code corresponding to the execution code, and acquires information in the terminal A first API (Application Program Interface) to be transmitted and a second API for transmitting information to an external device, and an extraction unit for extracting the API extracted from the source code by analyzing the source code An analysis unit that identifies a method to be executed and determines whether the identified method is executed based on an occurrence of an event that is not caused by an operation performed on a terminal by a user while the application is running; Occurrence of an event not caused by an operation performed by the user on the terminal while the application is running in the first API and the second API If it is determined to be executed on the basis of an application analyzing apparatus characterized by comprising: a determination unit and the analysis target application is malignant.

  In the application analysis apparatus of the present invention, the analysis unit analyzes the source code, specifies a method for executing the API extracted by the extraction unit, and further selects another method for executing the specified method. It is characterized in that it is determined whether or not another specified method is executed based on the occurrence of an event not caused by an operation performed by the user on the terminal while the application is running.

  Further, in the application analysis apparatus of the present invention, when an application generated from a source code in which a method name for specifying a predetermined method and a method name of the predetermined method are different from each other, the analysis is performed. The unit is characterized in that, if the specified method is the predetermined method, the other method is specified based on a method name when the predetermined method is designated.

  In the application analysis apparatus of the present invention, the analysis unit performs the specified method on the terminal in a state where the application is activated based on a manifest file that defines the function and authority used by the application. It is characterized by determining whether or not to execute based on the occurrence of an event not caused by an operation.

  Further, in the application analysis apparatus of the present invention, the analysis unit determines whether or not the specified method is executed when the user performs an operation on the terminal to start the application. To do.

  Further, in the application analysis apparatus of the present invention, the analysis unit determines whether or not the specified method is executed when an intent that is broadcast based on a state change of the terminal occurs. To do.

  In the application analysis apparatus of the present invention, the analysis unit determines whether or not the specified method is a method related to application state transition.

  In the application analysis apparatus of the present invention, the analysis unit determines whether or not the other specified method is a method related to application state transition.

  Further, the present invention is a program for causing a computer to function as the application analysis apparatus.

  According to the present invention, it is possible to detect a malignant application that automatically executes information acquisition and transmission based on the occurrence of an event that is not caused by an operation performed by a user on a terminal while the application is running. Become. For this reason, it is possible to reduce erroneous detection of a malignant application that may occur in a conventional method of determining benign / malignant of an application in consideration of an operation performed by a user on a terminal.

It is a block diagram which shows the structure of the application analysis apparatus by one Embodiment of this invention. It is a flowchart which shows the procedure of operation | movement of the application analysis apparatus by one Embodiment of this invention. It is a reference figure which shows the structure of the file obtained by disassembling the file of the application in one Embodiment of this invention. FIG. 5 is a reference diagram showing an API for acquiring personal information in an embodiment of the present invention. In one Embodiment of this invention, it is a reference figure which shows API which transmits information outside. It is a flowchart which shows the procedure of operation | movement of the application analysis apparatus by one Embodiment of this invention. It is a flowchart which shows the procedure of operation | movement of the application analysis apparatus by one Embodiment of this invention. It is a reference figure which shows the source code of the application in one Embodiment of this invention. It is a reference figure which shows the source code of the application in one Embodiment of this invention. It is a reference figure which shows the source code of the application in one Embodiment of this invention. It is a reference figure which shows the source code of the application in one Embodiment of this invention. It is a reference figure which shows the description of the manifest file in one Embodiment of this invention. It is a reference figure which shows the source code of the application in one Embodiment of this invention. It is a reference figure showing BroadcastIntent in one embodiment of the present invention. It is a reference figure which shows the description of the manifest file in one Embodiment of this invention. It is a reference figure which shows the source code of the application in one Embodiment of this invention.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. In this specification and drawings, for convenience, the character string Android (registered trademark) is substituted with the character string * Andrd * and the character string java (registered trademark) is substituted with the character string * jv * as necessary. ing. That is, the character string * Andrd * is equivalent to the character string Android (registered trademark), and the character string * jv * is equivalent to the character string java (registered trademark). Further, in this specification, when a character string such as a method name described in the source code is described, the character string may be surrounded by “to”. For example, in this specification, “XXX” indicates a character string “XXX”.

  The application analysis apparatus according to the present embodiment analyzes a source code (source file) obtained by disassembling (disassembling) an execution code of an application to be analyzed, and obtains personal information stored in the terminal (hereinafter referred to as an API). And an API for transmitting information to an external device (hereinafter referred to as an external transmission API) from the source code. In addition, the application analysis apparatus according to the present embodiment specifies a method for executing the personal information acquisition API and the external transmission API extracted from the source code, and the specified method is an operation performed on the terminal by the user (to start the application). In other words, it is determined that the analysis target application is malignant. Examples of such an event include an event that a terminal state change has occurred, an event that an operation for starting an application has been performed, and the like.

  In this embodiment, when a specific event that does not directly cause the operation performed by the user to accept (agree) the use of the information stored in the terminal occurs, the personal information acquisition API and the external transmission API are set. An automatically executed application is detected as a malicious application (information leakage application). For this reason, when analyzing an application configured to execute the personal information acquisition API and the external transmission API in accordance with the consent operation performed by the user, the analysis target application is not detected as a malignant application. Therefore, the possibility that a benign application is erroneously detected as a malignant application can be reduced.

  The application analysis apparatus according to the present embodiment is installed in a company that manages a sales site that sells, for example, smartphone applications on a communication network. The analysis algorithm performed by the application analysis apparatus according to the present embodiment can also be applied to anti-virus software. Therefore, the application that the user installs on the terminal can be examined in advance.

  FIG. 1 shows the configuration of the application analysis apparatus according to the present embodiment. As illustrated in FIG. 1, the application analysis apparatus includes an application analysis unit 1 and a storage unit 2.

  The application analysis unit 1 acquires source code by disassembly from a package file (application file) that is an execution file of the analysis target application, analyzes the acquired source code, and determines whether the analysis target application is benign / malignant. Do. A package file is a file with an extension of .apk, for example, an execution code including an instruction sequence (for example, extension .dex), a manifest file in which functions and privileges used by the application are defined (for example, extension .xml) ), Including various resource files such as text files and image files used by the application. The storage unit 2 stores a package file of an analysis target application and a list in which information such as a personal information acquisition API and an external transmission API is recorded.

  The application analysis unit 1 includes a disassembly unit 10, an API extraction unit 11, an analysis unit 12, an application determination unit 13, and a control unit 14. The disassembler 10 disassembles (disassembles) the execution code of the application to be analyzed, and obtains a source code (source file) corresponding to the execution code. The API extraction unit 11 extracts a personal information acquisition API and an external transmission API from the source code.

  The analysis unit 12 analyzes the source code, specifies a method for executing each of the personal information acquisition API and the external transmission API extracted by the API extraction unit 11, and the specified method is in a state where the application is activated. It is determined whether or not it is executed based on the occurrence of an event not caused by an operation performed on the terminal by the user. The application determination unit 13 determines benign / malignant of the analysis target application based on the result of the analysis unit 12 analyzing the source code. The control unit 14 controls the operation of each unit in the application analysis unit 1.

  Next, the concept of the application analysis method in this embodiment will be described. There are four components (components) of an application that runs on an Android (registered trademark) OS: Activity, Service, BroadcastReceiver, and ContentProvider. Hereinafter, each component will be described.

  Activity is a component that provides a visual interface to the user and interacts with the user on the screen. If the screen is displayed when the application is started, the program described in Activity is running.

  Service is a component that executes processing in the background without having a function of displaying a screen. For example, when the user activates a browser while listening to music and enjoys using the Internet, the user can listen to the music while using the Internet by activating the service for the music application.

  BroadcastReceiver is a component that receives INTENT (hereinafter referred to as “BroadcastIntent”) broadcasted to the entire system of a terminal equipped with an Android (registered trademark) OS. For example, an application that displays a screen that includes the message “Remaining battery level is low” when the battery level is low, receives the BroadcastIntent issued when the battery level changes by the BroadcastReceiver. The application starts Activity and displays the screen.

  ContentProvider is a component that makes it possible for other components to use data held by the application. For example, when an application wants to acquire phonebook data, the application acquires information registered in the phonebook using the ContentProvider of the phonebook application.

  In Android (registered trademark), there is a special method related to the life cycle (state transition) of an application. As methods related to the life cycle, there are onCreate, onStart, onBind, and the like that are called and executed when the component is activated, and onDestroy that is a method that is called and executed when the component is finished.

  The application analysis method in this embodiment is particularly suitable for detection of Trojan horses. As a technique for a malicious user to introduce an Android (registered trademark) Trojan to another person's terminal, a technique is adopted in which a legitimate application is falsified so that illegal behavior occurs and the application is released to the market. There is a feature. There are the following two methods as a simple method for falsifying a legitimate application so that an illegal behavior occurs. Trojan horses that have appeared so far often take one of two approaches.

  The first method uses a BroadcastReceiver for a legitimate application that acquires personal information and transmits information so that it can be tampered with when a terminal state change occurs. It is. This technique can be easily realized by falsifying only the manifest file without falsifying the execution code of a legitimate application.

  In the second method, in the source code of a legitimate application that acquires personal information and transmits information, an illegal behavior is found at the place where the method that is called and executed first when the application is started is described. This is a method of adding the code of the method that causes the problem. It is easy to analyze the method that is called first when the application is started, and this method can be realized by an easy method of inserting several lines of code.

  The application modified by the above two methods is executed by the personal information acquisition API and the external transmission API by a method that is automatically executed when a specific event such as the occurrence of a terminal state change or application startup occurs. It has the feature of being. Therefore, in this embodiment, an analysis method for determining an application having this feature as a malicious application is adopted.

  Next, the operation of the application analysis apparatus according to the present embodiment will be described. FIG. 2 shows the operation of the application analysis apparatus. First, the disassembly unit 10 reads and disassembles a package file of an analysis target application stored in the storage unit 2 to obtain a source code (step S100). When disassembly is performed using apk-tool, which is a typical disassembly tool, as shown in Fig. 3, the source code in the .smali format (Main $ JsObj.smali, etc.) from the package file (Sample.apk) And .xml format manifest file (* andrd * Manifest.xml) can be obtained.

  Subsequently, the API extraction unit 11 searches the source code obtained in step S100 using the method names of the personal information acquisition API and the external transmission API, and extracts the personal information acquisition API and the external transmission API (step S100). S110). FIG. 4 shows a typical personal information acquisition API. Personal methods include getDeviceId, which is a method to obtain IMEI (International Mobile Equipment Identity), which identifies the device, getDeviceSoftwareVersion, which obtains the software version of the device, and getLine1Number, which obtains the phone number of the device. Information acquisition API. FIG. 5 shows a typical external transmission API. SendTextMessage, which is a method for sending SMS (Short Message Service), is an external sending API.

  The storage unit 2 stores a list in which method names of the personal information acquisition API and the external transmission API are recorded. In step S110, the API extraction unit 11 reads this list from the storage unit 2, compares the method name character string included in the list with the character string in the source code, and matches the method name character string included in the list. Extract the character string to be used. Further, the API extraction unit 11 outputs the processing result of step S110 to the control unit 14.

  Subsequently, the control unit 14 determines whether or not both the personal information acquisition API and the external transmission API are extracted based on the processing result of Step S110 (Step S120). If at least one of the character string that matches the character string of the method name of the personal information acquisition API and the character string that matches the character string of the method name of the external transmission API is not extracted in step S110, the process proceeds to step S140. Proceed to In step S110, if both a character string that matches the method name character string of the personal information acquisition API and a character string that matches the method name character string of the external transmission API are extracted, the control unit 14 Then, the method name of the extracted personal information acquisition API and the method name of the external transmission API are given to the analysis unit 12, and the analysis unit 12 is made to analyze the source code obtained in step S100.

  The analysis unit 12 analyzes the source code and analyzes a method for executing each of the personal information acquisition API and the external transmission API extracted in step S110 (step S130). Subsequently, the application determination unit 13 determines benign / malignant of the application to be analyzed based on the analysis result by the analysis unit 12 (step S140). Detailed contents of the processing in steps S130 and S140 will be described later.

  6 and 7 show the detailed operation of the application analysis apparatus in step S130. The analysis unit 12 executes the processes shown in FIGS. 6 and 7 in correspondence with the individual APIs extracted by the API extraction unit 11. In the processing shown in FIGS. 6 and 7, all the source codes obtained in step S100 are to be analyzed. First, the analysis unit 12 specifies a method and class for executing an API (step S1300).

  FIG. 8 shows an example of the source code. The API includes ".method", "public", "private", "static", "synthetic", a line describing the method name ("onCreate" in FIG. 8), and ".end method" "Is described between the line in which" is described. In step S1300, the analysis unit 12 performs the following processing. First, the analysis unit 12 searches for an API name (method name shown in FIGS. 4 and 5) in the source code. Search for API names and method names is performed by matching character strings. The same applies to each search described later.

  When the API name is found, the analysis unit 12 searches for “.method” in a line before the line in which the API name is described in the source code, and searches for the method name from the line in which “.method” is described. ("OnCreate" in FIG. 8) is extracted. The method having the extracted method name is a method for executing the API. That is, in the example of FIG. 8, a method called onCreate executes getDeviceID that is a personal information acquisition API. Further, the analysis unit 12 searches for “.class”, which is a character string defining the class, in a line before the line in which the method name of the method for executing the API is described, and “.class” is described in the line. The class name ("com / app / sample / Main_Activity" in FIG. 8) is extracted from the line that has been processed.

  In the steps other than step S1300, when the same processing as step S1300 is performed when specifying the method and class for executing the method specified in the previous procedure, the method specified in the previous procedure is used instead of the above API name. You can do the same process using the method name and extract the method name and class name.

  Subsequent to step S1300, the analysis unit 12 determines whether or not the method specified in the previous procedure is onBind (step S1301). When the method specified in the previous procedure is onBind, the analysis unit 12 specifies the method and class for executing onBind (step S1307).

  In the source code for generating an application corresponding to the Android (registered trademark) OS, a special description is used to describe a predetermined method among methods related to the life cycle of the application. Specifically, in a portion describing that a certain method calls and executes a predetermined method, a special method name different from the method name of the predetermined method is designated. For example, onBind is called from another method with the method name BindService and executed.

  In step S1307, the analysis unit 12 performs the following processing. In the part where the method to execute onBind is described (the part between “.method” and “.end method”), both “BindService” and the class name specified with onBind in the previous step are described. Has been. Accordingly, the analysis unit 12 searches both “BindService” and the class name specified together with onBind in the previous procedure in the portion between “.method” and “.end method”. If both “BindService” and the class name specified together with onBind in the previous procedure are described in the portion between “.method” and “.end method”, the analysis unit 12 performs the same as in step S1300. Identify the method and class that executes BindService. When the process of step S1307 ends, the process of step S1308 is performed.

  If the method specified in the previous procedure is not onBind in step S1301, the analysis unit 12 determines whether the method specified in the previous procedure is onActivityResult (step S1302). When the method identified in the previous procedure is onActivityResult, the analysis unit 12 identifies the method and class for executing onActivityResult (step S1307). onActivityResult is a method related to the life cycle of the application, and is called from another method with the method name startActivityForResult and executed.

In step S1307, the analysis unit 12 performs the following processing. In the part where the method for executing onActivityResult is described (the part between “.method” and “.end method”), the following three requirements are satisfied.
First requirement: “const-class” and the class name specified in the previous procedure are described on the same line.
Second requirement: “startActivityForResult (L * andrd * / content / Intent; I) V” is described in a row below the row satisfying the first requirement.
Third requirement: “const-class” is not described in a row between a row satisfying the first requirement and a row satisfying the second requirement.

  FIG. 9 shows an example of source code in which a method for executing onActivityResult is described. If the class name specified in the previous step is com / app / sample / class, “const-class” and “com / app / sample / class” are described on the same line as shown in FIG. (First requirement). Also, “startActivityForResult (L * andrd * / content / Intent; I) V” is described in a line below this line (second requirement). Furthermore, between the line where "const-class" and "com / app / sample / class" are written, and the line where "startActivityForResult (L * andrd * / content / Intent; I) V" is written “Const-class” is not described in the line (third requirement).

  The analysis unit 12 determines whether or not the above three requirements are satisfied in a portion between “.method” and “.end method”. When the above three requirements are satisfied, the analysis unit 12 specifies a method and class for executing onActivityResult in the same manner as in step S1300. When the process of step S1307 ends, the process of step S1308 is performed.

  If the method specified in the previous procedure is not onActivityResult in step S1302, the analysis unit 12 determines whether the method specified in the previous procedure is onCreate (step S1303). onCreate is a method related to the life cycle of the application, and is called and executed from another method with a predetermined method name. Predetermined method names that other methods specify to call and execute onCreate differ depending on the component inherited by the class having onCreate as a constituent element.

  FIG. 10 shows only a part of the source code in which a component inherited by the class is described. By describing a component that a class inherits, a method that is a component of the class can use the component. As shown in FIG. 10, different declarations are described for each component in a line below the line in which “.class public Lcom / app / sample / Example”, which is a class declaration, is described. Specifically, when a class inherits Activity, it is described as “.super L * andrd * / app / Activity;”, and when a class inherits Service, it is denoted as “.super L * andrd * / app / Service. ”And“ .super L * andrd * / content / BroadcastReceiver; ”when the class inherits BroadcastReceiver.

  When the method specified in the previous procedure is onCreate, the analysis unit 12 inherits a class having onCreate as a component from the source code in which the specified onCreate is described (for example, the source code in FIG. 8). A component is specified (step S1310). More specifically, in step S1310, the analysis unit 12 specifies a component from a character string described after “.super” in the source code in which onCreate and the class name specified in the previous procedure are described. .

  Subsequently, the process branches according to the component specified in step S1310 (step S1311). When the component specified in step S1310 is Service, the analysis unit 12 specifies a method and class for executing onCreate (step S1307). When a class that has onCreate as a component inherits Service, onCreate is called and executed by another method with the method name startService.

In step S1307, the analysis unit 12 performs the following processing. In the part where the method for executing onCreate is described (the part between “.method” and “.end method”), the following three requirements are satisfied.
First requirement: “const-class” and the class name specified in the previous procedure are described on the same line.
Second requirement: “startService (L * andrd * / content / Intent;) L * andrd * / content / ComponentName” is described in a line below the line that satisfies the first requirement.
Third requirement: “const-class” is not described in a row between a row satisfying the first requirement and a row satisfying the second requirement.

  FIG. 11 shows an example of source code in which a method for executing onCreate is described. If the class name specified in the previous step is com / app / sample / class, “const-class” and “com / app / sample / class” are described on the same line as shown in FIG. (First requirement). Further, “startService (L * andrd * / content / Intent;) L * andrd * / content / ComponentName” is described in a line below this line (second requirement). In addition, a line describing "const-class" and "com / app / sample / class" and "startService (L * andrd * / content / Intent;) L * andrd * / content / ComponentName" are described. "Const-class" is not described in a line between the current line (third requirement).

  The analysis unit 12 determines whether or not the above three requirements are satisfied in a portion between “.method” and “.end method”. When the above three requirements are satisfied, the analysis unit 12 specifies the method and class for executing onCreate in the same manner as in step S1300. When the process of step S1307 ends, the process of step S1308 is performed.

  On the other hand, if the component identified in step S1310 is Activity, the analysis unit 12 checks whether or not onCreate is called from the launcher and executed, so a manifest file (* andrd * Manifest.xml) Is analyzed (step S1312). As described above, the manifest file is a file that defines functions and privileges used by the application. The launcher is a part of a program that is executed first when the user clicks an icon displayed on the standby screen of the smartphone in order to start an application. When onCreate is called from the launcher and executed, when an event occurs in which the user clicks an icon on the standby screen, onCreate is automatically executed and information leakage may occur.

  FIG. 12 shows an example of the description of the manifest file. As shown in FIG. 12, the class name “com.app.sample.Example_Activity” is described in the tag starting with “<activity”. In addition, there are tags <intent-filter> and </ intent-filter> between the tag that begins with <activity and the tag </ activity> that is paired with it. . Also, there is a description about the launcher "<category * andrd *: name =" * andrd * .intent.category.LAUNCHER "/>" between "<intent-filter>" and "</ intent-filter>" .

  In step S1312, the analysis unit 12 performs the following processing. The analysis unit 12 extracts a description portion starting with “<activity” and ending with “</ activity>” in the manifest file. Subsequently, the analysis unit 12 determines whether or not the class name specified in the previous procedure is described in the same line as “<activity” in the extracted portion. When the class name specified in the previous step is described in the same line as “<activity”, the analysis unit 12 adds “<intent-filter>” and “</ intent-filter>” to the extracted part. Whether or not is described is determined. When “<intent-filter>” and “</ intent-filter>” are described in the extracted part, the analysis unit 12 determines between “<intent-filter>” and “</ intent-filter>”. It is determined whether or not “<category * andrd *: name =" * andrd * .intent.category.LAUNCHER "/>" is described.

  Subsequent to step S1312, the analysis unit 12 determines whether or not a launcher is registered in the manifest file (step S1313). As a result of analyzing the manifest file in step S1312, "<category * andrd *: name =" * andrd * .intent.category.LAUNCHER "is inserted between" <intent-filter> "and" </ intent-filter> ". When “/>” is described, the launcher is registered in the manifest file. In this case, when the user clicks an icon displayed on the standby screen of the smartphone, onCreate is called and executed, so the personal information acquisition API or external transmission API is automatically executed. In this case, the analysis unit 12 uses the API method name extracted by the API extraction unit 11 in step S110, information indicating that the API is automatically executed, and the method name (onCreate) of the method that executes the API. Are output to the application determination unit 13.

  Also, as a result of analyzing the manifest file in step S1312, if the launcher is not registered in the manifest file, the analysis unit 12 identifies a method and class for executing onCreate (step S1307). . When a class having onCreate as a component inherits Activity, onCreate is called and executed by another method with the method name startActivity.

In step S1307, the analysis unit 12 performs the following processing. In the part where the method for executing onCreate is described (the part between “.method” and “.end method”), the following three requirements are satisfied.
First requirement: “const-class” and the class name specified in the previous procedure are described on the same line.
Second requirement: “startActivity (L * andrd * / content / Intent;) V” is described in a row below the row satisfying the first requirement.
Third requirement: “const-class” is not described in a row between a row satisfying the first requirement and a row satisfying the second requirement.

  FIG. 13 shows an example of source code in which a method for executing onCreate is described. If the class name specified in the previous step is com / app / sample / class, “const-class” and “com / app / sample / class” are described on the same line as shown in FIG. (First requirement). Further, “startActivity (L * andrd * / content / Intent;) V” is described in a line below this line (second requirement). Furthermore, between the line where "const-class" and "com / app / sample / class" are described, and the line where "startActivity (L * andrd * / content / Intent;) V" is described “Const-class” is not described in the line (third requirement).

  The analysis unit 12 determines whether or not the above three requirements are satisfied in a portion between “.method” and “.end method”. When the above three requirements are satisfied, the analysis unit 12 specifies the method and class for executing onCreate in the same manner as in step S1300. When the process of step S1307 ends, the process of step S1308 is performed.

  On the other hand, when the component specified in step S1310 is BroadcastReceiver, the analysis unit 12 checks whether or not onCreate is called and executed by BroadcastIntent, and thus a manifest file (* andrd * Manifest.xml). Is analyzed (step S1314). There are two methods for executing a method by BroadcastIntent: a method for executing a method by BroadcastIntent provided by the OS standard, and a method for executing a method by BroadcastIntent created by a user. When onCreate is executed by BroadcastIntent provided by OS standard, onCreate is automatically executed when the event that BroadcastIntent is issued due to the state change of the terminal regardless of whether the application is activated or not. Information leakage may occur.

  FIG. 14 shows an example of a BroadcastIntent (hereinafter referred to as OS standard BroadcastIntent) prepared as a standard in the OS. There are BOOT_COMPLETED issued when the terminal starts, ACTION_BATTERY_CHANGED issued when the remaining battery level changes.

  FIG. 15 shows an example of the description of the manifest file. As shown in FIG. 15, the class name “jp.kddilabs.helloservice.BCreceiver” is described in the tag starting with “<receiver”. In addition, there are tags <intent-filter> and </ intent-filter> between the tag that starts with "<receiver" and the paired tag "</ receiver>" . In addition, the description "<action * andrd *: name =" * andrd * .intent.action.BOOT_COMPLETED "/>" that includes the BroadcastIntent name between "<intent-filter>" and "</ intent-filter>" There is.

  In step S1314, the analysis unit 12 performs the following processing. The storage unit 2 stores a list in which the name of the OS standard BroadcastIntent is recorded. The analysis unit 12 extracts a description part starting with “<receiver” and ending with “</ receiver>” in the manifest file. Subsequently, the analysis unit 12 determines whether or not the class name specified in the previous procedure is described in the same line as “<receiver” in the extracted portion. When the class name specified in the previous step is described in the same line as “<receiver”, the analysis unit 12 adds “<intent-filter>” and “</ intent-filter>” to the extracted part. Whether or not is described is determined. When “<intent-filter>” and “</ intent-filter>” are described in the extracted part, the analysis unit 12 reads the above list from the storage unit 2 and reads “<intent-filter>” as It is determined whether or not a BroadcastIntent name included in the list is described between “</ intent-filter>”.

  Subsequent to step S1314, the analysis unit 12 determines whether or not the OS standard BroadcastIntent is registered in the manifest file (step S1315). As a result of analyzing the manifest file in step S1314, if the BroadcastIntent name included in the list is described between “<intent-filter>” and “</ intent-filter>”, the OS file is included in the manifest file. BroadcastIntent is registered. In this case, when a predetermined state change occurs in the terminal, since onCreate is called and executed, the personal information acquisition API or the external transmission API is automatically executed. In this case, the analysis unit 12 uses the API method name extracted by the API extraction unit 11 in step S110, information indicating that the API is automatically executed, and the method name (onCreate) of the method that executes the API. Are output to the application determination unit 13.

  Further, as a result of analyzing the manifest file in step S1314, if it is not confirmed that the OS standard BroadcastIntent is registered in the manifest file, the analyzing unit 12 specifies a method and a class for executing onCreate ( Step S1307). When a class having onCreate as a constituent element inherits BroadcastReceiver, onCreate is executed by the BroadcastIntent created by the user. When onCreate is executed by BroadcastIntent created by the user, the event that is the starting point of API execution is unknown, so further analysis is required.

  FIG. 16 shows an example of source code in which a method for executing onCreate is described by BroadcastIntent created by the user. When the name of BroadcastIntent defined by the user is ORIGINAL_BROADCAST, as shown in FIG. 16, in the part where the method for executing onCreate is described (the part between “.method” and “.end method”) In addition, “ORIGINAL_BROADCAST” which is a method name defined by the user and “sendBroadcast” which is a method for issuing a BroadcastIntent are described.

  In step S1307, the analysis unit 12 performs the following processing. The storage unit 2 stores a list in which the name of BroadcastIntent prepared by the OS standard is recorded. In the manifest file, the analysis unit 12 determines the BroadcastIntent name not included in the above list from the portion between “<intent-filter>” and “</ intent-filter>” of the portion analyzed in step S1314. To extract.

  Subsequently, the analysis unit 12 determines whether or not the extracted BroadcastIntent name and “sendBroadcast” are described in a portion between “.method” and “.end method” in the source code. When the extracted BroadcastIntent name and “sendBroadcast” are described in the portion between “.method” and “.end method”, the analysis unit 12 selects the method and class for executing onCreate in the same manner as in step S1300. Identify. When the process of step S1307 ends, the process of step S1308 is performed.

  On the other hand, if the method identified in the previous procedure is not onCreate in step S1303, the analysis unit 12 determines that the method identified in the previous procedure is any of onStart, onRestart, onResume, onPause, onStop, onDestroy, onUnbind, onRebind. It is determined whether or not (step S1304). These methods are related to the life cycle of the application.

  If the method identified in the previous step is one of onStart, onRestart, onResume, onPause, onStop, onDestroy, onUnbind, or onRebind, these methods are called when an event of a state change related to the application lifecycle occurs. Therefore, the personal information acquisition API or external transmission API is automatically executed. In this case, the analysis unit 12 uses the API method name extracted by the API extraction unit 11 in step S110, information indicating that the API is automatically executed, and the method name (onStart etc.) of the method executing the API. Are output to the application determination unit 13.

  If the method identified in the previous procedure is not one of onStart, onRestart, onResume, onPause, onStop, onDestroy, onUnbind, or onRebind, the analysis unit 12 determines whether the method identified in the previous procedure is onClick. Is determined (step S1305). onClick is a method that is called and executed when the user presses a button displayed on the screen of the user interface on the terminal. If the method identified in the previous step is onClick, the API is executed when the event that the user presses the button occurs. In this case, the analysis unit 12 outputs an analysis result including the method name of the API extracted by the API extraction unit 11 in step S110 and information indicating that the API is not automatically executed to the application determination unit 13.

  If the method specified in the previous procedure is not onClick, the analysis unit 12 determines whether the method specified in the previous procedure is onItemClick (step S1306). onItemClick is a method that is called and executed when the user selects a list item displayed on the screen on the terminal. If the method identified in the previous step is onItemClick, the API is executed when an event occurs in which the user selects an item in the list. In this case, the analysis unit 12 outputs an analysis result including the method name of the API extracted by the API extraction unit 11 in step S110 and information indicating that the API is not automatically executed to the application determination unit 13.

  If the method specified in the previous procedure is not onItemClick, the analysis unit 12 specifies the method and class for executing the method specified in the previous procedure in the same manner as in step S1300 (step S1307). Subsequently, the analysis unit 12 determines whether there is a method for executing the method specified in the previous procedure (step S1308).

  In step S1307, if the method and class for executing the method specified in the previous procedure cannot be specified, the API is not called and executed, so the analysis unit 12 performs the analysis by the API extraction unit 11 in step S110. An analysis result including the extracted API method name and information indicating that the API is not automatically executed is output to the application determination unit 13. If the method and class for executing the method specified in the previous procedure can be specified in step S1307, the process proceeds to step S1301. By analyzing according to the procedure shown in FIG. 6 and FIG. 7, it is determined whether or not the API is automatically executed without causing an operation performed by the user on the terminal while the application is running. Can do.

  Next, the benign / malignant determination method of the application in step S140 will be described. As described above, the analysis unit 12 outputs the analysis result to the application determination unit 13. Since the analysis unit 12 performs analysis for each API extracted by the API extraction unit 11 in step S110, the analysis result for each API is output to the application determination unit 13.

  In step S110, when at least one of the personal information acquisition API and the external transmission API is not extracted, the application determination unit 13 determines that the analysis target application is benign. When the analysis in step S130 is performed and the analysis result is output from the analysis unit 12, the application determination unit 13 determines whether the application is benign / malignant based on the analysis result as follows.

  When an analysis result including information indicating that the API is not automatically executed is output for at least one of the personal information acquisition API and the external transmission API, at least one of the personal information acquisition API and the external transmission API is It can be estimated that the risk of information leakage is low because it is not executed or at least one of the personal information acquisition API and the external transmission API is executed by a user operation after starting the application. In this case, the application determination unit 13 determines that the application to be analyzed is benign.

  When an analysis result including information indicating that the API is automatically executed is output for both the personal information acquisition API and the external transmission API, the application determination unit 13 executes a method for executing the personal information acquisition API. Confirm whether the method name of and the method name of the method that executes the external transmission API match. If they do not match, the personal information acquisition API and the external transmission API are automatically executed, but the methods that are the starting points of the execution are different and the relevance of both executions is low, so there is a risk of information leakage It can be estimated that the degree is low. In this case, the application determination unit 13 determines that the application to be analyzed is benign.

  On the other hand, if the two match, the personal information acquisition API and the external transmission API are automatically executed starting from the same method, so it can be estimated that the risk of information leakage is high. In this case, the application determination unit 13 determines that the analysis target application is malignant. In other words, when the personal information acquisition API and external transmission API are automatically executed by the same method, the analysis target application is determined to be malignant, and in other cases, the analysis target application is benign. Determined.

  As described above, according to the present embodiment, a malicious application that automatically executes information acquisition and transmission based on the occurrence of an event that is not caused by an operation performed by the user on the terminal while the application is running. Can be detected. For this reason, it becomes possible to distinguish an application that performs acquisition and transmission of information based on the occurrence of an event caused by an operation performed on the terminal in order for the user to consent to use of information from a malignant application. False detection of malicious applications can be reduced.

  Also, in the analysis of the source code, even if the method that executes the API is specified, the event that is the starting point of the API execution cannot be determined only from the method name (such as onBind) of the specified method. By specifying another method that executes a method that executes, the possibility of determining the event that is the starting point of API execution increases. For this reason, omission of detection of a malicious application can be reduced.

  In addition, for a given method such as onBind, the method name when another method specifies a given method is different from the method name of the given method, but it is possible that the method name may be different. Thus, by specifying other methods for executing the API, the possibility of determining the event that is the starting point for executing the API increases. For this reason, omission of detection of a malicious application can be reduced.

  In addition, regarding onCreate, onCreate is called from the launcher that is executed first when the icon displayed on the standby screen of the smartphone is clicked based on the manifest file, Whether or not the API is automatically executed can be confirmed by checking whether or not it is called and executed by the OS standard BroadcastIntent based on the state change.

  Further, by determining whether or not the specified method is a predetermined method (such as onStart) related to the state transition of the application, it can be confirmed whether or not the API is automatically executed.

  The application analysis apparatus described above is realized by recording a program for realizing the operation and function in a computer-readable recording medium, causing the computer to read and execute the program recorded in the recording medium. The Here, the “computer” includes a homepage providing environment (or display environment) if the WWW system is used. The “computer-readable recording medium” refers to a storage device such as a portable medium such as a flexible disk, a magneto-optical disk, a ROM, and a CD-ROM, and a hard disk built in the computer. Further, the “computer-readable recording medium” refers to a volatile memory (RAM) in a computer system that becomes a server or a client when a program is transmitted via a network such as the Internet or a communication line such as a telephone line. In addition, those holding programs for a certain period of time are also included.

  The program described above may be transmitted from a computer storing the program in a storage device or the like to another computer via a transmission medium or by a transmission wave in the transmission medium. Here, the “transmission medium” for transmitting a program refers to a medium having a function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. Further, the above-described program may be for realizing a part of the above-described function. Furthermore, what can implement | achieve the function mentioned above in combination with the program already recorded on the computer, what is called a difference file (difference program) may be sufficient.

  As described above, the embodiments of the present invention have been described in detail with reference to the drawings. However, the specific configuration is not limited to the above-described embodiments, and includes design changes and the like without departing from the gist of the present invention. .

  DESCRIPTION OF SYMBOLS 1 ... Application analysis part, 2 ... Memory | storage part, 10 ... Disassemble part, 11 ... API extraction part, 12 ... Analysis part, 13 ... Application determination part, 14 ... Control unit

Claims (9)

A disassemble unit that disassembles the execution code of the application to be analyzed and obtains a source code corresponding to the execution code;
An extraction unit for extracting, from the source code, a first API (Application Program Interface) for acquiring information in the terminal and a second API for transmitting information to an external device;
Analyze the source code, identify the method that executes the API extracted by the extraction unit, and the identified method will generate an event that does not result from an operation that the user performs on the terminal while the application is running An analysis unit for determining whether to be executed based on,
When it is determined that the first API and the second API are executed based on the occurrence of an event not caused by an operation performed by the user on the terminal while the application is running, the analysis target A determination unit that determines that the application is malicious;
An application analysis apparatus characterized by comprising:   The analysis unit analyzes the source code, identifies a method for executing the API extracted by the extraction unit, further identifies another method for executing the identified method, and the identified other method is: The application analysis apparatus according to claim 1, wherein the application analysis apparatus determines whether or not the process is executed based on an occurrence of an event not caused by an operation performed on the terminal by the user while the application is activated.   When an application generated from a source code in which a method name for specifying a predetermined method and a method name of the predetermined method are different from each other is an analysis target, the analysis unit determines that the specified method is the predetermined method. 3. The application analysis apparatus according to claim 2, wherein if the method is a method, the other method is specified based on a method name when the predetermined method is designated.   The analysis unit is based on the occurrence of an event that is not caused by an operation performed on the terminal by the user while the application is activated based on a manifest file that defines functions and privileges used by the application. It is determined whether it is performed, The application analysis apparatus as described in any one of Claims 1-3 characterized by the above-mentioned.   The application analysis apparatus according to claim 4, wherein the analysis unit determines whether or not the specified method is executed when a user performs an operation on the terminal to activate the application. .   5. The application analysis apparatus according to claim 4, wherein the analysis unit determines whether or not the specified method is executed when an intent to be broadcast is generated based on a state change of the terminal. .   The application analysis apparatus according to claim 1, wherein the analysis unit determines whether the identified method is a method related to an application state transition.   The application analysis apparatus according to claim 2, wherein the analysis unit determines whether the specified other method is a method related to application state transition.   A program for causing a computer to function as the application analysis apparatus according to claim 1.

Images