アプリケーション解析装置およびプログラム
【課題】悪性アプリケーションの誤検知を低減することができるアプリケーション解析装置およびプログラムを提供する。
【解決手段】ディスアセンブル部１０は、解析対象のアプリケーションの実行コードをディスアセンブルし、実行コードに対応するソースコードを得る。API抽出部１１は、端末内の情報を取得する第１のAPIおよび情報を外部の機器へ送信する第２のAPIをソースコードから抽出する。解析部１２は、ソースコードを解析し、抽出されたAPIを実行するメソッドを特定し、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定する。アプリケーション判定部１３は、解析部１２による解析の結果に基づいて、解析対象のアプリケーションの良性／悪性の判定を行う。
【解決手段】ディスアセンブル部１０は、解析対象のアプリケーションの実行コードをディスアセンブルし、実行コードに対応するソースコードを得る。API抽出部１１は、端末内の情報を取得する第１のAPIおよび情報を外部の機器へ送信する第２のAPIをソースコードから抽出する。解析部１２は、ソースコードを解析し、抽出されたAPIを実行するメソッドを特定し、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定する。アプリケーション判定部１３は、解析部１２による解析の結果に基づいて、解析対象のアプリケーションの良性／悪性の判定を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションの機能を解析するアプリケーション解析装置に関する。また、本発明は、本アプリケーション解析装置としてコンピュータを機能させるためのプログラムにも関する。
【背景技術】
【０００２】
汎用OS（オペレーティングシステム）を用いたオープンプラットフォームを採用する、スマートフォンと呼ばれる携帯情報端末が普及している。また、スマートフォンに搭載される汎用OSとして、端末で管理される情報や機能を利用するための命令や関数の集合であるAPI（Application Program Interface） が豊富に用意されているAndroid（登録商標） OS が注目を集めている。本明細書では一例として、Android（登録商標） OSを搭載したスマートフォンについて記載する。
【０００３】
スマートフォンは、誰もが自由にアプリケーションを開発して公開でき、公開されたアプリケーションをユーザが自由にインストールできるプラットフォームである。公開されたアプリケーションをスマートフォンに導入することにより、スマートフォンの様々な機能を柔軟かつ容易に拡張することができる。
【０００４】
しかし、アプリケーションの中には、ユーザに気付かれないように、端末内の情報を収集して外部に送信する悪性アプリケーションが存在する。特に、正規のアプリケーションを装いつつ、こうした不正な振る舞いを行うアプリケーションはトロイの木馬と呼ばれており、ユーザがその脅威に気付くことは困難である。
【０００５】
スマートフォンには、電話やカメラを制御するAPIが設けられており、アプリケーションがAPIを利用して発呼や、SMS通信、写真撮影を行うことができる。これらの行為を悪意のアプリケーションが密かに行った場合、勝手な課金やプライバシの漏洩が発生する。
【０００６】
また、スマートフォンは、ユーザとの結びつきがPC（パーソナルコンピュータ）よりも緊密な機器であり、電話番号、メールアドレス、住所録、メールの送受信履歴、インターネットの閲覧履歴等の個人情報が集積している。また、端末の高機能化と、常に携帯される利用形態とから、従来のPCでは収集されなかった位置情報等の情報も容易に取得可能となり、情報が悪用される脅威に直面する。
【０００７】
また、スマートフォンでは、ユーザが明示的に操作を行ってアプリケーションを起動できる機能以外にも、端末の状態の変化に応じてアプリケーションが自動的に起動する機能がある。例えば、電話の着信があった、端末が再起動した、WiFiがオンになった等の端末の状態の変化によってアプリケーションを自動的に起動させることができる。よって、ユーザが誤って悪性アプリケーションを一旦端末にインストールしてしまうと、ユーザの知らないうちに情報漏洩が発生する可能性がある。したがって、アプリケーションを容易に入手可能な環境において情報が悪用される脅威からユーザを保護する必要がある。
【０００８】
ユーザを悪性アプリケーションによる脅威から保護する手法として、アプリケーションの安全性を事前に検証し、悪性アプリケーションを検知する仕組みが有効である。情報漏洩を行うアプリケーションを検知する手法として、動的解析および静的解析の手法が提案されている。
【０００９】
動的解析とは、実際にアプリケーションを動作させ、アプリケーションの振る舞いが記録されたログを解析することで、アプリケーションの悪性／良性判定を行う手法である（例えば、非特許文献１参照）。代表的な解析方法として、straceログの情報を用いた手法がある。この手法は、アプリケーションがシステムの機能を利用した際にログに記録された情報から悪性の挙動を解析する手法である。しかしながら、この手法では、外部に送信する情報が暗号化されていた場合、悪性の挙動を検知することができない。また、アプリケーションがタイマー機能を持ち、アプリケーションが起動してから10時間後に悪性の挙動が発生するなどの設定が行われていることもあり、長時間の監視が必要になるなど、悪性の挙動を検知することが難しくなるといった課題がある。
【００１０】
一方、静的解析とは、アプリケーションの実行コードのディスアセンブルを行ってアプリケーションのソースコードを取得し、そのソースコードから悪性の挙動を解析する手法である。非特許文献２には、静的解析を用いてスマートフォン用のアプリケーションを検査し、解析対象のアプリケーションが情報漏洩アプリケーションか否かを判定する手法が記載されている。この手法では、具体的には、個人情報を取得するAPIと、外部に情報を送信するAPIとが繋がるかどうかを解析している。また、個人情報を取得するAPIが実行されるタイミングと、外部に情報を送信するAPIが実行されるタイミングとの間で、情報の利用に関するユーザの承諾（同意）の操作が行われるかどうかを考慮している。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】竹森敬祐、磯原隆将、窪田歩、高野智秋、「Android携帯電話上での情報漏洩検知」、電子情報通信学会、SCIS2011シンポジウム、2011年1月
【非特許文献２】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)
【発明の概要】
【発明が解決しようとする課題】
【００１２】
非特許文献２に記載された手法では、個人情報を取得するAPIが実行されるタイミングと、外部に情報を送信するAPIが実行されるタイミングとの間でユーザの承諾の操作が行われることを良性アプリケーションの特徴としている。しかし、この手法では、ユーザが承諾のための操作を行うタイミングとして上記以外のタイミング（例えばアプリケーションの起動直後のタイミング）は考慮されていない。このため、ユーザによる明示的な承諾の操作が行われてから個人情報の取得および外部への情報送信を行うように構成された良性アプリケーションを解析した場合に、個人情報を取得するAPIが実行されるタイミングと、外部に情報を送信するAPIが実行されるタイミングとの間でユーザの承諾の操作が行われないことが分かると、悪性アプリケーションとして誤検知する可能性があった。
【００１３】
本発明は、上述した課題に鑑みてなされたものであって、ユーザが端末に対して行う操作を考慮してアプリケーションの良性／悪性を判定する従来の手法で発生しうる悪性アプリケーションの誤検知を低減することができるアプリケーション解析装置およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明は、上記の課題を解決するためになされたもので、解析対象のアプリケーションの実行コードをディスアセンブルし、前記実行コードに対応するソースコードを得るディスアセンブル部と、端末内の情報を取得する第１のAPI（Application Program Interface）および情報を外部の機器へ送信する第２のAPIを前記ソースコードから抽出する抽出部と、前記ソースコードを解析し、前記抽出部によって抽出されたAPIを実行するメソッドを特定し、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定する解析部と、前記第１のAPIおよび前記第２のAPIが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されると判定された場合に、前記解析対象のアプリケーションが悪性であると判定する判定部と、を備えたことを特徴とするアプリケーション解析装置である。
【００１５】
また、本発明のアプリケーション解析装置において、前記解析部は、前記ソースコードを解析し、前記抽出部によって抽出されたAPIを実行するメソッドを特定し、さらに、特定したメソッドを実行する他のメソッドを特定し、特定した他のメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定することを特徴とする。
【００１６】
また、本発明のアプリケーション解析装置において、メソッドが所定のメソッドを指定するときのメソッド名と前記所定のメソッドのメソッド名とが異なるソースコードから生成されたアプリケーションが解析対象である場合に、前記解析部は、特定したメソッドが前記所定のメソッドであれば、前記所定のメソッドを指定するときのメソッド名に基づいて前記他のメソッドを特定することを特徴とする。
【００１７】
また、本発明のアプリケーション解析装置において、前記解析部は、アプリケーションが利用する機能や権限を規定したマニフェストファイルに基づいて、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定することを特徴とする。
【００１８】
また、本発明のアプリケーション解析装置において、前記解析部は、特定したメソッドが、アプリケーションを起動するためにユーザが端末上で操作を行ったときに実行されるか否かを判定することを特徴とする。
【００１９】
また、本発明のアプリケーション解析装置において、前記解析部は、特定したメソッドが、端末の状態変化に基づいてブロードキャストされるインテントが発生したときに実行されるか否かを判定することを特徴とする。
【００２０】
また、本発明のアプリケーション解析装置において、前記解析部は、特定したメソッドが、アプリケーションの状態遷移に関係するメソッドであるか否かを判定することを特徴とする。
【００２１】
また、本発明のアプリケーション解析装置において、前記解析部は、特定した他のメソッドが、アプリケーションの状態遷移に関係するメソッドであるか否かを判定することを特徴とする。
【００２２】
また、本発明は、上記のアプリケーション解析装置としてコンピュータを機能させるためのプログラムである。
【発明の効果】
【００２３】
本発明によれば、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて情報の取得と送信を自動的に実行する悪性アプリケーションを検知することが可能となる。このため、ユーザが端末上で行う操作を考慮してアプリケーションの良性／悪性を判定する従来の手法で発生しうる悪性アプリケーションの誤検知を低減することができる。
【図面の簡単な説明】
【００２４】
【図１】本発明の一実施形態によるアプリケーション解析装置の構成を示すブロック図である。
【図２】本発明の一実施形態によるアプリケーション解析装置の動作の手順を示すフローチャートである。
【図３】本発明の一実施形態におけるアプリケーションのファイルをディスアセンブルして得られるファイルの構造を示す参考図である。
【図４】本発明の一実施形態において、個人情報を取得するAPIを示す参考図である。
【図５】本発明の一実施形態において、外部に情報を送信するAPIを示す参考図である。
【図６】本発明の一実施形態によるアプリケーション解析装置の動作の手順を示すフローチャートである。
【図７】本発明の一実施形態によるアプリケーション解析装置の動作の手順を示すフローチャートである。
【図８】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図９】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図１０】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図１１】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図１２】本発明の一実施形態におけるマニフェストファイルの記述を示す参考図である。
【図１３】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図１４】本発明の一実施形態におけるBroadcastIntentを示す参考図である。
【図１５】本発明の一実施形態におけるマニフェストファイルの記述を示す参考図である。
【図１６】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【発明を実施するための形態】
【００２５】
以下、図面を参照し、本発明の実施形態を説明する。本明細書および図面では、便宜上、必要に応じてAndroid（登録商標）という文字列を*Andrd*という文字列で代用し、java（登録商標）という文字列を*jv*という文字列で代用している。すなわち、*Andrd*という文字列はAndroid（登録商標）という文字列と等価であり、*jv*という文字列はjava（登録商標）という文字列と等価である。また、本明細書では、ソースコードに記述されるメソッド名等の文字列を記載するときに、「と」で文字列を囲んで示すことがある。例えば、本明細書では、「XXX」はXXXという文字列を示すものとする。
【００２６】
本実施形態によるアプリケーション解析装置は、解析対象のアプリケーションの実行コードをディスアセンブル（逆アセンブル）して得られるソースコード（ソースファイル）を解析し、端末に格納された個人情報を取得するAPI（以下、個人情報取得APIと記載）と、情報を外部の機器へ送信するAPI（以下、外部送信APIと記載）とをソースコードから抽出する。また、本実施形態によるアプリケーション解析装置は、ソースコードから抽出した個人情報取得APIと外部送信APIを実行するメソッドを特定し、特定したメソッドが、ユーザが端末上で行う操作（アプリケーションを起動するための操作を除く）に起因しないイベントの発生に基づいて実行される場合に、解析対象のアプリケーションが悪性であると判定する。このようなイベントとして、端末の状態変化が発生したというイベントや、アプリケーションを起動する操作が行われたというイベント等がある。
【００２７】
本実施形態では、端末に格納された情報の利用を承諾（同意）するためにユーザが行う操作を直接的な発生原因としない特定のイベントが発生したときに個人情報取得APIと外部送信APIを自動的に実行するアプリケーションが悪性アプリケーション（情報漏洩アプリケーション）として検知される。このため、ユーザが行う承諾の操作に伴って個人情報取得APIと外部送信APIを実行するように構成されたアプリケーションを解析した場合には、解析対象のアプリケーションは悪性アプリケーションとして検知されない。したがって、良性アプリケーションを悪性アプリケーションとして誤検知する可能性を低減することができる。
【００２８】
本実施形態によるアプリケーション解析装置は、例えばスマートフォン用のアプリケーションを通信ネットワーク上で販売する販売サイトを管理する企業に設置される。また、本実施形態によるアプリケーション解析装置が行う解析のアルゴリズムをアンチウイルスソフトに適用することも可能である。したがって、ユーザが端末にインストールするアプリケーションを事前に審査することができる。
【００２９】
図１は、本実施形態によるアプリケーション解析装置の構成を示している。図１に示すように、アプリケーション解析装置は、アプリケーション解析部１および記憶部２を有する。
【００３０】
アプリケーション解析部１は、解析対象のアプリケーションの実行ファイルであるパッケージファイル（アプリケーションファイル）からディスアセンブルによりソースコードを取得し、取得したソースコードを解析して解析対象のアプリケーションの良性／悪性の判定を行う。パッケージファイルは、例えば拡張子が.apkのファイルであり、命令列を含む実行コード（例えば拡張子が.dex）、アプリケーションが利用する機能や権限が定義されたマニフェストファイル（例えば拡張子が.xml）、アプリケーションが利用するテキストファイルや画像ファイル等の各種リソースファイルを含む。記憶部２は、解析対象のアプリケーションのパッケージファイルを記憶するほか、個人情報取得APIおよび外部送信API等の情報が記録されたリストを記憶する。
【００３１】
アプリケーション解析部１は、ディスアセンブル部１０、API抽出部１１、解析部１２、アプリケーション判定部１３、および制御部１４を有する。ディスアセンブル部１０は、解析対象のアプリケーションの実行コードをディスアセンブル（逆アセンブル）し、実行コードに対応するソースコード（ソースファイル）を得る。API抽出部１１は、ソースコードから個人情報取得APIと外部送信APIを抽出する。
【００３２】
解析部１２は、ソースコードを解析し、API抽出部１１によって抽出された個人情報取得APIと外部送信API のそれぞれを実行するメソッドを特定し、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定する。アプリケーション判定部１３は、解析部１２がソースコードを解析した結果に基づいて、解析対象のアプリケーションの良性／悪性を判定する。制御部１４は、アプリケーション解析部１における各部の動作を制御する。
【００３３】
次に、本実施形態におけるアプリケーションの解析手法の概念を説明する。Android（登録商標）OS上で動作するアプリケーションの構成要素（コンポーネント）として、Activity、Service、BroadcastReceiver、ContentProviderの4つがある。以下、各コンポーネントについて説明する。
【００３４】
Activityは、ユーザに対して視覚的なインターフェイスを提供し、画面上でユーザと対話を行うコンポーネントである。アプリケーションを起動すると画面が表示される場合、Activityに記述されたプログラムが動作している。
【００３５】
Serviceは、画面を表示する機能を持たずに、バックグラウンドで処理を実行するコンポーネントである。例えば、ユーザが音楽を聞きながらブラウザを起動してインターネットの利用を楽しむ場合、音楽用アプリケーションがServiceを起動することにより、ユーザはインターネットの利用中に音楽を聞くことができる。
【００３６】
BroadcastReceiverは、Android（登録商標）OSが搭載された端末のシステム全体にブロードキャストされるINTENT（以下、BroadcastIntentと記載）を受け取るコンポーネントである。例えば、電池残量が減ってきたときに、「残りのバッテリー残量が少ないです」というメッセージを含む画面を表示するアプリケーションでは、電池残量が変化するときに発行されるBroadcastIntentをBroadcastReceiverにより受け取ったアプリケーションがActivityを起動して画面を表示する。
【００３７】
ContentProviderは、アプリケーションが保持するデータを他のコンポーネントでも使用可能にするコンポーネントである。例えば、あるアプリケーションが電話帳のデータを取得したい場合、そのアプリケーションは、電話帳アプリケーションのContentProviderを利用して、電話帳に登録されている情報を取得する。
【００３８】
Android（登録商標）では、アプリケーションのライフサイクル（状態遷移）に関する特別なメソッドがある。ライフサイクルに関するメソッドとして、コンポーネントが起動したタイミングで呼び出されて実行されるメソッドであるonCreate、onStart、onBind等のほか、コンポーネントが終了するタイミングで呼び出されて実行されるメソッドであるonDestroy等がある。
【００３９】
本実施形態におけるアプリケーションの解析手法は、特にトロイの木馬の検知に適している。悪意のユーザがAndroid（登録商標）のトロイの木馬を他人の端末に導入させる手法として、不正な挙動が発生するように正規のアプリケーションを改竄し、そのアプリケーションをマーケットに公開するという手法がとられるという特徴がある。不正な挙動が発生するように正規のアプリケーションを改竄する簡単な手法として、以下の２つの手法がある。これまでに出現したトロイの木馬では、２つの手法のどちらかがとられていることが多い。
【００４０】
第１の手法は、個人情報の取得と情報の送信を行う正規のアプリケーションに対して、BroadcastReceiverを利用して、端末の状態変化が発生したときに不正な挙動が発生するように改竄を施す手法である。この手法は、正規のアプリケーションの実行コードを改竄せずにマニフェストファイルだけを改竄するだけで容易に実現できる。
【００４１】
第２の手法は、個人情報の取得と情報の送信を行う正規のアプリケーションのソースコードにおいて、アプリケーションが起動した際に最初に呼び出されて実行されるメソッドが記述されている箇所に、不正な挙動が発生するメソッドのコードを追記する手法である。アプリケーションが起動した際に最初に呼び出されるメソッドを解析することは容易であり、この手法は、数行のコードを挿入するという容易な手法で実現できる。
【００４２】
上記の２つの手法で改竄されたアプリケーションは、端末の状態変化の発生やアプリケーションの起動等の特定のイベントが発生した際に自動的に実行されるメソッドによって個人情報取得APIと外部送信APIが実行されるという特徴を有する。そこで、本実施形態では、この特徴を有するアプリケーションを悪性アプリケーションと判定する解析手法をとっている。
【００４３】
次に、本実施形態によるアプリケーション解析装置の動作を説明する。図２はアプリケーション解析装置の動作を示している。まず、ディスアセンブル部１０は、記憶部２に格納されている解析対象のアプリケーションのパッケージファイルを読み出してディスアセンブルし、ソースコードを得る（ステップＳ１００）。代表的なディスアセンブルツールであるapk-toolを用いてディスアセンブルを行うと、図３に示すように、パッケージファイル（Sample.apk）から、.smali形式のソースコード（Main$JsObj.smali等）と.xml形式のマニフェストファイル（*andrd*Manifest.xml）を得ることができる。
【００４４】
続いて、API抽出部１１は、ステップＳ１００で得られたソースコードに対して、個人情報取得APIと外部送信APIのメソッド名で検索を行い、個人情報取得APIと外部送信APIを抽出する（ステップＳ１１０）。図４は、代表的な個人情報取得APIを示している。端末を識別するIDであるIMEI（International Mobile Equipment Identity）を取得するメソッドであるgetDeviceIdや、端末のソフトウェアのバージョンを取得するメソッドであるgetDeviceSoftwareVersion、端末の電話番号を取得するメソッドであるgetLine1Number等が個人情報取得APIである。図５は、代表的な外部送信APIを示している。SMS（Short Message Service）を送信するメソッドであるsendTextMessage等が外部送信APIである。
【００４５】
記憶部２には、個人情報取得APIと外部送信APIのメソッド名が記録されたリストが格納されている。ステップＳ１１０では、API抽出部１１はこのリストを記憶部２から読み出し、リストに含まれるメソッド名の文字列とソースコード中の文字列とを比較し、リストに含まれるメソッド名の文字列と一致する文字列を抽出する。また、API抽出部１１はステップＳ１１０の処理結果を制御部１４へ出力する。
【００４６】
続いて、制御部１４は、ステップＳ１１０の処理結果に基づいて、個人情報取得APIと外部送信APIの両方が抽出された否かを判定する（ステップＳ１２０）。ステップＳ１１０において、個人情報取得APIのメソッド名の文字列と一致する文字列、外部送信APIのメソッド名の文字列と一致する文字列のうちの少なくとも一方が抽出されなかった場合、処理はステップＳ１４０に進む。また、ステップＳ１１０において、個人情報取得APIのメソッド名の文字列と一致する文字列、外部送信APIのメソッド名の文字列と一致する文字列のうちの両方が抽出された場合、制御部１４は、抽出された個人情報取得APIのメソッド名と外部送信APIのメソッド名を解析部１２に与え、ステップＳ１００で得られたソースコードを解析部１２に解析させる。
【００４７】
解析部１２は、ソースコードを解析し、ステップＳ１１０で抽出された個人情報取得APIと外部送信API のそれぞれを実行するメソッドの解析を行う（ステップＳ１３０）。続いて、アプリケーション判定部１３は、解析部１２による解析の結果に基づいて、解析対象のアプリケーションの良性／悪性を判定する（ステップＳ１４０）。ステップＳ１３０，Ｓ１４０における処理の詳細な内容については、後述する。
【００４８】
図６および図７は、ステップＳ１３０におけるアプリケーション解析装置の詳細な動作を示している。解析部１２は、API抽出部１１によって抽出された個々のAPIに対応して、図６および図７に示す処理を実行する。図６および図７に示す処理では、ステップＳ１００で得られた全てのソースコードが解析の対象となる。まず、解析部１２は、APIを実行するメソッドとクラスを特定する（ステップＳ１３００）。
【００４９】
図８はソースコードの一例を示している。APIは、「.method」と「public」、「private」、「static」、「synthetic」のいずれかと、メソッド名（図８では「onCreate」）とが記述されている行と、「.end method」が記述されている行との間に記述されている。ステップＳ１３００において解析部１２は以下の処理を行う。まず、解析部１２は、ソースコードにおいてAPI名（図４および図５に示したメソッド名）を検索する。API名やメソッド名の検索は、文字列のマッチングにより行われる。これは、後述する各検索においても同様である。
【００５０】
API名を発見した場合、解析部１２は、ソースコードにおいてAPI名が記述されている行よりも前の行において「.method」を検索し、「.method」が記述されている行からメソッド名（図８では「onCreate」）を抽出する。抽出したメソッド名を有するメソッドが、APIを実行するメソッドである。つまり、図８の例では、onCreateというメソッドが、個人情報取得APIであるgetDeviceIDを実行する。さらに、解析部１２は、APIを実行するメソッドのメソッド名が記述されている行よりも前の行において、クラスを規定する文字列である「.class」を検索し、「.class」が記述されている行からクラス名（図８では「com/app/sample/Main_Activity」）を抽出する。
【００５１】
ステップＳ１３００以外のステップにおいて、前の手順で特定したメソッドを実行するメソッドとクラスを特定する際にステップＳ１３００と同様の処理を行う場合、上記のAPI名の代わりに、前の手順で特定したメソッドのメソッド名を使用して同様の処理を行い、メソッド名とクラス名を抽出すればよい。
【００５２】
ステップＳ１３００に続いて、解析部１２は、前の手順で特定したメソッドがonBindであるか否かを判定する（ステップＳ１３０１）。前の手順で特定したメソッドがonBindであった場合、解析部１２は、onBindを実行するメソッドとクラスを特定する（ステップＳ１３０７）。
【００５３】
Android（登録商標） OSに対応したアプリケーションを生成するためのソースコードでは、アプリケーションのライフサイクルに関するメソッドのうち所定のメソッドの記述に特別な記述が用いられる。具体的には、あるメソッドが所定のメソッドを呼び出して実行することを記述している部分では、所定のメソッドのメソッド名とは異なる特別なメソッド名が指定される。例えば、onBindは、他のメソッドからBindServiceというメソッド名で呼び出されて実行される。
【００５４】
ステップＳ１３０７において解析部１２は以下の処理を行う。onBindを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）には、「BindService」と、前の手順でonBindと共に特定したクラス名との両方が記述されている。したがって、解析部１２は、「.method」と「.end method」の間の部分において、「BindService」と、前の手順でonBindと共に特定したクラス名との両方を検索する。「.method」と「.end method」の間の部分において、「BindService」と、前の手順でonBindと共に特定したクラス名との両方が記述されていた場合、解析部１２はステップＳ１３００と同様にして、BindServiceを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００５５】
ステップＳ１３０１において、前の手順で特定したメソッドがonBindでなかった場合、解析部１２は、前の手順で特定したメソッドがonActivityResultであるか否かを判定する（ステップＳ１３０２）。前の手順で特定したメソッドがonActivityResultであった場合、解析部１２は、onActivityResultを実行するメソッドとクラスを特定する（ステップＳ１３０７）。onActivityResultは、アプリケーションのライフサイクルに関するメソッドであって、他のメソッドからstartActivityForResultというメソッド名で呼び出されて実行される。
【００５６】
ステップＳ１３０７において解析部１２は以下の処理を行う。onActivityResultを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）では、以下の３つの要件が満たされる。
第１の要件：「const-class」と、前の手順で特定したクラス名とが同一の行に記述されている。
第２の要件：第１の要件を満たす行よりも下の行に「startActivityForResult(L*andrd*/content/Intent;I)V」が記述されている。
第３の要件：第１の要件を満たす行と、第２の要件を満たす行との間の行に「const-class」が記述されていない。
【００５７】
図９は、onActivityResultを実行するメソッドが記述されたソースコードの一例を示している。前の手順で特定されたクラス名がcom/app/sample/classである場合、図９に示すように、「const-class」と「com/app/sample/class」が同一の行に記述されている（第１の要件）。また、この行よりも下の行に「startActivityForResult(L*andrd*/content/Intent;I)V」が記述されている（第２の要件）。さらに、「const-class」と「com/app/sample/class」が記述されている行と、「startActivityForResult(L*andrd*/content/Intent;I)V」が記述されている行との間の行に「const-class」が記述されていない（第３の要件）。
【００５８】
解析部１２は、「.method」と「.end method」の間の部分で上記の３つの要件が満たされるか否かを判定する。上記の３つの要件が満たされる場合、解析部１２はステップＳ１３００と同様にして、onActivityResultを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００５９】
ステップＳ１３０２において、前の手順で特定したメソッドがonActivityResultでなかった場合、解析部１２は、前の手順で特定したメソッドがonCreateであるか否かを判定する（ステップＳ１３０３）。onCreateは、アプリケーションのライフサイクルに関するメソッドであって、他のメソッドから所定のメソッド名で呼び出されて実行される。他のメソッドがonCreateを呼び出して実行するために指定する所定のメソッド名は、onCreateを構成要素とするクラスが継承するコンポーネントによって異なる。
【００６０】
図１０は、ソースコードのうち、クラスが継承するコンポーネントが記述されている部分のみを示している。クラスが継承するコンポーネントが記述されることにより、そのクラスの構成要素であるメソッドはそのコンポーネントを利用することが可能となる。図１０に示すように、クラスの宣言である「.class public Lcom/app/sample/Example」が記述されている行よりも下の行に、コンポーネント毎に異なる宣言が記述される。具体的には、クラスがActivityを継承する場合には「.super L*andrd*/app/Activity;」と記述され、クラスがServiceを継承する場合には「.super L*andrd*/app/Service;」と記述され、クラスがBroadcastReceiverを継承する場合には「.super L*andrd*/content/ BroadcastReceiver;」と記述される。
【００６１】
前の手順で特定したメソッドがonCreateであった場合、解析部１２は、特定したonCreateが記述されているソースコード（例えば、図８のソースコード）から、 onCreateを構成要素とするクラスが継承するコンポーネントを特定する（ステップＳ１３１０）。より具体的には、ステップＳ１３１０において解析部１２は、前の手順で特定したonCreateとクラス名が記述されているソースコードにおいて、「.super」の後に記述されている文字列からコンポーネントを特定する。
【００６２】
続いて、ステップＳ１３１０で特定されたコンポーネントに応じて処理が分岐する（ステップＳ１３１１）。ステップＳ１３１０で特定されたコンポーネントがServiceであった場合、解析部１２は、onCreateを実行するメソッドとクラスを特定する（ステップＳ１３０７）。onCreate を構成要素とするクラスがServiceを継承している場合、onCreateは、他のメソッドからstartServiceというメソッド名で呼び出されて実行される。
【００６３】
ステップＳ１３０７において解析部１２は以下の処理を行う。onCreateを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）では、以下の３つの要件が満たされる。
第１の要件：「const-class」と、前の手順で特定したクラス名とが同一の行に記述されている。
第２の要件：第１の要件を満たす行よりも下の行に「startService(L*andrd*/content/Intent;)L*andrd*/content/ComponentName」が記述されている。
第３の要件：第１の要件を満たす行と、第２の要件を満たす行との間の行に「const-class」が記述されていない。
【００６４】
図１１は、onCreateを実行するメソッドが記述されたソースコードの一例を示している。前の手順で特定されたクラス名がcom/app/sample/classである場合、図１１に示すように、「const-class」と「com/app/sample/class」が同一の行に記述されている（第１の要件）。また、この行よりも下の行に「startService(L*andrd*/content/Intent;)L*andrd*/content/ComponentName」が記述されている（第２の要件）。さらに、「const-class」と「com/app/sample/class」が記述されている行と、「startService(L*andrd*/content/Intent;)L*andrd*/content/ComponentName」が記述されている行との間の行に「const-class」が記述されていない（第３の要件）。
【００６５】
解析部１２は、「.method」と「.end method」の間の部分で上記の３つの要件が満たされるか否かを判定する。上記の３つの要件が満たされる場合、解析部１２はステップＳ１３００と同様にして、onCreateを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００６６】
一方、ステップＳ１３１０で特定されたコンポーネントがActivityであった場合、解析部１２は、onCreateがランチャーから呼び出されて実行されるか否かの確認を行うため、マニフェストファイル（*andrd*Manifest.xml）を解析する（ステップＳ１３１２）。前述したように、マニフェストファイルは、アプリケーションが利用する機能や権限を定義しているファイルである。ランチャーとは、ユーザがアプリケーションを起動するため、スマートフォンの待ち受け画面に表示されるアイコンをクリックした際に最初に実行されるプログラムの箇所である。onCreateがランチャーから呼び出されて実行される場合、ユーザが待ち受け画面上のアイコンをクリックしたというイベントが発生したときに、onCreateが自動的に実行され、情報漏洩が発生する可能性がある。
【００６７】
図１２はマニフェストファイルの記述の一例を示している。図１２に示すように、「<activity」で始まるタグの中に、クラス名である「com.app.sample.Example_Activity」が記述されている。また、「<activity」で始まるタグと、これと対になるタグである「</activity>」との間に、「<intent-filter>」と「</intent-filter>」のタグがある。また、「<intent-filter>」と「</intent-filter>」の間に、ランチャーに関する記述「<category *andrd*:name="*andrd*.intent.category.LAUNCHER" />」がある。
【００６８】
ステップＳ１３１２において解析部１２は以下の処理を行う。解析部１２は、マニフェストファイルにおいて、「<activity」で始まり「</activity>」で終わる記述の部分を抽出する。続いて、解析部１２は、抽出した部分において、「<activity」と同一の行に、前の手順で特定したクラス名が記述されているか否かを判定する。「<activity」と同一の行に、前の手順で特定したクラス名が記述されている場合、解析部１２は、抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されているか否かを判定する。抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されている場合、解析部１２は、「<intent-filter>」と「</intent-filter>」の間に「<category *andrd*:name="*andrd*.intent.category.LAUNCHER" />」が記述されているか否かを判定する。
【００６９】
ステップＳ１３１２に続いて、解析部１２は、マニフェストファイルにランチャーが登録されているか否かを判定する（ステップＳ１３１３）。ステップＳ１３１２でマニフェストファイルの解析を行った結果、「<intent-filter>」と「</intent-filter>」の間に「<category *andrd*:name="*andrd*.intent.category.LAUNCHER" />」が記述されている場合、マニフェストファイルにランチャーが登録されている。この場合、スマートフォンの待ち受け画面に表示されるアイコンをユーザがクリックしたときに、onCreateが呼び出されて実行されるため、個人情報取得APIまたは外部送信APIが自動的に実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されることを示す情報と、APIを実行するメソッドのメソッド名（onCreate）とを含む解析結果をアプリケーション判定部１３へ出力する。
【００７０】
また、ステップＳ１３１２でマニフェストファイルの解析を行った結果、マニフェストファイルにランチャーが登録されていることを確認できなかった場合、解析部１２は、onCreateを実行するメソッドとクラスを特定する（ステップＳ１３０７）。onCreate を構成要素とするクラスがActivityを継承している場合、onCreateは、他のメソッドからstartActivityというメソッド名で呼び出されて実行される。
【００７１】
ステップＳ１３０７において解析部１２は以下の処理を行う。onCreateを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）では、以下の３つの要件が満たされる。
第１の要件：「const-class」と、前の手順で特定したクラス名とが同一の行に記述されている。
第２の要件：第１の要件を満たす行よりも下の行に「startActivity(L*andrd*/content/Intent;)V」が記述されている。
第３の要件：第１の要件を満たす行と、第２の要件を満たす行との間の行に「const-class」が記述されていない。
【００７２】
図１３は、onCreateを実行するメソッドが記述されたソースコードの一例を示している。前の手順で特定されたクラス名がcom/app/sample/classである場合、図１３に示すように、「const-class」と「com/app/sample/class」が同一の行に記述されている（第１の要件）。また、この行よりも下の行に「startActivity(L*andrd*/content/Intent;)V」が記述されている（第２の要件）。さらに、「const-class」と「com/app/sample/class」が記述されている行と、「startActivity(L*andrd*/content/Intent;)V」が記述されている行との間の行に「const-class」が記述されていない（第３の要件）。
【００７３】
解析部１２は、「.method」と「.end method」の間の部分で上記の３つの要件が満たされるか否かを判定する。上記の３つの要件が満たされる場合、解析部１２はステップＳ１３００と同様にして、onCreateを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００７４】
一方、ステップＳ１３１０で特定されたコンポーネントがBroadcastReceiverであった場合、解析部１２は、onCreateがBroadcastIntentによって呼び出されて実行されるか否かの確認を行うため、マニフェストファイル（*andrd*Manifest.xml）を解析する（ステップＳ１３１４）。BroadcastIntentによってメソッドを実行する方法には、OS標準で用意されているBroadcastIntentによってメソッドを実行する方法と、ユーザが作成したBroadcastIntentによってメソッドを実行する方法とがある。onCreateが、OS標準で用意されているBroadcastIntentによって実行される場合、アプリケーションの起動の有無にかかわらず、端末の状態変化によってBroadcastIntentが発行されるというイベントが発生したときに、onCreateが自動的に実行され、情報漏洩が発生する可能性がある。
【００７５】
図１４は、OSに標準で用意されているBroadcastIntent（以下、OS標準のBroadcastIntentと記載）の一例を示している。端末が起動したときに発行されるBOOT_COMPLETEDや、バッテリーの残量が変化したときに発行されるACTION_BATTERY_CHANGED等がある。
【００７６】
図１５はマニフェストファイルの記述の一例を示している。図１５に示すように、「<receiver」で始まるタグの中に、クラス名である「jp.kddilabs.helloservice.BCreceiver」が記述されている。また、「<receiver」で始まるタグと、これと対になるタグである「</receiver>」との間に、「<intent-filter>」と「</intent-filter>」のタグがある。また、「<intent-filter>」と「</intent-filter>」の間に、BroadcastIntent名を含む記述「<action *andrd*:name="*andrd*.intent.action.BOOT_COMPLETED" />」がある。
【００７７】
ステップＳ１３１４において解析部１２は以下の処理を行う。記憶部２には、OS標準のBroadcastIntentの名称が記録されたリストが格納されている。解析部１２は、マニフェストファイルにおいて、「<receiver」で始まり「</receiver>」で終わる記述の部分を抽出する。続いて、解析部１２は、抽出した部分において、「<receiver」と同一の行に、前の手順で特定したクラス名が記述されているか否かを判定する。「<receiver」と同一の行に、前の手順で特定したクラス名が記述されている場合、解析部１２は、抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されているか否かを判定する。抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されている場合、解析部１２は、記憶部２から上記のリストを読み出し、「<intent-filter>」と「</intent-filter>」の間に、リストに含まれるBroadcastIntent名が記述されているか否かを判定する。
【００７８】
ステップＳ１３１４に続いて、解析部１２は、マニフェストファイルにOS標準のBroadcastIntentが登録されているか否かを判定する（ステップＳ１３１５）。ステップＳ１３１４でマニフェストファイルの解析を行った結果、「<intent-filter>」と「</intent-filter>」の間に、リストに含まれるBroadcastIntent名が記述されている場合、マニフェストファイルにOS標準のBroadcastIntentが登録されている。この場合、端末で所定の状態変化が発生したときに、onCreateが呼び出されて実行されるため、個人情報取得APIまたは外部送信APIが自動的に実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されることを示す情報と、APIを実行するメソッドのメソッド名（onCreate）とを含む解析結果をアプリケーション判定部１３へ出力する。
【００７９】
また、ステップＳ１３１４でマニフェストファイルの解析を行った結果、マニフェストファイルにOS標準のBroadcastIntentが登録されていることを確認できなかった場合、解析部１２は、onCreateを実行するメソッドとクラスを特定する（ステップＳ１３０７）。onCreate を構成要素とするクラスがBroadcastReceiverを継承している場合、onCreateは、ユーザが作成したBroadcastIntentによって実行される。ユーザが作成したBroadcastIntent によってonCreate が実行される場合、APIの実行の起点となるイベントが不明であるため、さらに解析を行う必要がある。
【００８０】
図１６は、ユーザが作成したBroadcastIntentによってonCreateを実行するメソッドが記述されたソースコードの一例を示している。ユーザが定義しているBroadcastIntentの名称がORIGINAL_BROADCASTである場合、図１６に示すように、onCreateを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）では、ユーザが定義したメソッド名である「ORIGINAL_BROADCAST」と、BroadcastIntentを発行するメソッドである「sendBroadcast」とが記述されている。
【００８１】
ステップＳ１３０７において解析部１２は以下の処理を行う。記憶部２には、OS標準で用意されているBroadcastIntentの名称が記録されたリストが格納されている。解析部１２は、マニフェストファイルにおいて、ステップＳ１３１４で解析を行った部分の「<intent-filter>」と「</intent-filter>」の間の部分から、上記のリストに含まれていないBroadcastIntent名を抽出する。
【００８２】
続いて、解析部１２は、ソースコードにおいて、「.method」と「.end method」の間の部分に、抽出したBroadcastIntent名と「sendBroadcast」が記述されているか否かを判定する。「.method」と「.end method」の間の部分に、抽出したBroadcastIntent名と「sendBroadcast」が記述されている場合、解析部１２はステップＳ１３００と同様にして、onCreateを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００８３】
一方、ステップＳ１３０３において、前の手順で特定したメソッドがonCreateでなかった場合、解析部１２は、前の手順で特定したメソッドがonStart，onRestart，onResume，onPause，onStop，onDestroy，onUnbind，onRebindのいずれかであるか否かを判定する（ステップＳ１３０４）。これらのメソッドは、アプリケーションのライフサイクルに関するメソッドである。
【００８４】
前の手順で特定したメソッドがonStart，onRestart，onResume，onPause，onStop，onDestroy，onUnbind，onRebindのいずれかである場合、アプリケーションのライフサイクルに関する状態変化というイベントが発生したときに、これらのメソッドが呼び出されて実行されるため、個人情報取得APIまたは外部送信APIが自動的に実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されることを示す情報と、APIを実行するメソッドのメソッド名（onStart等）とを含む解析結果をアプリケーション判定部１３へ出力する。
【００８５】
また、前の手順で特定したメソッドがonStart，onRestart，onResume，onPause，onStop，onDestroy，onUnbind，onRebindのどれでもなかった場合、解析部１２は、前の手順で特定したメソッドがonClickであるか否かを判定する（ステップＳ１３０５）。onClickは、端末上のユーザインタフェースの画面に表示されるボタンをユーザが押した際に呼び出されて実行されるメソッドである。前の手順で特定したメソッドがonClickである場合、ユーザがボタンを押すというイベントが発生したときにAPIが実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されないことを示す情報とを含む解析結果をアプリケーション判定部１３へ出力する。
【００８６】
また、前の手順で特定したメソッドがonClickでなかった場合、解析部１２は、前の手順で特定したメソッドがonItemClickであるか否かを判定する（ステップＳ１３０６）。onItemClickは、端末上の画面に表示されるリストの項目をユーザが選択した際に呼び出されて実行されるメソッドである。前の手順で特定したメソッドがonItemClickである場合、ユーザがリストの項目を選択するというイベントが発生したときにAPIが実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されないことを示す情報とを含む解析結果をアプリケーション判定部１３へ出力する。
【００８７】
また、前の手順で特定したメソッドがonItemClickでなかった場合、解析部１２は、ステップＳ１３００と同様にして、前の手順で特定したメソッドを実行するメソッドとクラスを特定する（ステップＳ１３０７）。続いて、解析部１２は、前の手順で特定したメソッドを実行するメソッドが存在するか否かを判定する（ステップＳ１３０８）。
【００８８】
ステップＳ１３０７において、前の手順で特定したメソッドを実行するメソッドとクラスを特定できなかった場合、APIが呼び出されて実行されることはないため、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されないことを示す情報とを含む解析結果をアプリケーション判定部１３へ出力する。また、ステップＳ１３０７において、前の手順で特定したメソッドを実行するメソッドとクラスを特定できた場合、処理はステップＳ１３０１に進む。図６および図７に示す手順に従って解析を行うことにより、アプリケーションが起動している状態でユーザが端末上で行う操作に起因せずにAPIが自動的に実行されるのか否かを判別することができる。
【００８９】
次に、ステップＳ１４０におけるアプリケーションの良性／悪性の判定方法を説明する。前述したように、解析部１２は解析結果をアプリケーション判定部１３へ出力する。解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPI毎に解析を行うので、API毎の解析結果がアプリケーション判定部１３へ出力される。
【００９０】
ステップＳ１１０において、個人情報取得APIと外部送信APIのうちの少なくとも一方が抽出されなかった場合、アプリケーション判定部１３は、解析対象のアプリケーションが良性であると判定する。また、ステップＳ１３０における解析が行われて解析部１２から解析結果が出力された場合、アプリケーション判定部１３は解析結果に基づいて以下のようにアプリケーションの良性／悪性を判定する。
【００９１】
個人情報取得APIと外部送信APIのうちの少なくとも一方について、APIが自動的に実行されないことを示す情報を含む解析結果が出力された場合、個人情報取得APIと外部送信APIのうちの少なくとも一方は実行されない、あるいは個人情報取得APIと外部送信APIのうちの少なくとも一方はアプリケーション起動後のユーザの操作によって実行されるので情報漏洩の危険度は低いと推定できる。この場合、アプリケーション判定部１３は、解析対象のアプリケーションが良性であると判定する。
【００９２】
また、個人情報取得APIと外部送信APIの両方について、APIが自動的に実行されることを示す情報を含む解析結果が出力された場合、アプリケーション判定部１３は、個人情報取得APIを実行するメソッドのメソッド名と、外部送信APIを実行するメソッドのメソッド名とが一致するか否かを確認する。両者が一致しなかった場合、個人情報取得APIと外部送信APIは自動的に実行されるが、両者の実行の起点となるメソッドは異なり、両者の実行の関連性は低いので、情報漏洩の危険度は低いと推定できる。この場合、アプリケーション判定部１３は、解析対象のアプリケーションが良性であると判定する。
【００９３】
これに対して、両者が一致した場合、同一のメソッドを起点として個人情報取得APIと外部送信APIが自動的に実行されるので、情報漏洩の危険度が高いと推定できる。この場合、アプリケーション判定部１３は、解析対象のアプリケーションが悪性であると判定する。つまり、個人情報取得APIと外部送信APIが同一のメソッドによって自動的に実行される場合に解析対象のアプリケーションが悪性であると判定され、それ以外の場合には解析対象のアプリケーションが良性であると判定される。
【００９４】
上述したように、本実施形態によれば、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて情報の取得と送信を自動的に実行する悪性アプリケーションを検知することができる。このため、ユーザが情報の利用を承諾するために端末上で行う操作に起因するイベントの発生に基づいて情報の取得と送信を実行するアプリケーションを悪性アプリケーションとは区別することが可能となるので、悪性アプリケーションの誤検知を低減することができる。
【００９５】
また、ソースコードの解析において、APIを実行するメソッドを特定しても、特定したメソッドのメソッド名（onBind等）だけからはAPIの実行の起点となるイベントを判別することができない場合に、APIを実行するメソッドを実行する他のメソッドを特定することによって、APIの実行の起点となるイベントを判別できる可能性が高まる。このため、悪性アプリケーションの検知漏れを低減することができる。
【００９６】
また、onBind等の所定のメソッドに関しては、他のメソッドが所定のメソッドを指定するときのメソッド名と所定のメソッドのメソッド名とが異なるが、このようにメソッド名が異なる場合があることを考慮して、APIを実行する他のメソッドを特定することによって、APIの実行の起点となるイベントを判別できる可能性が高まる。このため、悪性アプリケーションの検知漏れを低減することができる。
【００９７】
また、onCreateに関しては、マニフェストファイルに基づいて、onCreateが、スマートフォンの待ち受け画面に表示されるアイコンがクリックされた際に最初に実行されるランチャーから呼び出されて実行されるか否か、あるいは端末の状態変化に基づいてOS標準のBroadcastIntentによって呼び出されて実行されるか否かを確認することによって、APIが自動的に実行されるか否かを確認することができる。
【００９８】
また、特定したメソッドが、アプリケーションの状態遷移に関係する所定のメソッド（onStart等）であるか否かを判定することによって、APIが自動的に実行されるか否かを確認することができる。
【００９９】
上述したアプリケーション解析装置は、その動作および機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませ、実行させることにより、実現される。ここで、「コンピュータ」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。
【０１００】
また、上述したプログラムは、このプログラムを記憶装置等に格納したコンピュータから、伝送媒体を介して、あるいは伝送媒体中の伝送波により他のコンピュータに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように、情報を伝送する機能を有する媒体のことをいう。また、上述したプログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能を、コンピュータに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【０１０１】
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成は上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【符号の説明】
【０１０２】
１・・・アプリケーション解析部、２・・・記憶部、１０・・・ディスアセンブル部、１１・・・API抽出部、１２・・・解析部、１３・・・アプリケーション判定部、１４・・・制御部
【技術分野】
【０００１】
本発明は、アプリケーションの機能を解析するアプリケーション解析装置に関する。また、本発明は、本アプリケーション解析装置としてコンピュータを機能させるためのプログラムにも関する。
【背景技術】
【０００２】
汎用OS（オペレーティングシステム）を用いたオープンプラットフォームを採用する、スマートフォンと呼ばれる携帯情報端末が普及している。また、スマートフォンに搭載される汎用OSとして、端末で管理される情報や機能を利用するための命令や関数の集合であるAPI（Application Program Interface） が豊富に用意されているAndroid（登録商標） OS が注目を集めている。本明細書では一例として、Android（登録商標） OSを搭載したスマートフォンについて記載する。
【０００３】
スマートフォンは、誰もが自由にアプリケーションを開発して公開でき、公開されたアプリケーションをユーザが自由にインストールできるプラットフォームである。公開されたアプリケーションをスマートフォンに導入することにより、スマートフォンの様々な機能を柔軟かつ容易に拡張することができる。
【０００４】
しかし、アプリケーションの中には、ユーザに気付かれないように、端末内の情報を収集して外部に送信する悪性アプリケーションが存在する。特に、正規のアプリケーションを装いつつ、こうした不正な振る舞いを行うアプリケーションはトロイの木馬と呼ばれており、ユーザがその脅威に気付くことは困難である。
【０００５】
スマートフォンには、電話やカメラを制御するAPIが設けられており、アプリケーションがAPIを利用して発呼や、SMS通信、写真撮影を行うことができる。これらの行為を悪意のアプリケーションが密かに行った場合、勝手な課金やプライバシの漏洩が発生する。
【０００６】
また、スマートフォンは、ユーザとの結びつきがPC（パーソナルコンピュータ）よりも緊密な機器であり、電話番号、メールアドレス、住所録、メールの送受信履歴、インターネットの閲覧履歴等の個人情報が集積している。また、端末の高機能化と、常に携帯される利用形態とから、従来のPCでは収集されなかった位置情報等の情報も容易に取得可能となり、情報が悪用される脅威に直面する。
【０００７】
また、スマートフォンでは、ユーザが明示的に操作を行ってアプリケーションを起動できる機能以外にも、端末の状態の変化に応じてアプリケーションが自動的に起動する機能がある。例えば、電話の着信があった、端末が再起動した、WiFiがオンになった等の端末の状態の変化によってアプリケーションを自動的に起動させることができる。よって、ユーザが誤って悪性アプリケーションを一旦端末にインストールしてしまうと、ユーザの知らないうちに情報漏洩が発生する可能性がある。したがって、アプリケーションを容易に入手可能な環境において情報が悪用される脅威からユーザを保護する必要がある。
【０００８】
ユーザを悪性アプリケーションによる脅威から保護する手法として、アプリケーションの安全性を事前に検証し、悪性アプリケーションを検知する仕組みが有効である。情報漏洩を行うアプリケーションを検知する手法として、動的解析および静的解析の手法が提案されている。
【０００９】
動的解析とは、実際にアプリケーションを動作させ、アプリケーションの振る舞いが記録されたログを解析することで、アプリケーションの悪性／良性判定を行う手法である（例えば、非特許文献１参照）。代表的な解析方法として、straceログの情報を用いた手法がある。この手法は、アプリケーションがシステムの機能を利用した際にログに記録された情報から悪性の挙動を解析する手法である。しかしながら、この手法では、外部に送信する情報が暗号化されていた場合、悪性の挙動を検知することができない。また、アプリケーションがタイマー機能を持ち、アプリケーションが起動してから10時間後に悪性の挙動が発生するなどの設定が行われていることもあり、長時間の監視が必要になるなど、悪性の挙動を検知することが難しくなるといった課題がある。
【００１０】
一方、静的解析とは、アプリケーションの実行コードのディスアセンブルを行ってアプリケーションのソースコードを取得し、そのソースコードから悪性の挙動を解析する手法である。非特許文献２には、静的解析を用いてスマートフォン用のアプリケーションを検査し、解析対象のアプリケーションが情報漏洩アプリケーションか否かを判定する手法が記載されている。この手法では、具体的には、個人情報を取得するAPIと、外部に情報を送信するAPIとが繋がるかどうかを解析している。また、個人情報を取得するAPIが実行されるタイミングと、外部に情報を送信するAPIが実行されるタイミングとの間で、情報の利用に関するユーザの承諾（同意）の操作が行われるかどうかを考慮している。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】竹森敬祐、磯原隆将、窪田歩、高野智秋、「Android携帯電話上での情報漏洩検知」、電子情報通信学会、SCIS2011シンポジウム、2011年1月
【非特許文献２】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)
【発明の概要】
【発明が解決しようとする課題】
【００１２】
非特許文献２に記載された手法では、個人情報を取得するAPIが実行されるタイミングと、外部に情報を送信するAPIが実行されるタイミングとの間でユーザの承諾の操作が行われることを良性アプリケーションの特徴としている。しかし、この手法では、ユーザが承諾のための操作を行うタイミングとして上記以外のタイミング（例えばアプリケーションの起動直後のタイミング）は考慮されていない。このため、ユーザによる明示的な承諾の操作が行われてから個人情報の取得および外部への情報送信を行うように構成された良性アプリケーションを解析した場合に、個人情報を取得するAPIが実行されるタイミングと、外部に情報を送信するAPIが実行されるタイミングとの間でユーザの承諾の操作が行われないことが分かると、悪性アプリケーションとして誤検知する可能性があった。
【００１３】
本発明は、上述した課題に鑑みてなされたものであって、ユーザが端末に対して行う操作を考慮してアプリケーションの良性／悪性を判定する従来の手法で発生しうる悪性アプリケーションの誤検知を低減することができるアプリケーション解析装置およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明は、上記の課題を解決するためになされたもので、解析対象のアプリケーションの実行コードをディスアセンブルし、前記実行コードに対応するソースコードを得るディスアセンブル部と、端末内の情報を取得する第１のAPI（Application Program Interface）および情報を外部の機器へ送信する第２のAPIを前記ソースコードから抽出する抽出部と、前記ソースコードを解析し、前記抽出部によって抽出されたAPIを実行するメソッドを特定し、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定する解析部と、前記第１のAPIおよび前記第２のAPIが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されると判定された場合に、前記解析対象のアプリケーションが悪性であると判定する判定部と、を備えたことを特徴とするアプリケーション解析装置である。
【００１５】
また、本発明のアプリケーション解析装置において、前記解析部は、前記ソースコードを解析し、前記抽出部によって抽出されたAPIを実行するメソッドを特定し、さらに、特定したメソッドを実行する他のメソッドを特定し、特定した他のメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定することを特徴とする。
【００１６】
また、本発明のアプリケーション解析装置において、メソッドが所定のメソッドを指定するときのメソッド名と前記所定のメソッドのメソッド名とが異なるソースコードから生成されたアプリケーションが解析対象である場合に、前記解析部は、特定したメソッドが前記所定のメソッドであれば、前記所定のメソッドを指定するときのメソッド名に基づいて前記他のメソッドを特定することを特徴とする。
【００１７】
また、本発明のアプリケーション解析装置において、前記解析部は、アプリケーションが利用する機能や権限を規定したマニフェストファイルに基づいて、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定することを特徴とする。
【００１８】
また、本発明のアプリケーション解析装置において、前記解析部は、特定したメソッドが、アプリケーションを起動するためにユーザが端末上で操作を行ったときに実行されるか否かを判定することを特徴とする。
【００１９】
また、本発明のアプリケーション解析装置において、前記解析部は、特定したメソッドが、端末の状態変化に基づいてブロードキャストされるインテントが発生したときに実行されるか否かを判定することを特徴とする。
【００２０】
また、本発明のアプリケーション解析装置において、前記解析部は、特定したメソッドが、アプリケーションの状態遷移に関係するメソッドであるか否かを判定することを特徴とする。
【００２１】
また、本発明のアプリケーション解析装置において、前記解析部は、特定した他のメソッドが、アプリケーションの状態遷移に関係するメソッドであるか否かを判定することを特徴とする。
【００２２】
また、本発明は、上記のアプリケーション解析装置としてコンピュータを機能させるためのプログラムである。
【発明の効果】
【００２３】
本発明によれば、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて情報の取得と送信を自動的に実行する悪性アプリケーションを検知することが可能となる。このため、ユーザが端末上で行う操作を考慮してアプリケーションの良性／悪性を判定する従来の手法で発生しうる悪性アプリケーションの誤検知を低減することができる。
【図面の簡単な説明】
【００２４】
【図１】本発明の一実施形態によるアプリケーション解析装置の構成を示すブロック図である。
【図２】本発明の一実施形態によるアプリケーション解析装置の動作の手順を示すフローチャートである。
【図３】本発明の一実施形態におけるアプリケーションのファイルをディスアセンブルして得られるファイルの構造を示す参考図である。
【図４】本発明の一実施形態において、個人情報を取得するAPIを示す参考図である。
【図５】本発明の一実施形態において、外部に情報を送信するAPIを示す参考図である。
【図６】本発明の一実施形態によるアプリケーション解析装置の動作の手順を示すフローチャートである。
【図７】本発明の一実施形態によるアプリケーション解析装置の動作の手順を示すフローチャートである。
【図８】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図９】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図１０】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図１１】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図１２】本発明の一実施形態におけるマニフェストファイルの記述を示す参考図である。
【図１３】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【図１４】本発明の一実施形態におけるBroadcastIntentを示す参考図である。
【図１５】本発明の一実施形態におけるマニフェストファイルの記述を示す参考図である。
【図１６】本発明の一実施形態におけるアプリケーションのソースコードを示す参考図である。
【発明を実施するための形態】
【００２５】
以下、図面を参照し、本発明の実施形態を説明する。本明細書および図面では、便宜上、必要に応じてAndroid（登録商標）という文字列を*Andrd*という文字列で代用し、java（登録商標）という文字列を*jv*という文字列で代用している。すなわち、*Andrd*という文字列はAndroid（登録商標）という文字列と等価であり、*jv*という文字列はjava（登録商標）という文字列と等価である。また、本明細書では、ソースコードに記述されるメソッド名等の文字列を記載するときに、「と」で文字列を囲んで示すことがある。例えば、本明細書では、「XXX」はXXXという文字列を示すものとする。
【００２６】
本実施形態によるアプリケーション解析装置は、解析対象のアプリケーションの実行コードをディスアセンブル（逆アセンブル）して得られるソースコード（ソースファイル）を解析し、端末に格納された個人情報を取得するAPI（以下、個人情報取得APIと記載）と、情報を外部の機器へ送信するAPI（以下、外部送信APIと記載）とをソースコードから抽出する。また、本実施形態によるアプリケーション解析装置は、ソースコードから抽出した個人情報取得APIと外部送信APIを実行するメソッドを特定し、特定したメソッドが、ユーザが端末上で行う操作（アプリケーションを起動するための操作を除く）に起因しないイベントの発生に基づいて実行される場合に、解析対象のアプリケーションが悪性であると判定する。このようなイベントとして、端末の状態変化が発生したというイベントや、アプリケーションを起動する操作が行われたというイベント等がある。
【００２７】
本実施形態では、端末に格納された情報の利用を承諾（同意）するためにユーザが行う操作を直接的な発生原因としない特定のイベントが発生したときに個人情報取得APIと外部送信APIを自動的に実行するアプリケーションが悪性アプリケーション（情報漏洩アプリケーション）として検知される。このため、ユーザが行う承諾の操作に伴って個人情報取得APIと外部送信APIを実行するように構成されたアプリケーションを解析した場合には、解析対象のアプリケーションは悪性アプリケーションとして検知されない。したがって、良性アプリケーションを悪性アプリケーションとして誤検知する可能性を低減することができる。
【００２８】
本実施形態によるアプリケーション解析装置は、例えばスマートフォン用のアプリケーションを通信ネットワーク上で販売する販売サイトを管理する企業に設置される。また、本実施形態によるアプリケーション解析装置が行う解析のアルゴリズムをアンチウイルスソフトに適用することも可能である。したがって、ユーザが端末にインストールするアプリケーションを事前に審査することができる。
【００２９】
図１は、本実施形態によるアプリケーション解析装置の構成を示している。図１に示すように、アプリケーション解析装置は、アプリケーション解析部１および記憶部２を有する。
【００３０】
アプリケーション解析部１は、解析対象のアプリケーションの実行ファイルであるパッケージファイル（アプリケーションファイル）からディスアセンブルによりソースコードを取得し、取得したソースコードを解析して解析対象のアプリケーションの良性／悪性の判定を行う。パッケージファイルは、例えば拡張子が.apkのファイルであり、命令列を含む実行コード（例えば拡張子が.dex）、アプリケーションが利用する機能や権限が定義されたマニフェストファイル（例えば拡張子が.xml）、アプリケーションが利用するテキストファイルや画像ファイル等の各種リソースファイルを含む。記憶部２は、解析対象のアプリケーションのパッケージファイルを記憶するほか、個人情報取得APIおよび外部送信API等の情報が記録されたリストを記憶する。
【００３１】
アプリケーション解析部１は、ディスアセンブル部１０、API抽出部１１、解析部１２、アプリケーション判定部１３、および制御部１４を有する。ディスアセンブル部１０は、解析対象のアプリケーションの実行コードをディスアセンブル（逆アセンブル）し、実行コードに対応するソースコード（ソースファイル）を得る。API抽出部１１は、ソースコードから個人情報取得APIと外部送信APIを抽出する。
【００３２】
解析部１２は、ソースコードを解析し、API抽出部１１によって抽出された個人情報取得APIと外部送信API のそれぞれを実行するメソッドを特定し、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定する。アプリケーション判定部１３は、解析部１２がソースコードを解析した結果に基づいて、解析対象のアプリケーションの良性／悪性を判定する。制御部１４は、アプリケーション解析部１における各部の動作を制御する。
【００３３】
次に、本実施形態におけるアプリケーションの解析手法の概念を説明する。Android（登録商標）OS上で動作するアプリケーションの構成要素（コンポーネント）として、Activity、Service、BroadcastReceiver、ContentProviderの4つがある。以下、各コンポーネントについて説明する。
【００３４】
Activityは、ユーザに対して視覚的なインターフェイスを提供し、画面上でユーザと対話を行うコンポーネントである。アプリケーションを起動すると画面が表示される場合、Activityに記述されたプログラムが動作している。
【００３５】
Serviceは、画面を表示する機能を持たずに、バックグラウンドで処理を実行するコンポーネントである。例えば、ユーザが音楽を聞きながらブラウザを起動してインターネットの利用を楽しむ場合、音楽用アプリケーションがServiceを起動することにより、ユーザはインターネットの利用中に音楽を聞くことができる。
【００３６】
BroadcastReceiverは、Android（登録商標）OSが搭載された端末のシステム全体にブロードキャストされるINTENT（以下、BroadcastIntentと記載）を受け取るコンポーネントである。例えば、電池残量が減ってきたときに、「残りのバッテリー残量が少ないです」というメッセージを含む画面を表示するアプリケーションでは、電池残量が変化するときに発行されるBroadcastIntentをBroadcastReceiverにより受け取ったアプリケーションがActivityを起動して画面を表示する。
【００３７】
ContentProviderは、アプリケーションが保持するデータを他のコンポーネントでも使用可能にするコンポーネントである。例えば、あるアプリケーションが電話帳のデータを取得したい場合、そのアプリケーションは、電話帳アプリケーションのContentProviderを利用して、電話帳に登録されている情報を取得する。
【００３８】
Android（登録商標）では、アプリケーションのライフサイクル（状態遷移）に関する特別なメソッドがある。ライフサイクルに関するメソッドとして、コンポーネントが起動したタイミングで呼び出されて実行されるメソッドであるonCreate、onStart、onBind等のほか、コンポーネントが終了するタイミングで呼び出されて実行されるメソッドであるonDestroy等がある。
【００３９】
本実施形態におけるアプリケーションの解析手法は、特にトロイの木馬の検知に適している。悪意のユーザがAndroid（登録商標）のトロイの木馬を他人の端末に導入させる手法として、不正な挙動が発生するように正規のアプリケーションを改竄し、そのアプリケーションをマーケットに公開するという手法がとられるという特徴がある。不正な挙動が発生するように正規のアプリケーションを改竄する簡単な手法として、以下の２つの手法がある。これまでに出現したトロイの木馬では、２つの手法のどちらかがとられていることが多い。
【００４０】
第１の手法は、個人情報の取得と情報の送信を行う正規のアプリケーションに対して、BroadcastReceiverを利用して、端末の状態変化が発生したときに不正な挙動が発生するように改竄を施す手法である。この手法は、正規のアプリケーションの実行コードを改竄せずにマニフェストファイルだけを改竄するだけで容易に実現できる。
【００４１】
第２の手法は、個人情報の取得と情報の送信を行う正規のアプリケーションのソースコードにおいて、アプリケーションが起動した際に最初に呼び出されて実行されるメソッドが記述されている箇所に、不正な挙動が発生するメソッドのコードを追記する手法である。アプリケーションが起動した際に最初に呼び出されるメソッドを解析することは容易であり、この手法は、数行のコードを挿入するという容易な手法で実現できる。
【００４２】
上記の２つの手法で改竄されたアプリケーションは、端末の状態変化の発生やアプリケーションの起動等の特定のイベントが発生した際に自動的に実行されるメソッドによって個人情報取得APIと外部送信APIが実行されるという特徴を有する。そこで、本実施形態では、この特徴を有するアプリケーションを悪性アプリケーションと判定する解析手法をとっている。
【００４３】
次に、本実施形態によるアプリケーション解析装置の動作を説明する。図２はアプリケーション解析装置の動作を示している。まず、ディスアセンブル部１０は、記憶部２に格納されている解析対象のアプリケーションのパッケージファイルを読み出してディスアセンブルし、ソースコードを得る（ステップＳ１００）。代表的なディスアセンブルツールであるapk-toolを用いてディスアセンブルを行うと、図３に示すように、パッケージファイル（Sample.apk）から、.smali形式のソースコード（Main$JsObj.smali等）と.xml形式のマニフェストファイル（*andrd*Manifest.xml）を得ることができる。
【００４４】
続いて、API抽出部１１は、ステップＳ１００で得られたソースコードに対して、個人情報取得APIと外部送信APIのメソッド名で検索を行い、個人情報取得APIと外部送信APIを抽出する（ステップＳ１１０）。図４は、代表的な個人情報取得APIを示している。端末を識別するIDであるIMEI（International Mobile Equipment Identity）を取得するメソッドであるgetDeviceIdや、端末のソフトウェアのバージョンを取得するメソッドであるgetDeviceSoftwareVersion、端末の電話番号を取得するメソッドであるgetLine1Number等が個人情報取得APIである。図５は、代表的な外部送信APIを示している。SMS（Short Message Service）を送信するメソッドであるsendTextMessage等が外部送信APIである。
【００４５】
記憶部２には、個人情報取得APIと外部送信APIのメソッド名が記録されたリストが格納されている。ステップＳ１１０では、API抽出部１１はこのリストを記憶部２から読み出し、リストに含まれるメソッド名の文字列とソースコード中の文字列とを比較し、リストに含まれるメソッド名の文字列と一致する文字列を抽出する。また、API抽出部１１はステップＳ１１０の処理結果を制御部１４へ出力する。
【００４６】
続いて、制御部１４は、ステップＳ１１０の処理結果に基づいて、個人情報取得APIと外部送信APIの両方が抽出された否かを判定する（ステップＳ１２０）。ステップＳ１１０において、個人情報取得APIのメソッド名の文字列と一致する文字列、外部送信APIのメソッド名の文字列と一致する文字列のうちの少なくとも一方が抽出されなかった場合、処理はステップＳ１４０に進む。また、ステップＳ１１０において、個人情報取得APIのメソッド名の文字列と一致する文字列、外部送信APIのメソッド名の文字列と一致する文字列のうちの両方が抽出された場合、制御部１４は、抽出された個人情報取得APIのメソッド名と外部送信APIのメソッド名を解析部１２に与え、ステップＳ１００で得られたソースコードを解析部１２に解析させる。
【００４７】
解析部１２は、ソースコードを解析し、ステップＳ１１０で抽出された個人情報取得APIと外部送信API のそれぞれを実行するメソッドの解析を行う（ステップＳ１３０）。続いて、アプリケーション判定部１３は、解析部１２による解析の結果に基づいて、解析対象のアプリケーションの良性／悪性を判定する（ステップＳ１４０）。ステップＳ１３０，Ｓ１４０における処理の詳細な内容については、後述する。
【００４８】
図６および図７は、ステップＳ１３０におけるアプリケーション解析装置の詳細な動作を示している。解析部１２は、API抽出部１１によって抽出された個々のAPIに対応して、図６および図７に示す処理を実行する。図６および図７に示す処理では、ステップＳ１００で得られた全てのソースコードが解析の対象となる。まず、解析部１２は、APIを実行するメソッドとクラスを特定する（ステップＳ１３００）。
【００４９】
図８はソースコードの一例を示している。APIは、「.method」と「public」、「private」、「static」、「synthetic」のいずれかと、メソッド名（図８では「onCreate」）とが記述されている行と、「.end method」が記述されている行との間に記述されている。ステップＳ１３００において解析部１２は以下の処理を行う。まず、解析部１２は、ソースコードにおいてAPI名（図４および図５に示したメソッド名）を検索する。API名やメソッド名の検索は、文字列のマッチングにより行われる。これは、後述する各検索においても同様である。
【００５０】
API名を発見した場合、解析部１２は、ソースコードにおいてAPI名が記述されている行よりも前の行において「.method」を検索し、「.method」が記述されている行からメソッド名（図８では「onCreate」）を抽出する。抽出したメソッド名を有するメソッドが、APIを実行するメソッドである。つまり、図８の例では、onCreateというメソッドが、個人情報取得APIであるgetDeviceIDを実行する。さらに、解析部１２は、APIを実行するメソッドのメソッド名が記述されている行よりも前の行において、クラスを規定する文字列である「.class」を検索し、「.class」が記述されている行からクラス名（図８では「com/app/sample/Main_Activity」）を抽出する。
【００５１】
ステップＳ１３００以外のステップにおいて、前の手順で特定したメソッドを実行するメソッドとクラスを特定する際にステップＳ１３００と同様の処理を行う場合、上記のAPI名の代わりに、前の手順で特定したメソッドのメソッド名を使用して同様の処理を行い、メソッド名とクラス名を抽出すればよい。
【００５２】
ステップＳ１３００に続いて、解析部１２は、前の手順で特定したメソッドがonBindであるか否かを判定する（ステップＳ１３０１）。前の手順で特定したメソッドがonBindであった場合、解析部１２は、onBindを実行するメソッドとクラスを特定する（ステップＳ１３０７）。
【００５３】
Android（登録商標） OSに対応したアプリケーションを生成するためのソースコードでは、アプリケーションのライフサイクルに関するメソッドのうち所定のメソッドの記述に特別な記述が用いられる。具体的には、あるメソッドが所定のメソッドを呼び出して実行することを記述している部分では、所定のメソッドのメソッド名とは異なる特別なメソッド名が指定される。例えば、onBindは、他のメソッドからBindServiceというメソッド名で呼び出されて実行される。
【００５４】
ステップＳ１３０７において解析部１２は以下の処理を行う。onBindを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）には、「BindService」と、前の手順でonBindと共に特定したクラス名との両方が記述されている。したがって、解析部１２は、「.method」と「.end method」の間の部分において、「BindService」と、前の手順でonBindと共に特定したクラス名との両方を検索する。「.method」と「.end method」の間の部分において、「BindService」と、前の手順でonBindと共に特定したクラス名との両方が記述されていた場合、解析部１２はステップＳ１３００と同様にして、BindServiceを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００５５】
ステップＳ１３０１において、前の手順で特定したメソッドがonBindでなかった場合、解析部１２は、前の手順で特定したメソッドがonActivityResultであるか否かを判定する（ステップＳ１３０２）。前の手順で特定したメソッドがonActivityResultであった場合、解析部１２は、onActivityResultを実行するメソッドとクラスを特定する（ステップＳ１３０７）。onActivityResultは、アプリケーションのライフサイクルに関するメソッドであって、他のメソッドからstartActivityForResultというメソッド名で呼び出されて実行される。
【００５６】
ステップＳ１３０７において解析部１２は以下の処理を行う。onActivityResultを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）では、以下の３つの要件が満たされる。
第１の要件：「const-class」と、前の手順で特定したクラス名とが同一の行に記述されている。
第２の要件：第１の要件を満たす行よりも下の行に「startActivityForResult(L*andrd*/content/Intent;I)V」が記述されている。
第３の要件：第１の要件を満たす行と、第２の要件を満たす行との間の行に「const-class」が記述されていない。
【００５７】
図９は、onActivityResultを実行するメソッドが記述されたソースコードの一例を示している。前の手順で特定されたクラス名がcom/app/sample/classである場合、図９に示すように、「const-class」と「com/app/sample/class」が同一の行に記述されている（第１の要件）。また、この行よりも下の行に「startActivityForResult(L*andrd*/content/Intent;I)V」が記述されている（第２の要件）。さらに、「const-class」と「com/app/sample/class」が記述されている行と、「startActivityForResult(L*andrd*/content/Intent;I)V」が記述されている行との間の行に「const-class」が記述されていない（第３の要件）。
【００５８】
解析部１２は、「.method」と「.end method」の間の部分で上記の３つの要件が満たされるか否かを判定する。上記の３つの要件が満たされる場合、解析部１２はステップＳ１３００と同様にして、onActivityResultを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００５９】
ステップＳ１３０２において、前の手順で特定したメソッドがonActivityResultでなかった場合、解析部１２は、前の手順で特定したメソッドがonCreateであるか否かを判定する（ステップＳ１３０３）。onCreateは、アプリケーションのライフサイクルに関するメソッドであって、他のメソッドから所定のメソッド名で呼び出されて実行される。他のメソッドがonCreateを呼び出して実行するために指定する所定のメソッド名は、onCreateを構成要素とするクラスが継承するコンポーネントによって異なる。
【００６０】
図１０は、ソースコードのうち、クラスが継承するコンポーネントが記述されている部分のみを示している。クラスが継承するコンポーネントが記述されることにより、そのクラスの構成要素であるメソッドはそのコンポーネントを利用することが可能となる。図１０に示すように、クラスの宣言である「.class public Lcom/app/sample/Example」が記述されている行よりも下の行に、コンポーネント毎に異なる宣言が記述される。具体的には、クラスがActivityを継承する場合には「.super L*andrd*/app/Activity;」と記述され、クラスがServiceを継承する場合には「.super L*andrd*/app/Service;」と記述され、クラスがBroadcastReceiverを継承する場合には「.super L*andrd*/content/ BroadcastReceiver;」と記述される。
【００６１】
前の手順で特定したメソッドがonCreateであった場合、解析部１２は、特定したonCreateが記述されているソースコード（例えば、図８のソースコード）から、 onCreateを構成要素とするクラスが継承するコンポーネントを特定する（ステップＳ１３１０）。より具体的には、ステップＳ１３１０において解析部１２は、前の手順で特定したonCreateとクラス名が記述されているソースコードにおいて、「.super」の後に記述されている文字列からコンポーネントを特定する。
【００６２】
続いて、ステップＳ１３１０で特定されたコンポーネントに応じて処理が分岐する（ステップＳ１３１１）。ステップＳ１３１０で特定されたコンポーネントがServiceであった場合、解析部１２は、onCreateを実行するメソッドとクラスを特定する（ステップＳ１３０７）。onCreate を構成要素とするクラスがServiceを継承している場合、onCreateは、他のメソッドからstartServiceというメソッド名で呼び出されて実行される。
【００６３】
ステップＳ１３０７において解析部１２は以下の処理を行う。onCreateを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）では、以下の３つの要件が満たされる。
第１の要件：「const-class」と、前の手順で特定したクラス名とが同一の行に記述されている。
第２の要件：第１の要件を満たす行よりも下の行に「startService(L*andrd*/content/Intent;)L*andrd*/content/ComponentName」が記述されている。
第３の要件：第１の要件を満たす行と、第２の要件を満たす行との間の行に「const-class」が記述されていない。
【００６４】
図１１は、onCreateを実行するメソッドが記述されたソースコードの一例を示している。前の手順で特定されたクラス名がcom/app/sample/classである場合、図１１に示すように、「const-class」と「com/app/sample/class」が同一の行に記述されている（第１の要件）。また、この行よりも下の行に「startService(L*andrd*/content/Intent;)L*andrd*/content/ComponentName」が記述されている（第２の要件）。さらに、「const-class」と「com/app/sample/class」が記述されている行と、「startService(L*andrd*/content/Intent;)L*andrd*/content/ComponentName」が記述されている行との間の行に「const-class」が記述されていない（第３の要件）。
【００６５】
解析部１２は、「.method」と「.end method」の間の部分で上記の３つの要件が満たされるか否かを判定する。上記の３つの要件が満たされる場合、解析部１２はステップＳ１３００と同様にして、onCreateを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００６６】
一方、ステップＳ１３１０で特定されたコンポーネントがActivityであった場合、解析部１２は、onCreateがランチャーから呼び出されて実行されるか否かの確認を行うため、マニフェストファイル（*andrd*Manifest.xml）を解析する（ステップＳ１３１２）。前述したように、マニフェストファイルは、アプリケーションが利用する機能や権限を定義しているファイルである。ランチャーとは、ユーザがアプリケーションを起動するため、スマートフォンの待ち受け画面に表示されるアイコンをクリックした際に最初に実行されるプログラムの箇所である。onCreateがランチャーから呼び出されて実行される場合、ユーザが待ち受け画面上のアイコンをクリックしたというイベントが発生したときに、onCreateが自動的に実行され、情報漏洩が発生する可能性がある。
【００６７】
図１２はマニフェストファイルの記述の一例を示している。図１２に示すように、「<activity」で始まるタグの中に、クラス名である「com.app.sample.Example_Activity」が記述されている。また、「<activity」で始まるタグと、これと対になるタグである「</activity>」との間に、「<intent-filter>」と「</intent-filter>」のタグがある。また、「<intent-filter>」と「</intent-filter>」の間に、ランチャーに関する記述「<category *andrd*:name="*andrd*.intent.category.LAUNCHER" />」がある。
【００６８】
ステップＳ１３１２において解析部１２は以下の処理を行う。解析部１２は、マニフェストファイルにおいて、「<activity」で始まり「</activity>」で終わる記述の部分を抽出する。続いて、解析部１２は、抽出した部分において、「<activity」と同一の行に、前の手順で特定したクラス名が記述されているか否かを判定する。「<activity」と同一の行に、前の手順で特定したクラス名が記述されている場合、解析部１２は、抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されているか否かを判定する。抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されている場合、解析部１２は、「<intent-filter>」と「</intent-filter>」の間に「<category *andrd*:name="*andrd*.intent.category.LAUNCHER" />」が記述されているか否かを判定する。
【００６９】
ステップＳ１３１２に続いて、解析部１２は、マニフェストファイルにランチャーが登録されているか否かを判定する（ステップＳ１３１３）。ステップＳ１３１２でマニフェストファイルの解析を行った結果、「<intent-filter>」と「</intent-filter>」の間に「<category *andrd*:name="*andrd*.intent.category.LAUNCHER" />」が記述されている場合、マニフェストファイルにランチャーが登録されている。この場合、スマートフォンの待ち受け画面に表示されるアイコンをユーザがクリックしたときに、onCreateが呼び出されて実行されるため、個人情報取得APIまたは外部送信APIが自動的に実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されることを示す情報と、APIを実行するメソッドのメソッド名（onCreate）とを含む解析結果をアプリケーション判定部１３へ出力する。
【００７０】
また、ステップＳ１３１２でマニフェストファイルの解析を行った結果、マニフェストファイルにランチャーが登録されていることを確認できなかった場合、解析部１２は、onCreateを実行するメソッドとクラスを特定する（ステップＳ１３０７）。onCreate を構成要素とするクラスがActivityを継承している場合、onCreateは、他のメソッドからstartActivityというメソッド名で呼び出されて実行される。
【００７１】
ステップＳ１３０７において解析部１２は以下の処理を行う。onCreateを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）では、以下の３つの要件が満たされる。
第１の要件：「const-class」と、前の手順で特定したクラス名とが同一の行に記述されている。
第２の要件：第１の要件を満たす行よりも下の行に「startActivity(L*andrd*/content/Intent;)V」が記述されている。
第３の要件：第１の要件を満たす行と、第２の要件を満たす行との間の行に「const-class」が記述されていない。
【００７２】
図１３は、onCreateを実行するメソッドが記述されたソースコードの一例を示している。前の手順で特定されたクラス名がcom/app/sample/classである場合、図１３に示すように、「const-class」と「com/app/sample/class」が同一の行に記述されている（第１の要件）。また、この行よりも下の行に「startActivity(L*andrd*/content/Intent;)V」が記述されている（第２の要件）。さらに、「const-class」と「com/app/sample/class」が記述されている行と、「startActivity(L*andrd*/content/Intent;)V」が記述されている行との間の行に「const-class」が記述されていない（第３の要件）。
【００７３】
解析部１２は、「.method」と「.end method」の間の部分で上記の３つの要件が満たされるか否かを判定する。上記の３つの要件が満たされる場合、解析部１２はステップＳ１３００と同様にして、onCreateを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００７４】
一方、ステップＳ１３１０で特定されたコンポーネントがBroadcastReceiverであった場合、解析部１２は、onCreateがBroadcastIntentによって呼び出されて実行されるか否かの確認を行うため、マニフェストファイル（*andrd*Manifest.xml）を解析する（ステップＳ１３１４）。BroadcastIntentによってメソッドを実行する方法には、OS標準で用意されているBroadcastIntentによってメソッドを実行する方法と、ユーザが作成したBroadcastIntentによってメソッドを実行する方法とがある。onCreateが、OS標準で用意されているBroadcastIntentによって実行される場合、アプリケーションの起動の有無にかかわらず、端末の状態変化によってBroadcastIntentが発行されるというイベントが発生したときに、onCreateが自動的に実行され、情報漏洩が発生する可能性がある。
【００７５】
図１４は、OSに標準で用意されているBroadcastIntent（以下、OS標準のBroadcastIntentと記載）の一例を示している。端末が起動したときに発行されるBOOT_COMPLETEDや、バッテリーの残量が変化したときに発行されるACTION_BATTERY_CHANGED等がある。
【００７６】
図１５はマニフェストファイルの記述の一例を示している。図１５に示すように、「<receiver」で始まるタグの中に、クラス名である「jp.kddilabs.helloservice.BCreceiver」が記述されている。また、「<receiver」で始まるタグと、これと対になるタグである「</receiver>」との間に、「<intent-filter>」と「</intent-filter>」のタグがある。また、「<intent-filter>」と「</intent-filter>」の間に、BroadcastIntent名を含む記述「<action *andrd*:name="*andrd*.intent.action.BOOT_COMPLETED" />」がある。
【００７７】
ステップＳ１３１４において解析部１２は以下の処理を行う。記憶部２には、OS標準のBroadcastIntentの名称が記録されたリストが格納されている。解析部１２は、マニフェストファイルにおいて、「<receiver」で始まり「</receiver>」で終わる記述の部分を抽出する。続いて、解析部１２は、抽出した部分において、「<receiver」と同一の行に、前の手順で特定したクラス名が記述されているか否かを判定する。「<receiver」と同一の行に、前の手順で特定したクラス名が記述されている場合、解析部１２は、抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されているか否かを判定する。抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されている場合、解析部１２は、記憶部２から上記のリストを読み出し、「<intent-filter>」と「</intent-filter>」の間に、リストに含まれるBroadcastIntent名が記述されているか否かを判定する。
【００７８】
ステップＳ１３１４に続いて、解析部１２は、マニフェストファイルにOS標準のBroadcastIntentが登録されているか否かを判定する（ステップＳ１３１５）。ステップＳ１３１４でマニフェストファイルの解析を行った結果、「<intent-filter>」と「</intent-filter>」の間に、リストに含まれるBroadcastIntent名が記述されている場合、マニフェストファイルにOS標準のBroadcastIntentが登録されている。この場合、端末で所定の状態変化が発生したときに、onCreateが呼び出されて実行されるため、個人情報取得APIまたは外部送信APIが自動的に実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されることを示す情報と、APIを実行するメソッドのメソッド名（onCreate）とを含む解析結果をアプリケーション判定部１３へ出力する。
【００７９】
また、ステップＳ１３１４でマニフェストファイルの解析を行った結果、マニフェストファイルにOS標準のBroadcastIntentが登録されていることを確認できなかった場合、解析部１２は、onCreateを実行するメソッドとクラスを特定する（ステップＳ１３０７）。onCreate を構成要素とするクラスがBroadcastReceiverを継承している場合、onCreateは、ユーザが作成したBroadcastIntentによって実行される。ユーザが作成したBroadcastIntent によってonCreate が実行される場合、APIの実行の起点となるイベントが不明であるため、さらに解析を行う必要がある。
【００８０】
図１６は、ユーザが作成したBroadcastIntentによってonCreateを実行するメソッドが記述されたソースコードの一例を示している。ユーザが定義しているBroadcastIntentの名称がORIGINAL_BROADCASTである場合、図１６に示すように、onCreateを実行するメソッドが記述されている部分（「.method」と「.end method」の間の部分）では、ユーザが定義したメソッド名である「ORIGINAL_BROADCAST」と、BroadcastIntentを発行するメソッドである「sendBroadcast」とが記述されている。
【００８１】
ステップＳ１３０７において解析部１２は以下の処理を行う。記憶部２には、OS標準で用意されているBroadcastIntentの名称が記録されたリストが格納されている。解析部１２は、マニフェストファイルにおいて、ステップＳ１３１４で解析を行った部分の「<intent-filter>」と「</intent-filter>」の間の部分から、上記のリストに含まれていないBroadcastIntent名を抽出する。
【００８２】
続いて、解析部１２は、ソースコードにおいて、「.method」と「.end method」の間の部分に、抽出したBroadcastIntent名と「sendBroadcast」が記述されているか否かを判定する。「.method」と「.end method」の間の部分に、抽出したBroadcastIntent名と「sendBroadcast」が記述されている場合、解析部１２はステップＳ１３００と同様にして、onCreateを実行するメソッドとクラスを特定する。ステップＳ１３０７の処理が終了すると、ステップＳ１３０８の処理が行われる。
【００８３】
一方、ステップＳ１３０３において、前の手順で特定したメソッドがonCreateでなかった場合、解析部１２は、前の手順で特定したメソッドがonStart，onRestart，onResume，onPause，onStop，onDestroy，onUnbind，onRebindのいずれかであるか否かを判定する（ステップＳ１３０４）。これらのメソッドは、アプリケーションのライフサイクルに関するメソッドである。
【００８４】
前の手順で特定したメソッドがonStart，onRestart，onResume，onPause，onStop，onDestroy，onUnbind，onRebindのいずれかである場合、アプリケーションのライフサイクルに関する状態変化というイベントが発生したときに、これらのメソッドが呼び出されて実行されるため、個人情報取得APIまたは外部送信APIが自動的に実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されることを示す情報と、APIを実行するメソッドのメソッド名（onStart等）とを含む解析結果をアプリケーション判定部１３へ出力する。
【００８５】
また、前の手順で特定したメソッドがonStart，onRestart，onResume，onPause，onStop，onDestroy，onUnbind，onRebindのどれでもなかった場合、解析部１２は、前の手順で特定したメソッドがonClickであるか否かを判定する（ステップＳ１３０５）。onClickは、端末上のユーザインタフェースの画面に表示されるボタンをユーザが押した際に呼び出されて実行されるメソッドである。前の手順で特定したメソッドがonClickである場合、ユーザがボタンを押すというイベントが発生したときにAPIが実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されないことを示す情報とを含む解析結果をアプリケーション判定部１３へ出力する。
【００８６】
また、前の手順で特定したメソッドがonClickでなかった場合、解析部１２は、前の手順で特定したメソッドがonItemClickであるか否かを判定する（ステップＳ１３０６）。onItemClickは、端末上の画面に表示されるリストの項目をユーザが選択した際に呼び出されて実行されるメソッドである。前の手順で特定したメソッドがonItemClickである場合、ユーザがリストの項目を選択するというイベントが発生したときにAPIが実行される。この場合、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されないことを示す情報とを含む解析結果をアプリケーション判定部１３へ出力する。
【００８７】
また、前の手順で特定したメソッドがonItemClickでなかった場合、解析部１２は、ステップＳ１３００と同様にして、前の手順で特定したメソッドを実行するメソッドとクラスを特定する（ステップＳ１３０７）。続いて、解析部１２は、前の手順で特定したメソッドを実行するメソッドが存在するか否かを判定する（ステップＳ１３０８）。
【００８８】
ステップＳ１３０７において、前の手順で特定したメソッドを実行するメソッドとクラスを特定できなかった場合、APIが呼び出されて実行されることはないため、解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPIのメソッド名と、APIが自動的に実行されないことを示す情報とを含む解析結果をアプリケーション判定部１３へ出力する。また、ステップＳ１３０７において、前の手順で特定したメソッドを実行するメソッドとクラスを特定できた場合、処理はステップＳ１３０１に進む。図６および図７に示す手順に従って解析を行うことにより、アプリケーションが起動している状態でユーザが端末上で行う操作に起因せずにAPIが自動的に実行されるのか否かを判別することができる。
【００８９】
次に、ステップＳ１４０におけるアプリケーションの良性／悪性の判定方法を説明する。前述したように、解析部１２は解析結果をアプリケーション判定部１３へ出力する。解析部１２は、ステップＳ１１０でAPI抽出部１１によって抽出されたAPI毎に解析を行うので、API毎の解析結果がアプリケーション判定部１３へ出力される。
【００９０】
ステップＳ１１０において、個人情報取得APIと外部送信APIのうちの少なくとも一方が抽出されなかった場合、アプリケーション判定部１３は、解析対象のアプリケーションが良性であると判定する。また、ステップＳ１３０における解析が行われて解析部１２から解析結果が出力された場合、アプリケーション判定部１３は解析結果に基づいて以下のようにアプリケーションの良性／悪性を判定する。
【００９１】
個人情報取得APIと外部送信APIのうちの少なくとも一方について、APIが自動的に実行されないことを示す情報を含む解析結果が出力された場合、個人情報取得APIと外部送信APIのうちの少なくとも一方は実行されない、あるいは個人情報取得APIと外部送信APIのうちの少なくとも一方はアプリケーション起動後のユーザの操作によって実行されるので情報漏洩の危険度は低いと推定できる。この場合、アプリケーション判定部１３は、解析対象のアプリケーションが良性であると判定する。
【００９２】
また、個人情報取得APIと外部送信APIの両方について、APIが自動的に実行されることを示す情報を含む解析結果が出力された場合、アプリケーション判定部１３は、個人情報取得APIを実行するメソッドのメソッド名と、外部送信APIを実行するメソッドのメソッド名とが一致するか否かを確認する。両者が一致しなかった場合、個人情報取得APIと外部送信APIは自動的に実行されるが、両者の実行の起点となるメソッドは異なり、両者の実行の関連性は低いので、情報漏洩の危険度は低いと推定できる。この場合、アプリケーション判定部１３は、解析対象のアプリケーションが良性であると判定する。
【００９３】
これに対して、両者が一致した場合、同一のメソッドを起点として個人情報取得APIと外部送信APIが自動的に実行されるので、情報漏洩の危険度が高いと推定できる。この場合、アプリケーション判定部１３は、解析対象のアプリケーションが悪性であると判定する。つまり、個人情報取得APIと外部送信APIが同一のメソッドによって自動的に実行される場合に解析対象のアプリケーションが悪性であると判定され、それ以外の場合には解析対象のアプリケーションが良性であると判定される。
【００９４】
上述したように、本実施形態によれば、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて情報の取得と送信を自動的に実行する悪性アプリケーションを検知することができる。このため、ユーザが情報の利用を承諾するために端末上で行う操作に起因するイベントの発生に基づいて情報の取得と送信を実行するアプリケーションを悪性アプリケーションとは区別することが可能となるので、悪性アプリケーションの誤検知を低減することができる。
【００９５】
また、ソースコードの解析において、APIを実行するメソッドを特定しても、特定したメソッドのメソッド名（onBind等）だけからはAPIの実行の起点となるイベントを判別することができない場合に、APIを実行するメソッドを実行する他のメソッドを特定することによって、APIの実行の起点となるイベントを判別できる可能性が高まる。このため、悪性アプリケーションの検知漏れを低減することができる。
【００９６】
また、onBind等の所定のメソッドに関しては、他のメソッドが所定のメソッドを指定するときのメソッド名と所定のメソッドのメソッド名とが異なるが、このようにメソッド名が異なる場合があることを考慮して、APIを実行する他のメソッドを特定することによって、APIの実行の起点となるイベントを判別できる可能性が高まる。このため、悪性アプリケーションの検知漏れを低減することができる。
【００９７】
また、onCreateに関しては、マニフェストファイルに基づいて、onCreateが、スマートフォンの待ち受け画面に表示されるアイコンがクリックされた際に最初に実行されるランチャーから呼び出されて実行されるか否か、あるいは端末の状態変化に基づいてOS標準のBroadcastIntentによって呼び出されて実行されるか否かを確認することによって、APIが自動的に実行されるか否かを確認することができる。
【００９８】
また、特定したメソッドが、アプリケーションの状態遷移に関係する所定のメソッド（onStart等）であるか否かを判定することによって、APIが自動的に実行されるか否かを確認することができる。
【００９９】
上述したアプリケーション解析装置は、その動作および機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませ、実行させることにより、実現される。ここで、「コンピュータ」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（ＲＡＭ）のように、一定時間プログラムを保持しているものも含むものとする。
【０１００】
また、上述したプログラムは、このプログラムを記憶装置等に格納したコンピュータから、伝送媒体を介して、あるいは伝送媒体中の伝送波により他のコンピュータに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように、情報を伝送する機能を有する媒体のことをいう。また、上述したプログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能を、コンピュータに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。
【０１０１】
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成は上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【符号の説明】
【０１０２】
１・・・アプリケーション解析部、２・・・記憶部、１０・・・ディスアセンブル部、１１・・・API抽出部、１２・・・解析部、１３・・・アプリケーション判定部、１４・・・制御部
【特許請求の範囲】
【請求項１】
解析対象のアプリケーションの実行コードをディスアセンブルし、前記実行コードに対応するソースコードを得るディスアセンブル部と、
端末内の情報を取得する第１のAPI（Application Program Interface）および情報を外部の機器へ送信する第２のAPIを前記ソースコードから抽出する抽出部と、
前記ソースコードを解析し、前記抽出部によって抽出されたAPIを実行するメソッドを特定し、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定する解析部と、
前記第１のAPIおよび前記第２のAPIが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されると判定された場合に、前記解析対象のアプリケーションが悪性であると判定する判定部と、
を備えたことを特徴とするアプリケーション解析装置。
【請求項２】
前記解析部は、前記ソースコードを解析し、前記抽出部によって抽出されたAPIを実行するメソッドを特定し、さらに、特定したメソッドを実行する他のメソッドを特定し、特定した他のメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定することを特徴とする請求項１に記載のアプリケーション解析装置。
【請求項３】
メソッドが所定のメソッドを指定するときのメソッド名と前記所定のメソッドのメソッド名とが異なるソースコードから生成されたアプリケーションが解析対象である場合に、前記解析部は、特定したメソッドが前記所定のメソッドであれば、前記所定のメソッドを指定するときのメソッド名に基づいて前記他のメソッドを特定することを特徴とする請求項２に記載のアプリケーション解析装置。
【請求項４】
前記解析部は、アプリケーションが利用する機能や権限を規定したマニフェストファイルに基づいて、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定することを特徴とする請求項１〜請求項３のいずれか一項に記載のアプリケーション解析装置。
【請求項５】
前記解析部は、特定したメソッドが、アプリケーションを起動するためにユーザが端末上で操作を行ったときに実行されるか否かを判定することを特徴とする請求項４に記載のアプリケーション解析装置。
【請求項６】
前記解析部は、特定したメソッドが、端末の状態変化に基づいてブロードキャストされるインテントが発生したときに実行されるか否かを判定することを特徴とする請求項４に記載のアプリケーション解析装置。
【請求項７】
前記解析部は、特定したメソッドが、アプリケーションの状態遷移に関係するメソッドであるか否かを判定することを特徴とする請求項１に記載のアプリケーション解析装置。
【請求項８】
前記解析部は、特定した他のメソッドが、アプリケーションの状態遷移に関係するメソッドであるか否かを判定することを特徴とする請求項２に記載のアプリケーション解析装置。
【請求項９】
請求項１に記載のアプリケーション解析装置としてコンピュータを機能させるためのプログラム。
【請求項１】
解析対象のアプリケーションの実行コードをディスアセンブルし、前記実行コードに対応するソースコードを得るディスアセンブル部と、
端末内の情報を取得する第１のAPI（Application Program Interface）および情報を外部の機器へ送信する第２のAPIを前記ソースコードから抽出する抽出部と、
前記ソースコードを解析し、前記抽出部によって抽出されたAPIを実行するメソッドを特定し、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定する解析部と、
前記第１のAPIおよび前記第２のAPIが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されると判定された場合に、前記解析対象のアプリケーションが悪性であると判定する判定部と、
を備えたことを特徴とするアプリケーション解析装置。
【請求項２】
前記解析部は、前記ソースコードを解析し、前記抽出部によって抽出されたAPIを実行するメソッドを特定し、さらに、特定したメソッドを実行する他のメソッドを特定し、特定した他のメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定することを特徴とする請求項１に記載のアプリケーション解析装置。
【請求項３】
メソッドが所定のメソッドを指定するときのメソッド名と前記所定のメソッドのメソッド名とが異なるソースコードから生成されたアプリケーションが解析対象である場合に、前記解析部は、特定したメソッドが前記所定のメソッドであれば、前記所定のメソッドを指定するときのメソッド名に基づいて前記他のメソッドを特定することを特徴とする請求項２に記載のアプリケーション解析装置。
【請求項４】
前記解析部は、アプリケーションが利用する機能や権限を規定したマニフェストファイルに基づいて、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定することを特徴とする請求項１〜請求項３のいずれか一項に記載のアプリケーション解析装置。
【請求項５】
前記解析部は、特定したメソッドが、アプリケーションを起動するためにユーザが端末上で操作を行ったときに実行されるか否かを判定することを特徴とする請求項４に記載のアプリケーション解析装置。
【請求項６】
前記解析部は、特定したメソッドが、端末の状態変化に基づいてブロードキャストされるインテントが発生したときに実行されるか否かを判定することを特徴とする請求項４に記載のアプリケーション解析装置。
【請求項７】
前記解析部は、特定したメソッドが、アプリケーションの状態遷移に関係するメソッドであるか否かを判定することを特徴とする請求項１に記載のアプリケーション解析装置。
【請求項８】
前記解析部は、特定した他のメソッドが、アプリケーションの状態遷移に関係するメソッドであるか否かを判定することを特徴とする請求項２に記載のアプリケーション解析装置。
【請求項９】
請求項１に記載のアプリケーション解析装置としてコンピュータを機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１３−６５１６８（Ｐ２０１３−６５１６８Ａ）
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願番号】特願２０１１−２０３０１０（Ｐ２０１１−２０３０１０）
【出願日】平成２３年９月１６日（２０１１．９．１６）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願日】平成２３年９月１６日（２０１１．９．１６）
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
[ Back to top ]