以下、図面を参照し、本発明の実施形態を説明する。本明細書および図面では、便宜上、必要に応じてAndroid(登録商標)という文字列を*Andrd*という文字列で代用し、java(登録商標)という文字列を*jv*という文字列で代用している。すなわち、*Andrd*という文字列はAndroid(登録商標)という文字列と等価であり、*jv*という文字列はjava(登録商標)という文字列と等価である。また、本明細書では、ソースコードに記述されるメソッド名等の文字列を記載するときに、「と」で文字列を囲んで示すことがある。例えば、本明細書では、「XXX」はXXXという文字列を示すものとする。
本実施形態によるアプリケーション解析装置は、解析対象のアプリケーションの実行コードをディスアセンブル(逆アセンブル)して得られるソースコード(ソースファイル)を解析し、端末に格納された個人情報を取得するAPI(以下、個人情報取得APIと記載)と、情報を外部の機器へ送信するAPI(以下、外部送信APIと記載)とをソースコードから抽出する。また、本実施形態によるアプリケーション解析装置は、ソースコードから抽出した個人情報取得APIと外部送信APIを実行するメソッドを特定し、特定したメソッドが、ユーザが端末上で行う操作(アプリケーションを起動するための操作を除く)に起因しないイベントの発生に基づいて実行される場合に、解析対象のアプリケーションが悪性であると判定する。このようなイベントとして、端末の状態変化が発生したというイベントや、アプリケーションを起動する操作が行われたというイベント等がある。
本実施形態では、端末に格納された情報の利用を承諾(同意)するためにユーザが行う操作を直接的な発生原因としない特定のイベントが発生したときに個人情報取得APIと外部送信APIを自動的に実行するアプリケーションが悪性アプリケーション(情報漏洩アプリケーション)として検知される。このため、ユーザが行う承諾の操作に伴って個人情報取得APIと外部送信APIを実行するように構成されたアプリケーションを解析した場合には、解析対象のアプリケーションは悪性アプリケーションとして検知されない。したがって、良性アプリケーションを悪性アプリケーションとして誤検知する可能性を低減することができる。
本実施形態によるアプリケーション解析装置は、例えばスマートフォン用のアプリケーションを通信ネットワーク上で販売する販売サイトを管理する企業に設置される。また、本実施形態によるアプリケーション解析装置が行う解析のアルゴリズムをアンチウイルスソフトに適用することも可能である。したがって、ユーザが端末にインストールするアプリケーションを事前に審査することができる。
図1は、本実施形態によるアプリケーション解析装置の構成を示している。図1に示すように、アプリケーション解析装置は、アプリケーション解析部1および記憶部2を有する。
アプリケーション解析部1は、解析対象のアプリケーションの実行ファイルであるパッケージファイル(アプリケーションファイル)からディスアセンブルによりソースコードを取得し、取得したソースコードを解析して解析対象のアプリケーションの良性/悪性の判定を行う。パッケージファイルは、例えば拡張子が.apkのファイルであり、命令列を含む実行コード(例えば拡張子が.dex)、アプリケーションが利用する機能や権限が定義されたマニフェストファイル(例えば拡張子が.xml)、アプリケーションが利用するテキストファイルや画像ファイル等の各種リソースファイルを含む。記憶部2は、解析対象のアプリケーションのパッケージファイルを記憶するほか、個人情報取得APIおよび外部送信API等の情報が記録されたリストを記憶する。
アプリケーション解析部1は、ディスアセンブル部10、API抽出部11、解析部12、アプリケーション判定部13、および制御部14を有する。ディスアセンブル部10は、解析対象のアプリケーションの実行コードをディスアセンブル(逆アセンブル)し、実行コードに対応するソースコード(ソースファイル)を得る。API抽出部11は、ソースコードから個人情報取得APIと外部送信APIを抽出する。
解析部12は、ソースコードを解析し、API抽出部11によって抽出された個人情報取得APIと外部送信API のそれぞれを実行するメソッドを特定し、特定したメソッドが、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて実行されるか否かを判定する。アプリケーション判定部13は、解析部12がソースコードを解析した結果に基づいて、解析対象のアプリケーションの良性/悪性を判定する。制御部14は、アプリケーション解析部1における各部の動作を制御する。
次に、本実施形態におけるアプリケーションの解析手法の概念を説明する。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(登録商標)のトロイの木馬を他人の端末に導入させる手法として、不正な挙動が発生するように正規のアプリケーションを改竄し、そのアプリケーションをマーケットに公開するという手法がとられるという特徴がある。不正な挙動が発生するように正規のアプリケーションを改竄する簡単な手法として、以下の2つの手法がある。これまでに出現したトロイの木馬では、2つの手法のどちらかがとられていることが多い。
第1の手法は、個人情報の取得と情報の送信を行う正規のアプリケーションに対して、BroadcastReceiverを利用して、端末の状態変化が発生したときに不正な挙動が発生するように改竄を施す手法である。この手法は、正規のアプリケーションの実行コードを改竄せずにマニフェストファイルだけを改竄するだけで容易に実現できる。
第2の手法は、個人情報の取得と情報の送信を行う正規のアプリケーションのソースコードにおいて、アプリケーションが起動した際に最初に呼び出されて実行されるメソッドが記述されている箇所に、不正な挙動が発生するメソッドのコードを追記する手法である。アプリケーションが起動した際に最初に呼び出されるメソッドを解析することは容易であり、この手法は、数行のコードを挿入するという容易な手法で実現できる。
上記の2つの手法で改竄されたアプリケーションは、端末の状態変化の発生やアプリケーションの起動等の特定のイベントが発生した際に自動的に実行されるメソッドによって個人情報取得APIと外部送信APIが実行されるという特徴を有する。そこで、本実施形態では、この特徴を有するアプリケーションを悪性アプリケーションと判定する解析手法をとっている。
次に、本実施形態によるアプリケーション解析装置の動作を説明する。図2はアプリケーション解析装置の動作を示している。まず、ディスアセンブル部10は、記憶部2に格納されている解析対象のアプリケーションのパッケージファイルを読み出してディスアセンブルし、ソースコードを得る(ステップS100)。代表的なディスアセンブルツールであるapk-toolを用いてディスアセンブルを行うと、図3に示すように、パッケージファイル(Sample.apk)から、.smali形式のソースコード(Main$JsObj.smali等)と.xml形式のマニフェストファイル(*andrd*Manifest.xml)を得ることができる。
続いて、API抽出部11は、ステップS100で得られたソースコードに対して、個人情報取得APIと外部送信APIのメソッド名で検索を行い、個人情報取得APIと外部送信APIを抽出する(ステップS110)。図4は、代表的な個人情報取得APIを示している。端末を識別するIDであるIMEI(International Mobile Equipment Identity)を取得するメソッドであるgetDeviceIdや、端末のソフトウェアのバージョンを取得するメソッドであるgetDeviceSoftwareVersion、端末の電話番号を取得するメソッドであるgetLine1Number等が個人情報取得APIである。図5は、代表的な外部送信APIを示している。SMS(Short Message Service)を送信するメソッドであるsendTextMessage等が外部送信APIである。
記憶部2には、個人情報取得APIと外部送信APIのメソッド名が記録されたリストが格納されている。ステップS110では、API抽出部11はこのリストを記憶部2から読み出し、リストに含まれるメソッド名の文字列とソースコード中の文字列とを比較し、リストに含まれるメソッド名の文字列と一致する文字列を抽出する。また、API抽出部11はステップS110の処理結果を制御部14へ出力する。
続いて、制御部14は、ステップS110の処理結果に基づいて、個人情報取得APIと外部送信APIの両方が抽出された否かを判定する(ステップS120)。ステップS110において、個人情報取得APIのメソッド名の文字列と一致する文字列、外部送信APIのメソッド名の文字列と一致する文字列のうちの少なくとも一方が抽出されなかった場合、処理はステップS140に進む。また、ステップS110において、個人情報取得APIのメソッド名の文字列と一致する文字列、外部送信APIのメソッド名の文字列と一致する文字列のうちの両方が抽出された場合、制御部14は、抽出された個人情報取得APIのメソッド名と外部送信APIのメソッド名を解析部12に与え、ステップS100で得られたソースコードを解析部12に解析させる。
解析部12は、ソースコードを解析し、ステップS110で抽出された個人情報取得APIと外部送信API のそれぞれを実行するメソッドの解析を行う(ステップS130)。続いて、アプリケーション判定部13は、解析部12による解析の結果に基づいて、解析対象のアプリケーションの良性/悪性を判定する(ステップS140)。ステップS130,S140における処理の詳細な内容については、後述する。
図6および図7は、ステップS130におけるアプリケーション解析装置の詳細な動作を示している。解析部12は、API抽出部11によって抽出された個々のAPIに対応して、図6および図7に示す処理を実行する。図6および図7に示す処理では、ステップS100で得られた全てのソースコードが解析の対象となる。まず、解析部12は、APIを実行するメソッドとクラスを特定する(ステップS1300)。
図8はソースコードの一例を示している。APIは、「.method」と「public」、「private」、「static」、「synthetic」のいずれかと、メソッド名(図8では「onCreate」)とが記述されている行と、「.end method」が記述されている行との間に記述されている。ステップS1300において解析部12は以下の処理を行う。まず、解析部12は、ソースコードにおいてAPI名(図4および図5に示したメソッド名)を検索する。API名やメソッド名の検索は、文字列のマッチングにより行われる。これは、後述する各検索においても同様である。
API名を発見した場合、解析部12は、ソースコードにおいてAPI名が記述されている行よりも前の行において「.method」を検索し、「.method」が記述されている行からメソッド名(図8では「onCreate」)を抽出する。抽出したメソッド名を有するメソッドが、APIを実行するメソッドである。つまり、図8の例では、onCreateというメソッドが、個人情報取得APIであるgetDeviceIDを実行する。さらに、解析部12は、APIを実行するメソッドのメソッド名が記述されている行よりも前の行において、クラスを規定する文字列である「.class」を検索し、「.class」が記述されている行からクラス名(図8では「com/app/sample/Main_Activity」)を抽出する。
ステップS1300以外のステップにおいて、前の手順で特定したメソッドを実行するメソッドとクラスを特定する際にステップS1300と同様の処理を行う場合、上記のAPI名の代わりに、前の手順で特定したメソッドのメソッド名を使用して同様の処理を行い、メソッド名とクラス名を抽出すればよい。
ステップS1300に続いて、解析部12は、前の手順で特定したメソッドがonBindであるか否かを判定する(ステップS1301)。前の手順で特定したメソッドがonBindであった場合、解析部12は、onBindを実行するメソッドとクラスを特定する(ステップS1307)。
Android(登録商標) OSに対応したアプリケーションを生成するためのソースコードでは、アプリケーションのライフサイクルに関するメソッドのうち所定のメソッドの記述に特別な記述が用いられる。具体的には、あるメソッドが所定のメソッドを呼び出して実行することを記述している部分では、所定のメソッドのメソッド名とは異なる特別なメソッド名が指定される。例えば、onBindは、他のメソッドからBindServiceというメソッド名で呼び出されて実行される。
ステップS1307において解析部12は以下の処理を行う。onBindを実行するメソッドが記述されている部分(「.method」と「.end method」の間の部分)には、「BindService」と、前の手順でonBindと共に特定したクラス名との両方が記述されている。したがって、解析部12は、「.method」と「.end method」の間の部分において、「BindService」と、前の手順でonBindと共に特定したクラス名との両方を検索する。「.method」と「.end method」の間の部分において、「BindService」と、前の手順でonBindと共に特定したクラス名との両方が記述されていた場合、解析部12はステップS1300と同様にして、BindServiceを実行するメソッドとクラスを特定する。ステップS1307の処理が終了すると、ステップS1308の処理が行われる。
ステップS1301において、前の手順で特定したメソッドがonBindでなかった場合、解析部12は、前の手順で特定したメソッドがonActivityResultであるか否かを判定する(ステップS1302)。前の手順で特定したメソッドがonActivityResultであった場合、解析部12は、onActivityResultを実行するメソッドとクラスを特定する(ステップS1307)。onActivityResultは、アプリケーションのライフサイクルに関するメソッドであって、他のメソッドからstartActivityForResultというメソッド名で呼び出されて実行される。
ステップS1307において解析部12は以下の処理を行う。onActivityResultを実行するメソッドが記述されている部分(「.method」と「.end method」の間の部分)では、以下の3つの要件が満たされる。
第1の要件:「const-class」と、前の手順で特定したクラス名とが同一の行に記述されている。
第2の要件:第1の要件を満たす行よりも下の行に「startActivityForResult(L*andrd*/content/Intent;I)V」が記述されている。
第3の要件:第1の要件を満たす行と、第2の要件を満たす行との間の行に「const-class」が記述されていない。
図9は、onActivityResultを実行するメソッドが記述されたソースコードの一例を示している。前の手順で特定されたクラス名がcom/app/sample/classである場合、図9に示すように、「const-class」と「com/app/sample/class」が同一の行に記述されている(第1の要件)。また、この行よりも下の行に「startActivityForResult(L*andrd*/content/Intent;I)V」が記述されている(第2の要件)。さらに、「const-class」と「com/app/sample/class」が記述されている行と、「startActivityForResult(L*andrd*/content/Intent;I)V」が記述されている行との間の行に「const-class」が記述されていない(第3の要件)。
解析部12は、「.method」と「.end method」の間の部分で上記の3つの要件が満たされるか否かを判定する。上記の3つの要件が満たされる場合、解析部12はステップS1300と同様にして、onActivityResultを実行するメソッドとクラスを特定する。ステップS1307の処理が終了すると、ステップS1308の処理が行われる。
ステップS1302において、前の手順で特定したメソッドがonActivityResultでなかった場合、解析部12は、前の手順で特定したメソッドがonCreateであるか否かを判定する(ステップS1303)。onCreateは、アプリケーションのライフサイクルに関するメソッドであって、他のメソッドから所定のメソッド名で呼び出されて実行される。他のメソッドがonCreateを呼び出して実行するために指定する所定のメソッド名は、onCreateを構成要素とするクラスが継承するコンポーネントによって異なる。
図10は、ソースコードのうち、クラスが継承するコンポーネントが記述されている部分のみを示している。クラスが継承するコンポーネントが記述されることにより、そのクラスの構成要素であるメソッドはそのコンポーネントを利用することが可能となる。図10に示すように、クラスの宣言である「.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であった場合、解析部12は、特定したonCreateが記述されているソースコード(例えば、図8のソースコード)から、 onCreateを構成要素とするクラスが継承するコンポーネントを特定する(ステップS1310)。より具体的には、ステップS1310において解析部12は、前の手順で特定したonCreateとクラス名が記述されているソースコードにおいて、「.super」の後に記述されている文字列からコンポーネントを特定する。
続いて、ステップS1310で特定されたコンポーネントに応じて処理が分岐する(ステップS1311)。ステップS1310で特定されたコンポーネントがServiceであった場合、解析部12は、onCreateを実行するメソッドとクラスを特定する(ステップS1307)。onCreate を構成要素とするクラスがServiceを継承している場合、onCreateは、他のメソッドからstartServiceというメソッド名で呼び出されて実行される。
ステップS1307において解析部12は以下の処理を行う。onCreateを実行するメソッドが記述されている部分(「.method」と「.end method」の間の部分)では、以下の3つの要件が満たされる。
第1の要件:「const-class」と、前の手順で特定したクラス名とが同一の行に記述されている。
第2の要件:第1の要件を満たす行よりも下の行に「startService(L*andrd*/content/Intent;)L*andrd*/content/ComponentName」が記述されている。
第3の要件:第1の要件を満たす行と、第2の要件を満たす行との間の行に「const-class」が記述されていない。
図11は、onCreateを実行するメソッドが記述されたソースコードの一例を示している。前の手順で特定されたクラス名がcom/app/sample/classである場合、図11に示すように、「const-class」と「com/app/sample/class」が同一の行に記述されている(第1の要件)。また、この行よりも下の行に「startService(L*andrd*/content/Intent;)L*andrd*/content/ComponentName」が記述されている(第2の要件)。さらに、「const-class」と「com/app/sample/class」が記述されている行と、「startService(L*andrd*/content/Intent;)L*andrd*/content/ComponentName」が記述されている行との間の行に「const-class」が記述されていない(第3の要件)。
解析部12は、「.method」と「.end method」の間の部分で上記の3つの要件が満たされるか否かを判定する。上記の3つの要件が満たされる場合、解析部12はステップS1300と同様にして、onCreateを実行するメソッドとクラスを特定する。ステップS1307の処理が終了すると、ステップS1308の処理が行われる。
一方、ステップS1310で特定されたコンポーネントがActivityであった場合、解析部12は、onCreateがランチャーから呼び出されて実行されるか否かの確認を行うため、マニフェストファイル(*andrd*Manifest.xml)を解析する(ステップS1312)。前述したように、マニフェストファイルは、アプリケーションが利用する機能や権限を定義しているファイルである。ランチャーとは、ユーザがアプリケーションを起動するため、スマートフォンの待ち受け画面に表示されるアイコンをクリックした際に最初に実行されるプログラムの箇所である。onCreateがランチャーから呼び出されて実行される場合、ユーザが待ち受け画面上のアイコンをクリックしたというイベントが発生したときに、onCreateが自動的に実行され、情報漏洩が発生する可能性がある。
図12はマニフェストファイルの記述の一例を示している。図12に示すように、「<activity」で始まるタグの中に、クラス名である「com.app.sample.Example_Activity」が記述されている。また、「<activity」で始まるタグと、これと対になるタグである「</activity>」との間に、「<intent-filter>」と「</intent-filter>」のタグがある。また、「<intent-filter>」と「</intent-filter>」の間に、ランチャーに関する記述「<category *andrd*:name="*andrd*.intent.category.LAUNCHER" />」がある。
ステップS1312において解析部12は以下の処理を行う。解析部12は、マニフェストファイルにおいて、「<activity」で始まり「</activity>」で終わる記述の部分を抽出する。続いて、解析部12は、抽出した部分において、「<activity」と同一の行に、前の手順で特定したクラス名が記述されているか否かを判定する。「<activity」と同一の行に、前の手順で特定したクラス名が記述されている場合、解析部12は、抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されているか否かを判定する。抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されている場合、解析部12は、「<intent-filter>」と「</intent-filter>」の間に「<category *andrd*:name="*andrd*.intent.category.LAUNCHER" />」が記述されているか否かを判定する。
ステップS1312に続いて、解析部12は、マニフェストファイルにランチャーが登録されているか否かを判定する(ステップS1313)。ステップS1312でマニフェストファイルの解析を行った結果、「<intent-filter>」と「</intent-filter>」の間に「<category *andrd*:name="*andrd*.intent.category.LAUNCHER" />」が記述されている場合、マニフェストファイルにランチャーが登録されている。この場合、スマートフォンの待ち受け画面に表示されるアイコンをユーザがクリックしたときに、onCreateが呼び出されて実行されるため、個人情報取得APIまたは外部送信APIが自動的に実行される。この場合、解析部12は、ステップS110でAPI抽出部11によって抽出されたAPIのメソッド名と、APIが自動的に実行されることを示す情報と、APIを実行するメソッドのメソッド名(onCreate)とを含む解析結果をアプリケーション判定部13へ出力する。
また、ステップS1312でマニフェストファイルの解析を行った結果、マニフェストファイルにランチャーが登録されていることを確認できなかった場合、解析部12は、onCreateを実行するメソッドとクラスを特定する(ステップS1307)。onCreate を構成要素とするクラスがActivityを継承している場合、onCreateは、他のメソッドからstartActivityというメソッド名で呼び出されて実行される。
ステップS1307において解析部12は以下の処理を行う。onCreateを実行するメソッドが記述されている部分(「.method」と「.end method」の間の部分)では、以下の3つの要件が満たされる。
第1の要件:「const-class」と、前の手順で特定したクラス名とが同一の行に記述されている。
第2の要件:第1の要件を満たす行よりも下の行に「startActivity(L*andrd*/content/Intent;)V」が記述されている。
第3の要件:第1の要件を満たす行と、第2の要件を満たす行との間の行に「const-class」が記述されていない。
図13は、onCreateを実行するメソッドが記述されたソースコードの一例を示している。前の手順で特定されたクラス名がcom/app/sample/classである場合、図13に示すように、「const-class」と「com/app/sample/class」が同一の行に記述されている(第1の要件)。また、この行よりも下の行に「startActivity(L*andrd*/content/Intent;)V」が記述されている(第2の要件)。さらに、「const-class」と「com/app/sample/class」が記述されている行と、「startActivity(L*andrd*/content/Intent;)V」が記述されている行との間の行に「const-class」が記述されていない(第3の要件)。
解析部12は、「.method」と「.end method」の間の部分で上記の3つの要件が満たされるか否かを判定する。上記の3つの要件が満たされる場合、解析部12はステップS1300と同様にして、onCreateを実行するメソッドとクラスを特定する。ステップS1307の処理が終了すると、ステップS1308の処理が行われる。
一方、ステップS1310で特定されたコンポーネントがBroadcastReceiverであった場合、解析部12は、onCreateがBroadcastIntentによって呼び出されて実行されるか否かの確認を行うため、マニフェストファイル(*andrd*Manifest.xml)を解析する(ステップS1314)。BroadcastIntentによってメソッドを実行する方法には、OS標準で用意されているBroadcastIntentによってメソッドを実行する方法と、ユーザが作成したBroadcastIntentによってメソッドを実行する方法とがある。onCreateが、OS標準で用意されているBroadcastIntentによって実行される場合、アプリケーションの起動の有無にかかわらず、端末の状態変化によってBroadcastIntentが発行されるというイベントが発生したときに、onCreateが自動的に実行され、情報漏洩が発生する可能性がある。
図14は、OSに標準で用意されているBroadcastIntent(以下、OS標準のBroadcastIntentと記載)の一例を示している。端末が起動したときに発行されるBOOT_COMPLETEDや、バッテリーの残量が変化したときに発行されるACTION_BATTERY_CHANGED等がある。
図15はマニフェストファイルの記述の一例を示している。図15に示すように、「<receiver」で始まるタグの中に、クラス名である「jp.kddilabs.helloservice.BCreceiver」が記述されている。また、「<receiver」で始まるタグと、これと対になるタグである「</receiver>」との間に、「<intent-filter>」と「</intent-filter>」のタグがある。また、「<intent-filter>」と「</intent-filter>」の間に、BroadcastIntent名を含む記述「<action *andrd*:name="*andrd*.intent.action.BOOT_COMPLETED" />」がある。
ステップS1314において解析部12は以下の処理を行う。記憶部2には、OS標準のBroadcastIntentの名称が記録されたリストが格納されている。解析部12は、マニフェストファイルにおいて、「<receiver」で始まり「</receiver>」で終わる記述の部分を抽出する。続いて、解析部12は、抽出した部分において、「<receiver」と同一の行に、前の手順で特定したクラス名が記述されているか否かを判定する。「<receiver」と同一の行に、前の手順で特定したクラス名が記述されている場合、解析部12は、抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されているか否かを判定する。抽出した部分に「<intent-filter>」と「</intent-filter>」が記述されている場合、解析部12は、記憶部2から上記のリストを読み出し、「<intent-filter>」と「</intent-filter>」の間に、リストに含まれるBroadcastIntent名が記述されているか否かを判定する。
ステップS1314に続いて、解析部12は、マニフェストファイルにOS標準のBroadcastIntentが登録されているか否かを判定する(ステップS1315)。ステップS1314でマニフェストファイルの解析を行った結果、「<intent-filter>」と「</intent-filter>」の間に、リストに含まれるBroadcastIntent名が記述されている場合、マニフェストファイルにOS標準のBroadcastIntentが登録されている。この場合、端末で所定の状態変化が発生したときに、onCreateが呼び出されて実行されるため、個人情報取得APIまたは外部送信APIが自動的に実行される。この場合、解析部12は、ステップS110でAPI抽出部11によって抽出されたAPIのメソッド名と、APIが自動的に実行されることを示す情報と、APIを実行するメソッドのメソッド名(onCreate)とを含む解析結果をアプリケーション判定部13へ出力する。
また、ステップS1314でマニフェストファイルの解析を行った結果、マニフェストファイルにOS標準のBroadcastIntentが登録されていることを確認できなかった場合、解析部12は、onCreateを実行するメソッドとクラスを特定する(ステップS1307)。onCreate を構成要素とするクラスがBroadcastReceiverを継承している場合、onCreateは、ユーザが作成したBroadcastIntentによって実行される。ユーザが作成したBroadcastIntent によってonCreate が実行される場合、APIの実行の起点となるイベントが不明であるため、さらに解析を行う必要がある。
図16は、ユーザが作成したBroadcastIntentによってonCreateを実行するメソッドが記述されたソースコードの一例を示している。ユーザが定義しているBroadcastIntentの名称がORIGINAL_BROADCASTである場合、図16に示すように、onCreateを実行するメソッドが記述されている部分(「.method」と「.end method」の間の部分)では、ユーザが定義したメソッド名である「ORIGINAL_BROADCAST」と、BroadcastIntentを発行するメソッドである「sendBroadcast」とが記述されている。
ステップS1307において解析部12は以下の処理を行う。記憶部2には、OS標準で用意されているBroadcastIntentの名称が記録されたリストが格納されている。解析部12は、マニフェストファイルにおいて、ステップS1314で解析を行った部分の「<intent-filter>」と「</intent-filter>」の間の部分から、上記のリストに含まれていないBroadcastIntent名を抽出する。
続いて、解析部12は、ソースコードにおいて、「.method」と「.end method」の間の部分に、抽出したBroadcastIntent名と「sendBroadcast」が記述されているか否かを判定する。「.method」と「.end method」の間の部分に、抽出したBroadcastIntent名と「sendBroadcast」が記述されている場合、解析部12はステップS1300と同様にして、onCreateを実行するメソッドとクラスを特定する。ステップS1307の処理が終了すると、ステップS1308の処理が行われる。
一方、ステップS1303において、前の手順で特定したメソッドがonCreateでなかった場合、解析部12は、前の手順で特定したメソッドがonStart,onRestart,onResume,onPause,onStop,onDestroy,onUnbind,onRebindのいずれかであるか否かを判定する(ステップS1304)。これらのメソッドは、アプリケーションのライフサイクルに関するメソッドである。
前の手順で特定したメソッドがonStart,onRestart,onResume,onPause,onStop,onDestroy,onUnbind,onRebindのいずれかである場合、アプリケーションのライフサイクルに関する状態変化というイベントが発生したときに、これらのメソッドが呼び出されて実行されるため、個人情報取得APIまたは外部送信APIが自動的に実行される。この場合、解析部12は、ステップS110でAPI抽出部11によって抽出されたAPIのメソッド名と、APIが自動的に実行されることを示す情報と、APIを実行するメソッドのメソッド名(onStart等)とを含む解析結果をアプリケーション判定部13へ出力する。
また、前の手順で特定したメソッドがonStart,onRestart,onResume,onPause,onStop,onDestroy,onUnbind,onRebindのどれでもなかった場合、解析部12は、前の手順で特定したメソッドがonClickであるか否かを判定する(ステップS1305)。onClickは、端末上のユーザインタフェースの画面に表示されるボタンをユーザが押した際に呼び出されて実行されるメソッドである。前の手順で特定したメソッドがonClickである場合、ユーザがボタンを押すというイベントが発生したときにAPIが実行される。この場合、解析部12は、ステップS110でAPI抽出部11によって抽出されたAPIのメソッド名と、APIが自動的に実行されないことを示す情報とを含む解析結果をアプリケーション判定部13へ出力する。
また、前の手順で特定したメソッドがonClickでなかった場合、解析部12は、前の手順で特定したメソッドがonItemClickであるか否かを判定する(ステップS1306)。onItemClickは、端末上の画面に表示されるリストの項目をユーザが選択した際に呼び出されて実行されるメソッドである。前の手順で特定したメソッドがonItemClickである場合、ユーザがリストの項目を選択するというイベントが発生したときにAPIが実行される。この場合、解析部12は、ステップS110でAPI抽出部11によって抽出されたAPIのメソッド名と、APIが自動的に実行されないことを示す情報とを含む解析結果をアプリケーション判定部13へ出力する。
また、前の手順で特定したメソッドがonItemClickでなかった場合、解析部12は、ステップS1300と同様にして、前の手順で特定したメソッドを実行するメソッドとクラスを特定する(ステップS1307)。続いて、解析部12は、前の手順で特定したメソッドを実行するメソッドが存在するか否かを判定する(ステップS1308)。
ステップS1307において、前の手順で特定したメソッドを実行するメソッドとクラスを特定できなかった場合、APIが呼び出されて実行されることはないため、解析部12は、ステップS110でAPI抽出部11によって抽出されたAPIのメソッド名と、APIが自動的に実行されないことを示す情報とを含む解析結果をアプリケーション判定部13へ出力する。また、ステップS1307において、前の手順で特定したメソッドを実行するメソッドとクラスを特定できた場合、処理はステップS1301に進む。図6および図7に示す手順に従って解析を行うことにより、アプリケーションが起動している状態でユーザが端末上で行う操作に起因せずにAPIが自動的に実行されるのか否かを判別することができる。
次に、ステップS140におけるアプリケーションの良性/悪性の判定方法を説明する。前述したように、解析部12は解析結果をアプリケーション判定部13へ出力する。解析部12は、ステップS110でAPI抽出部11によって抽出されたAPI毎に解析を行うので、API毎の解析結果がアプリケーション判定部13へ出力される。
ステップS110において、個人情報取得APIと外部送信APIのうちの少なくとも一方が抽出されなかった場合、アプリケーション判定部13は、解析対象のアプリケーションが良性であると判定する。また、ステップS130における解析が行われて解析部12から解析結果が出力された場合、アプリケーション判定部13は解析結果に基づいて以下のようにアプリケーションの良性/悪性を判定する。
個人情報取得APIと外部送信APIのうちの少なくとも一方について、APIが自動的に実行されないことを示す情報を含む解析結果が出力された場合、個人情報取得APIと外部送信APIのうちの少なくとも一方は実行されない、あるいは個人情報取得APIと外部送信APIのうちの少なくとも一方はアプリケーション起動後のユーザの操作によって実行されるので情報漏洩の危険度は低いと推定できる。この場合、アプリケーション判定部13は、解析対象のアプリケーションが良性であると判定する。
また、個人情報取得APIと外部送信APIの両方について、APIが自動的に実行されることを示す情報を含む解析結果が出力された場合、アプリケーション判定部13は、個人情報取得APIを実行するメソッドのメソッド名と、外部送信APIを実行するメソッドのメソッド名とが一致するか否かを確認する。両者が一致しなかった場合、個人情報取得APIと外部送信APIは自動的に実行されるが、両者の実行の起点となるメソッドは異なり、両者の実行の関連性は低いので、情報漏洩の危険度は低いと推定できる。この場合、アプリケーション判定部13は、解析対象のアプリケーションが良性であると判定する。
これに対して、両者が一致した場合、同一のメソッドを起点として個人情報取得APIと外部送信APIが自動的に実行されるので、情報漏洩の危険度が高いと推定できる。この場合、アプリケーション判定部13は、解析対象のアプリケーションが悪性であると判定する。つまり、個人情報取得APIと外部送信APIが同一のメソッドによって自動的に実行される場合に解析対象のアプリケーションが悪性であると判定され、それ以外の場合には解析対象のアプリケーションが良性であると判定される。
上述したように、本実施形態によれば、アプリケーションの起動している状態でユーザが端末上で行う操作に起因しないイベントの発生に基づいて情報の取得と送信を自動的に実行する悪性アプリケーションを検知することができる。このため、ユーザが情報の利用を承諾するために端末上で行う操作に起因するイベントの発生に基づいて情報の取得と送信を実行するアプリケーションを悪性アプリケーションとは区別することが可能となるので、悪性アプリケーションの誤検知を低減することができる。
また、ソースコードの解析において、APIを実行するメソッドを特定しても、特定したメソッドのメソッド名(onBind等)だけからはAPIの実行の起点となるイベントを判別することができない場合に、APIを実行するメソッドを実行する他のメソッドを特定することによって、APIの実行の起点となるイベントを判別できる可能性が高まる。このため、悪性アプリケーションの検知漏れを低減することができる。
また、onBind等の所定のメソッドに関しては、他のメソッドが所定のメソッドを指定するときのメソッド名と所定のメソッドのメソッド名とが異なるが、このようにメソッド名が異なる場合があることを考慮して、APIを実行する他のメソッドを特定することによって、APIの実行の起点となるイベントを判別できる可能性が高まる。このため、悪性アプリケーションの検知漏れを低減することができる。
また、onCreateに関しては、マニフェストファイルに基づいて、onCreateが、スマートフォンの待ち受け画面に表示されるアイコンがクリックされた際に最初に実行されるランチャーから呼び出されて実行されるか否か、あるいは端末の状態変化に基づいてOS標準のBroadcastIntentによって呼び出されて実行されるか否かを確認することによって、APIが自動的に実行されるか否かを確認することができる。
また、特定したメソッドが、アプリケーションの状態遷移に関係する所定のメソッド(onStart等)であるか否かを判定することによって、APIが自動的に実行されるか否かを確認することができる。
上述したアプリケーション解析装置は、その動作および機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータに読み込ませ、実行させることにより、実現される。ここで、「コンピュータ」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ(RAM)のように、一定時間プログラムを保持しているものも含むものとする。
また、上述したプログラムは、このプログラムを記憶装置等に格納したコンピュータから、伝送媒体を介して、あるいは伝送媒体中の伝送波により他のコンピュータに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク(通信網)や電話回線等の通信回線(通信線)のように、情報を伝送する機能を有する媒体のことをいう。また、上述したプログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、前述した機能を、コンピュータに既に記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル(差分プログラム)であってもよい。
以上、図面を参照して本発明の実施形態について詳述してきたが、具体的な構成は上記の実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。