JP2020531936A - アプリケーションの脆弱点を探知する方法およびシステム - Google Patents

Abstract

【課題】 アプリケーションの脆弱点を探知する方法およびシステムを提供する。【解決手段】 脆弱点探知方法は、アプリケーションのインストールおよび実行のためのパッケージファイルが含むファイルと、該ファイルが含むコードのうちの少なくとも一方と関連し、アプリケーションの脆弱点診断のための予め設定された探知パターンを管理する段階、アプリケーションのインストールおよび実行のために利用者に配布するためのパッケージファイルを登録する段階、および探知パターンのうちの少なくとも１つの探知パターンによって、登録されたパッケージファイルを分析し、少なくとも１つの探知パターン別に脆弱点情報を探知する段階を含む。【選択図】 図７

Description

以下の説明は、アプリケーションの脆弱点を探知する方法およびシステム、コンピュータと結合して脆弱点探知方法をコンピュータに実行させるためのコンピュータプログラムが記録されるコンピュータ読み取り可能な記録媒体およびそのコンピュータプログラムに関する。

アプリストア（Ａｐｐ ｓｔｏｒｅ）とは、スマートフォンのような端末に搭載することのできる多様なアプリケーションを販売するオンライン上のコンテンツマーケットである。例えば、アプリケーションの開発者は、開発したアプリケーションを端末にインストールするためのファイル（一例として、アンドロイド（登録商標）アプリケーションパッケージ（Ａｎｄｒｏｉｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｃｋａｇｅ：ＡＰＫ））をアプリストアに登録し、アプリケーションの利用者は、アプリストアから必要なアプリケーションのためのファイルをダウンロードすることで、自身の端末においてアプリケーションをインストールおよび実行することができる。また、ゲームパブリッシャのような多様なゲームアプリケーションを利用者に配布する場合も存在する。すなわち、自身が直接開発したものでない多様なアプリケーションを開発者が登録し、登録されたアプリケーションを利用者に配布するアプリケーションパブリッシャが存在する。

このとき、アプリケーションの危険性は、多様な観点から説明することができる。

一例として、アプリケーションの１つ目の危険性として、アプリケーションが悪性コードのように悪意的な意図で開発された情報を含むことにより、アプリケーションが登録されるアプリケーションパブリッシャやアプリケーションがインストールおよび実行される利用者の端末において悪意のある機能が実行される場合の危険性が挙げられる。特許文献１（韓国公開特許第１０−２０１４−００９８０２５号公報）は、アプリストアにアップロードされたアプリケーションの保安評価のためのシステムおよびその方法に関するものであって、アプリストアに登録されたアプリケーションが悪意のある機能を実行するものと探知された場合、該当のアプリケーションの進入（アプリストアへの登録）を拒絶する技術について開示している。

他の例として、アプリケーションの２つ目の危険性として、アプリケーション自体の保安性に対する危険性が挙げられる。配布されたアプリケーションに対する分析によってアプリケーションのソースコードが変更または修正されることにより、開発者が本来意図した機能ではない他の機能をアプリケーションが実行するようになることで、該当のアプリケーションが提供しようとしていたサービスの信頼度が低下するという問題が存在する。したがって、アプリケーションパブリッシャは、自身が直接開発したものでない多様なアプリケーション（アプリケーションのインストールファイル）を配布するにあたり、アプリケーションに対して一定水準以上の保安性を提供する必要がある。

しかし、上述したような２つ目の危険性に関し、登録されるアプリケーションごとに提供する保安水準には差がある。例えば、各アプリケーションには、互いに異なる保安水準の保安ソリューションが搭載されており、中には保安手段が一切含まれていないものもある。さらに、各アプリケーションに搭載された保安ソリューションごとに提供する保安水準にも差がある。

従来技術では、単にプログラミング言語水準（一例として、アンドロイドアプリケーションパッケージ（Ａｎｄｒｏｉｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｃｋａｇｅ：ＡＰＫ））に対してジャバ（ｊａｖａ（登録商標））側の脆弱点を点検することしかできておらず、アプリケーションパブリッシャの観点では、登録される幾多のアプリケーションそれぞれの保安性を一定水準以上に保つことは難しいという問題を抱えている。

韓国公開特許第１０−２０１４−００９８０２５号公報

アプリケーションの脆弱点（ｖｕｌｎｅｒａｂｉｌｉｔｙ）を診断するための探知パターンを予め設定し、設定された探知パターンにより、配布のために登録されるアプリケーションのパッケージファイルの脆弱点を探知することができる、脆弱点探知方法およびシステムを提供する。

アプリケーションの脆弱点を探知する脆弱点探知方法であって、アプリケーションのインストールおよび実行のためのパッケージファイルが含むファイルと、前記ファイルが含むコードとのうちの少なくとも一方と関連し、前記アプリケーションの脆弱点診断のための予め設定された探知パターンを管理する段階、アプリケーションのインストールおよび実行のために利用者に配布するためのパッケージファイルを登録する段階、および前記探知パターンのうちの少なくとも１つの探知パターンによって前記登録されたパッケージファイルを分析し、前記少なくとも１つの探知パターン別に脆弱点情報を探知する段階を含む、脆弱点探知方法を提供する。

前記脆弱点探知方法をコンピュータに実行させるためのコンピュータプログラムが記録されている、コンピュータ読み取り可能な記録媒体を提供する。

コンピュータと結合して前記脆弱点探知方法をコンピュータに実行させるためにコンピュータ読み取り可能な記録媒体に記録される、コンピュータプログラムを提供する。

アプリケーションの脆弱点を探知する脆弱点探知システムであって、コンピュータ読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサは、アプリケーションのインストールおよび実行のためのパッケージファイルが含むファイルと、前記ファイルが含むコードのうちの少なくとも一方と関連し、前記アプリケーションの脆弱点診断のための予め設定された探知パターンを管理し、アプリケーションのインストールおよび実行のために利用者に配布するためのパッケージファイルを登録し、前記探知パターンのうちの少なくとも１つの探知パターンによって前記登録されたパッケージファイルを分析し、前記少なくとも１つの探知パターン別に脆弱点情報を探知する、脆弱点探知システムを提供する。

アプリケーションの脆弱点（ｖｕｌｎｅｒａｂｉｌｉｔｙ）を診断するための探知パターンを予め設定し、設定された探知パターンにより、配布のために登録されるアプリケーションのパッケージファイルの脆弱点を探知することができる。

本発明の一実施形態における、ネットワーク環境の例を示した図である。 本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。 本発明の一実施形態における、保安性評価システムのブロックダイヤグラムである。 本発明の一実施形態における、インストラクションマス間の呼び出し関係を説明するための図である。 本発明の一実施形態における、メソッド間の呼び出し関係を説明するための図である。 本発明の一実施形態における、ルールおよびパターンを説明するための図である。 本発明の一実施形態における、パターンの構造を説明するための図である。 本発明の一実施形態における、パターンのソースを説明するための図である。 本発明の一実施形態における、任意のファイルに対するパターンの例を示した図である。 本発明の一実施形態における、ファイルから特定の文字列を探知した結果とパッケージファイルから特定のファイルを探知した結果の例を示した図である。 本発明の一実施形態における、アンドロイドマニフェストファイルに対するパターンの例を示した図である。 本発明の一実施形態における、デックスファイルに対するパターンの例を示した図である。 本発明の一実施形態における、ｓｏファイルに対するパターンの例を示した図である。 本発明の一実施形態における、ｄｌｌファイルに対するパターンの例を示した図である。 本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の例を示したブロック図である。 本発明の一実施形態における、サーバが実行することのできる脆弱点探知方法の例を示したフローチャートである。

以下、実施形態について、添付の図面を参照しながら詳細に説明する。

本発明の実施形態に係る脆弱点探知システムは、以下で説明されるサーバによって実現されてよく、本発明の実施形態に係る脆弱点探知方法は、上述したサーバによって実行されてよい。例えば、サーバにおいては、本発明の一実施形態に係るコンピュータプログラムがインストールおよび実行されてよく、サーバは、実行されるコンピュータプログラムの制御に従って本発明の一実施形態に係る脆弱点探知方法を実行してよい。上述したコンピュータプログラムは、コンピュータで実現されるサーバと結合して脆弱点探知方法をコンピュータに実行させるためにコンピュータ読み取り可能な記録媒体に記録されてよい。

図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。

複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定端末や移動端末であってよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン、携帯電話、ナビゲーション、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）、ノート型ＰＣ、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ Ｍｕｌｔｉｍｅｄｉａ Ｐｌａｙｅｒ）、タブレットなどがある。一例として、図１では、電子機器１（１１０）の例としてスマートフォンを示しているが、本発明の実施形態において、電子機器１（１１０）は、実質的に無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信することのできる多様な物理的なコンピュータ装置のうちの１つを意味してよい。

通信方式が限定されることはなく、ネットワーク１７０が含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を利用する通信方式だけではなく、機器間の近距離無線通信が含まれてもよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ ａｒｅａ ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター−バスネットワーク、ツリーまたは階層的ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これらに限定されることはない。

サーバ１５０、１６０それぞれは、複数の電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供する１つ以上のコンピュータ装置によって実現されてよい。例えば、サーバ１５０は、ネットワーク１７０を介して接続した複数の電子機器１１０、１２０、１３０、１４０に第１サービスを提供するシステムであってよく、サーバ１６０も、ネットワーク１７０を介して接続した複数の電子機器１１０、１２０、１３０、１４０に第２サービスを提供するシステムであってよい。より具体的な例として、サーバ１５０は、アプリケーションパブリッシャのシステムを構成する装置のうちの少なくとも一部であってよく、複数の電子機器１１０、１２０、１３０、１４０においてインストールされて実行されるアプリケーションのパッケージファイルが登録されて配布するサービスを第１サービスとして提供してよい。他の例として、サーバ１６０は、配布されたパッケージファイルによってアプリケーションをインストールおよび実行する複数の電子機器１１０、１２０、１３０、１４０に、そのアプリケーションと関連するサービスを第２サービスとして提供してよい。実施形態によって、サーバ１５０は、登録されるパッケージファイルの脆弱点情報を探知するための専用システムを実現するために利用されてもよい。

図２は、本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。図２では、電子機器に対する例として電子機器１（１１０）の内部構成と、サーバ１５０の内部構成を説明する。また、他の電子機器１２０、１３０、１４０やサーバ１６０も、上述した電子機器１（１１０）またはサーバ１５０と同一あるいは類似の内部構成を備えてよい。

電子機器１（１１０）とサーバ１５０は、メモリ２１１、２２１、プロセッサ２１２、２２２、通信モジュール２１３、２２３、および入力／出力インタフェース２１４、２２４を含んでよい。メモリ２１１、２２１は、コンピュータ読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、およびディスクドライブのような永続的大容量記録装置を含んでよい。ここで、ＲＯＭやディスクドライブのような永続的大容量記録装置は、メモリ２１１、２２１とは区分される別の永続的記録装置として電子機器１（１１０）やサーバ１５０に含まれてもよい。また、メモリ２１１、２２１には、オペレーティングシステムと、少なくとも１つのプログラムコード（一例として、電子機器１（１１０）においてインストールされて実行されるブラウザや特定のサービスの提供のために電子機器１（１１０）にインストールされたアプリケーションなどのためのコード）が記録されてよい。このようなソフトウェア構成要素は、メモリ２１１、２２１とは別のコンピュータ読み取り可能な記録媒体からロードされてよい。このような別のコンピュータ読み取り可能な記録媒体は、フロッピードライブ、ディスク、テープ、ＤＶＤ／ＣＤ−ＲＯＭドライブ、メモリカードなどのコンピュータ読み取り可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータ読み取り可能な記録媒体ではない通信モジュール２１３、２２３を通じてメモリ２１１、２２１にロードされてもよい。例えば、少なくとも１つのプログラムは、開発者またはアプリケーションのインストールファイルを配布するファイル配布システム（一例として、上述したサーバ１６０）がネットワーク１７０を介して提供するファイルによってインストールされるコンピュータプログラム（一例として、上述したアプリケーション）に基づいてメモリ２１１、２２１にロードされてよい。

プロセッサ２１２、２２２は、基本的な算術、ロジック、および入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１１、２２１または通信モジュール２１３、２２３によって、プロセッサ２１２、２２２に提供されてよい。例えば、プロセッサ２１２、２２２は、メモリ２１１、２２１のような記録装置に記録されたプログラムコードに従って受信される命令を実行するように構成されてよい。

通信モジュール２１３、２２３は、ネットワーク１７０を介して電子機器１（１１０）とサーバ１５０が互いに通信するための機能を提供してもよいし、電子機器１（１１０）および／またはサーバ１５０が他の電子機器（一例として、電子機器２（１２０））または他のサーバ（一例として、サーバ１６０）と通信するための機能を提供してもよい。一例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１のような記録装置に記録されたプログラムコードに従って生成した要求が、通信モジュール２１３の制御に従ってネットワーク１７０を介してサーバ１５０に伝達されてよい。これとは逆に、サーバ１５０のプロセッサ２２２の制御に従って提供される制御信号や命令、コンテンツ、ファイルなどが、通信モジュール２２３とネットワーク１７０を経て電子機器１（１１０）の通信モジュール２１３を通じて電子機器１（１１０）に受信されてよい。例えば、通信モジュール２１３を通じて受信されたサーバの制御信号や命令、コンテンツ、ファイルなどは、プロセッサ２１２やメモリ２１１に伝達されてよく、コンテンツやファイルなどは、電子機器１（１１０）がさらに含むことのできる記録媒体（上述した永続的記録装置）に記録されてよい。

入力／出力インタフェース２１４は、入力／出力装置２１５とのインタフェースのための手段であってよい。例えば、入力装置は、キーボードまたはマウスなどの装置を、出力装置は、ディスプレイやスピーカなどのような装置を含んでよい。他の例として、入力／出力インタフェース２１４は、タッチスクリーンのように入力と出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。入力／出力装置２１５は、電子機器１（１１０）と１つの装置で構成されてもよい。また、サーバ１５０の入力／出力インタフェース２２４は、サーバ１５０と連結するか、サーバ１５０が含むことのできる入力または出力のための装置（図示せず）とのインタフェースのための手段であってよい。より具体的な例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１にロードされたコンピュータプログラムの命令を処理するにあたり、サーバ１５０や電子機器２（１２０）が提供するデータを利用して構成されるサービス画面やコンテンツが、入力／出力インタフェース２１４を経てディスプレイに表示されてよい。

また、他の実施形態において、電子機器１（１１０）およびサーバ１５０は、図２の構成要素よりも多くの構成要素を含んでもよい。しかし、大部分の従来技術的構成要素を明確に図に示す必要はない。例えば、電子機器１（１１０）は、上述した入力／出力装置２１５のうちの少なくとも一部を含むように実現されてもよいし、トランシーバ、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）モジュール、カメラ、各種センサ、データベースなどのような他の構成要素をさらに含んでもよい。より具体的な例として、電子機器１（１１０）がスマートフォンである場合、一般的にスマートフォンが含んでいる加速度センサやジャイロセンサ、カメラモジュール、物理的な各種ボタン、タッチパネルを利用したボタン、入力／出力ポート、振動のための振動器などのような多様な構成要素が電子機器１（１１０）にさらに含まれるように実現されてよい。

図３は、本発明の一実施形態における、保安性評価システムのブロックダイヤグラムである。図３の保安性評価システム３００は、上述したサーバ１５０によって実現されてよく、上述した脆弱点探知システムは、保安性評価システム３００に含まれるように実現されても、または保安性評価システム３００で脆弱点を探知するための構成だけを別に含むように実現されてもよい。

保安性評価システム３００が含むパッケージ分解モジュール３１０、ファイル識別モジュール３２０、パーシングモジュール３３０、分析モジュール３４０、およびレポートモジュール３５０は、サーバ１５０が含むプロセッサ２２２の互いに異なる機能（ｄｉｆｆｅｒｅｎｔ ｆｕｎｃｔｉｏｎｓ）の表現であってよい。例えば、サーバ１５０のプロセッサ２２２が、コンピュータプログラムが含む制御命令に従ってパッケージファイルを分解するプロセッサ２２２の機能として、パッケージ分解モジュール３１０が利用されてよい。このとき、分析モジュール３４０に含まれる脆弱点探知モジュール３４２が、脆弱点探知のための核心モジュールとして実現されてよい。

上述したように、サーバ１５０は、開発者が登録するアプリケーションのパッケージファイルを利用者に配布するサービスを提供する。

このとき、パッケージ分解モジュール３１０は、登録されたパッケージファイルを分解してよい。例えば、アンドロイドアプリケーションパッケージ（Ａｎｄｒｏｉｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｃｋａｇｅ：ＡＰＫ）は、モバイルオペレーティングシステムであるアンドロイドのソフトウェアと、ミドルウェア配布に使用されるパッケージファイルのファイルフォーマットとして「．ａｐｋ」拡張子を有する。以下の実施形態では、このようなＡＰＫのようなパッケージファイルを基盤として本発明の実施形態を説明するが、このような説明から、他の種類のパッケージファイルにも同一または類似の特徴が適用可能であることは、当業者であれば容易に理解できるであろう。

また、ＡＰＫは周知の事項であるため、ＡＰＫファイルまたはＡＰＫファイルが含むファイル自体に関する説明も、当業者であれば周知の従来技術から容易に理解できるはずであり、したがって、ＡＰＫファイルまたはＡＰＫファイルが含むファイル自体の詳しい説明については省略する。

ファイル識別モジュール３２０は、分解されたパッケージファイルに含まれるファイルを識別してよい。図３に示した拡張子（「ｄｅｘ」、「ｓｏ」、「ｄｌｌ」、「ｊｓｏｎ」、「ｉｎｉ」、「ａｐｋ」、「ｘｍｌ」、「ｃｅｒｔ」）は、上述したように、ＡＰＫと関連する従来技術から、当業者であれば容易に理解できるであろう。

パーシングモジュール３３０は、識別されたファイルをパースする。このために、パーサ３３１は、識別されたファイルのうち特定の拡張子（一例として、「ｄｅｘ」、「ｓｏ」、「ｄｌｌ」）のファイルをパースしてよく、コレクタ３３２は、特定の拡張子（一例として、「ｊｓｏｎ」、「ｉｎｉ」、「ａｐｋ」、「ｘｍｌ」、「ｃｅｒｔ」）のファイルから必要な情報を収集してよい。

例えば、パーシングモジュール３３０は、「ｄｅｘ」ファイルが含むクラス（ｃｌａｓｓ）とメソッド（ｍｅｔｈｏｄ）それぞれを識別してよく、メソッドが含むインストラクション（命令（ｉｎｓｔｒｕｃｔｉｏｎ））を追跡し、多数のマス（ｍａｓｓ）に区分して識別してよい。インストラクションのマスは、「ｇｏｔｏ」文や「ｓｗｉｔｃｈ」文、または「ｉｆ」文などのような分岐命令を基準として区分されてよい。また、パーシングモジュール３３０は、このようなインストラクションマス間の呼び出し関係に関する情報を生成して管理してよい。一例として、インストラクションマス間の呼び出し関係はツリー構造で管理されてよく、呼び出し関係に関する情報は、特定のインストラクションマスが呼び出すメソッドに関する情報を含んでよい。このような情報の生成および管理は、ＡＰＫファイルのようなパッケージファイルが含むファイルそれぞれに対して処理されてよく、ファイルの特性によってパーシング方式が異なってよい。

パースされた情報と収集された情報は、分析モジュール３４０に伝達されてよい。

分析モジュール３４０は、パーシングモジュール３３０から伝達される情報に基づき、該当のパッケージファイル（または、該当のパッケージファイルによって電子機器１（１１０）のような利用者端末においてインストールおよび実行されるアプリケーション）に対する難読化（ｏｂｆｕｓｃａｔｉｏｎ）観点、脆弱点（ｖｕｌｎｅｒａｂｉｌｉｔｙ）観点、および保安ソリューション観点での分析情報を生成および提供してよい。

例えば、難読化探知モジュール３４１は、特定の拡張子（一例として、「ｄｅｘ」、「ｓｏ」、「ｄｌｌ」）のファイルにどのくらいの水準の難読化が適用されているかに関する分析情報を生成してよい。このために、難読化探知モジュール３４１は、ファイルの種類によって予め設定される項目別に難読化が適用されているかを判断してよい。

また、脆弱点探知モジュール３４２は、特定の拡張子（一例として、「ｄｅｘ」、「ｓｏ」、または設定（ｃｏｎｆｉｇｕｒａｔｉｏｎ）ファイルの拡張子である「ｃｏｎｆｉｇ」）のファイルに、どのような脆弱点があるかに関する分析情報を生成してよい。このために、保安性評価システム３００は、既に知られた脆弱点に関する情報を管理してよく、脆弱点探知モジュール３４２は、このような脆弱点に関する情報を利用してどのようなファイルにどのような脆弱点が存在するかに関する分析情報を生成してよい。

また、プラットフォーム探知モジュール３４３は、該当のアプリケーションが開発されたプラットフォームおよび／または該当のアプリケーションが動作するプラットフォームに関する情報を抽出してよい。例えば、保安性評価システム３００は、該当のアプリケーションがどのようなプラットフォーム（一例として、ユニティ（Ｕｎｉｔｙ）やココス（Ｃｏｃｏｓ）のような開発ツール）で開発されたかに応じて互いに異なる分析方式を活用してよい。

または、保安性評価システム３００は、アプリケーションが動作するプラットフォームごとにパッケージファイルが含むファイルフォーマットが異なることがあるため、このようなプラットフォームごとに互いに異なる分析方式を活用してもよい。

このために、保安性評価システム３００は、パッケージファイルのプラットフォームに関する情報を抽出してよく、このような情報に基づいてパッケージファイルを分析するか、または抽出されたプラットフォームに関する情報を外部に提供してよい。

保安ツール探知モジュール３４４は、パッケージファイルの開発者が自主的にパッケージファイルに挿入した保安ソリューションを探知してよい。例えば、第三者によってライブラリ形態で提供される第１保安ツールが、開発者によって該当のパッケージファイルに追加されることがある。他の例として、開発者が自ら開発した第２保安ツールが、開発者によって該当のパッケージファイルに追加されることもある。言い換えれば、保安ツール探知モジュール３４４は、このような保安ツールのパッケージファイルが適用されているかに関する分析情報を生成してよい。

関係分析モジュール３４５は、パッケージファイルが含むファイル間の参照関係に関する分析情報を生成してよい。例えば、第１ファイルが第２ファイルを呼び出すためのコードを含んでいる場合、第１ファイルと第２ファイルとの参照関係に関する情報が分析情報に含まれるように分析情報が生成されてよい。

レポートモジュール３５０は、分析モジュール３４０で生成される分析情報を収集し、保安性評価システム３００の関係者（一例として、サーバ１５０の管理者またはアプリケーションパブリッシャの保安検査チーム）に提供するための報告書を生成してよい。このような報告書は、図３に示すように、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）やＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を利用して関係者の端末に提供されてよい。

図４は、本発明の一実施形態における、インストラクションマス間の呼び出し関係を説明するための図である。図４は、１つのメソッドＡ（Ｍｅｔｈｏｄ Ａ）４００に対し、ルートマス（Ｒｏｏｔ Ｍａｓｓ）４１０、インストラクションマス１（Ｉｎｓｔｒｕｃｔｉｏｎ Ｍａｓｓ １）４２０、インストラクションマス２（４３０）、インストラクションマス３（４４０）、およびインストラクションマス５（４５０）のような５つのインストラクションマスが識別された例を示している。上述したように、インストラクションマスは、分岐命令を基準として区分されてよく、インストラクションマスそれぞれをノードと仮定するとき、図４において、点線矢印は、特定のノードの親ノードを指している。例えば、図４は、インストラクションマス３（４４０）の親ノードがインストラクションマス１（４２０）であることを示している。ここで、子ノードは、親ノードが含む分岐命令に従って区分されるインストラクションのマスを含んでよい。ルートマス４１０は、メソッドＡ（４００）に対して最初に実行されるインストラクションのマスであってよい。

より具体的な例として、図４は、インストラクションマス１（４２０）が条件分岐（ｃｏｎｄｉｔｉｏｎａｌ ｂｒａｎｃｈ）４２１のための命令を含み、条件に従ってインストラクションマス３（４４０）またはインストラクションマス４（４５０）の命令が実行されると仮定する。このとき、インストラクションマス３（４４０）とインストラクションマス４（４５０）が識別され、インストラクションマス３（４４０）とインストラクションマス４（４５０）の親ノードは、インストラクションマス１（４２０）となる。また、条件分岐４２１のための命令に従い、インストラクションマス３（４４０）に移動される位置がラベル１（Ｌａｂｌｅ １）４４１によって、インストラクションマス４（４５０）に移動される位置がラベル２（Ｌａｂｌｅ２）４５１によって、それぞれ指示される。言い換えれば、インストラクションマス１（４２０）で呼び出しが探知されると、探知された呼び出しに従って呼び出されるインストラクションマス４４０、４５０は、ラベル４４１、４５１によって指示されるのである。図４では、実線によってこのような指示関係を示した。

図５は、本発明の一実施形態における、メソッド間の呼び出し関係を説明するための図である。図５は、呼び出し参照に関する情報５１０とメソッドａ５２０を示している。メソッドａ５２０は、少なくとも１つのインストラクションマスを含んでよく、図５では、１つのインストラクションマス５２１を示している。

このとき、図５では、インストラクションマス５２１でメソッドｂ５１１とメソッドｃ５１２に対する呼び出しが探知された例を示している。メソッドは、それぞれ固有のメソッドＩＤによって識別されてよい。本実施形態に係る脆弱点探知システムは、探知された呼び出しに従い、呼び出し参照に関する情報５１０からメソッドａ５２０のメソッドＩＤを利用してメソッドｂ５１１とメソッドｃ５１２に関する情報を取得してよい。

ここで、メソッドｂ５１１とメソッドｃ５１２に関する情報は、それぞれ、図４を参照しながら説明したように、呼び出されたメソッドｂ５１１とメソッドｃ５１２それぞれに対するインストラクションマスに関する情報、またはインストラクションマス間の参照関係に関する情報などを含んでよい。したがって、脆弱点探知システムは、該当のファイルによるプログラムの実行制御がどのような方法で動いているかの把握が可能となる。

図６は、本発明の一実施形態における、ルールおよびパターンを説明するための図である。図６は、本実施形態に係るルール（Ｒｕｌｅ）６００の構造の例を説明している。本実施形態において、ルール６００は、既に知られている脆弱点のうちのいずれか１つに対応し、該当の脆弱点を探知するための探知パターンに関する情報を含んでよい。

図６において、「名称（Ｎａｍｅ）」項目６１０は、該当のルール６００の名称を含んでよく、「説明（Ｄｅｓｃｒｉｐｔｉｏｎ）」項目６２０は、該当のルール６００に関する詳しい説明を含んでよい。例えば、該当のルール６００がどのような脆弱点に対するものかに関する説明情報を含んでよい。また、「ガイド（Ｇｕｉｄｅ）」項目６４０は、該当のルール６００の使用と関連する行動原理や指針に関する情報を含んでよい。

また、「優先順位（Ｐｒｉｏｒｉｔｙ）」項目６３０は、該当の脆弱点に対する危険性等級に関する情報を含んでよい。例えば、「クリティカル（Ｃｒｉｔｉｃａｌ）」、「ワーニング（Ｗａｒｎｉｎｇ）」、「ノーマル（Ｎｏｒｍａｌ）」のような３つの危険性等級のうちの１つの等級に対する値が「優先順位（ｐｒｉｏｒｉｔｙ）」項目６３０に含まれてよい。このような危険性等級は、２つの等級や４つ以上の等級でも設定可能であることが明らかである。

また、「依存性（Ｄｅｐｅｎｄｅｎｃｙ）」項目６５０は、脆弱階層の実際の脆弱性を動的に決定しなければならない条件が存在するかを示してよい。例えば、１つの脆弱点に対する危険性が条件に応じて異なる場合が存在する。例えば、脆弱点ａが、条件１では「クリティカル（Ｃｒｉｔｉｃａｌ）」な危険性等級を有するのに反し、条件２では「ノーマル（Ｎｏｒｍａｌ）」な危険性等級を有するか、または危険性がまったくない場合も存在する。したがって、このような条件別の差を区分するために、「依存性（Ｄｅｐｅｎｄｅｎｃｙ）」項目６５０は、条件に関する情報と条件別の危険性等級に関する情報を含んでよい。または、単に、このような条件が存在するかに関する情報だけを含んでもよい。

以上で説明したルール６００の項目は、実施形態によって選択的にルール６００に含まれて活用されてよい。

「パターン（Ｐａｔｔｅｒｎ）」項目６６０は、脆弱点探知のための１つ以上の探知パターンを含んでよい。探知パターンは予め設定されてよく、１つのルール６００は、脆弱点探知のための１つの探知パターンを含んでもよいし、２つ以上の探知パターンの組み合わせを含んでもよい。探知パターンは、少なくとも１つの命令で実現されてよく、少なくとも１つの命令それぞれは、パラメータを有するメソッドやクラスの形態で実現されてよい。パラメータは、予め設定されてもよいし、他のパターンによって抽出される値で動的に設定されてもよい。

図７は、本発明の一実施形態における、パターンの構造を説明するための図である。

ルールテーブル（ｒｕｌｅ＿ｔｂｌ）７１０は、設定されたルールに関する情報を含んでよい。「ｒｕｌｅ＿ｉｄ（ｐｋ）」は、設定されたルールのうちで主識別子（ｐｒｉｍａｒｙ ｋｅｙ、ｐｋ）に対応するルールを意味してよい。このような実際には「ｒｕｌｅ＿ｉｄ（ｐｋ）」は、主識別子ｐｋをパラメータとして受け、対応するルールの識別子を返還する関数を意味してよい。「ｎａｍｅ（ｋｅｙ）」は、キー（ｋｅｙ）に対応するルールの名称を意味してよい。このような「ｎａｍｅ（ｋｅｙ）」も、実際にはキー（ｋｅｙ）をパラメータとして受け、対応するルールの名称を返す関数を意味してよい。このように、図７において、「ｘ（ｙ）」は、「ｙ」が入力された関数「ｘ」を意味してよいが、「ｙ」に対応する「ｘ」を意味するものと説明する。「ｐａｔｔｅｒｎ＿ｈａｓｈ（ｆｋ）」は、外部識別子（ｆｏｒｅｉｇｎ ｋｅｙ、ｆｋ）に対応するパターンのハッシュ値を意味してよい。さらに、「説明（ｄｅｓｃｒｉｐｔｉｏｎ）」、「優先順位（ｐｒｉｏｒｉｔｙ）」、「ガイド（ｇｕｉｄｅ）」、「依存性（ｄｅｐｅｎｄｅｎｃｙ）」はそれぞれ、図６を参照しながら説明した「説明（Ｄｅｓｃｒｉｐｔｉｏｎ）」項目６２０、「優先順位（Ｐｒｉｏｒｉｔｙ）」項目６３０、「ガイド（Ｇｕｉｄｅ）」項目６４０、および「依存性（Ｄｅｐｅｎｄｅｎｃｙ）」項目６５０に対応する値を意味してよい。「ｐａｔｔｅｒｎ＿ｈａｓｈ（ｋｅｙ）」は、キーに対応するパターンのハッシュ値を意味してよい。脆弱点探知システムは、ルールテーブル７１０を利用して必要なルールに関する情報を得てよく、得られたルールに含まれるパターンの識別子としてパターンのハッシュ値を取得してよい。

パターンテーブル（ｐａｔｔｅｒｎ＿ｔｂｌ）７２０は、設定されたパターンに関する情報を含んでよい。「ｐａｔｔｅｒｎ＿ｉｄ（ｐｋ）」は主識別子（ｐｒｉｍａｒｙ ｋｅｙ、ｐｋ）に対応するパターンを、「ｒｕｌｅ＿ｉｄ（ｐｋ）」は外部識別子（ｆｏｒｅｉｇｎ ｋｅｙ、ｆｋ）に対応するルールを、それぞれ意味してよい。また、「ソース（ｓｏｕｒｃｅ）」は、パターンのソースに関する情報を意味してよい。例えば、パターンのソースは、ＡＰＫのようなパッケージファイルで探索されるファイルの種類を示してよい。「テーブルタイプ（ｔａｂｌｅ＿ｔｙｐｅ）」は返されるパターンのタイプに関する情報を、「ジョインパターン（ｊｏｉｎ＿ｐａｔｔｅｒｎ）」は該当のパターンと結合して１つのルールを構成する他のパターンに関する情報を、「ｊｏｉｎ＿ｔｙｐｅ（ａｎｄ／ｏｒ／ｓｕｂ）」はパターンがどのようなタイプで結合されるかに関する情報を、それぞれ意味してよい。ここで、「ａｎｄ」、「ｏｒ」、および「ｓｕｂ」は、以下で表１９を参照しながら説明するように、パターンの組み合わせのための論理演算子を意味してよい。脆弱点探知システムは、ルールテーブル７１０から得られるルールに関する情報に基づいて該当のルールが含むパターンを識別してよく、パターンテーブル７２０から該当のルールが含むパターンに関する情報を得てよい。

デックスファイルテーブル（ｐａｔｔｅｒｎ＿ｄａｔａ＿ｄｅｘ＿ｆｉｎｄ＿ａｐｉ）７３０は、ＡＰＫのデックスファイルから抽出される情報を含んでよい。「ｐａｔｔｅｒｎ＿ｉｄ（ｆｋ）」は、設定されたパターンのうちで外部識別子（ｆｏｒｅｉｇｎ ｋｅｙ：ｆｋ）に対応するパターンを意味してよい。「呼び出されたクラス名（ｃａｌｌｅｄ＿ｃｌａｓｓ＿ｎａｍｅ）」は呼び出しされるクラス名を識別するための値を、「呼び出されたメソッド名（ｃａｌｌｅｄ＿ｍｅｔｈｏｄ＿ｎａｍｅ）」は呼び出しされるメソッド名を識別するための値を、それぞれ意味してよい。「ｅｎａｂｌｅ＿ｔｒａｃｉｎｇ＿ａｒｇｕｍｅｎｔ（ｏｐｔｉｏｎａｌ）」は追跡可能な引数（ａｒｇｕｍｅｎｔ）を返す関数を、「ａｒｇｕｍｅｎｔ＿ｉｎｄｅｘ（ｏｐｔｉｏｎａｌ）」は引数のインデックスを返す関数を、「引数タイプ（ａｒｇｕｍｅｎｔ＿ｔｙｐｅ）」は返される引数のタイプを、それぞれ意味してよい。「ａｒｇｕｍｅｎｔ＿ｆｒｏｍ＿ｎｕｌｌ＿ｄｅｔｅｃｔ（ｔｒｕｅ／ｆａｌｓｅ）」はヌル（ｎｕｌｌ）引数を探知するか否かを、「ａｒｇｕｍｅｎｔ＿ｆｒｏｍ＿ｎｕｌｌ＿ｅｘｃｅｐｔ（ｔｒｕｅ／ｆａｌｓｅ）」はヌル（ｎｕｌｌ）引数を例外にするか否かを、それぞれ意味してよい。また、デックスファイルテーブル７３０は、探知されたＡＰＩリストからの引数（ａｒｇｕｍｅｎｔ＿ｆｒｏｍ＿ｄｅｔｅｃｔ＿ａｐｉ＿ｌｉｓｔ）、例外処理されたＡＰＩリストからの引数（ａｒｇｕｍｅｎｔ＿ｆｒｏｍ＿ｅｘｃｅｐｔ＿ａｐｉ＿ｌｉｓｔ）、探知されたフィールドリストからの引数（ａｒｇｕｍｅｎｔ＿ｆｒｏｍ＿ｄｅｔｅｃｔ＿ｆｉｅｌｄ＿ｌｉｓｔ）、および例外処理されたリストからの引数（ａｒｇｕｍｅｎｔ＿ｆｒｏｍ＿ｅｘｃｅｐｔ＿ｌｉｓｔ）に関する情報を含んでよい。脆弱点探知システムは、パターンによって脆弱点探知に必要な情報を探知するにあたり、デックスファイルテーブル７３０を参照してよい。例えば、脆弱点探知システムは、特定のインストラクションマスに対する脆弱点を探知するにあたり、該当のインストラクションマスから呼び出すメソッドやクラスを、デックスファイルテーブル７３０を利用して識別してよい。

ファイルテーブル（ｐａｔｔｅｒｎ＿ｄａｔａ＿ｒｅｔｒｉｅｖｅ＿ｆｉｌｅ＿ｔｂｌ）７４０は、パッケージファイルが含む特定のファイルの情報を抽出するパターン情報を含んでよい。「ｐａｔｔｅｒｎ＿ｉｄ（ｆｋ）」は、設定されたパターンのうちで外部識別子（ｆｏｒｅｉｇｎ ｋｅｙ、ｆｋ）に対応するパターンを意味してよく、「ｐａｔｔｅｒｎ＿ｈａｓｈ（ｋｅｙ）」は、キーに対応するパターンのハッシュ値を意味してよい。「ファイルタイプ（ｆｉｌｅ＿ｔｙｐｅ）」はパターンによって検索されるファイルのタイプを、「ファイル拡張子（ｆｉｌｅ＿ｅｘｔｅｎｓｉｏｎ）」はパターンによって検索されるファイルの拡張子を、「ファイル名（ｆｉｌｅ＿ｎａｍｅ）」はパターンによって検索されるファイル名を、それぞれ意味してよい。

コンテンツテーブル（ｐａｔｔｅｒｎ＿ｄａｔａ＿ｒｅｔｒｉｅｖｅ＿ｆｉｌｅ＿ｃｏｎｔｅｎｔｓ＿ｔｂｌ）７５０は、ファイルに含まれる文字を抽出するパターン情報を含んでよい。「ｐａｔｔｅｒｎ＿ｉｄ（ｆｋ）」は、設定されたパターンのうちで外部識別子（ｆｏｒｅｉｇｎ ｋｅｙ、ｆｋ）に対応するパターンを意味してよく、「ｐａｔｔｅｒｎ＿ｈａｓｈ（ｋｅｙ）」は、キーに対応するパターンのハッシュ値を意味してよい。「ファイルタイプ（ｆｉｌｅ＿ｔｙｐｅ）」はパターンによって検索されるファイルのタイプを、「文字タイプ（ｃｈａｒａｃｔｅｒ＿ｔｙｐｅ）」は文字（または文字列）のタイプを、「文字（ｃｈａｒａｃｔｅｒ）」はファイルで検索しようとする文字（または文字列）を、それぞれ意味してよい。

パーミッションテーブル（ｐａｔｔｅｒｎ＿ｄａｔａ＿ｒｅｔｒｉｅｖｅ＿ｐｅｒｍｉｓｓｉｏｎ＿ｔｂｌ）７６０は、パッケージファイルのパーミッション（ｐｅｒｍｉｓｓｉｏｎ）情報を抽出するパターン情報を含んでよい。「ｐａｔｔｅｒｎ＿ｉｄ（ｆｋ）」は、設定されたパターンのうちで外部識別子（ｆｏｒｅｉｇｎ ｋｅｙ、ｆｋ）に対応するパターンを意味してよく、「名称（ｎａｍｅ）」は、パーミッションの名称を意味してよい。

アクティビティテーブル（ｐａｔｔｅｒｎ＿ｄａｔａ＿ｒｅｔｒｉｅｖｅ＿ａｃｔｉｖｉｔｙ＿ｔｂｌ）７７０は、アクティビティ情報を抽出するパターン情報を含んでよい。「ｐａｔｔｅｒｎ＿ｉｄ（ｆｋ）」は、設定されたパターンのうちで外部識別子（ｆｏｒｅｉｇｎ ｋｅｙ、ｆｋ）に対応するパターンを意味してよく、「名称（ｎａｍｅ）」は、アクティビティの名称を意味してよい。ここで、アクティビティとは、ユーザインタフェースがある１つの画面を意味するものであって、一例として、ＡＰＫからアクティビティクラス（ａｃｔｉｖｉｔｙ ｃｌａｓｓ）を継承して実現されてよい。このように、上述したアクティビティやパーミッションなどの用語は、当業者であれば、ＡＰＫに対する従来の技術から容易に理解できるであろう。

ＳＤＫテーブル（ｐａｔｔｅｒｎ＿ｄａｔａ＿ｒｅｔｒｉｅｖｅ＿ｍｉｎ＿ｓｄｋ）７８０は、ＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）に関する情報を抽出するパターン情報を含んでよい。「ｐａｔｔｅｒｎ＿ｉｄ（ｆｋ）」は、設定されたパターンのうちで外部識別子（ｆｏｒｅｉｇｎ ｋｅｙ、ｆｋ）に対応するパターンを意味してよく、「バージョン（ｖｅｒｓｉｏｎ）」はＳＤＫのバージョン情報を、「バージョン探知条件（ｃｏｎｄｉｔｉｏｎａｌ＿ｅｑｕａｌｉｔｙ）」はバージョンの探知条件を、それぞれ意味してよい。例えば、「バージョン（ｖｅｒｓｉｏｎ）」が「２１」に設定され、「バージョン探知条件（ｃｏｎｄｉｔｉｏｎａｌ＿ｅｑｕａｌｉｔｙ）」が「小さいか同じ」である場合、バージョンが２１以下の場合に該当のＳＤＫのバージョンが探知されてよい。

図８は、本発明の一実施形態における、パターンのソースを説明するための図である。ルール６００が含むパターン６６０のソースは、ＡＰＫのようなパッケージファイルの特定のファイルであってよい。図８では、パターン６６０が、パッケージファイルが含む任意のファイル（Ａｎｙ ｆｉｌｅｓ）８１０、デックスファイル（ｄｅｘ）８２０、アンドロイドマニフェストファイル（ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌ）８３０、ｓｏファイル（ｓｏ）８４０、またはｄｌｌファイル（ｄｌｌ）８５０をソースとして有することを示している。

図９は、本発明の一実施形態における、任意のファイルに対するパターンの例を示した図である。図９は、任意のファイル８１０に対するパターン９００の種類を示している。

第１種類９１０のパターンは、ファイルから特定の文字（または文字列）を探索するパターンを意味してよく、以下のパターン１のように表現されてよい。
［パターン１］
RetrieveFileContents:
: FileType(string) CharacterType(string) Character(string)
例えば、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）ファイルからＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を探索するパターンは、「ＲｅｔｒｉｅｖｅＦｉｌｅＣｏｎｔｅｎｔｓ：ＦｉｌｅＴｙｐｅ（ｊｓｏｎ）ＣｈａｒａｃｔｅｒＴｙｐｅ（ｓｔｒｉｎｇ）Ｃｈａｒａｃｔｅｒ（ｈｔｔｐ：／／＊）」のように実現されてよい。言い換えれば、上述したパターンの例は、ファイルに含まれるコンテンツを検索するパターンであって、「ｊｓｏｎ」タイプのファイルから「ｓｔｒｉｎｇ」タイプの文字列として「ｈｔｔｐ：／／＊」を探索しろという命令を意味してよい。このようなパターン「ＲｅｔｒｉｅｖｅＦｉｌｅＣｏｎｔｅｎｔｓ」において、ファイルタイプ「ＦｉｌｅＴｙｐｅ（）」のパラメータは、「ａｌｌ」、「ａｐｋ」、「ｔｘｔ」、「ｉｎｉ」、「ｐｒｏｐｅｒｔｙ」、「ｊｓｏｎ」、「ｘｍｌ」、「ｉｍｇ」、「ｍｐ４」などのようなファイル拡張子に基づいて予め設定された値のうちで予め設定されてもよいし、動的に設定されてもよい。ここで、ファイルタイプ「ａｌｌ」は、すべての拡張子のファイルを意味してよい。また、キャラクタタイプ「ＣｈａｒａｃｔｅｒＴｙｐｅ（）」のパラメータは、「ｓｔｒｉｎｇ」、「ｈｅｘａ」などのように文字や文字列の種類を意味してよい。「Ｃｈａｒａｃｔｅｒ（）」のパラメータは、検索しようとする文字列を意味してよく、＊は、＊よりも前の文字列から始まるすべての文字列を意味してよい。

第２種類９２０のパターンは、パッケージファイル内から特定のファイルを探索するパターンを意味してよく、以下のパターン２のように表現されてよい。
［パターン２］
RetrieveFile:
: FileType(string) FileName(string)
例えば、パッケージファイルが含むファイルのうちから、ＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋｉｎｇ Ｌｉｂｒａｒｙ）タイプを有してファイル名が「Ａｓｓｅｍｂｌｙ−Ｃｓｈａｒｐ」であるファイルを探索するパターンは、「ＲｅｔｒｉｅｖｅＦｉｌｅ：ＦｉｌｅＴｙｐｅ（ｓｔｒｉｎｇ）ＦｉｌｅＮａｍｅ（Ａｓｓｅｍｂｌｙ−Ｃｓｈａｒｐ）」のように実現されてよい。他の例として、パッケージファイルが含むファイルのうちからＤＬＬタイプのファイルを探索するパターンは、「ＲｅｔｒｉｅｖｅＦｉｌｅ：ＦｉｌｅＴｙｐｅ（ｓｔｒｉｎｇ）」のように実現されてよい。

ファイルタイプ「ＦｉｌｅＴｙｐｅ（）」のパラメータは、「ａｌｌ」、「ａｐｋ」、「ｔｘｔ」、「ｉｎｉ」、「ｐｒｏｐｅｒｔｙ」、「ｊｓｏｎ」、「ｘｍｌ」、「ｉｍｇ」、「ｍｐ４」などのようなファイル拡張子に基づいて設定された値のうちで予め設定されてもよいし、動的に設定されてもよい。ファイル名「ＦｉｌｅＮａｍｅ（）」のパラメータも、予め設定されてもよいし、動的に設定されてもよい。必要に応じて、ファイル拡張子を基準としてファイルを探索するための「ＦｉｌｅＥｘｔｅｎｓｉｏｎ（）」がさらに利用されてもよく、「ＦｉｌｅＥｘｔｅｎｓｉｏｎ（）」のパラメータも、予め設定されてもよいし、動的に設定されてもよい。

図１０は、本発明の一実施形態における、ファイルから特定の文字列を探知した結果とパッケージファイルから特定のファイルを探知した結果の例を示した図である。

探知された情報１０１０は、第１種類９１０のパターンによって探知されたファイル名（Ｆｉｌｅ ｎａｍｅ）１０１１とマッチングストリング（Ｍａｔｃｈ ｓｔｒｉｎｇ）１０１２を含むことを示している。上述した図９において、「ｊｓｏｎ」タイプのファイルが３つ存在する場合、３つのファイルそれぞれで「ｓｔｒｉｎｇ」タイプの文字列として「ｈｔｔｐ：／／＊」が探索されてよく、探知された文字列がファイル名別に提供されてよい。１つの「ｊｓｏｎ」ファイルが複数のＵＲＬを含む場合、複数の文字列が探知されてよい。

また、探知された情報１０２０は、第２種類９２０のパターンによってパッケージファイルから探知されたファイル名（Ｆｉｌｅ ｎａｍｅ）１０２１を含むことを示している。この場合にも、パターンによって複数のファイル名が探索されてよい。

図１１は、本発明の一実施形態における、アンドロイドマニフェストファイルに対するパターンの例を示した図である。図１１は、アンドロイドマニフェストファイル（ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌ）８３０に対するパターン１１００の種類を示している。

第３種類１１１０のパターンは、アンドロイドマニフェストファイル８３０からパーミッション（ｐｅｒｍｉｓｓｉｏｎ）グループを探索するパターンを意味してよく、以下のパターン３のように表現されてよい。
［パターン３］
RetrievePermission:
: Name(string or *)
例えば、パターン「ＲｅｔｒｉｅｖｅＰｅｒｍｉｓｓｉｏｎ：Ｎａｍｅ（＊）」に対する探知結果として「ａｎｄｒｏｉｄ．ｐｅｒｍｉｓｓｉｏｎ．ＧＥＴ＿ＴＡＳＫＳ」および「ａｎｄｒｏｉｄ．ｐｅｒｍｉｓｓｉｏｎ．ＩＮＴＥＲＮＥＴ」のようなパーミッションが提供されてよい。他の例として、パターン「ＲｅｔｒｉｅｖｅＰｅｒｍｉｓｓｉｏｎ：Ｎａｍｅ（ａｎｄｒｏｉｄ．ｐｅｒｍｉｓｓｉｏｎ．ＲＥＡＤ＿ＥＸＴＥＲＮＡＬ＿ＳＴＯＲＡＧＥ）」のように、特定のパーミッション名によって該当の名称のパーミッションが検索されてもよい。特定のパーミッションと関連する脆弱点が分かっていれば、該当のパーミッションが存在するかを探索するためのパターンが予め設定されてよく、設定されたパターンに基づいて脆弱点探知が実行されてよい。以下で説明するパターンでも、共通するファクタは共通する役割を含んでよい。

第４種類１１２０のパターンは、アンドロイドマニフェストファイル８３０からアクティビティ（ａｃｔｉｖｉｔｙ）グループを探索するパターンを意味してよく、以下のパターン４のように表現されてよい。
［パターン４］
RetrieveActivity:
: Name(string or *)

第５種類１１３０のパターンは、アンドロイドマニフェストファイル８３０から最小ＳＤＫ ＡＰＩバージョンを探索するパターンを意味してよく、以下のパターン５のように表現されてよい。
［パターン５］
RetrieveMinSDK:
: Version(string or *)
: ConditionalEquality
バージョン「Ｖｅｒｓｉｏｎ（）」のパラメータは、所望するバージョンの値がストリングタイプとして動的に設定されるか、またはすべてのバージョンを意味する「＊」が活用されてよい。また、比較条件を意味する「ＣｏｎｄｉｔｉｏｎａｌＥｑｕａｌｉｔｙ」は、等号や不等号を利用し、バージョン「Ｖｅｒｓｉｏｎ（）」で設定された値とアンドロイドマニフェストファイルに設定されたＳＤＫ ＡＰＩバージョンとの比較のために活用されてよい。例えば、「ＲｅｔｒｉｅｖｅＭｉｎＳＤＫ：Ｖｅｒｓｉｏｎ（２１）ＣｏｎｄｉｔｉｏｎａｌＥｑｕａｌｉｔｙ（＜＝）」は、バージョン２１以下の場合を探知するパターンを意味してよい。

第６種類１１４０のパターンは、アンドロイドマニフェストファイル８３０からターゲットＳＤＫ ＡＰＩバージョンを探索するパターンを意味してよく、以下のパターン６のように表現されてよい。
［パターン６］
RetrieveTargetSDK:
: Version(string or *)
: ConditionalEquality
バージョン「Ｖｅｒｓｉｏｎ（）」と比較条件を意味する「ＣｏｎｄｉｔｉｏｎａｌＥｑｕａｌｉｔｙ」は、パターン６と共通されてよい。

第７種類１１５０のパターンは、アンドロイドマニフェストファイル８３０からメインアプリケーション（ｍａｉｎ ａｐｐｌｉｃａｔｉｏｎ）を探索するパターンを意味してよく、以下のパターン７のように表現されてよい。
［パターン７］
RetrieveMainApplication:
: Name(string or *)

第８種類１１６０のパターンは、アンドロイドマニフェストファイル８３０からサービスグループを探索するパターンを意味してよく、以下のパターン８のように表現されてよい。
［パターン８］
RetrieveService:
: Name(string or *)

第９種類１１７０のパターンは、アンドロイドマニフェストファイル８３０からレシーバグループを探索するパターンを意味してよく、以下のパターン９のように表現されてよい。
［パターン９］
RetrieveReceiver:
: Name(string or *)

第１０種類１１８０のパターンは、アンドロイドマニフェストファイル８３０からプロバイダグループを探索するパターンを意味してよく、以下のパターン１０のように表現されてよい。
［パターン１０］
RetrieveProvider:
: Name(string or *)

アンドロイドマニフェストファイル８３０から探索されるパーミッション、アクティビティ、最小ＳＤＫ ＡＰＩバージョン、ターゲットＳＤＫ ＡＰＩバージョン、メインアプリケーション、サービス、レシーバ、プロバイダは、当業者であれば、ＡＰＫに対する周知の従来技術から容易に理解できるであろう。

図１２は、本発明の一実施形態における、デックスファイルに対するパターンの例を示した図である。図１２は、デックスファイル（ｄｅｘ）８２０に対するパターン１２００の種類を示している。

第１１種類１２１０のパターンは、呼び出されたＡＰＩを探索するパターンを意味してよく、以下のパターン１１のように表現されてよい。
［パターン１１］
DexFindApi:
: DexCalledAPI (require)
: ClassName, MethodName
: DexTraceArgument (optional)
: ArgumentIndex(number)
: ArgumentType(string)
: DexArgumentFrom (optional)
: Exceptional(true/false)
: FromNull
: List: FromAPIList
:ClassName, MethodName
: List: FromFieldList
:ClassName, MethodName
ここで、「ＤｅｘＦｉｎｄＡｐｉ」は、呼び出されたＡＰＩを探索するパターンのパターン名を意味してよい。また、「ＤｅｘＣａｌｌｅｄＡＰＩ」は、特定クラスの特定メソッドを指定するためのファクタを意味してよい。このようなクラスとメソッドは、「ＣｌａｓｓＮａｍｅ」および「ＭｅｔｈｏｄＮａｍｅ」によって指定されてよい。また、「ＤｅｘＴｒａｃｅＡｒｇｕｍｅｎｔ」は、特定インデックスおよび／または特定タイプの引数（ａｒｇｕｍｅｎｔ）を指定するためのファクタを意味してよい。さらに、「ＤｅｘＡｒｇｕｍｅｎｔＦｒｏｍ」は、例外処理の可否を決定したり、ヌル（ｎｕｌｌ）からの引数を探知したり、または特定ＡＰＩリストやフィールドリストを指定したりするためのファクタを意味してよい。

以下の表１はインストラクションマスの第１例を、表２はパターンの第１例を、それぞれ示している。

表２のパターンは、クラス「Ｌｉａｖａｘ／ｎｅｔ／ｓｓｌ／ＳＳＬＣｏｎｔｅｘｔ」のメソッド「ｉｎｉｔ」を呼び出すＡＰＩを探索するパターンを意味してよい。この場合、脆弱点探知システムは、該当のパターンに基づき、表１のインストラクションマスからクラス「ｃｆｉｎｄＭｅ」のメソッド「ｍｆｉｎｄＭｅ」が該当のメソッド「ｉｎｉｔ」を呼び出すことを探知してよく、探知結果として「ｃａｌｌｅｄ ｆｒｏｍ ｃｆｉｎｄＭｅ−＞ｍｆｉｎｄＭｅ」のようなメッセージを提供してよい。

以下の表３はインストラクションマスの第２例を、表４はパターンの第２例を、それぞれ示している。

表４のパターンは、クラス「Ｌｉａｖａｘ／ｎｅｔ／ｓｓｌ／ＳＳＬＣｏｎｔｅｘｔ」のメソッド「ｉｎｉｔ」を呼び出すＡＰＩを探索してメソッド「ｉｎｉｔ」のインデックス「２」のタイプ「Ｌｊａｖａｘ／ｎｅｔ／ｓｓｌ／ＴｒｕｓｔＭａｎａｇｅｒ」の引数を追跡するが、ここで、ＡｐｉＬｉｓｔに指定されたクラス「Ｌｊａｖａｘ／ｎｅｔ／ｓｓｌ／ＴｒｕｓｔＭａｎａｇｅｒＦａｃｔｏｒｙ」とメソッド「ｇｅｔＴｒｕｓｔＭａｎａｇｅｒｓ」に対しては例外（ｔｒｕｅ）として扱うパターンを意味してよい。

表３を詳しく見ると、クラス「Ｌｉａｖａｘ／ｎｅｔ／ｓｓｌ／ＳＳＬＣｏｎｔｅｘｔ」のメソッド「ｉｎｉｔ」を呼び出すＡＰＩは、クラス「ｃｆｉｎｄＭｅ」のメソッド「ｍｆｉｎｄＭｅ」であり、メソッド「ｉｎｉｔ」のインデックス「２」のタイプ「Ｌｊａｖａｘ／ｎｅｔ／ｓｓｌ／ＴｒｕｓｔＭａｎａｇｅｒ」の引数が「ｔｍ」であることが分かる。しかし、クラス「Ｌｊａｖａｘ／ｎｅｔ／ｓｓｌ／ＴｒｕｓｔＭａｎａｇｅｒＦａｃｔｏｒｙ」のメソッド「ｇｅｔＴｒｕｓｔＭａｎａｇｅｒｓ」に対しては例外処理をするため、引数「ｔｍ」やクラス「ｃｆｉｎｄＭｅ」のメソッド「ｍｆｉｎｄＭｅ」は、探知されずに例外処理されてよい。

以下の表５はインストラクションマスの第３例を、表６はパターンの第３例を、それぞれ示している。

表６のパターンは、クラス「Ｌｉａｖａｘ／ｎｅｔ／ｓｓｌ／ＳＳＬＣｏｎｔｅｘｔ」のメソッド「ｉｎｉｔ」を呼び出すＡＰＩを探索してメソッド「ｉｎｉｔ」のインデックス「２」の引数を追跡するが、ここで、ヌル（ｎｕｌｌ）からの引数であるかを探索するパターンを意味してよい。

表５のインストラクションマスを詳しく見ると、クラス「Ｌｉａｖａｘ／ｎｅｔ／ｓｓｌ／ＳＳＬＣｏｎｔｅｘｔ」のメソッド「ｉｎｉｔ」を呼び出すＡＰＩは、クラス「ｃｆｉｎｄＭｅ」のメソッド「ｍｆｉｎｄＭｅ」であり、メソッド「ｉｎｉｔ」のインデックス「２」の引数がヌル（ｎｕｌｌ）であることが分かる。したがって、「ＤｅｘＣａｌｌｅｄＡＰＩ」によってクラス「ｃｆｉｎｄＭｅ」のメソッド「ｍｆｉｎｄＭｅ」が該当のメソッド「ｉｎｉｔ」を呼び出すことを探知することができ、「ＤｅｘＴｒａｃｅＡｒｇｕｍｅｎｔ」および「ＤｅｘＡｒｇｕｍｅｎｔＦｒｏｍ」によってヌル（ｎｕｌｌ）からの引数がメソッド「ｉｎｉｔ」のインデックス２に存在することを探知することができる。このとき、探知結果として「ｃａｌｌｅｄ ｆｒｏｍ ｃｆｉｎｄＭｅ−＞ｍｆｉｎｄＭｅ」メッセージおよび「ａｒｇｕｍｅｎｔ ｆｒｏｍ ｎｕｌｌ」メッセージが提供されてよい。

以下の表７はインストラクションマスの第４例を、表８はパターンの第４例を、それぞれ示している。

表８のパターンは、クラス「Ｓｙｓｔｅｍ」のメソッド「ｌｏａｄＬｉｂｒａｒｙ」を呼び出すＡＰＩを探索してメソッド「ｌｏａｄＬｉｂｒａｒｙ」のインデックス「１」の引数を追跡するパターンを意味してよい。

表７のインストラクションマスによると、クラス「Ｓｙｓｔｅｍ」のメソッド「ｌｏａｄＬｉｂｒａｒｙ」を呼び出すＡＰＩは、クラス「Ｃ」のメソッド「ｍ」であることが分かる。このとき、メソッド「ｌｏａｄＬｉｂｒａｒｙ」のインデックス「１」の引数は「ｓｔｒ」であり、引数「ｓｔｒ」はメソッド「ｍ」を呼び出すクラス「Ａ」のメソッド「ｉｎｉｔ」において「ｘｘｘ」であり、クラス「Ｃ」のメソッド「ｍ」において「ｘｘ」が「ａｐｐｅｎｄ」されることが分かる。このような引数「ｓｔｒ」に対する追跡は、上述したように、予め生成および管理されるメソッド間の呼び出し関係を利用してなされてよい。

このとき、パターンに対する探知結果は、以下の表９のメッセージのように提供されてよい。

「ｃａｌｌｅｄ ｆｒｏｍ Ｃ−＞ｍ」は、クラス「Ｓｙｓｔｅｍ」のメソッド「ｌｏａｄＬｉｂｒａｒｙ」を呼び出すＡＰＩがクラスＣのメソッドｍであることを示してよい。「ａｒｇｕｍｅｎｔ ｓｔｒ ｉｓ ｓｔｒｉｎｇ」は、引数「ｓｔｒ」のタイプが「ｓｔｒｉｎｇ」であることを示してよい。また、「ｓｔｒ＋＝“ｘｘ”」は、表７のメソッド「ｓｔｒ．ａｐｐｅｎｄ（“ｘｘ”）；」によって引数「ｓｔｒ」に「ｘｘ」が加えられることを意味してよい。さらに、ｓｔｒ＝ｉｎｐｕｔ（ｐａｒａｍｅｔｅｒ）は、引数「ｓｔｒ」がパラメータ「ｉｎｐｕｔ」として伝達されたことを意味してよく、「Ｐａｒａｍｅｔｅｒ ｉｓ“ｘｘｘ”ｉｎ Ａ−＞ｉｎｉｔ」伝達されたパラメータ「ｉｎｐｕｔ」は、クラス「Ａ」のメソッド「ｉｎｉｔ」において「ｘｘｘ」であることを意味してよい。したがって、クラス「Ｓｙｓｔｅｍ」のメソッド「ｌｏａｄＬｉｂｒａｒｙ」のインデックス「１」の引数である「ｓｔｒ」は現在、「ｓｔｒｉｎｇ」タイプの値「ｘｘｘｘｘ」を有することが分かる。

以下の表１０はインストラクションマスの第５例を、表１１はパターンの第５例を、それぞれ示している。

表１１のパターンは、クラス「Ｌｉａｖａｘ／ｎｅｔ／ｓｓｌ／ＳＳＬＣｏｎｔｅｘｔ」のメソッド「ｉｎｉｔ」を呼び出すＡＰＩを探索してメソッド「ｉｎｉｔ」のインデックス「２」の引数を追跡するが、このとき、「ＦｒｏｍＦｉｅｌｄＬｉｓｔ」によって指定されるフィールドに対しては例外処理をしないパターンを意味してよい。

表１０のインストラクションマスによってクラス「Ｌｉａｖａｘ／ｎｅｔ／ｓｓｌ／ＳＳＬＣｏｎｔｅｘｔ」のメソッド「ｉｎｉｔ」を呼び出すＡＰＩがクラス「ｃｆｉｎｄＭｅ」のメソッド「ｍｆｉｎｄＭｅ」であることが分かり、メソッド「ｉｎｉｔ」のインデックス「２」の引数が「ｔｍ」であることが分かる。

このとき、クラス「Ｌｏｒｇ／ａｐａｃｈｅ／ｈｔｔｐ／ｃｏｎｎ／ｓｓｌ／ＳＳＬＳｏｃｋｅｔＦａｃｔｏｒｙ」のフィールド「ＡＬＬＯＷ＿ＡＬＬ＿ＨＯＳＴＮＡＭＥ＿ＶＥＲＩＦＩＥＲ」は例外処理をしないため、クラス「Ｌｉａｖａｘ／ｎｅｔ／ｓｓｌ／ＳＳＬＣｏｎｔｅｘｔ」のメソッド「ｉｎｉｔ」を呼び出すＡＰＩがクラス「ｃｆｉｎｄＭｅ」のメソッド「ｍｆｉｎｄＭｅ」であることを知らせるためのメッセージ（一例として、「ｃａｌｌｅｄ ｆｒｏｍ ｃｆｉｎｄＭｅ−＞ｍｆｉｎｄＭｅ」）が探知結果として提供されてよく、メソッド「ｉｎｉｔ」のインデックス「２」の引数「ｔｍ」がフィールド「ＳＳＬＳｏｃｋｅｔＦａｃｔｏｒｙ．ＡＬＬＯＷ＿ＡＬＬ＿ＨＯＳＴＮＡＭＥ＿ＶＥＲＩＦＩＥＲ」からの引数であることを知らせるためのメッセージ（一例として、「ａｒｇｕｍｅｎｔ ｆｒｏｍ ＳＳＬＳｏｃｋｅｔＦａｃｔｏｒｙ．ＡＬＬＯＷ＿ＡＬＬ＿ＨＯＳＴＮＡＭＥ＿ＶＥＲＩＦＩＥＲ」）が探知結果としてさらに提供されてよい。

図１２を再び参照すると、第１２種類１２２０のパターンは、メソッドの特定インストラクションを探索するパターンを意味してよく、以下のパターン１２のように表現されてよい。
［パターン１２］
DexMethodBody :
: MethodName (require)
: MethodName
: DexInstructionList (require)
: List<DexInstruction>
: Except(true/false)
: DexInstruction
: VoidBody
: InvokeInstruction
: ClassName(string)
: MethodName(string)
ここで、「ＤｅｘＭｅｔｈｏｄＢｏｄｙ」は、特定のメソッド内で特定のインストラクションを探索するためのパターンであることを意味してよい。また、「ＭｅｔｈｏｄＮａｍｅ」は、メソッドを指定するためのファクタを意味してよい。また、「ＤｅｘＩｎｓｔｒｕｃｔｉｏｎＬｉｓｔ」は、探知するためのインストラクションを特定するためのファクタを意味してよい。例えば、「Ｌｉｓｔ＜ＤｅｘＩｎｓｔｒｕｃｔｉｏｎ＞」は、探知するためのインストラクションを指定するために利用されてよく、「Ｅｘｃｅｐｔ（ｔｒｕｅ／ｆａｌｓｅ）」は、指定されたインストラクションを例外処理するかを決定するために利用されてよい。さらに、「ＶｏｉｄＢｏｄｙ」は、ｖｏｉｄタイプのインストラクションを指定するために利用されてよく、「ＩｎｖｏｋｅＩｎｓｔｒｕｃｔｉｏｎ」は、呼び出しされるインストラクションを指定するために利用されてよい。

以下の表１２はインストラクションマスの第６例を、表１３はパターンの第６例を、それぞれ示している。

表１３のパターンは、メソッド「ｃｈｅｃｋＳｅｒｖｅｒＴｒｕｓｔｅｄ」がｖｏｉｄタイプであるか否かを確認するパターンを意味してよい。表１２のインストラクションマスにおいて、メソッド「ｃｈｅｃｋＳｅｒｖｅｒＴｒｕｓｔｅｄ」はｖｏｉｄタイプとして宣言されているため、メソッド「ｃｈｅｃｋＳｅｒｖｅｒＴｒｕｓｔｅｄ」がｖｏｉｄタイプであることを知らせるためのメッセージ（一例として、「Ｂｏｄｙ ｉｓ ｖｏｉｄ」）が提供されてよい。

以下の表１４はインストラクションマスの第７例を、表１５はパターンの第７例を、それぞれ示している。

表１５のパターンは、メソッド「ｃｈｅｃｋＳｅｒｖｅｒＴｒｕｓｔｅｄ」からメソッド「Ｌｊａｖａ／ｓｅｃｕｒｉｔｙ／ｃｅｒｔ／ＣｅｒｔｉｆｉｃａｔｅＥｘｃｅｐｔｉｏｎ」を呼び出すインストラクションとメソッド「Ｌｊａｖａ／ｌａｎｇ／ＩｌｌｅｇａｌＡｒｇｕｍｅｎｔＥｘｃｅｐｔｉｏｎ」を呼び出すインストラクションを探索するパターンを意味してよい。表１４のインストラクションマスと関連し、メソッド「Ｌｊａｖａ／ｓｅｃｕｒｉｔｙ／ｃｅｒｔ／ＣｅｒｔｉｆｉｃａｔｅＥｘｃｅｐｔｉｏｎ」を呼び出すインストラクションが存在することが分かる。したがって、メソッド「Ｌｊａｖａ／ｓｅｃｕｒｉｔｙ／ｃｅｒｔ／ＣｅｒｔｉｆｉｃａｔｅＥｘｃｅｐｔｉｏｎ」を呼び出すインストラクションが探知されたことを知らせるためのメッセージ（一例として、「Ｉｎｖｏｋｅ ｉｎｓｔｒｕｃｔｉｏｎ ｉｓｄｅｔｅｃｔｅｄ、ＣｅｒｔｉｆｉｃａｔｅＥｘｃｅｐｔｉｏｎ−＞＜ｉｎｉｔ＞」）が提供されてよい。

上記で簡単に説明したように、パターンは結合（ｊｏｉｎ）されてよい。例えば、パターン「ＤｅｘＦｉｎｄＡｐｉ」を利用して特定のクラス「ａ」を探索した後、パターン「ＤｅｘＭｅｔｈｏｄｙＢｏｄｙ」を利用してクラス「ａ」のメソッドから特定のインストラクションを探索してよい。例えば、１つのルールにこのような２つのパターンが結合されて含まれてよい。

図１２を再び参照すると、第１３種類１２３０のパターンは、特定のクラスの子クラスを探索するパターンを意味してよく、以下のパターン１３のように表現されてよい。
［パターン１３］
DexFindSubClass :
: DexParent (require)
: ClassName(string)
ここで、「ＤｅｘＦｉｎｄＳｕｂＣｌａｓｓ」は、特定のクラスの子クラスを探索するパターン名を意味してよい。「ＤｅｘＰａｒｅｎｔ」は、探索しようとする子クラスの親クラスを指定するためのファクタを意味してよい。

以下の表１６はインストラクションマスの第８例を、表１７はパターンの第８例を、それぞれ示している。

表１７は、クラス「ＩａｍＹｏｕｒＦａｔｈｅｒ」を親にもつ子クラスを探索するためのパターンを意味してよい。表１６のインストラクションマスと関連し、クラス「ｃｆｉｎｄＭｅ」とクラス「ｃｓｅａｒｃｈＭｅ」はそれぞれ、クラス「ＩａｍＹｏｕｒＦａｔｈｅｒ」の子ノードであるため、クラス「ｃｆｉｎｄＭｅ」とクラス「ｃｓｅａｒｃｈＭｅ」がそれぞれ探知されてよく、探知されたクラス「ｃｆｉｎｄＭｅ」とクラス「ｃｓｅａｒｃｈＭｅ」を知らせるためのメッセージが提供されてよい。

パターン間の結合（ｊｏｉｎ）は、より多様に活用されてよい。例えば、パターン「ＤｅｘＦｉｎｄＳｕｂＣｌａｓｓ」を利用してクラス「ａ」を親にもつ子クラス「ｂ」を探索した後、探知されたクラス「ｂ」をパターン「ＤｅｘＦｉｎｄＡｐｉ」における「ＣｌａｓｓＮａｍｅ（ｂ）」のように動的パラメータとして活用してよい。

図１３は、本発明の一実施形態において、ｓｏファイルに対するパターンの例を示した図である。図１３は、ｓｏファイル８４０に対するパターン１３００の種類を示している。

第１４種類１３１０のパターンは、ｓｏファイル８４０からストリング（特定の文字列）を検索するパターンを意味してよく、以下のパターン１４のように表現されてよい。
［パターン１４］
RetrieveSoContents :
: Character(string)
ここで、パターン「ＲｅｔｒｉｅｖｅＳｏＣｏｎｔｅｎｔｓ」は、ｓｏファイル８４０からストリングを検索するパターン名を意味してよく、「Ｃｈａｒａｃｔｅｒ（ｓｔｒｉｎｇ）」は、ｓｏファイル８４０から検索しようとする特定のストリング（一例として、「ｈｔｔｐ：／／＊」のような文字列）を指定するためのファクタを意味してよい。このとき、ストリングは、ｓｏファイル８４０が含む「．ｒｄａｔａ」セクションから検索されてよい。

第１５種類１３２０のパターンは、ｓｏファイル８４０からＡＰＩを検索するパターンを意味してよく、以下のパターン１５のように表現されてよい。
［パターン１５］
RetrieveApiContents :
: APIType(iat) Name(strcpy)
ここで、パターン「ＲｅｔｒｉｅｖｅＡｐｉＣｏｎｔｅｎｔｓ」は、ｓｏファイル８４０からＡＰＩを検索するパターン名を意味してよく、「ＡＰＩＴｙｐｅ（）」は、ＡＰＩのタイプをＩＡＴ（Ｉｍｐｏｒｔ Ａｄｄｒｅｓｓ Ｔａｂｌｅ）とＥＡＴ（Ｅｘｐｏｒｔ Ａｄｄｒｅｓｓ Ｔａｂｌｅ）のうちの１つに設定するためのファクタを、「Ｎａｍｅ（）」は、検索しようとするＡＰＩの名称を指定するためのファクタを、それぞれ意味してよい。

図１４は、本発明の一実施形態における、ｄｌｌファイルに対するパターンの例を示した図である。図１４は、ｄｌｌファイル８５０に対するパターン１４００の種類を示している。

第１６種類１４１０のパターンは、ｄｌｌファイル８５０からストリング（特定の文字列）を検索するためのパターンを意味してよく、以下のパターン１６のように表現されてよい。
［パターン１６］
RetrieveDllContents :
: Character(string)
ここで、パターン「ＲｅｔｒｉｅｖｅＤｌｌＣｏｎｔｅｎｔｓ」は、ｄｌｌファイル８５０からストリングを検索するパターン名を意味してよく、「Ｃｈａｒａｃｔｅｒ（ｓｔｒｉｎｇ）」は、ｄｌｌファイル８５０から検索しようとする特定のストリング（一例として、「ｈｔｔｐ：／／＊」のような文字列）を指定するためのファクタを意味してよい。

パターンにおいて、パラメータは、上述したように動的に決定されてよい。例えば、パターンａとパターンｂとの結合により、パターンａによって抽出される値がパターンｂのためのパラメータとして動的に活用されてよい。

上述したパターン１〜１６は、ＡＰＫのための一実施形態であって、他のパッケージファイルのためには他のパターンが活用されてよい。脆弱点探知システムは、このようなパターンを登録するか、登録されたパターンを編集することのできるエディタ機能を管理者や利用者に提供してよい。例えば、アプリケーションに対する新たな脆弱点が分かった場合、新たに分かった脆弱点を探知できるようにエディタ機能を利用して新たなパターンが登録されてよく、脆弱点探知システムは、新たなパターンに基づいてアプリケーションのパッケージファイルを分析して脆弱点を探知してよい。

さらに他の実施形態において、パターンの種類は、以下の表１８のように示されてよい。

表１８のパターンのうち、パターン「ｄｅｘ（ｆｉｎｄ＿ａｐｉ）」は、上述したパターン１１「ＤｅｘＦｉｎｄＡｐｉ」に対応してよい。このようなパターン「ｄｅｘ（ｆｉｎｄ＿ａｐｉ）」は、メソッド内で指定されたａｐｉの呼び出しを探知するためのパターンであってよい。

また、パターン「ｄｅｘ（ｆｉｎｄ＿ｓｕｂ）」は、上述したパターン１３「ＤｅｘＦｉｎｄＳｕｂＣｌａｓｓ」に対応してよく、指定されたクラスの相続を受けて実現した子クラスを探知するために利用されてよい。

また、パターン「ｄｅｘ（ｍｅｔｈｏｄ＿ｂｏｄｙ）」は、上述したパターン１２「ＤｅｘＭｅｔｈｏｄＢｏｄｙ」に対応してよく、ａｐｔｊｅｍ内のインボークインストラクション（ｉｎｖｏｋｅ ｉｎｓｔｒｕｃｔｉｏｎ）、インストラクションの個数、メソッド名などを比較および探知するために利用されてよい。

また、パターン「ｄｅｘ（ｍｅｔｈｏｄ＿ａｎｎｏｔａｔｉｏｎ）」は、Ｊａｖａでメソッドに指定された注釈（ａｎｎｏｔａｔｉｏｎ）を探知するために利用されてよい。

また、パターン「ｄｅｘ（ｅｘｉｓｔ＿ａｐｉ）」は、特定のクラスおよび／またはメソッドが存在するかを探索するために利用されてよい。例えば、以下で説明する論理演算を利用したパターンの組み合わせを利用する場合、パターン組み合わせ（ｄｅｘ（ｅｘｉｓｔ＿ａｐｉ）ｓｕｂ ｄｅｘ（ｆｉｎｄ＿ａｐｉ））は、左側パターンである「ｄｅｘ（ｅｘｉｓｔ＿ａｐｉ）」によって探索されたクラスを対象に、右側パターンである「ｄｅｘ（ｆｉｎｄ＿ａｐｉ）」によって指定されたａｐｉ呼び出しを探索してよい。

また、パターン「ｄｅｘ（ｅｘｉｓｔ＿ｆｉｅｌｄ）」は、特定のクラスのメンバーが存在するかを探索するために利用されてよい。例えば、パターン「ｄｅｘ（ｅｘｉｓｔ＿ｆｉｅｌｄ）」は、「クラス−＞メンバー名」のような形態の値を該当のメンバーの値と比べる正規表現式を指定することにより、指定された正規表現式に該当するメンバーが探索されてよい。

また、パターン「ｍａｎｉｆｅｓｔ」は、ＡｎｄｒｏｉｄＭａｎｉｆｅｓｔ．ｘｍｌの項目との比較のために利用されてよい。

さらに、パターン「ｘｍｌ」、「ｓｏ」、「ｄｌｌ」、「ｆｉｎｄ＿ｆｉｌｅ」はそれぞれ、ｘｍｌファイル、ｓｏファイル、ｄｌｌファイル、およびすべてのファイルで探索を実行するために利用されてよい。例えば、ｄｌｌファイルで探索を実行する例については、パターン１６（ＲｅｔｒｉｅｖｅＤｌｌＣｏｎｔｅｎｔｓ）を参照しながら詳しく説明したとおりである。

また、パターンは、論理演算と括弧を利用して組み合わされて活用されてもよい。例えば、以下の表１９は、パターンの組み合わせのために活用可能な論理演算の例を示している。

例えば、（パターンＡ ｏｒ パターンＢ）でパターンＡが探知されると、既に「ｔｒｕｅ」であるため、パターンＢに対する探知は実行されないことがある。また、（パターンＡ ｓｕｂ パターンＢ）でパターンＡが「ｆａｌｓｅ」であれば、パターンＢに対する探知は実行されないことがある。このような論理演算を利用したパターンの組み合わせに対するより具体的な例として、パターン組み合わせ（ｄｅｘ（ｆｉｎｄ＿ｓｕｂ＿ｃｌａｓｓ）ｓｕｂ ｄｅｘ（ｆｉｎｄ＿ａｐｉ））が挙げられる。該当のパターン組み合わせでは、左側のパターン「ｄｅｘ（ｆｉｎｄ＿ｓｕｂ＿ｃｌａｓｓ）」によってすべてのアクティビティの子を探索するようになり、左側のパターンによって探索されたクラスが、右側パターンのためのクラスに利用されてよい。言い換えれば、右側パターン「ｄｅｘ（ｆｉｎｄ＿ａｐｉ）」は、左側パターンによって探索されたクラスでａｐｉを探索するようになる。

図１５は、本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の例を示したブロック図であり、図１６は、本発明の一実施形態における、サーバが実行することのできる脆弱点探知方法の例を示したフローチャートである。

本発明の実施形態に係る脆弱点探知システムは、上述したサーバ１５０のようなコンピュータ装置の形態で実現されてよい。また、図１５に示すように、サーバ１５０のプロセッサ２２２は、脆弱点探知システムを実現するための構成要素として、探知パターン管理部１５１０、パッケージファイル登録部１５２０、および脆弱点情報探知部１５３０を含んでよい。このようなプロセッサ２２２およびプロセッサ２２２の構成要素は、図１６の脆弱点探知方法が含む段階１６１０〜段階１６３０を実行してよい。このとき、プロセッサ２２２およびプロセッサ２２２の構成要素は、メモリ２２１が含むオペレーティングシステムのコードと、少なくとも１つのプログラムのコードとによる制御命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行するように実現されてよい。ここで、プロセッサ２２２の構成要素は、サーバ１５０に記録されたコードが提供する制御命令に従ってプロセッサ２２２によって実行される、プロセッサ２２２の互いに異なる機能（ｄｉｆｆｅｒｅｎｔ ｆｕｎｃｔｉｏｎｓ）の表現であってよい。例えば、プロセッサ２２２が上述した制御命令に従って探知パターンを管理するプロセッサ２２２の機能的表現として、探知パターン管理部１５１０が使用されてよい。

段階１６１０において、探知パターン管理部１５１０は、アプリケーションのインストールおよび実行のためのパッケージファイルに含まれるファイルと、ファイルに含まれるコードのうちの少なくとも一方に関連し、アプリケーションの脆弱点診断のための予め設定された探知パターンを管理してよい。探知パターンについては、詳しい実施形態を参照しながら上述したとおりであり、脆弱点によってさらに多様な実施形態が導き出されてもよいことは、当業者であれば、上述した実施形態から容易に理解できるであろう。

このとき、探知パターン管理部１５１０は、段階１６１０で新たな探知パターンを登録するか、または登録された探知パターンを編集するためのエディタ機能を提供し、提供されたエディタ機能を利用して登録または編集された探知パターンに関する情報を記録および管理してよい。エディタ機能は、一例として、特定のウェプページの形態や特定のアプリケーションの形態で脆弱点探知システムの管理者や利用者に提供されてよい。例えば、管理者の端末にインストールされる特定のアプリケーションによって管理者の端末と脆弱点探知システムとが通信してよく、特定のアプリケーションで登録または編集される探知パターンに対する情報は、ネットワークを介して脆弱点探知システムに送信されてよい。このとき、探知パターン管理部１５１０は、新たな探知パターンを登録するか、または編集された探知パターンを更新してよい。

上述した実施形態では、パターンが含むファクタのパラメータが予め設定されてもよいが、必要に応じて動的に決定されてもよいことを説明したし、パラメータが動的に決定可能であることにより、さらに多様な方式で探知パターンが実現されることについて説明した。

段階１６２０において、パッケージファイル登録部１５２０は、アプリケーションのインストールおよび実行のために利用者に配布するためのパッケージファイルを登録してよい。サーバ１５０は、上述したように、脆弱点探知システムが含まれる形態で実現されてよい。例えば、アプリケーションパブリッシャのシステムと脆弱点探知システムとが結合された形態でサーバ１５０が実現されてよい。このとき、パッケージファイルは、アプリケーションパブリッシャが利用者に配布するために開発者側から提供を受けて登録されてよい。

このとき、登録されるパッケージファイルにおいてそれぞれのファイルが識別されてよく、クラスとメソッドが識別されてよい。また、メソッドそれぞれは、分岐命令（分岐文）を基準としてインストラクションマスの形態で区分されてよく、インストラクションマス間の呼び出し関係および／またはメソッド間の呼び出し関係は、ツリー構造のようなデータ構造の形態で記録および管理されてよい。このような呼び出し関係に関する情報は、引数（ａｒｇｕｍｅｎｔ）の追跡や呼び出されたＡＰＩなどを検索するために活用されてよい。

段階１６３０において、脆弱点情報探知部１５３０は、探知パターンのうちの少なくとも１つの探知パターンによって登録されたパッケージファイルを分析し、少なくとも１つの探知パターン別に脆弱点情報を探知してよい。このような脆弱点情報の探知については、多様な実施形態を参照しながら詳しく上述したとおりである。このとき、脆弱点情報探知部１５３０は、複数の探知パターンを結合（ｊｏｉｎ）し、第１探知パターンによって登録されたパッケージファイルから探知された第１情報を、第２探知パターンが含むファクタのパラメータとして動的に設定し、探知された第１情報がパラメータとして設定されたファクタを含む第２探知パターンによって登録されたパッケージファイルから脆弱点情報を探知してよい。

探知パターンは、登録されたパッケージファイルが含むファイルのうちの少なくとも１つのファイルから特定の文字列を検索するパターンを含んでよい。例えば、上述したパターン１、パターン１４、およびパターン１６は、ファイルから特定の文字列（またはストリング）を検索するパターンについて説明している。特に、パターン１は、登録されたパッケージファイルが含むファイルのうちで特定のタイプのファイルを指定するためのファクタを含むことを説明した。

また、探知パターンは、登録されたパッケージファイルが含むファイルのうちで特定のタイプのファイルおよび特定のファイル名のファイルのうちの少なくとも１つを検索するためのパターンを含んでよい。例えば、上述したパターン２は、指定されたタイプのファイルおよび／または指定されたファイル名のファイルを検索するためのパターンについて説明している。

また、探知パターンは、ＡＰＫ（Ａｎｄｒｏｉｄ ａｐｐｌｉｃａｔｉｏｎ ｐａｃｋａｇｅ）が含むアンドロイドマニフェストファイルからパーミッション（ｐｅｒｍｉｓｓｉｏｎ）を検索するためのパターン、アクティビティ（ａｃｔｉｖｉｔｙ）を検索するためのパターン、ＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）バージョンを検索するためのパターン、メインアプリケーション（ｍａｉｎ ａｐｐｌｉｃａｔｉｏｎ）を検索するためのパターン、サービスを検索するためのパターン、レシーバ（ｒｅｃｅｉｖｅｒ）を検索するためのパターン、およびプロバイダ（ｐｒｏｖｉｄｅｒ）を検索するためのパターンのうちの少なくとも１つのパターンを含んでよい。このようなパターンは、パターン３〜１０を参照しながら詳しく説明したとおりである。

また、探知パターンは、指定されたクラスと指定されたメソッドのうちの少なくとも一方から呼び出されたＡＰＩを検索するパターンを含んでよい。このとき、呼び出されたＡＰＩを検索するためのパターンは、クラスとメソッドのうちの少なくとも一方を指定するファクタ、指定されたメソッドの引数（ａｒｇｕｍｅｎｔ）を追跡するために前記引数のインデックスとタイプのうちの少なくとも一方を指定するファクタ、および指定されたメソッドの引数に対して指定されたＡＰＩ、指定されたフィールド、およびヌル（ｎｕｌｌ）のうちの少なくとも１つから伝達された引数を探知するためにＡＰＩ、フィールドおよびヌル（ｎｕｌｌ）のうちの少なくとも１つを指定するファクタのうちの少なくとも１つのファクタを含んでよい。このようなパターンについては、パターン１１を参照しながら詳しく説明したとおりである。

また、探知パターンは、指定されたメソッドから指定されたインストラクションを検索するパターンを含んでよい。このとき、特定のインストラクションを検索するためのパターンは、検索するインストラクションを指定するファクタ、検索するインストラクションのタイプを指定するファクタ、および検索するインストラクションが呼び出すクラスとメソッドを指定するファクタのうちの少なくとも１つのファクタを含んでよい。このようなパターンについては、パターン１２を参照しながら詳しく説明したとおりである。

また、探知パターンは、指定されたクラスの子クラスを検索するパターンおよび／または登録されたパッケージファイルが含むファイルのうちの少なくとも１つのファイルからＡＰＩを検索するパターンを含んでよい。このようなパターンについては、パターン１３およびパターン１５を参照しながら詳しく説明したとおりである。

以上のように、本発明の実施形態によると、アプリケーションの脆弱点（ｖｕｌｎｅｒａｂｉｌｉｔｙ）を診断するための探知パターンを予め設定し、設定された探知パターンに基づき、配布のために登録されるアプリケーションのパッケージファイルの脆弱点を探知することができる。

上述したシステムまたは装置は、ハードウェア構成要素、ソフトウェア構成要素、またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを記録、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。

ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置、コンピュータ記録媒体または装置に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で記録されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータ読み取り可能な記録媒体に記録されてよい。

実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータ読み取り可能な媒体に記録されてよい。コンピュータ読み取り可能な媒体は、プログラム命令、データファイル、データ構造などを単独でまたは組み合わせて含んでよい。媒体に記録されるプログラム命令は、実施形態のために特別に設計されたものであっても、コンピュータソフトウェアの当業者に公知されて使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例には、ハードディスク、フロッピーディスク、および磁気テープのような磁気媒体、ＣＤ−ＲＯＭおよびＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどのような、プログラム命令を記録して実行するように特別に構成されたハードウェア装置が含まれる。このような記録媒体は、単一または複数のハードウェアが結合された状態の多様な記録手段または格納手段であってよく、あるコンピュータシステムに直接に接続される媒体に限定されることはなく、ネットワーク上に分散存在するものであってもよい。プログラム命令の例には、コンパイラによって生成されるもののような機械語コードだけではなく、インタプリタなどを使用してコンピュータによって実行される高級言語コードを含む。

以上のように、実施形態を、限定された実施形態および図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。

したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。

Claims (19)

1. アプリケーションの脆弱点を探知する脆弱点探知方法であって、
   アプリケーションのインストールおよび実行のためのパッケージファイルが含むファイルと、前記ファイルが含むコードとのうちの少なくとも一方と関連し、前記アプリケーションの脆弱点診断のための予め設定された探知パターンを管理する段階、
   アプリケーションのインストールおよび実行のために利用者に配布するためのパッケージファイルを登録する段階、および
   前記探知パターンのうちの少なくとも１つの探知パターンによって前記登録されたパッケージファイルを分析し、前記少なくとも１つの探知パターン別に脆弱点情報を探知する段階
   を含む、脆弱点探知方法。
2. 前記予め設定された探知パターンを管理する段階は、
   新たな探知パターンを登録するか、登録された探知パターンを編集するためのエディタ機能を提供し、前記提供されたエディタ機能を利用して登録または編集された探知パターンに関する情報を記録および管理する、
   請求項１に記載の脆弱点探知方法。
3. 前記少なくとも１つの探知パターン別に脆弱点情報を探知する段階は、
   複数の探知パターンを結合し、第１探知パターンによって前記登録されたパッケージファイルから探知された第１情報を、第２探知パターンが含むファクタのパラメータとして動的に設定し、前記探知された第１情報がパラメータとして設定されたファクタを含む前記第２探知パターンにより、前記登録されたパッケージファイルから脆弱点情報を探知する、
   請求項１に記載の脆弱点探知方法。
4. 前記探知パターンは、前記登録されたパッケージファイルが含むファイルのうちの少なくとも１つのファイルから特定の文字列を検索するパターンを含む、
   請求項１に記載の脆弱点探知方法。
5. 前記特定の文字列を検索するためのパターンは、前記登録されたパッケージファイルが含むファイルのうちで特定のタイプのファイルを指定するためのファクタを含む、
   請求項４に記載の脆弱点探知方法。
6. 前記探知パターンは、前記登録されたパッケージファイルが含むファイルのうちで指定されたタイプのファイルと、指定されたファイル名のファイルのうちの少なくとも一方を検索するためのパターンを含む、
   請求項１に記載の脆弱点探知方法。
7. 前記探知パターンは、ＡＰＫ（Ａｎｄｒｏｉｄ（登録商標） ａｐｐｌｉｃａｔｉｏｎ ｐａｃｋａｇｅ）が含むアンドロイド（登録商標）マニフェストファイルからパーミッションを検索するためのパターン、アクティビティを検索するためのパターン、ＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）バージョンを検索するためのパターン、メインアプリケーションを検索するためのパターン、サービスを検索するためのパターン、レシーバを検索するためのパターン、およびプロバイダを検索するためのパターンのうちの少なくとも１つのパターンを含む、
   請求項１に記載の脆弱点探知方法。
8. 前記探知パターンは、指定されたクラスと、指定されたメソッドのうちの少なくとも一方で呼び出されたＡＰＩを検索するパターンを含む、
   請求項１に記載の脆弱点探知方法。
9. 前記呼び出されたＡＰＩを検索するためのパターンは、クラスとメソッドのうちの少なくとも一方を指定するファクタを含む、
   請求項８に記載の脆弱点探知方法。
10. 前記呼び出されたＡＰＩを検索するためのパターンは、前記指定されたメソッドの引数を追跡するために前記引数のインデックスおよびタイプのうちの少なくとも１つを指定するファクタを含む、
    請求項８に記載の脆弱点探知方法。
11. 前記呼び出されたＡＰＩを検索するためのパターンは、前記指定されたメソッドの引数に対して指定されたＡＰＩ、指定されたフィールド、およびヌルうちの少なくとも１つから伝達された引数を探知するために、ＡＰＩ、フィールドおよびヌルのうちの少なくとも１つを指定するファクタを含む、
    請求項８に記載の脆弱点探知方法。
12. 前記探知パターンは、指定されたメソッドから指定されたインストラクションを検索するパターンを含む、
    請求項１に記載の脆弱点探知方法。
13. 前記指定されたインストラクションを検索するためのパターンは、検索するインストラクションを指定するファクタ、検索するインストラクションのタイプを指定するファクタ、および検索するインストラクションが呼び出すクラスとメソッドを指定するファクタのうちの少なくとも１つのファクタを含む、
    請求項１２に記載の脆弱点探知方法。
14. 前記探知パターンは、指定されたクラスの子クラスを検索するパターンを含む、請求項１に記載の脆弱点探知方法。
15. 前記探知パターンは、前記登録されたパッケージファイルが含むファイルのうちの少なくとも１つのファイルからＡＰＩを検索するパターンを含む、
    請求項１に記載の脆弱点探知方法。
16. 請求項１〜１５のうちのいずれか一項に記載の方法をコンピュータに実行させるためのコンピュータプログラムが記録されている、コンピュータ読み取り可能な記録媒体。
17. アプリケーションの脆弱点を探知する脆弱点探知システムであって、
    コンピュータで読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサ
    を含み、
    前記少なくとも１つのプロセッサは、
    アプリケーションのインストールおよび実行のためのパッケージファイルが含むファイルと、前記ファイルが含むコードのうちの少なくとも一方と関連し、前記アプリケーションの脆弱点診断のための予め設定された探知パターンを管理し、
    アプリケーションのインストールおよび実行のために利用者に配布するためのパッケージファイルを登録し、
    前記探知パターンのうちの少なくとも１つの探知パターンによって前記登録されたパッケージファイルを分析し、前記少なくとも１つの探知パターン別に脆弱点情報を探知する、
    脆弱点探知システム。
18. 前記少なくとも１つのプロセッサは、前記予め設定された探知パターンを管理するために、
    新たな探知パターンを登録するか、登録された探知パターンを編集するためのエディタ機能を提供し、前記提供されたエディタ機能を利用して登録または編集された探知パターンに関する情報を記録および管理する、
    請求項１７に記載の脆弱点探知システム。
19. 前記少なくとも１つのプロセッサは、前記少なくとも１つの探知パターン別に脆弱点情報を探知するために、
    複数の探知パターンを結合し、第１探知パターンによって前記登録されたパッケージファイルから探知された第１情報を第２探知パターンが含むファクタのパラメータとして動的に設定し、前記探知された第１情報がパラメータとして設定されたファクタを含む前記第２探知パターンにより、前記登録されたパッケージファイルから脆弱点情報を探知する、
    請求項１７に記載の脆弱点探知システム。

Images